Previous code accepted the `scheduledAt` value as a String, and kept it
as a String (including when serialising as part of a draft). Then it was
converted to an actual Date for display.
Refactor to keep it as a Date for as long as possible. Moshi decodes
Dates correctly over the network, and the database is configured to
serialise Dates as Longs.
This necessitates two migration steps to preserve any existing
`scheduledAt` values for drafts. The first step adds a new column to
store the date as a Long and copies over existing data. The second step
replaces the old column with the new column.
For some users this feature has too many false positives, particularly
when emojis are used.
Provide a preference that enables/disables the feature, default to
"enable".
When the user is prompted the dialog has a third "Don't ask again"
option. If chosen the preference is set to prevent future prompts and
the status is sent as-is.
Fixes#893
GoToSocial servers don't support scheduled posts; they return the wrong
type, and this can cause a loop of posting.
The GoToSocial bug to implement scheduled posts is
https://github.com/superseriousbusiness/gotosocial/issues/1006.
Fix this by adding a new server capability for scheduled post support,
using it for most servers, and disabling it for GoToSocial.
If scheduled post support is not available for an account:
- The "Scheduled posts" menu option is not shown.
- The scheduling button (clock) when composing a post is hidden, so the
user cannot set scheduling parameters.
Fixes#963
The MaterialTimePicker library has a bug that results in the "Cancel"
and "Ok" buttons on the dialog being cut off.
See
https://github.com/material-components/material-components-android/issues/3584
Work around this by updating their layout params and explicitly setting
the "bottomToBottom" constraint to their parent.
This wasn't acting as a preference.
It presented as a switch. If the user toggled it some notification
settings were changed for all accounts.
It wasn't clear what was changed, and if the user changed some of those
settings back the switch position did not change (it couldn't, you
couldn't meaningfully represent a partial change using a single switch).
Since the user has full control over the notification filters on a
per-account basis remove this "preference" to reduce confusion.
Fixes#935
Seen the following crash in user reports:
```
com.google.android.gms.common.api.ApiException: 17:
API: ModuleInstall.API is not available on this device.
Connection failed with:
ConnectionResult{statusCode=SERVICE_INVALID, resolution=null, message=null}
```
Doesn't appear to be properly documented anywhere I can find. To work
around this catch exceptions when checking for MLKit modules or
installing them and return defaults.
Previous code assumed the active account could always be determined from
the account manager.
This causes a few problems.
1. The account manager has to handle the case where there is no active
account (e.g., the user is logging out of the last account). This meant
the `activeAccount` property had to be nullable, so every consumer of
that property either used it with a `let` or `!!` expression.
2. The active account can change over the life of the UI component, for
example, when the user is switching accounts. There's a theoretical race
condition where the UI component has started an operation for one
account, then the account changes and the network authentication code
uses the new account.
3. All operations assume they operate on whatever the active account is,
making it difficult to provide any features that allow the user to
temporarily operate as another account ("Boost as...", etc).
This "ambient account" was effectively global mutable state, with all
the problems that can cause.
Start to fix this. The changes in this commit do not fix the problem
completely, but they are some progress.
Each activity (except LoginActivity) is expected to be launched with an
intent that includes the ID of the Pachli account it defaults to
operating with. This is `pachliAccountId`, and is the *database ID*
(not the server ID) of the account. This is non-null, which removes one
class of bugs.
This account is passed to each fragment and any piece of code that has
to perform an operation on behalf of this account. It's not used in
most of those places yet, that will be done over a number of followup
PRs as part of modernising each module.
Previous code didn't encode v2 filter keywords, so created v2 filters by
first creating the filter with no keywords (one API call) then making
1-N API calls to add each keyword to the filter.
Fix this by adding a dedicated converter for the `NewContentFilter` type
that encodes it correctly so the filter can be created with a single API
call.
This necessitates moving some types around,
It's possible for some servers to return a conversation that has an
empty (or possibly missing) `accounts` property. In the previous code
this would crash trying to access an item in an empty list.
Fix this by handling the "no participants" case.
Fixes#971
The new anti-harassment features will add several different types of
filtering options through the UI.
To ensure there is no confusion, rename the existing "Filters" UI and
code to "Content filters" to accurately describe what they operate on,
distinct from new filters which will act on account metadata.
Fixes#926.
Previously, tapping a tab would jump to the top of the loaded content,
which might trigger a load of a fresh page.
Provide a preference to control this; the default is the current
behaviour, the user can also choose to discard the current content and
load the newest content.
Fixes#939
Update `DownloadUrlUseCase` with a parameter to specify the account that
"owns" the media. This is either the account that posted the status, or
the account being viewed (e.g., if downloading an account's header
image).
Add a new `DownloadLocation` enum constant to download to directories
named after that account.
Pass this information through at the call sites.
Fixes#938
Provde an `appTheme` property in `SharedPreferenceRepository` to manage
read access, simplifying calling code.
Update `PreferenceEnum.from` to check the `value` property of the enum
first.
Fixes#950
The existing code downloaded any attachments to the user's "Downloads"
folder. If the user is logged in with several accounts these downloads
will be mixed up together.
Fix this by adding a new preference that allows the user to specify the
downloads should be placed in a sub-folder per account, named after the
account.
To do this:
- Add an interface for enums that can be used as preferences, with
properties for the string resource to display and the value to store.
- Add `EnumListPreference`, a `ListPreference` that allows the user to
choose between different enum values.
- Add a `DownloadLocation` enum and preference key so the user can
choose the location.
- Add a `core.domain` module, with a use case for downloading URLs that
respect's the user's download preference. Use this use-case everywhere
that files are currently downloaded.
Fixes#938
Previous code showed any JSON-wrapped errors from notification fetches
as the JSON string, instead of the error message.
Fix this by switching to `ApiResult` and using the formatted error
message.
Fixes 937
Previous code saved the reading position of a fully visible status. But
there are situations where no status is fully visible.
1. The user is in the middle of viewing a status longer than the screen
height, and the top/bottom of the status are off the top/bottom of the
screen.
2. The user has scrolled between two statuses. Collectively they are
longer than the screen height, and the top of one status is off the top
of the screen and the bottom of the other status is off the bottom of
the screen.
In both cases the user's reading position was not saved.
In these situations use the ID of the status closest to the bottom of
the screen, even if not fully visible. This should ensure the user never
missing anything.
Fixes#936
Previous code used `Response`. Convert to `ApiResult` as part of the
work to implement anti-harassment controls, which will need to query the
user's list of accounts they are following.
Converting just `accountFollowing` wasn't practical, as all the methods
are called by a single function in `AccountListFragment` which expects
the return type to be the same.
Nik Clayton
mondstern
Weblate (bot)
Kalle Kniivilä
--//--
Languages add-on
Juan M Sevilla
renovate[bot]
Weblate (bot)
