mirror of
https://github.com/pachli/pachli-android.git
synced 2025-01-23 21:51:57 +01:00
fc81e8bad7
Previously when the user interacted with a status the operation (reblog, favourite, etc) travels through multiple layers of code, carrying with it the position of the item in the list that the user operated on. At some point the status is retrieved from the list using its position so that the correct status ID can be used in the network operation. If this happens while the list is also refreshing there's a possible race condition, and the original status' position may have changed in the list. Looking up the status by position to determine which status to perform the action on may cause the action to happen on the wrong status. Fix this by passing the status' viewdata to any actions instead of its position. This includes all the information necessary to make the API call, so there is no chance of a race. This is quite an involved change because there are three types of viewdata: - `StatusViewData`, used for regular timelines - `NotificationViewData`, used for notifications, may wrap a status that can be operated on - `ConversationViewData`, used for conversations, does wrap a status The previous code treated them all differently, which is probably why it operated by position instead of type. The high level fix is to: 1. Create an interface, `IStatusViewData`, that contains the data exposed by any viewdata that contains a status. 2. Implement the interface in `StatusViewData`, `NotificationViewData`, and `ConversationViewData`. 3. Change the code that operates on viewdata (`SFragment`, `StatusActionListener`, etc) to be generic over anything that implements `IStatusViewData`. 4. Change the code that handles actions to pass the viewdata instead of the position. Fixes #370 |
||
|---|---|---|
| .. | ||
| schemas/app.pachli.core.database.AppDatabase | ||
| src | ||
| build.gradle.kts | ||
| lint-baseline.xml | ||