This refactors the NotificationsFragment and related classes to Kotlin &
paging.
While trying to preserve as much of the original behavior as possible,
this adds the following improvements as well:
- The "show notifications filter" preference was added again
- The "load more" button now has a background ripple effect when clicked
- The "legal" report category of Mastodon 4.2 is now supported in report
notifications
- Unknown notifications now display "unknown notification type" instead
of an empty line
Other code quality improvements:
- All views from xml layouts are now referenced via ViewBindings
- the classes responsible for showing system notifications were moved to
a new package `systemnotifications` while the classes from this
refactoring are in `notifications`
- the id of the local Tusky account is now called `tuskyAccountId` in
all places I could find
closes https://github.com/tuskyapp/Tusky/issues/3429
---------
Co-authored-by: Zongle Wang <wangzongler@gmail.com>
The only crash so far in the 25.0-beta1 crash reports. Probably not a
regression though as that code did not change in a while.
```
Exception java.lang.IllegalArgumentException: Max number of dynamic shortcuts exceeded
at android.os.Parcel.createExceptionOrNull (Parcel.java:3032)
at android.os.Parcel.createException (Parcel.java:3012)
at android.os.Parcel.readException (Parcel.java:2995)
at android.os.Parcel.readException (Parcel.java:2937)
at android.content.pm.IShortcutService$Stub$Proxy.addDynamicShortcuts (IShortcutService.java:618)
at android.content.pm.ShortcutManager.addDynamicShortcuts (ShortcutManager.java:240)
at androidx.core.content.pm.ShortcutManagerCompat.addDynamicShortcuts (ShortcutManagerCompat.java:334)
at com.keylesspalace.tusky.util.ShareShortcutHelper$updateShortcut$1.invokeSuspend (ShareShortcutHelper.kt:96)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run (DispatchedTask.kt:104)
at android.os.Handler.handleCallback (Handler.java:984)
at android.os.Handler.dispatchMessage (Handler.java:104)
at android.os.Looper.loopOnce (Looper.java:238)
at android.os.Looper.loop (Looper.java:357)
at android.app.ActivityThread.main (ActivityThread.java:8094)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:957)
Caused by android.os.RemoteException: Remote stack trace:
at com.android.server.pm.ShortcutService.enforceMaxActivityShortcuts (ShortcutService.java:1768)
at com.android.server.pm.ShortcutPackage.enforceShortcutCountsBeforeOperation (ShortcutPackage.java:1551)
at com.android.server.pm.ShortcutService.addDynamicShortcuts (ShortcutService.java:2161)
at android.content.pm.IShortcutService$Stub.onTransact (IShortcutService.java:281)
at android.os.Binder.execTransactInternal (Binder.java:1294)
```
This pull request removes the remaining RxJava code and replaces it with
coroutine-equivalent implementations.
- Remove all duplicate methods in `MastodonApi`:
- Methods returning a RxJava `Single` have been replaced by suspending
methods returning a `NetworkResult` in order to be consistent with the
new code.
- _sync_/_async_ method variants are replaced with the _async_ version
only (suspending method), and `runBlocking{}` is used to make the async
variant synchronous.
- Create a custom coroutine-based implementation of `Single` for usage
in Java code where launching a coroutine is not possible. This class can
be deleted after remaining Java code has been converted to Kotlin.
- `NotificationsFragment.java` can subscribe to `EventHub` events by
calling the new lifecycle-aware `EventHub.subscribe()` method. This
allows using the `SharedFlow` as single source of truth for all events.
- Rx Autodispose is replaced by `lifecycleScope.launch()` which will
automatically cancel the coroutine when the Fragment view/Activity is
destroyed.
- Background work is launched in the existing injectable
`externalScope`, since using `GlobalScope` is discouraged.
`externalScope` has been changed to be a `@Singleton` and to use the
main dispatcher by default.
- Transform `ShareShortcutHelper` to an injectable utility class so it
can use the application `Context` and `externalScope` as provided
dependencies to launch a background coroutine.
- Implement a custom Glide extension method
`RequestBuilder.submitAsync()` to do the same thing as
`RequestBuilder.submit().get()` in a non-blocking way. This way there is
no need to switch to a background dispatcher and block a background
thread, and cancellation is supported out-of-the-box.
- An utility method `Fragment.updateRelativeTimePeriodically()` has been
added to remove duplicate logic in `TimelineFragment` and
`NotificationsFragment`, and the logic is now implemented using a simple
coroutine instead of `Observable.interval()`. Note that the periodic
update now happens between onStart and onStop instead of between
onResume and onPause, since the Fragment is not interactive but is still
visible in the started state.
- Rewrite `BottomSheetActivityTest` using coroutines tests.
- Remove all RxJava library dependencies.
builds upon work from #4082
Additionally fixes some deprecations and adds support for [predictive
back](https://developer.android.com/guide/navigation/custom-back/predictive-back-gesture).
I also refactored how the activity transitions work because they are
closely related to predictive back. The awkward
`finishWithoutSlideOutAnimation` is gone, activities that have been
started with slide in will now automatically close with slide out.
To test predictive back you need an emulator or device with Sdk 34
(Android 14) and then enable it in the developer settings.
Predictive back requires the back action to be determined before it
actually occurs so the system can play the right predictive animation,
which made a few reorganisations necessary.
closes#4082closes#4005
unlocks a bunch of dependency upgrades that require sdk 34
---------
Co-authored-by: Goooler <wangzongler@gmail.com>
There are some new rules, I think they mostly make sense, except for the
max line length which I had to disable because we are over it in a lot
of places.
---------
Co-authored-by: Goooler <wangzongler@gmail.com>
Turns out that the crash I thought will not occur with #4153 did occur
again. 😒
But this time I managed to reproduce it (faking a slow network for that
one request only and then quickly switching activities to get it
destroyed) so I'm sure it is fixed, and I did a check for possible side
effects but it seems Glide is clever enough to cancel all requests by
itself.
<details>
<summary>stacktrace</summary>
```
Exception java.lang.IllegalArgumentException: You cannot start a load for a destroyed activity
at com.bumptech.glide.manager.RequestManagerRetriever.assertNotDestroyed (RequestManagerRetriever.java:236)
at com.bumptech.glide.manager.RequestManagerRetriever.get (RequestManagerRetriever.java:110)
at com.bumptech.glide.manager.RequestManagerRetriever.get (RequestManagerRetriever.java:176)
at com.bumptech.glide.Glide.with (Glide.java:634)
at com.keylesspalace.tusky.MainActivity$setupDrawer$2.cancel (MainActivity.kt:573)
at com.mikepenz.materialdrawer.util.DrawerImageLoader.cancelImage (DrawerImageLoader.java:56)
at com.mikepenz.materialdrawer.model.BaseDescribeableDrawerItem.unbindView (BaseDescribeableDrawerItem.kt:95)
at com.mikepenz.materialdrawer.model.BaseDescribeableDrawerItem.unbindView (BaseDescribeableDrawerItem.kt:20)
at com.mikepenz.fastadapter.listeners.OnBindViewHolderListenerImpl.unBindViewHolder (OnBindViewHolderListenerImpl.java:36)
at com.mikepenz.fastadapter.FastAdapter.onViewRecycled (FastAdapter.kt:410)
at androidx.recyclerview.widget.RecyclerView$Recycler.dispatchViewRecycled (RecyclerView.java:7346)
at androidx.recyclerview.widget.RecyclerView$Recycler.addViewHolderToRecycledViewPool (RecyclerView.java:7108)
at androidx.recyclerview.widget.RecyclerView$Recycler.recycleViewHolderInternal (RecyclerView.java:7059)
at androidx.recyclerview.widget.RecyclerView.removeAnimatingView (RecyclerView.java:1556)
at androidx.recyclerview.widget.RecyclerView$ItemAnimatorRestoreListener.onAnimationFinished (RecyclerView.java:13564)
at androidx.recyclerview.widget.RecyclerView$ItemAnimator.dispatchAnimationFinished (RecyclerView.java:14066)
at androidx.recyclerview.widget.SimpleItemAnimator.dispatchChangeFinished (SimpleItemAnimator.java:328)
at androidx.recyclerview.widget.DefaultItemAnimator.endChangeAnimationIfNecessary (DefaultItemAnimator.java:437)
at androidx.recyclerview.widget.DefaultItemAnimator.endChangeAnimationIfNecessary (DefaultItemAnimator.java:418)
at androidx.recyclerview.widget.DefaultItemAnimator.endAnimations (DefaultItemAnimator.java:588)
at androidx.recyclerview.widget.RecyclerView.onDetachedFromWindow (RecyclerView.java:3383)
at android.view.View.dispatchDetachedFromWindow (View.java:20898)
at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:3956)
at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:3948)
at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:3948)
at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:3948)
at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:3948)
at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:3948)
at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:3948)
at android.view.ViewGroup.dispatchDetachedFromWindow (ViewGroup.java:3948)
at android.view.ViewRootImpl.dispatchDetachedFromWindow (ViewRootImpl.java:5114)
at android.view.ViewRootImpl.doDie (ViewRootImpl.java:8309)
at android.view.ViewRootImpl.die (ViewRootImpl.java:8286)
at android.view.WindowManagerGlobal.removeViewLocked (WindowManagerGlobal.java:538)
at android.view.WindowManagerGlobal.removeView (WindowManagerGlobal.java:479)
at android.view.WindowManagerImpl.removeViewImmediate (WindowManagerImpl.java:162)
at android.app.ActivityThread.handleDestroyActivity (ActivityThread.java:5564)
at android.app.ActivityThread.handleRelaunchActivityInner (ActivityThread.java:5842)
at android.app.ActivityThread.handleRelaunchActivity (ActivityThread.java:5758)
at android.app.servertransaction.ActivityRelaunchItem.execute (ActivityRelaunchItem.java:71)
at android.app.servertransaction.ActivityTransactionItem.execute (ActivityTransactionItem.java:45)
at android.app.servertransaction.TransactionExecutor.executeCallbacks (TransactionExecutor.java:135)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:95)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2293)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:329)
at android.app.ActivityThread.main (ActivityThread.java:8058)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1026)
```
</details>
Saw an ANR (app not responding) error being reported in the Play console
and then found this. Sorry but `runBlocking` in production code is an
absolute no go.
Another fix for a memory leak. This one is not as big as #4150, but
still worth fixing for memory constrained devices imo.
The `DrawerImageLoader` implementation (a global singleton) references a
member of the `MainActivity`, causing the whole activity to leak.
This weird construct was introduced in #1989 to fix a crash, but I think
since we migrated to coroutines it is no longer necessary because all
calls get correctly cancelled. I tried reproducing the crash but could
not, so I'm pretty sure it is fine. I would appreciate it if someone
else could try it as well though.
(The crash could be reproduced on slow internet, when
`onFetchUserInfoSuccess` was called while the activity was being
destroyed, causing Glide to crash the app because it can't use destroyed
activities. `onFetchUserInfoSuccess` is now no longer called in this
case because it is inside a `lifecycleScope.launch` block.)
Not quite sure why/when this happens - every stack trace is not our
code, but I do get an ClassNotFoundException for Notification$Type with
the new reverted code.
The notification fetching (worker) then stops/crashes so I never get an
Android notification.
It might have something to do with
https://github.com/tuskyapp/Tusky/pull/3732 ?
Previously the notification filter and clear actions were shown as
buttons in the UI, with a preference that determined whether they were
displayed.
Remove this preference, and display them as menu items.
- "Filter notifications" is shown as an icon, if possible
- "Clear notifications" is only ever shown as a menu item, to reduce the
chance the user inadvertently selects it
To ensure that the options menu appears correctly, remove the code that
creates a "fake" action bar, and adjust the layouts so that there are
three toolbars;
- mainToolbar -- displays the icons, and the current "location" (Home,
Notifications, etc)
- topNav -- displays the row of tabs at the top
- bottomNav -- displays the row of tabs at the bottom
Only one of them is set as the support action bar (depending on the
user's preferences). This provides the "show a logo" and "show the
options menu" functionality as standard, without needing to re-implement
as the previous code did.
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
The previous code used `notificationTabPosition`, which was never
changed, so always 0.
This meant that if you e.g., got to `MainActivity` by clicking on a
notification, and the notification tab was current, the title would
still show "Home".
Fix that by using the existing `position` variable which represents the
currently selected tab, and ensure the correct title is shown.
Fixes#3864.
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
Previous code was:
```
for (i in tabs.indices) {
// ...
if (tabs[i].id == LIST) {
tab.contentDescription = tabs[i].arguments[1]
} else {
tab.setContentDescription(tabs[i].text)
}
// ...
```
When I converted it over, `i` was replaced with `position`, but I misread `tab.contentDescription = tabs[i].arguments[1]` as `tab.contentDescription = tabs[i].arguments[i]`.
Put the `1` back.
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add initial feature for viewing trending graphs. Currently only views hash tag trends.
Contains API additions, tab additions and a set of trending components.
* Add clickable system through a LinkListener. Duplicates a little code from SFragment.
* Add accessibility description.
* The background for the graph should match the background for black theme too.
* Add error handling through a state flow system using existing code as an example.
* Graphing: Use a primary and a secondary line. Remove under line fill. Apply line thickness. Dotted end of line.
* Trending changes: New layout for trending: Cell. Use ViewBinding. Add padding to RecyclerView to stop the FAB from hiding content. Multiple bugs in GraphView resolved. Wide (landscape, for example) will show 4 columns, portrait will show 2. Remove unused base holder class. ViewModel invalidate scoping changed. Some renaming to variables made. For uses and accounts, use longs. These could be big numbers eventually. TagViewHolder renamed to TrendingTagViewHolder.
* Trending changes: Remove old layout. Update cell textsizes and use proper string. Remove bad comment.
* Trending changes: Refresh the main drawer when the tabs are edited. This will allow the trending item to toggle.
* Trending changes: Add a trending activity to be able to view the trending data from the main drawer.
* Trending changes: The title text should be changed to Trending Hashtags.
* Trending changes: Add meta color to draw axis etc. Draw the date boundaries on the graph. Remove dates from each cell and place them in the list as a header. Graphs should be proportional to the highest historical value. Add a new interface to control whether the FAB should be visible (important when switching tabs, the state is lost). Add header to the adapter and viewdata structures. Add QOL extensions for getting the dates from history.
* Trending changes: Refresh FAB through the main activity and FabFragment interface. Trending has no FAB.
* Trending changes: Make graph proportional to the highest usage value. Fixes to the graph ratio calculations.
* Trending changes: KtLintFix
* Trending changes: Remove accidental build gradle change. Remove trending cases. Remove unused progress. Set drawer button addition explicitly to false, leaving the code there for future issue #3010. Remove unnecessary arguments for intent. Remove media preview preferences, there is nothing to preview. No padding between hashtag symbol and text. Do not ellipsize hashtags.
* Trending changes: Use bottomsheet slide in animation helper for opening the hashtag intent. Remove explicit layout height from the XML and apply it to the view holder itself. The height was not being respected in XML.
* Use some platform standards for styling
- Align on an 8dp grid
- Use android:attr for paddingStart and paddingEnd
- Use textAppearanceListItem variants
- Adjust constraints to handle different size containers
* Correct lineWidth calculations
Previous code didn't convert the value to pixels, so it was always displaying
as a hairline stroke, irrespective of the value in the layout file.
While I'm here, rename from lineThickness to lineWidth, to be consistent
with parameters like strokeWidth.
* Does not need to inherit from FabFragment
* Rename to TrendingAdapter
"Paging" in the adapter name is a misnomer here
* Clean up comments, use full class name as tag
* Simplify TrendingViewModel
- Remove unncessary properties
- Fetch tags and map in invalidate()
- emptyList() instead of listOf() for clarity
* Remove line dividers, use X-axis to separate content
Experiment with UI -- instead of dividers between each item, draw an explicit
x-axis for each chart, and add a little more vertical padding, to see if that
provides a cleaner separation between the content
* Adjust date format
- Show day and year
- Use platform attributes for size
* Locale-aware format of numbers
Format numbers < 100,000 by inserting locale-aware separators. Numbers larger
are scaled and have K, M, G, ... etc suffix appended.
* Prevent a crash if viewData is empty
Don't access viewData without first checking if it's empty. This can be the
case if the server returned an empty list for some reason, or the data has
been filtered.
* Filter out tags the user has filtered from their home timeline
Invalidate the list if the user's preferences change, as that may indicate
they've changed their filters.
* Experiment with alternative layout
* Set chart height to 160dp to align to an 8dp grid
* Draw ticks that are 5% the height of the x-axis
* Legend adjustments
- Use tuskyblue for the ticks
- Wrap legend components in a layout so they can have a dedicated background
- Use a 60% transparent background for the legend to retain legibility
if lines go under it
* Bezier curves, shorter cell height
* More tweaks
- List tags in order of popularity, most popular first
- Make it clear that uses/accounts in the legend are totals, not current
- Show current values at end of the chart
* Hide FAB
* Fix crash, it's not always hosted in an ActionButtonActivity
* Arrange totals vertically in landscape layout
* Always add the Trending drawer menu if it's not a tab
* Revert unrelated whitespace changes
* One more whitespace revert
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* make BlocksAdapter use viewbinding
* remove LoadingFooterViewHolder
* cleanup code
* move accountlist to component packes
* make FollowRequestsHeaderAdapter use viewbinding
* add license to MutesAdapter
* move accountlist to component packages
* use ConstraintLayout in item_blocked_user.xml
* support the bot badge everywhere
* cleanup code
* cleanup xml files
* ktlint
* ktlint
* First attempt at user notifications of failure when media upload fails
* Drafts alert displays alert
* ktLint
* Fix defaced 46.json, add 47.json
* Mock draftsNeedUserAlert in MainActivityTest to prevent spurious failure
* Friendlier posts-failed message
* Create DraftsAlert object
* DraftsAlert works
* Not the cleanest, but DraftsAlert works with multiple accounts
* Use plural strings
* KtLint
* Clean up debug prints
* Simplify DraftsAlert per Conny suggestions
* Text change suggested by Conny
* ktLint again
* Back out test changes
* Fix MainActivityTest for new approach
* Tweak debug log
* Do not use GlobalScope for coroutines
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Ensure the user can't have two simultaneous "Load more" coroutines
Having two simultanous coroutines would break the calculation used to figure
out which item in the list to scroll to after a "Load more" in the timeline.
Do this by:
- Creating a TimelineUiState and associated flow that tracks the "Load more"
state
- Updating this in the (Cached|Network)TimelineViewModel
- Listening for changes to it in TimelineFragment, and notifying the adapter
- The adapter will disable any placeholder views while "Load more" is active
* Revert changes that loaded the oldest statuses instead of the newest
* Be more robust about locating the status to scroll to
Weirdness with the PagingData library meant that positionStart could still be
wrong after "Load more" was clicked.
Instead, remember the position of the "Load more" item and the ID of the
status immediately after it.
When new items are added, search for the remembered status at the position of
the "Load more" item. This is quick, testing at most LOAD_AT_ONCE items in
the adapter.
If the remembered status is not visible on screen then scroll to it.
* Lint
* Add a preference to specify the reading order
Default behaviour (oldest first) is for "load more" to load statuses and
stay at the oldest of the new statuses.
Alternative behaviour (if the user is reading from top to bottom) is to
stay at the newest of the new statuses.
* Move ReadingOrder enum construction logic in to the enum
* Jump to top if swipe/refresh while preferring newest-first order
* Show a circular progress spinner during "Load more" operations
Remove a dedicated view, and use an icon on the button instead.
Adjust the placeholder attributes and styles accordingly.
* Remove the "loadMoreActive" property
Complicates the code and doesn't really achieve the desired effect. If the
user wants to tap multiple "Load more" buttons they can.
* Update comments in TimelineFragment
* Respect the user's reading order preference if it changes
* Add developer tools
This is for functionality that makes it easier for developers to interact
with the app, or get it in to a known-state.
These features are for use by users, so are only visible in debug builds.
* Adjust how content is loaded based on preferred reading order
- Add the readingOrder to TimelineViewModel so derived classes can use it.
- Update the homeTimeline API to support the `minId` parameter and update
calls in NetworkTimelineViewModel
In CachedTimelineViewModel:
- Set the bounds of the load to be the status IDs on either side of the
placeholder ID (update TimelineDao with a new query for this)
- Load statuses using either minId or sinceId depending on the reading order
- Is there was no overlap then insert the new placeholder at the start/end
of the list depending on reading order
* Lint
* Rename unused dialog parameter to _
* Update API arguments in tests
* Simplify ReadingOrder preference handling
* Fix bug with Placeholder and the "expanded" property
If a status is a Placeholder the "expanded" propery is used to indicate
whether or not it is loading.
replaceStatusRange() set this property based on the old value, and the user's
alwaysOpenSpoiler preference setting.
This shouldn't have been used if the status is a Placeholder, as it can lead
to incorrect loading states.
Fix this.
While I'm here, introduce an explicit computed property for whether a
TimelineStatusEntity is a placeholder, and use that for code clarity.
* Set the "Load more" button background to transparent
* Fix typo.
* Inline spec, update comment
* Revert 1480c6aa3ac5c0c2d362fb271f47ea2259ab14e2
Turns out the behaviour is not desired.
* Remove unnecessary Log call
* Extract function
* Change default to newest first
* Fix off-by-one error in HttpHeaderLink
Link headers with multiple URLs with multiple parameters were being parsed
incorrectly.
Detected by adding unit tests ahead of converting to Kotlin.
* Convert util/HttpHeaderLink from Java to Kotlin
* Convert util/ThemeUtils from Java to Kotlin
* Convert util/TimestampUtils from Java to Kotlin
* Add tests for PairedList
* Convert util/PairedList from Java to Kotlin
* Implement feedback from PR
* Relicense as GPL
The "Enable swipe gesture to switch between tabs" preference was ignored
on the tabs on a profile page ("Posts", "With Replies", "Pinned", "Media"),
and search ("Posts", "Accounts", "Hashtags").
Fix this.
While I'm here, replace a string for the preference name in MainActivity.kt
with a constant.
Fixes https://github.com/tuskyapp/Tusky/issues/2874.
* update to Api 33, fix some deprecations
* fix deprecated serializable/parcelable methods
* ask for notification permission
* fix code formatting
* add back comment in PreferencesActivity
* Preference to disable multiple-login usernames (with problems)
* Fix problem where 'show self username disambiguation' does not take effect immediately because MainActivity needed to be restarted
* Make 'show username in toolbars' a 3-option selector, default when multiple accounts logged in
* Move SHOW_SELF_USERNAME higher in preference fragment
Fixes#793.
This is an implementation for push notifications based on UnifiedPush
for Tusky. No push gateway (other than UP itself) is needed, since
UnifiedPush is simple enough such that it can act as a catch-all
endpoint for WebPush messages. When a UnifiedPush distributor is present
on-device, we will by default register Tusky as a receiver; if no
UnifiedPush distributor is available, then pull notifications are used
as a fallback mechanism.
Because WebPush messages are encrypted, and Mastodon does not send the
keys and IV needed for decryption in the request body, for now the push
handler simply acts as a trigger for the pre-existing NotificationWorker
which is also used for pull notifications. Nevertheless, I have
implemented proper key generation and storage, just in case we would
like to implement full decryption support in the future when Mastodon
upgrades to the latest WebPush encryption scheme that includes all
information in the request body.
For users with existing accounts, push notifications will not be enabled
until all of the accounts have been re-logged in to grant the new push
OAuth scope. A small prompt will be shown (until dismissed) as a
Snackbar to explain to the user about this, and an option is added in
Account Preferences to facilitate re-login without deleting local drafts
and cache.
