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
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
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
The "trending" functionality will expand to include trending links and
posts. But at the moment the "Trending" references in the code are
exclusively to hashtags.
Rename "Trending" to "TrendingTags" or similar everywhere necessary in
order to prepare for this.
This includes a database migration, as the identifier for the "Trending
tags" tab in the account preferences was changed from "Trending" to
"TrendingTags". The migration updates the stored value if necessary.
Before, intent creation was scattered across multiple sites, with account switching logic in both `ComposeActivity` and `MainActivity`.
Now, intents are only created in `MainActivity` Companion, and account switching only occurs in `MainActivity`
Fixes#3695
Android lint was erroneously warning that the forEach construct in
Kotlin required API 24+, which is incorrect, see
https://issuetracker.google.com/issues/185418482.
Work around that by forcing the Android lint version to 8.1.0.
This triggered some additional checks, which have been ignored, and a
new baseline.
Fix a crash where workers, in some conditions, should show a notification. These are sent to a dedicated channel with no importance.
Convert NotificationWorker to a CoroutineWorker and remove its use of `runBlocking`.
Fixes#3754
* Disable lint checks for unused resource IDs
The check doesn't catch some instances where resources are used through viewbinding, and has too many false positives to be useful.
* Regenerate lint baseline
Delete the existing file, then regenerated with `.\gradlew lintBlueDebug -Dlint.baselines.continue=true`
* Enforce lint cleanliness when building
The volume of lintable issues is growing. To stem the tide:
1. Add `app/lint-baseline.xml`, which contains the current set of lint issues.
Any issue appearing here will not cause the build to fail.
2. Move lint configuration settings in to `lint.xml`.
3. Update the lint configuration so that any issue (i.e., any issue not
in lint-baseline.xml) causes a build failure.
4. Add the lint tasks as depedency when assembling an APK, to ensure the
lint checks are run.
* lint: Convert launcher images to webp
* Move lint.xml location
* Don't lint when assembling
* Update baseline
Nik Clayton
Konrad Pozniak
UlrichKu