12 Commity (2eb8df347e76388112065514659500933cef14aa)

Autor	SHA1	Wiadomość	Data
Greyson Parrelli	0d0c74f358	Fix in-memory message updates. ... We can also switch to using the message-specific update route for receipts too.	2022-01-03 18:47:11 -05:00
Rashad Sookram	4ae129d2af	Use Gradle dependency verification. ... Generated by running: ./gradlew --write-verification-metadata sha256 qa --rerun-tasks	2021-12-16 14:48:25 -05:00
Greyson Parrelli	ef7d5d55cb	Protect against individual item updates being put into an invalidated list.	2021-11-22 10:40:06 -05:00
Greyson Parrelli	62ee60df82	Add full support for unknown fields in storage service.	2021-11-01 17:07:01 -04:00
Greyson Parrelli	0c8b6f8ef8	Add an observer to log blocked threads.	2021-10-08 15:18:52 -04:00
Alex Hart	b589449c34	Consolidate app dependencies using gradle version catalogs.	2021-09-16 14:17:38 -03:00
Greyson Parrelli	f5a6d61362	Add support for granular conversation data changes.	2021-09-02 21:24:53 -04:00
Greyson Parrelli	95978f16e9	Possible fix to getting thrown to the bottom while reading unreads. ... Shoutout to @fumiakiy for the excellent research here! Sometimes we get thrown to the bottom of the list (or other list locations) when reading content in the middle of the list. Most often, this happens when you have a lot of unread messages and you open the conversation. FixedSizePagingController#onDataNeededAroundIndex() can be called very fast in rapid succession, and we use the DataStatus class for bookkeeping to know which requests are in-flight. We then make those requests in LIFO order in order to make sure that the data visible on screen now gets the highest priority. ...But in practice, that LIFO ordering can make things a little screwy. Imagine we called onDataNeedAroundIndex() 50 times in rapid succession (1, 2..., 50). Each time it's called, we generate a range and mark that range as being fetched in DataStatus. That could mean that the latest request for index 50 might only have, like, 1 item in it, because a previously-enqueued fetch already got assigned most of it's data. BUT we execute the nearly-empty request for index 50 first because of the LIFO ordering. We give that data to RecyclerView first, and it doesn't like that at all, and it jumps to weird places because we gave it mostly null values, which are rendered as placeholder values (which are smaller than real cells). So then, when we give it the real data right after, its position is all off. I switched to a serial executor. That prevents us from giving back weird lists. The consequence is that if you scroll super fast, you run the risk of the executor getting 'backed up' fetching data that's offscreen. However, in practice, I couldn't trigger this. We'll see how it goes. I think the true solution is a smarter way of fetching and ordering requests, but that gets to be really tricky from a threading perspective, and I'd rather keep things simple.	2021-01-27 11:52:32 -04:00
Alan Evans	b4c2e21415	Custom streaming video muxer.	2021-01-06 17:03:21 -04:00
Greyson Parrelli	ec8793c6fe	Fix rendering issue when deleting the last message in a conversation.	2020-12-09 14:39:22 -05:00
Greyson Parrelli	8e93bf9075	Create a core-util module with some common utilities.	2020-12-05 13:44:13 -05:00
Greyson Parrelli	31960b53a0	Use our own homemade paging library for conversation paging. ... I made the lib, and Alan made the build actually work. Co-authored-by: Alan Evans <alan@signal.org>	2020-12-05 13:44:13 -05:00