The previous code had a number of problems, including:
- Calls to the filters API were scattered through UI and viewmodel code.
- Repeated places where the differences between the v1 and v2 Mastodon
filters API had to be handled.
- UI and viewmodel code using the network filter classes, which tied
them to the API implementation.
- Error handling was inconsistent.
Fix this.
## FiltersRepository
- All filter management now goes through `FiltersRepository`.
- `FiltersRepository` exposes the current set of filters as a
`StateFlow`, and automatically updates it when the current server
changes or any changes to filters are made. This makes
`FilterChangeEvent` obsolete.
- Other operations on filters are exposed through `FiltersRepository` as
functions for viewmodels to call.
- Within the bulk of the app a new `Filter` class is used to represent a
filter; handling the differences between the v1 and v2 APIs is
encapsulated in `FiltersRepository`.
- Represent errors when handling filters as subclasses of `PachliError`,
and use `Result<V, E>` throughout, including using `ApiResult` for all
filter API results.
- Provide different types to distinguish between new-and-unsaved
filters, new-and-unsaved keywords, and in-progress edits to filters.
## Editing filters
- Accept an optional complete filter, or filter ID, as parameters in the
intent that launches `EditFilterActivity`. Pass those to the viewmodel
using assisted injection so the viewmodel has the info immediately.
- In the viewmodel use a new `FilterViewData` type to model the data
used to display and edit the filter.
- Start using the UiSuccess/UiError model. Refrain from cutting over to
full the action implementation as that would be a much larger change.
- Use `FiltersRepository` instead of making any API calls directly.
## Listing filters
- Use `FiltersRepository` instead of making any API calls directly.
## EventHub
- Remove `FilterChangedEvent`. Update everywhere that used it to use the
flow from `FiltersRepository`.
New lint checks mean:
- Some trivial uses of String.format() are replaced with templates
- Use a string resource for the scheduled date and time
Some reported SetTextI18n warnings have been ignored, as they relate to
e.g., clearing a view's text by setting it to "".
Implement suggestions as a new `feature:suggestions` module, with
associated activity, fragment, etc.
Suggested accounts are shown with their normal information, as well as
information about the number of follows / followers, and a guide to
posting frequency, so the user can make a more informed decision about
whether to follow or not.
In the previous code `PachliError` could correctly chain errors and
generate error messages, `ApiError` didn't, which is why there was the
temporary `ApiError.fmt()` extension function.
Rewrite `ApiError` to implement `PachliError` so it gets these benefits
and to reduce the number of different error-handling mechanisms in the
code.
Main changes:
- `PachliError` is now an interface so it can be extended by other
error interfaces.
- All the `ApiError` subclasses implement `PachliError`, and can
specify the error string and interpolated variables at the point of
declaration.
- Update `ListsRepository` and `ServerRepository` to return
`PachliError` subclasses.
Previous code didn't hide the list-of-lists if an error occurred after
the list was displayed (e.g., load the list, turn on airplane mode,
reload the list).
Hide the list when errors are shown, and show it when there is content.
Previous code was inconsistent about using getServerErrorMessage() and
whether or not the case where getServerErrorMessage() returns null was
handled.
Switch to using getErrorString() which does handle the null case and
always returns a usable string.
Some string resources are rendered temporarily unused by this change.
They will be used again soon, so configure lint to ignore them at the
moment.
Crash was occuring because the instance info hadn't been fetched, trying
to take the last item of an empty list.
To fix:
- Expose the instance info as a state flow, with a default. New instance
info is fetched whenever the active account changes.
- Do the same for the emojis supported by the server.
- Update call sites as appropriate.
- Mark `InstanceInfoRepository` as `@Singleton` so it isn't repeatedly
created causing fresh content fetches.
The tests needed updating to get this to work.
- Extract the network fake modules in to a network-test module so
multiple other modules can use them.
- Rewrite `InstanceInfoRepositoryTest` to use Hilt and use Turbine to
test the new flows.
Checking this showed cosmetic bugs in the About layout when instance
info is missing, clean those up.
Previous code used a single animation type (slide) when transitioning,
the transition was quite slow, and didn't behave appropriately if the
device was set to a RTL writing system.
In addition, handling the back affordance didn't work well with the new
"Predictive Back" feature in Android 14
(https://developer.android.com/guide/navigation/custom-back/predictive-back-gesture).
Fix this.
## Transitions
To update the transitions the `startActivityWithSlideInAnimation()`
implementation (and associated `finishWithoutSlideOutAnimation()`) have
been replaced.
There are three transitions; `default`, `slide`, and `explode`,
represented as an enum passed to the activity intent.
The `default` transition is the activity transition from Android 14,
from the Android open source project
(https://cs.android.com/android/platform/superproject/+/android-14.0.0_r18:frameworks/base/core/res/res/anim/;bpv=1).
This is used for most transitions.
The `slide` transition is the pre-existing slide transition, with a
shorter transition time so it feels more responsive, and an RTL
implementation. This is used when there is a strong spatial component to
the navigation, for example, when going from:
- a status to its thread
- a preference menu item to its subscreen
- a filter in a list to the "edit filter" screen
- viewing your profile to editing your profile
The `explode` transition is used when the state of the app changes
significantly, such as when switching accounts.
Activities are now started with `startActivityWithTransition()` which
sets the intent and prepares the transition. `BaseActivity` checks the
intent for the transition type and makes further changes to the
transition as necessary.
## Predictive back
"Predictive back" needs to know what the back button would do before the
user interacts with it with an `onBackPressedCallback` that is either
enabled or disabled. This required refactoring some code (particularly
in `ComposeActivity`) to gather data ahead of time and enable/disable
the callback appropriately.
## Fixed bugs
- Back button wasn't stepping back through the tabs in AccountActivity
- Modifying a filter and pressing back without saving wasn't prompting
the user to save the changes
- Writing a content warning and then hiding it would still count the
text of the content warning toward's the post's length
## Other cleanups
- Use `ViewCompat.setTransitionName()` instead of setting the
`transitionName` property
- Delete the unused `fade_in` and `fade_out` animations.
- Use androidx-activity 1.9.0 to get the latest predictive back support
library code
- Show validation errors when creating / editing filters
Use `unicodeWrap` when inserting placeholders in error messages so they
set the correct text direction.
Update some strings with formatting directives to (a) include `_fmt`
in the name, and (b) use `%1$s` instead of `%s`.
Previous code expected callers to typically provide the drawable and the
error message string resource, resulting in duplicate code at many
callsites.
Replace with three canned messages for empty containers, generic errors,
and network errors respectively. The images for these are fixed, the
caller may choose a different string resource for the error if there is
a more specific option.
Update and simplify the call sites.
Move `ListsActivity`, along with fragments and viewmodels, to a new
`feature:lists` module.
Previous code used the `item_follow_request` layout, which was not
ideal, so update it to use a dedicated layout, `item_account_in_list`.
The UI uses strings and views originally defined in the main app, so
move them elsewhere so they can be re-used.
- `BackgroundMessageView` moves to `core.ui`.
- `Lazy` moves to `core.common`.
- `ThrowableExtensions` split; the extensions specific to throwables
from network activity move to `core.network`, others move to `core.ui`.
- `BindingHolder` moves to `core.ui`
- Shared drawables and strings move to `core.ui`.
Once desugaring is enabled it needs to be enabled for up/down the
dependency chain, so enable it in the shared configuration defined by
the build convention code.
Highlighted a failing test that wasn't being run, so fix that too.
Some users report that Pachli is not retrieving/displaying notifications
in a timely fashion.
To assist in diagnosing these errors, provide an additional set of tabs
on the "About" screen that contain information about how Pachli is
fetching notifications, and if not, why not.
Allow the user to save notification related logs and other details to a
file that can be attached to an e-mail or bug report.
Recording data:
- Provide a `NotificationConfig` singleton with properties to record
different aspects of the notification configuration. Update these
properties as different notification actions occur.
- Store logs in a `LogEntryEntity` table. Log events of interest with a
new `Timber` `LogEntryTree` that is planted in all cases.
- Add `PruneLogEntryEntityWorker` to trim saved logs to the last 48
hours.
Display:
- Add a `NotificationFragment` to `AboutActivity`. It hosts two other
fragments in tabs to show details from `NotificationConfig` and the
relevant logs, as well as controls for interacting with them.
Bug fixes:
- Filter out notifications with a null tag when processing active
notifications, prevents an NPE crash
Other changes:
- Log more details when errors occur so the bug reports are more helpful
- Use format strings so any overhead of building the string is only
incurred if the message is actually logged
- Pass throwables as the first parameter so they are logged with the
stacktrace
Previously, `AboutActivity` had buttons and links to show the privacy
policy and licenses of dependencies.
Change this to a selection of fragments in tabs, one tab each for:
- General "About" information
- Licenses
- Privacy Policy
The information shown hasn't changed, but this lays the groundwork for
including additional tabs in the future for information like server
rules, detected capabilities, or troubleshooting information.
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