The previous code unilaterally enabled filter functionality. Some
Mastodon-like servers -- like GoToSocial -- do not support filters, and
this resulted in user visible error messages when connecting to those
servers.
To fix this:
- Extend the set of supported server capabilities to include client and
server side filtering.
- Disable the filter preferences if the server does not support filters
and show a message explaining why it's disabled.
Extend the capabilities model to support this:
- Fetch server software name and version from the nodeinfo endpoints
(implementing the nodeinfo API and schema)
- Extend the use of kotlin-result to provide hierarchies of Error
classes and demonstrate how to chain errors and display more informative
messages without using exceptions.
Fixes#343
Previously some tests had to manually create dependencies (instead of
injecting them) because the dependency required the `TestScope`
`CoroutineScope` as one of its dependencies.
Resolve this with a `FakeCoroutineScopeModule` that provides `TestScope`
as `@ApplicationScope`. The tests can now inject their dependencies,
which will use `TestScope`.
To inject `AccountPreferenceDataStore` it has been updated to use the
current active account when reading or writing preferences.
e35fa1db inadvertently contained some left over debug code that treats
non-bot accounts as bots (for displaying the bot badge) and vice versa.
Fixes#321
If a status was part of a thread, and it was not the "detailed" status,
and it had been translated, then the view data was marked as "show the
translation". But the translation was not loaded, so the status content
appeared as empty.
Fix that by loading the translated content of all statuses in the thead
and ensure that the translated content is rendered.
Throw an `IllegalStateException` in debug builds to catch any future
occurrences of this.
Fixes#281
Add a dependency on ACRA (in orange builds only), and catch crashes.
The user is given the option to e-mail the crash report data to the
support address, and can view and edit/redact the data before doing so.
Mastodon counts post lengths by considering emojis to be single
characters, no matter how many unicode code points they are composed of.
So "😜" has length 1.
Pachli was using `String.length`, which considers "😜" as length 2.
Correct the calculation by using a BreakIterator to count the characters
in the string, which treats multi-character emojis as a length 1.
Poll options had a similar problem, exacerbated by the Mastodon web UI
also having the same problem, see
https://github.com/mastodon/mastodon/issues/28336.
Fix that by creating `MastodonLengthFilter`, an `InputFilter` that does
the right thing for regular text that may contain emojis.
See also https://github.com/tuskyapp/Tusky/pull/4152, which has the fix
for status length but not polls.
---------
Co-authored-by: Konrad Pozniak <opensource@connyduck.at>
Roles for the logged in user appeared in Mastodon 4.0.0 and can be
displayed on the user's profile screen.
Show them as chips, adjusting the display of the existing "Follows you"
and "Bot" indicators to make allowances for this.
Roles can have a custom colour assigned by the server admin. This is
blended with the app colour so it is not too jarring in the display.
See also https://github.com/tuskyapp/Tusky/pull/4029
Co-authored-by: Konrad Pozniak <opensource@connyduck.at>
Quoting @connyduck in https://github.com/tuskyapp/Tusky/pull/4150:
"""
The transformation ends up in Glide's memory cache and leaks whole
Activities through the view -> context reference.
This fixes the problem by removing the background detection logic (so
the view reference is no longer needed) and setting the background
directly instead. Looks exactly as before.
"""
Co-authored-by: Konrad Pozniak <opensource@connyduck.at>
The previous code generally started an activity by having the activity
provide a method in a companion object that returns the relevant intent,
possibly taking additional parameters that will be included in the
intent as extras.
E.g., if A wants to start B, B provides the method that returns the
intent that starts B.
This introduces a dependency between A and B.
This is worse if B also wants to start A.
For example, if A is `StatusListActivity` and B is`ViewThreadActivity`.
The user might click a status in `StatusListActivity` to view the
thread, starting `ViewThreadActivity`. But from the thread they might
click a hashtag to view the list of statuses with that hashtag. Now
`StatusListActivity` and `ViewThreadActivity` have a circular
dependency.
Even if that doesn't happen the dependency means that any changes to B
will trigger a rebuild of A, even if the changes to B are not relevant.
Break this dependency by adding a `:core:navigation` module with an
`app.pachli.core.navigation` package that contains `Intent` subclasses
that should be used instead. The `quadrant` plugin is used to generate
constants that can be used to launch activities by name instead of by
class, breaking the dependency chain.
The plugin uses the `Activity` names from the manifest, so when an
activity is moved in the future the constant will automatically update
to reflect the new package name.
If the activity's intent requires specific extras those are passed via
the constructor, with companion object methods to extract them from the
intent.
Using the intent classes from this package is enforced by a lint
`IntentDetector` which will warn if any intents are created using a
class literal.
See #291
The package wasn't renamed when it was moved, so was still
`app.pachli.components.timeline`, instead of the new location,
`app.pachli.core.network.model`.
The existing code base is a single monolithic module. This is relatively
simple to configure, but many of the tasks to compile the module and
produce the final app have to run in series.
This is unnecessarily slow.
This change starts to split the code in to multiple modules, which are:
- :core:account - AccountManager, to break a dependency cycle
- :core:common - low level types or utilities used in many other modules
- :core:database - database types, DAOs, and DI infrastructure
- :core:network - network types, API definitions, and DI infrastructure
- :core:preferences - shared preferences definitions and DI
infrastructure
- :core:testing - fakes and rules used across different modules
Benchmarking with gradle-profiler shows a ~ 17% reduction in incremental
build times after an ABI change. That will improve further as more code
is moved to modules.
The rough mechanics of the changes are:
- Create the modules, and move existing files in to them. This causes a
lot of churn in import arguments.
- Convert build.gradle files to build.gradle.kts
- Separate out the data required to display a tab (`TabViewData`) from
the data required to configure a tab (`TabData`) to avoid circular
dependencies.
- Abstract the repeated build logic shared between the modules in to
a set of plugins under `build-logic/`, to simplify configuration of
the application and library builds.
- Be explicit that some nullable types are non-null at time of use.
Nullable properties in types imported from modules generally can't be
smart cast to non-null. There's a detailed discussion of why this
restriction exists at
https://discuss.kotlinlang.org/t/what-is-the-reason-behind-smart-cast-being-impossible-to-perform-when-referenced-class-is-in-another-module/2201.
The changes highlight design problems with the current code, including:
- The main application code is too tightly coupled to the network types
- Too many values are declared unnecessarily nullable
- Dependency cycles between code that make modularisation difficult
Future changes will add more modules.
See #291.
Previous code always called `startActivityAndCollapse()` with a regular
intent, which triggers an `UnsupportedOperationException` at API 34.
Use the non-deprecated variant that uses pending intents when
appropriate.
While looking at this I noticed the icon for the tile was incorrect, so
replaced that with the notification icon.
Show up to two lines of the link's title and three lines of the link's
description in link preview cards. This provides additional useful
context to the user, especially when many links bury the important
information at the end of the title.
Upgrading to this version of Pachli may trigger an Android bug where
cached animation specifications are not cleared, resulting in incorrect
animations (e.g., when navigating between activities).
This is an Android bug triggered by the Android Material library,
https://github.com/material-components/material-components-android/issues/3644.
Show the user a dialog (once) when launching after an upgrade, so they
know to restart their device if necessary.
Display the "compose" FAB when viewing a hashtag list. Tapping the
button will open `ComposeActivity` prepopulated with the hashtag at the
end of the post with the cursor at the start.
Fixes#228
Viewing edited statuses could crash on API levels around 26 with a
ResourceNotFoundException. Using `?colorOutline` for the divider colour
instead of `?android:textColorPrimary` fixes this, and is also a better
colour to use.
`Theme.Pachli` was being overriden on v29+ devices which meant that poll
options were showing with too much padding. Fix that by using `AppTheme`
as the final theme, and basing that off `Theme.Pachli`.
Black themes were using dark grey for toolbar and tab backgrounds, so
fix that too for a seamless experience with the black theme.
Not all subclasses were calling `super.onViewCreated()` so collecting
the server capability wasn't happening consistently. Fix this, and add a
`@CallSuper` annotation to prevent the problem from recurring.
Without this the model classes are not retained, which causes a
`ClassCastException` when parsing the new models for the instance v1 and
instance v2 API calls.
Fixes#250
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>
Now that the flavour includes the store name it's not sufficient to
check for "orange" as the flavour, as that no longer matches. Now it
must start with "orange" to trigger using the git commit count as the
version code.
Users can inadvertently get stuck on older versions of the app; e.g., by
installing from one F-Droid repository that stops hosting the app at
some later time.
Analytics from the Play Store also shows a long tail of users who are,
for some reason, on an older version.
On resuming `MainActivity`, and approximately once per day, check and
see if a newer version of Pachli is available, and prompt the user to
update by going to the relevant install location (Google Play, F-Droid,
or GitHub).
The dialog prompt allows them to ignore this specific version, or
disable all future update notifications. This is also exposed through
the preferences, so the user can adjust it there too.
A different update check method is used for each installation location.
- F-Droid: Use the F-Droid API to query for the newest released version
- GitHub: Use the GitHub API to query for the newest release, and check
the APK filename attached to that release
- Google Play: Use the Play in-app-updates library
(https://developer.android.com/guide/playcore/in-app-updates) to query
for the newest released version
These are kept in different build flavours (source sets), so that e.g.,
the build for the F-Droid store can only query the F-Droid API, the UI
strings are specific to F-Droid, etc. This also ensures that the update
service libraries are specific to that build and do not
"cross-contaminate".
Note that this *does not* update the app, it takes the user to either
the relevant store page (F-Droid, Play) or GitHub release page. The user
must still start the update from that page.
CI configuration is updated to build the different flavours.
The preference change listener was being optimised out by R8, causing
rapid garbage collection, breaking the `changes` flow in release builds.
Fix this by annotating the field with `@Keep` so it is retained.
Fixes#225
Previous code always set `navigationBarColor` and `statusBarColor` to
`transparent` irrespective of the API level.
This only works on API 29 and above; if you do it on API levels lower
than that the system navigation buttons (home, back, recents) are
typically shown on a very similar colour to the background, making them
very hard to see.
Fixes#221
The previous code used `androidx.appcompat.widget.Toolbar` in a several
places.
It's better to use `MaterialToolbar` as that plays better with other
Material components.
Update the usage throughout the project.
In addition, implement a lint check that will prevent any future use
from creeping back in.
Fixes#28
Use Timber instead of `android.util.Log`. Removes the need for `TAG`
statics in companion objects, slightly simplifying the code. Opens the
door for some production logging in the future.
Previously the middle-of-screen progress spinner and the spinner that
appears on a swipe-to-refresh could get out of sync.
Fix this by removing the middle-of-screen progress spinner from relevant
fragments, as the swipe-to-refresh spinner shows the user that an
operation is in progress, and also clues them in to the fact that a
swipe-to-refresh is possible (by using the common UX control).
Fixes#75
There's a well-hidden `updateLintBaseline` task that does what the
custom `newLintBaseline` task does. Prefer the `update...` task to
reduce the amount of custom machinery in this build.
Previously, ending a drag on an image (that didn't result in dismissing
the fragment) animates the image back in to position restoring the X
axis scale factor.
The Y axis scale factor was not restored, potentially breaking the
image's aspect ratio. Restore the Y axis scale factor to fix this
(`ViewVideoFragment` already handles this correctly).
Fixes#202
This previous code could crash if `filterModel.kind` (marked `lateinit`)
had not been set before the filters are loaded. This could happen in
rare cases.
Fix this by rewriting `FilterModel`. Instead of creating a half-empty
object that still needs further initialisation, delay the creation until
all the necessary information is available, and pass it in the
`FilterModel` constructor.
This also forces code that uses `FilterModel` to properly handle the
case where it might be null at the point where filtering decisions have
to be made.
This means that `TimelineViewModel` (and subclasses) no longer need the
`init()` function to complete their construction, which was another
significant code smell. Pass the `TimelineKind` to the view models via
their `SavedStateHandle`.
This showed that changing filters wasn't causing the timelines to update
without a manual refresh, so fix that too. Editing filters sends change
events for the old and new contexts (in case a context is removed from a
filter), and deleting a filter sends a change event too.
Previous code called filters that affect threads "Conversations".
Correct this to "Threads", to distinguish from "Direct Messages" which
can also be known as "conversations" (in the API in particular).
Previous copyright notice mentioned that the license should have been
distributed with Tusky. Correct that to Pachli.
This does not change the copyright assignment, only the instructions
as to where to find the license.
A "self-boost" is someone boosting their own post. Some people are
particularly prolific at this, and it can clutter the timeline. Provide
a new preference that allows the user to show/hide these boosts from
their timeline.
Most parts of the UI will truncate the display of long names (display
and user), but it makes sense to show them untruncated on the account's
profile screen.
The previous code (a) used an emoji as the prefix character when showing
the destination of an obscured link, and (b) made the destination part
of the link anchor text.
Using an emoji was a problem because the user can use different emoji
sets and it can give strange results. Making the destination part of the
link text made it difficult to distinguish at a glance where one link
ends and another starts.
Fix the emoji problem by replacing the emoji with a drawable.
Fix the destination problem by changing the string resource so it only
includes the destination part, and inserting it at the end of the link
instead of replacing the whole link. This means the disclosed
destination is not clickable, does not look like part of the link, and
stands out more.
Previously was showing pale text on a pale background, so effectively
invisible.
Use `colorPrimary` and `colorOnPrimary` to ensure the text can be seen.
Using a sealed interface (instead of a sealed class) at the root of the
hierarchy avoids the overhead of having to create and initialise the
class (visible in the generated bytecode).
It also makes the instantiation code slightly less cumbersome because
the code doesn't need to pass parameters to the root's constructor.
Previously, playing a video would show the controls and associated
overlay for five seconds before fading them out. This obscures the video
for too long.
Fix this by:
- Only showing the media description on start, and remove after two
seconds
- Show the controls (and media description) if the user taps, removing
after two seconds
- Pausing the video (with the pause control, or tapping on the media
description) keeps the controls and description on-screen indefinitely
so they are easier to read
Fixes#144
The previous code didn't include SHOW_CARDS_IN_TIMELINES in the list of
prefkeys that change `StatusDisplayOptions`, so changing the preference
wouldn't update the timeline display; you had to close/restart the app.
Display the time that an announcement was posted, as well as the
most recent update to the announcement (if there is one). Time display
honours the user's "use absolute time" preference.
Fixes#35
Previously, code for handling shared preferences, and how those
preferences affect `StatusDisplayOptions`, was scattered through the
code base with duplicate implementations.
Bring it together in to a `SharedPreferencesRepository` and a
`StatusDisplayOptionsRepository`.
`SharedPreferencesRepository` is a thin wrapper over`SharedPreferences`
that delegates most work to `SharedPreferences`. It configures a
listener for preference changes, and exposes those changes as a flow.
`StatusDisplayOptions` now contains explicit defaults to ensure they
are in one place.
`StatusDisplayOptionsRepository` exposes a `StatusDisplayOptions` flow
that updates whenever the active account changes or a relevant
preference changes.
The viewmodels expose `StatusDisplayOptionsRepository.flow` to the
activities and fragments so they can pass the current value to the
adapter.
This obsoletes `PreferenceChangedEvent`. An event is still fired when
filters change, `FilterChangedEvent`.
This allowed many of the mocks in tests to be replaced with either the
real type (because a fake is injected in to it, or one of its
dependencies) or a custom fake that provides a mock.
Previous code had to distinguish between showing an attachment or
showing an image by URL.
Simplify this by -- in the image URL case -- creating a fake attachment
that references the image URL.
Move the code that unmarshalls the Bundle arguments to
`ViewMediaFragment` to share between `ViewImageFragment` and
`ViewVideoFragment`.
Previous code finalised the view setup in `onViewCreated`, so if you
opened some media, switched away from the app, and switched back you'd
get a blank screen.
Fix this by doing the finalisation in `onResume()`, so the media is
displayed correctly when returning to the fragment.
Fixes#161
Android 14 (SDK 34) requires a `foregroundServiceType` and `onTimeout()`
implementation for foreground services, otherwise creating the service
will crash.
Do this. If `SendStatusService` does timeout then any pending statuses
are marked as failed, saved to drafts, and the user is informed.
Fixes#162
Use the Material colour for `conversation_thread_line` (which is
`colorOutlineVariant`) instead of a custom attribute.
Elsewhere, use the Material attribute directly (in code), or replace the
custom divider with a `MaterialDivider`.
This makes some colour definitions unused, so remove them.
Fixes#148
Previously the tests mocked shared preferences with a map and a mock
that had to be implemented for each test that needed it.
Replace this with `InMemorySharedPreferences`, which provides the normal
`SharedPreferences` interface so can be used as a drop-in replacement.
Associated changes:
- Handle new null/non-null type signatures in overriden methods
- Configure Robolectric to use SDK 33 (current highest supported
version)
- Remove `Injectable` interface, use `@AndroidEntryPoint`
- Remove `DispatchingAndroidInjector`
- Remove `viewModelFactory`, use `@HiltViewModel`
- Create providers for the different DAOs, and inject those instead of
`AppDatabase`
- Create provider for a database transaction, inject that instead of
`AppDatabase`
- Update tests
Instead of linking to the privacy policy embed it in the app as a string
of HTML.
The string is created with a new `markdown2resource` plugin, which
converts `PRIVACY.md` to HTML and generates a Java class with the HTML
content.
Create `PrivacyPolicyActivity` to display the HTML in a `WebView`, and
link to it from `AboutActivity`.
The previous code did not always work when the user returned to the app
after a lengthy absence (e.g., overnight).
Instead of restoring by scrolling in `TimelineFragment`, restore by
working with the platform.
Determine the initial page to fetch by looking half a page ahead of the
saved saved status ID, and fetch that status and the page immediately
prior. This seems to match the view's expectations about what will be
immediately available.
Set `jumpThreshold` and `enablePlaceholders` in the `PagingConfig` so
the paging system will jump to the saved status.
Remove the restoration code in `TimelineFragment`.
Fixes#53
Start building infrastructure to automatically build and deploy the
`orangeRelease` variant to Google Play.
The variant needs an automatically incrementing `versionCode`. That is
derived from the count of all commits.
Change the separator between the version and the build metadata in the
`versionName` from `-` to `+` to be consistent with semantic versioning.
This is still an experiment, so the workflow is triggered manually and
only uploads to the internal track
The previous code ran the API call in a `try/catch block`, and handled
errors in the `catch`. But `NetworkResult` already catches the exception
and transforms it to a failure, so the error case was not handled.
Replace with `NetworkResult.fold`.
Remove the rxjava3 `Single` type from the MastodonAPI definition,
replacing with `Response` or `NetworkResult` as appropriate.
Update callsites and tests as appropriate.
This removes the need for `com.squareup.retrofit2:adapter-rxjava3`
A previous change dropped the check to see if media was marked as
sensitive, and so all media was hidden when viewing a thread. Reinstate
the check so only sensitive media is hidden (if the user preferences are
set that way).
Previous code created `statusDisplayOptions` in full each time, risking
the creation of inconsistent states / defaults.
Refactor to use `StatusDisplayOptions.from()` so the user's settings
(and defaults) are always respected.
Previously the voting button was always enabled, even if the user hadn't
made a choice.
Disable the button by default, and listen for clicks on the options.
Enable the button whenever one or more options are selected.
Fixes#90
Previous code `include`'d `toolbar_basic` inside an `AppBarLayout`.
But `toolbar_basic` already contains an `AppBarLayout`, which
resulted in some rendering issues.
Remove the `include` and incorporate the `MaterialToolbar` directly.
Set the toolbar to scroll out of the way when the screen scrolls, so
the behaviour is consistent with the tabs in `MainActivity` and
`AccountActivity`.
Previously, in `MainActivity` and `AccountActivity` the status bar would
be `colorPrimaryDark`.
Adjust the layouts and code so that `colorSurface` is used to match
the toolbar colour.
Fixes#79
The previous code generally converted between a higher and a lower type
by putting the type conversion functions on the lower type.
This introduced cycles in the code dependency graph, and made it more
difficult to follow the code flow.
Refactor the code so that types generally have a `from(...)` static
factory method that can create an instance from a lower type, and if
appropriate a `to...()` method that can also create an instance of that
lower type.
Add `docs/code-style.md` which explains the rationale for this change
in more detail so that future contributors can write code in the same
style.
In `MediaUploader` the lint warning can be ignored, as the stream is
closed elsewhere.
In the other files `.use` is used to simplify the code and remove
the need for Closeable.closeQuietly (as `.use` catches exceptions that
are thrown when closing).
Use `assert` to note when a nullable value is known to be non-null.
Extract a method call to a variable where necessary to do this.
Update `CharSequence.unicodeWrap()` to handle a null `CharSequence`.
`ConversationViewHolder` calls `getDisplayName()`, which may return
null.
Replace with `getName()`, which is consistent with usage in other
classes. Mark `getDisplayName()` as deprecated to prevent future
usage.
The previous code used SwitchPreference to generate the switches, which
didn't apply the Material colours. This made it difficult to distinguish
between the on/off states, as the non-Material colours for those states
are very similar.
Fix by using SwitchPreferenceCompat which uses the correct Material
colours.
The previous code used "?attr/colorOnTertiary", which is the wrong
colour for the default background. Remove the override, so the correct
styled colour is used.
The previous code only attempted to restore the user's reading position
once, after any initial refresh.
Adjust this so the position is restored after any refresh (which may
have been triggered from a menu instead of a swipe), and use
`scrollToPositionWithOffset` to ensure it's visible.
Testing showed additional activities with toolbar flicking issues. Fix
as before, using `setLiftOnScrollTargetView` to specify the scrolling
view the toolbar should lift above.
The chips for adding a new hashtag to a tab specified the background
colour without setting the text colour, resulting in the colour being
too low-contrast against the background.
Use `?colorOnPrimary` to get the correct colour.
Switching to the Material 3 themes caused the previous list dividers to
disappear.
Replace `DividerItemDecoration` with `MaterialDividerItemDecoration` to
restore them.
The previous code would always fetch the latest statuses when the app
restarts, jumping the user to the top of the home timeline. This is
because state.anchorPosition was null in this case.
Fix this by passing the saved initialKey to CachedTimelineRemoteMediator
and using it to construct a page of statuses around the requested
status.
This restores the user's reading position, and ensures that if the
user is at the top of the list their reading position is not reset
to the second item in the list.
Fixes#41, #42
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
The previous code didn't collect the uiState, so it was fixed at the
default value, ignoring any changes that happened over the life of
the viewmodel.
Fix that, so that the FAB will hide/show on scroll according to the
user's preferences.
While I'm here simplify the show/hide logic. The previous code would
ignore the user's preference if scrolling up. There doesn't seem to
be a good reason for that, and spelunking 6+ years back through the
history didn't find a justification for that behaviour in the original
commit.
Fixes#15
Scrolling a thread, set of search results, or viewing a thread would
cause the toolbar to flicker as items moved under it.
Fix this by configuring the toolbar to `liftOnScroll` in the relevant
layouts.
It needs to be configured with the view (or ID of the view) that it
will be scrolling. For views that are in the same layout this is done
with the `liftOnScrollTargetViewId` attribute.
For views that are in different layouts (e.g. the toolbar is in
the activity and the scrolling view is in a fragment) the app bar's
`setLiftOnScrollTargetView` method must be called.
Do this in `TimelineFragment` if the hosting activity is a new
interface `AppBarLayoutHost`. Implement this interface in
`StatusListActivity`.
Update the relevant layouts to use `MaterialToolbar`.
Fixes#21
First crash appeared to be caused by a failure to find the
`attr/colorBackgroundAccent` colour from the theme.
It wasn't clear why the attribute could not be found, so to fix it was
simpler to remove the color and attribute entirely, and replace it with
something more appropriate from the Material 3 tokens.
- Preview cards are stroked with `colorOutline`
- Poll options use `colorPrimary` (user's vote) or `colorSecondary`
(other choices) with appropriate text colours.
- Links in link preview cards use `android:attr/textColorLink`
- The placeholder icon in preview cards uses `?android/textColorLink`
- Remove it from `help_message_background`, and stroke with
`?colorOutline`
Doing this I discovered several places where a colour was being
specified unnecessarily, those have been removed.
To make it easier to understand the theme hierarchy that has been
collapsed and renamed to follow Android conventions.
- AppTheme -> Base.Theme.Pachli
- BaseTheme -> Theme.Pachli
- DefaultTheme has been removed as unnecessary
This unearthed a second crash, where `attr/actionBarSizeWithSubtitle`
was not found.
To fix that create an explicit style for toolbars that need it, and
apply the style (`Pachli.Widget.Toolbar`).
This also surfaced a third problem, where the `fragment_timeline*`
layouts had not been updated in `layout-sw640dp`, so those have been
updated to reflect the same views/IDs as the default `fragment_timeline`
layout.
These changes caused a small chain of "unused resource" lint errors,
which have been fixed by removing the unused colours.
The Android Material libraries were also being implicitly depended on
through other library imports instead of being explicit. So include
them as an explicit dependency.
Fixes#18
The previous code was operating on the wrong text, resulting in normal
URL spans (which have an underline) being applied, instead of the
correct spans (which don't).
Fix this by using the correct length.
Previous code created hashtag filters without the `#`, so muting the
tag `#something` would filter all posts that contained `something`,
with or without the `#`.
Fix this when creating filters, and only remove filters (when unmuting)
if the title and contents match.
Show a snackbar when hashtags are successfully muted/unmuted, so the
user is aware something happened.
While drafting the policy I noticed that the `READ_MEDIA_*` permissions
could be added (for newer devices), the `ACCESS_NETWORK_STATE`
permission was missing, and `VIBRATE` was unnecessary.
- 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
Requiring trailing commas on multi-line lists of items (declarations
and call sites) reduces future repository churn when those lines are
changed, but introduces additional churn now.
Bite the bullet and make the change, as well as adjusting lines that
were too long / indented incorrectly.
The changes were performed automatically, using the `ktlintFormat` task.
Based on https://github.com/tuskyapp/Tusky/pull/3968 by
https://github.com/tinsukE
Filters that the user had set for the notifications timeline were not
being applied.
Fix this in NotificationsViewModel; fetch the user's filters and apply
them against the status in a notification. If the status should be
hidden it is removed, and if it should show a warning it does so.
The user can click through the warning to show the status.
Prior to this change the user had to repeatedly tap "Load more" when
scrolling. This is tedious for the user.
In addition, the previous code had bugs that meant that not all statuses
were being loaded. Users could leave the app for a while (overnight,
say), and when returning would discover far fewer statuses than had
actually been posted.
Fix this, following the architecture first introduced for notifications
(Fragment -> ViewModel -> Repository -> Source/Mediator).
- Load statuses for cached and non-cached timelines using Paging3
- Show Failures during a load, and the user can retry
- Delete the "Reading order" preference, it is no longer necessary
Android's choices for font customisation can be limited, depending on
the vendor. Allow users to choose from a small collection of embedded
fonts, chosen by asking users for recommendations.
The font choice is implemented as a preference. Provide a custom dialog
that shows the fonts (in that font) so the user can see what they're
choosing between.
Ensure the font's license information is displayed in the "About"
section.
The previous code did not credit all third party code used in the app,
or provide access to the licenses.
Fix this by adopting the "aboutlibraries" library, which processes
dependencies at build time and generates a list of dependencies,
versions, and license information to display to the user.
Use this to also ensure that the non-source dependencies (artwork,
emoji) are given appropriate credit.
- Remove the existing restriction on the number of tabs
- Allow the tabs to scroll to display more
- Update UI and text resources to remove obsolete content
- Implement the trending posts API
- Display trending statuses as a new Timeline kind
- Allow the user to add trending statuses to a dedicated tab
- Always show the "Trending" option in the navigation menu
- Implement the trending links API
- Provide a Fragment/ViewModel/Repository and Adapter/ViewHolder set
to display the content
- Show all trends (as a pageable fragment list) in TrendingActivity
- Allow the user to add trending links to a dedicated tab
- Always show the "Trending" option in the navigation menu
### Objective
* Prevent data loss when the user inadvertently hits back or wants to
leave the profile edition with unsaved changes.
### Description
* To limit the number of changes to the existing codebase, I merely
re-used the same method used by `save()` in the ViewModel to decide
whether to make a network request or simply return the profile as-is.
* ~A bit of code juggling around in the ViewModel and I was able to use
the logic for all the encoding of each profile field (Which is what the
ViewModel caches in memory).~ Thanks @Lakoja for improving this in the
VM.
* A couple of internal data classes used as helpers to move all the
fields around (now that they are no longer used in one single place)
were introduced.
### Potential Optimizations
* ~The profile encoding is done twice (once for checking, and then again
if the user has to actually save it). I'd say this is a negligible price
to pay, since the alternative would be to create a different set of
comparisons and/or keeping another profile in memory for the purpose of
comparison.~
### Visual Improvement
* I believe the Dialog is difficult to see, but it's being displayed
with Tusky's theme. Perhaps there's a better style to apply in this
case? (or maybe the edit profile activity shouldn't have the same
background color as dialogs?!)
### Issue
* #3486
Set the "System Design" as the default theme.
This ensures that the app's initial behaviour respect's the user's system-wide theme choice, while still allowing the user to adjust it later.
This is only done for new installs of Tusky. If the user is upgrading from a previous release and they did not have an explicit theme set then the dark theme is used, and the UX does not change.
dc9e9f2aeb
modifed the code that fetched the value of EXTRA_NOTIFICATION_TYPE in an
intent, to use getSerializable().
However, the value was being placed in to the intent using putString().
This caused an exception when trying to update the summary notification,
so it would never update.
```
java.lang.ClassCastException: java.lang.String cannot be cast to com.keylesspalace.tusky.entity.Notification$Type
at com.keylesspalace.tusky.components.notifications.NotificationHelper.updateSummaryNotifications(NotificationHelper.java:321)
at com.keylesspalace.tusky.components.notifications.NotificationFetcher.fetchAndShow(NotificationFetcher.kt:87)
at com.keylesspalace.tusky.components.notifications.NotificationFetcher$fetchAndShow$1.invokeSuspend(Unknown Source:14)
```
Fix this by placing the value in to the intent using putSerializable(),
to match how it will be fetched.
Martijn de Boer
Jener Gomes
Kalle Kniivilä
ButterflyOfFire
Nik Clayton
bittin1ddc447d824349b2
sanao
renovate[bot]
sköldpadda
sanao
vinz
chaoscalm
chaoscalm
Weblate (bot)
Levi Bard
Mike Haynes
Martin Marconcini
Martin Marconcini
Lakoja
SpaceFox
Weblate
