Getting error reports with logs of strange behaviour is useful even if
the app doesn't crash.
Move crash reporting in to `core.activity`, and provide a menu option
(in orange builds) to trigger a non-fatal crash report that is handled
the same way (i.e., sent by e-mail) as a regular crash report.
`BaseActivity` has to be able to create and handle menus, so adjust
subclasses to call the superclass when necessary.
Update `tools/mvstring` to be able to move strings between different
flavour directories, not just `main`.
Continue modularisation by moving activities in the "About" feature to a
new `feature.about` module.
Implement `feature.about:
- Move `AboutActivity`, `LicenseActivity`, and `PrivacyPolicyActivity`
here.
- Update `markdown2resource` plugin to work with libraries
Implement `core.data`:
- Types and repositories used through the app
- Move `InstanceInfo` and `InstanceInfoRepository` here so they are
available to `feature.about`.
Implement `core.ui`:
- App-specific views, spans, and other UI content
- Move `ClickableSpanTextView` and `NoUnderlineURLSpan` here so they are
available to `feature.about`.
Continue modularisation by moving core activity classes that almost all
activities depende on to a `core.activity` module. This includes
core "helper" classes as well.
Implement core.activity:
- Contains BaseActivity, BottomSheetActivity
- Contains LinkHelper and other utility classes used by activities
Implement core.common.extensions:
- Move ViewBindingExtensions and ViewExtensions here
Implement core.common.util:
- Move BlurHashDecoder and VersionName here
Implement core.designsystem:
- Holds common resources (animations, colours, drawables, etc) used
through the app
- Import "core.designsystem.R as DR" through the app to distinguish
from the module's own resources
Implement feature.login:
- Move the LoginActivity and related code/resources to its own module
Implement tools/mvstring
- Moves string resources (and all translations) from one module to
another
Previous code would show errors when fetching server info but with no
mechanism to retry the operation, so it would "stick" until the user
restarted the app.
Fix this with a retry action.
While I'm here use styles to ensure that all snackbars are 5 lines max
length and remove code that sets the length.
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
Previous code created the drawer image loader as an anonymous inner
class that kept a reference to `glide`, which had a reference to `this`
and could leak.
Fix that by create a separate class that takes these as constructor
parameters.
ButterflyOfFire
bittin1ddc447d824349b2
Nik Clayton
Weblate (bot)
Reza Almanda
