Fix race conditions when updating UI from events (again)
This is my second attempt at fixing race conditions caused by updating the UI from events while background tasks are loading data from the DB. Unlike my first attempt, this one is pretty simple and doesn't require too much reasoning about possible races.
The first commit fixes a few list loading bugs I found while working on this problem, and moves the lifecycle callbacks from resume/pause to start/stop, closing #609. The second commit contains the fix for #705, which works as follows:
* Each BriarAdapter has a revision counter
* Before making a change to the adapter that could be overwritten by a background task, increment the revision
* Before starting a background task that could overwrite other changes, get the current revision
* Before applying changes from a background task that could overwrite other changes, check whether the revision has changed
* If the revision has changed, restart the background task
* Otherwise apply the changes
Closes#609. #705 remains open because the PagerAdapters for blogs need to be updated.
See merge request !356
Private Group Threaded Conversation
This MR refactors the forum activity, its controller, its adapter and view holder so *most* of the code can be re-used for private groups by making heavy use of generics.
The refactoring has 1383 additions and 1087 deletions, so just grows the code-base slightly and adding the private group conversation just takes an additional 400 lines.
The MR also includes one commit that moves post/message creation more into clients, so the UI doesn't need to keep track of timestamps. This commit can of course be split out into a separate MR if desired.
Closes#662, #663
See merge request !350
This way the forum and private group client do not need to keep track of
message timestamps themselves and do not need to interact with
post/message factories.
Use constructor injection for controllers
Also made some listeners volatile.
This is part of #704 - if I don't find any other classes that need constructor injection I'll close the ticket.
See merge request !351
Null safety annotations
The @NotNullByDefault annotation marks all fields, methods and parameters in a class or package @NotNull, so Android Studio will warn if values that may be null are used. Please use this annotation for new classes, and specify @Nullable for any fields, methods and parameters that may be null.
Injected fields are initialised to null, so injected classes should use @MethodsNotNullByDefault and @ParametersNotNullByDefault, or specify @Nullable for injected fields.
See merge request !349
Private Group List UI
This MR implements the UI for the list of private groups.
It reacts to three types of events to refresh the displayed data:
* new group message received
* private group added
* private group removed
Missing from final implementation:
* entering groups
* adding new groups
* reacting to a future group dissolved event
* actually removing a dissolved group
Closes#660
See merge request !335
Always show the keyboard when asked for it
The main fix is maintaining the internal keyboard state when the entire view gets hidden, because `onMeasure()` isn't called anymore in that case and can't update it itself.
Closes#676
See merge request !348
Always check whether the context has been destroyed
#551 has the same root cause as #610, which is that when a background operation completes, we need to check whether the activity or fragment that started the operation has been destroyed before doing anything with the UI.
DestroyableActivity has been renamed to DestroyableContext because it's now implemented by some fragments as well. Various existing listener interfaces now extend DestroyableContext.
I also modified the ActivityLifecycleController interface so the activity is passed into the onActivityCreate() method rather than being injected - @ernir please check I haven't broken anything!
Closes#551
See merge request !341
Fix NPE when stopping KeyAgreementTask, improve thread safety
This branch fixes#696 and improves the thread safety of the camera code, mostly by adding @UiThread annotations and occasionally by moving stuff onto the UI thread that might have happened on other threads before.
Closes#696
See merge request !345
Use new group metadata for showing lists
What was supposed to be a minimal change turned into a rather large MR. I did my best to keep things in separate commits, so I can still split this into smaller MRs if desired.
While making use of the new group metadata in the contact and forum list, I noticed some other things in need of improvement to get rid of needing to load all messages:
* Refactor `SharingManager` so its events provide message headers that can be used to update list items
* Add `GroupId` to conversation items, so the metadata of the respective group can be updated as well when marking the items read
* Create a very basic `ConversationManager` so the GroupCount for the various clients can be queried in one go without needing to know all their groups per contact
* Fix a nasty bug that caused forum and blog invitation to not update their read state
* Fix some bugs related to displaying the forum list with proper unread count
Some casual measurements with just a few contacts and messages showed a reduction of the contact list load time by one third.
See merge request !343
