Implement some support for server-side status translation. Do this by:
- Implement support for the `api/v1/instance` endpoint to determine if
the remote server supports translation.
- Create new `ServerCapabilities` to allow the app to query the remote
capabilities in a server-agnostic way. Use this to query if the
remote server supports the Mastodon implementation of server-side
translation
- If translation is supported then show a translate/undo translate
option on the status "..." menu.
- Fetch translated content from the server if requested, and store it
locally as a new Room entity.
- Update displaying a status to check if the translated version
should be displayed; if it should then new code is used to show
translated content, content warning, poll options, and media
descriptions.
- Add a `TextView` to show an "in progress" message while translation
is happening, and to show the translation provider (generally
required by agreements with them).
Partially fixes#62
---------
Co-authored-by: sanao <naosak1006@gmail.com>
The previous code did not handle refreshing correctly; it retained some
of the cache, and tried merge new statuses in to the cache. This does
not work, and resulted in the app creating gaps in the timeline if more
than a page's worth of statuses had appeared since the user last
refreshed (e.g., overnight).
Fix this by treating the on-device cache as disposable, as the Paging3
library intends. On refresh the cached timeline is emptied and replaced
with a fresh page.
This causes a problem for state that is not stored on the server but is
part of a status' viewdata (has the user toggled viewing a piece of
media, expanded a CW, etc).
The previous code tried to work around that by pulling the state out of
the page cache and copying it in to the new statuses. That won't work
when the page cache is being destroyed.
So do it properly -- store the viewdata state in a separate (sparse)
table that contains only rows for statuses that have a non-default
state.
Save changes to the state when the user interacts with a status, and
use the state to ensure that the viewdata for a status in a thread
matches the viewdata for the same status if it is shown on the home
timeline (and vice-versa).
Fixes#16
- Rename packages to app.pachli.*
- Switch to Pachli icons (blue / orange)
- Reset database schema version to 1
- Reset versionCode to 1 and versionName to "1.0"
- Update colour scheme, use colorPrimary etc through the app
- Use Material UI components for toolbars
- Use "Pachli" in strings (UI, constants, etc)
- Update copyright on code I contributed
- Update README
- Update fastlane metadata
Nik Clayton