closes#4631closes#4629
and other weirdness introduced in Tusky 26.1.
I did a lot of testing on 2 physical devices and multiple emulators. It
definitely is better than before, but probably still not perfect.
Instead of calling the endpoint every time filters are needed, it will
be called only once and the result cached. This will result in quite
some requests less on instances supporting v2.
I also tested v1 filters and made some small improvements. We should
[remove filters v1
support](https://github.com/tuskyapp/Tusky/issues/4538) some time in the
future though.
This PR fixes https://github.com/tuskyapp/Tusky/issues/2798 and is
mostly based on and supersedes
https://github.com/tuskyapp/Tusky/pull/2826 but I have fixed all merge
conflicts and unit tests.
I tested the changes locally and the setting takes effect immediately
for replies, and persists across killing the app.
---------
Co-authored-by: Eva Tatarka <eva@tatarka.me>
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
(this one is for @charlag)
Calling `PreferenceManager.getDefaultSharedPreferences()` will read the
preference file from disk every time. This PR makes `SharedPreferences`
a singleton so they will only be created once at appstart (with a few
exceptions where it is hard to inject, e.g. in the `openLink` helper)
which should help getting our ANRs down.
```
StrictMode policy violation; ~duration=285 ms: android.os.strictmode.DiskReadViolation
at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1666)
at libcore.io.BlockGuardOs.access(BlockGuardOs.java:74)
at libcore.io.ForwardingOs.access(ForwardingOs.java:128)
at android.app.ActivityThread$AndroidOs.access(ActivityThread.java:8054)
at java.io.UnixFileSystem.checkAccess(UnixFileSystem.java:313)
at java.io.File.exists(File.java:813)
at android.app.ContextImpl.ensurePrivateDirExists(ContextImpl.java:790)
at android.app.ContextImpl.ensurePrivateDirExists(ContextImpl.java:781)
at android.app.ContextImpl.getPreferencesDir(ContextImpl.java:737)
at android.app.ContextImpl.getSharedPreferencesPath(ContextImpl.java:962)
at android.app.ContextImpl.getSharedPreferences(ContextImpl.java:583)
at android.content.ContextWrapper.getSharedPreferences(ContextWrapper.java:221)
at android.content.ContextWrapper.getSharedPreferences(ContextWrapper.java:221)
at androidx.preference.PreferenceManager.getDefaultSharedPreferences(PreferenceManager.java:119)
at com.keylesspalace.tusky.BaseActivity.onCreate(BaseActivity.java:96)
...
```
- Remove empty file `ExampleInstrumentedTest.java`.
- Replace deprecated `MigrationTestHelper` constructor call.
- Add reified inline extension methods for `Bundle` and `Intent` to
retrieve `Parcelable` and `Serializable` objects by calling the core
`BundleCompat` and `IntentCompat` methods, to allow shorter syntax and
removing the need to pass the class explicitly.
- Replace deprecated `drawable.setColorFilter()` with simpler
`drawable.setTint()` (uses blend mode `SRC_IN` by default, has the same
effect as `SRC_ATOP` when the source is a color).
- Rename shadowed variables (mostly caught exceptions).
- Remove unnecessary `.orEmpty()` on non-null fields.
- Replace `.size() == 0` with `.isEmpty()`.
- Prevent `NullPointerException` when `account.getDisplayName()` is
`null` in `StatusBaseViewHolder.setDisplayName()`.
- Declare `customEmojis` argument as non-null in
`StatusBaseViewHolder.setDisplayName()` because it calls
`CustomEmojiHelper.emojify()` which now requires it to be non-null.
- Prevent `NullPointerException` when no matching filter is found in
`StatusBaseViewHolder.setupFilterPlaceholder()`.
- Remove deprecated call to `setTargetFragment()` (target fragment is
not used anyway).
- Remove deprecated call to `isUserVisibleHint()` and test if the view
has been destroyed instead.
- Remove some unused imports.
- Remove unnecessary casts.
- Rename arguments to supertype names when a warning is shown.
- Prevent a potential memory leak by clearing the
`toolbarVisibilityDisposable` reference in `onDestroyView()`.
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>
**! ! Warning**: Do not merge before testing every API call and database
read involving JSON !
**Gson** is obsolete and has been superseded by **Moshi**. But more
importantly, parsing Kotlin objects using Gson is _dangerous_ because
Gson uses Java serialization and is **not Kotlin-aware**. This has two
main consequences:
- Fields of non-null types may end up null at runtime. Parsing will
succeed, but the code may crash later with a `NullPointerException` when
trying to access a field member;
- Default values of constructor parameters are always ignored. When
absent, reference types will be null, booleans will be false and
integers will be zero.
On the other hand, Kotlin-aware parsers like **Moshi** or **Kotlin
Serialization** will validate at parsing time that all received fields
comply with the Kotlin contract and avoid errors at runtime, making apps
more stable and schema mismatches easier to detect (as long as logs are
accessible):
- Receiving a null value for a non-null type will generate a parsing
error;
- Optional types are declared explicitly by adding a default value. **A
missing value with no default value declaration will generate a parsing
error.**
Migrating the entity declarations from Gson to Moshi will make the code
more robust but is not an easy task because of the semantic differences.
With Gson, both nullable and optional fields are represented with a null
value. After converting to Moshi, some nullable entities can become
non-null with a default value (if they are optional and not nullable),
others can stay nullable with no default value (if they are mandatory
and nullable), and others can become **nullable with a default value of
null** (if they are optional _or_ nullable _or_ both). That third option
is the safest bet when it's not clear if a field is optional or not,
except for lists which can usually be declared as non-null with a
default value of an empty list (I have yet to see a nullable array type
in the Mastodon API).
Fields that are currently declared as non-null present another
challenge. In theory, they should remain as-is and everything will work
fine. In practice, **because Gson is not aware of nullable types at
all**, it's possible that some non-null fields currently hold a null
value in some cases but the app does not report any error because the
field is not accessed by Kotlin code in that scenario. After migrating
to Moshi however, parsing such a field will now fail early if a null
value or no value is received.
These fields will have to be identified by heavily testing the app and
looking for parsing errors (`JsonDataException`) and/or by going through
the Mastodon documentation. A default value needs to be added for
missing optional fields, and their type could optionally be changed to
nullable, depending on the case.
Gson is also currently used to serialize and deserialize objects to and
from the local database, which is also challenging because backwards
compatibility needs to be preserved. Fortunately, by default Gson omits
writing null fields, so a field of type `List<T>?` could be replaced
with a field of type `List<T>` with a default value of `emptyList()` and
reading back the old data should still work. However, nullable lists
that are written directly (not as a field of another object) will still
be serialized to JSON as `"null"` so the deserializing code must still
be handling null properly.
Finally, changing the database schema is out of scope for this pull
request, so database entities that also happen to be serialized with
Gson will keep their original types even if they could be made non-null
as an improvement.
In the end this is all for the best, because the app will be more
reliable and errors will be easier to detect by showing up earlier with
a clear error message. Not to mention the performance benefits of using
Moshi compared to Gson.
- Replace Gson reflection with Moshi Kotlin codegen to generate all
parsers at compile time.
- Replace custom `Rfc3339DateJsonAdapter` with the one provided by
moshi-adapters.
- Replace custom `JsonDeserializer` classes for Enum types with
`EnumJsonAdapter.create(T).withUnknownFallback()` from moshi-adapters to
support fallback values.
- Replace `GuardedBooleanAdapter` with the more generic `GuardedAdapter`
which works with any type. Any nullable field may now be annotated with
`@Guarded`.
- Remove Proguard rules related to Json entities. Each Json entity needs
to be annotated with `@JsonClass` with no exception, and adding this
annotation will ensure that R8/Proguard will handle the entities
properly.
- Replace some nullable Boolean fields with non-null Boolean fields with
a default value where possible.
- Replace some nullable list fields with non-null list fields with a
default value of `emptyList()` where possible.
- Update `TimelineDao` to perform all Json conversions internally using
`Converters` so no Gson or Moshi instance has to be passed to its
methods.
- ~~Create a custom `DraftAttachmentJsonAdapter` to serialize and
deserialize `DraftAttachment` which is a special entity that supports
more than one json name per field. A custom adapter is necessary because
there is not direct equivalent of `@SerializedName(alternate = [...])`
in Moshi.~~ Remove alternate names for some `DraftAttachment` fields
which were used as a workaround to deserialize local data in 2-years old
builds of Tusky.
- Update tests to make them work with Moshi.
- Simplify a few `equals()` implementations.
- Change a few functions to `val`s
- Turn `NetworkModule` into an `object` (since it contains no abstract
methods).
Please test the app thoroughly before merging. There may be some fields
currently declared as mandatory that are actually optional.
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>
Posted this as issue #3999 before. The reasoning is personal experiments
and forks may add database fields and must bump the database number to
do so, but this causes massive merge difficulties when Tusky then
inevitably itself bumps the number. To alleviate this, Tusky official
should use only even database numbers, so odd versions are available for
third party scribbling.
There was little discussion positive or negative in #3999 (one proposal
we switch to a date-based number system, which would work but also could
be unnecessarily complicated). With PR #4115 we now have to make a
decision because that's the first post-proposal PR to bump the database
number odd. So, since I see no outright objections, I'd like to
implement this.
@connyduck suggested the best way to implement the proposal would be to
add a comment to the version number's home in AppDatabase.java.
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
# Overview
In the previous code, when you open preferences, there is a section
headed "Filters" with a section called "Tabs"
This is confusing.
# Changes
- Change the section title from "Filters" to "Per-timeline preferences."
- Change the current "Tabs" section to "Home timeline" since it is only
for home timelines
# Screenshots
account preference screen | detail screen
:--: | :--:
|<image
src="https://github.com/tuskyapp/Tusky/assets/62137820/12694f24-b7e3-4ba3-90f5-53740e9c4269"
width="250" />|<image
src="https://github.com/tuskyapp/Tusky/assets/62137820/796e9ac1-76d6-43ef-a087-a1cd2d899ef8"
width="250" />
# Note
- Maybe string resources should have a new property? (for translation)
# Related link
Fixes#3536
---------
Co-authored-by: mcc <andi.m.mcclure@gmail.com>
The idea here is: Everytime we get hold of a new version of a post, we
update everything about that post everywhere.
This makes the distincion between different event types unnecessary, as
everythng is just a `StatusChangedEvent`.
The main benefit is that posts should be up-to-date more often, which is
important considering there is now editing and #3413
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.
Update to Kotlin 1.9.0 and migrate to newer language idioms.
- Remove unnecessary @OptIn for features migrated to mainstream
- Use `data object` where appropriate
- Use new enum `entries` property
Don't use `accountManager.activeAccount` throughout the code.
Instead, get the active account once, and use that over the life of the viewmodel.
As shown in https://github.com/tuskyapp/Tusky/issues/3689#issuecomment-1567219338 the active account can change before the view model is destroyed, and if that happens account information for the account will be written to the wrong account.
Not all servers support the marker API. If they don't the user will
potentially get duplicate Android notifications.
To resolve this, store a copy of the notification marker ID locally as
well. Defer to the remote marker if it exists (and is newer than the
local marker).
Fixes https://github.com/tuskyapp/Tusky/issues/3671
When fetching:
- Maintain a marker with the position of the newest fetched notification
- Use the marker to determine which notifications to fetch
- Fetch notifications with min_id to ensure that none are lost
- Update the marker as necessary
- Perform a one-time immediate fetch of notifications on startup
When creating notifications:
- Identify each notification with tag=${MastodonNotificationId}, id=${account.id}
- Remove activeNotifications field, it's no longer necessary
- Use the tag/id tuple to reliably identify existing notifications and avoid creating duplicates
- Cancelling notifications for an account must iterate over all the notifications, and individually remove the notifications that exist for that account.
- Limit notifications to a maximum of 40 (excluding summary notifications)
- Remove notifications (oldest first) to get under this limit
- Rate limit notification creation to 1 per second, so the OS won't drop them
Adjust the summary notification:
- Ensure the summary notification and the child notifications have the same group key
- Dismiss the summary notification if there is only one child notification
NotificationClearBroadcastReceiver is no longer needed, so remove it, and the need for deletePendingIntent.
Fixes#3625, #3539
- Add a field to AccountEntity to hold the reading position
- Provide a method to save in the viewmodel to save the position
- Save the position when TimelineFragment pauses
Does not restore the position yet.
* Replace "warn"-filtered posts in timelines and thread view with placeholders
* Adapt hashtag muting interface
* Rework filter UI
* Add icon for account preferences
* Clean up UI
* WIP: Use chips instead of a list. Adjust padding
* Scroll the filter edit activity
Nested scrolling views (e.g., an activity that scrolls with an embedded list
that also scrolls) can be difficult UI.
Since the list of contexts is fixed, replace it with a fixed collection of
switches, so there's no need to scroll the list.
Since the list of actions is only two (warn, hide), and are mutually
exclusive, replace the spinner with two radio buttons.
Use the accent colour and title styles on the different heading titles in
the layout, to match the presentation in Preferences.
Add an explicit "Cancel" button.
The layout is a straightforward LinearLayout, so use that instead of
ConstraintLayout, and remove some unncessary IDs.
Update EditFilterActivity to handle the new layout.
* Cleanup
* Add more information to the filter list view
* First pass on code review comments
* Add view model to filters activity
* Add view model to edit filters activity
* Only use the status wrapper for filtered statuses
* Relint
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* Unmodified output from "Convert Java to Kotlin" on NotificationsFragment.java
* Bare minimum changes to get this to compile and run
- Use `lateinit` for `eventhub`, `adapter`, `preferences`, and `scrolllistener`
- Removed override for accountManager, it can be used from the superclass
- Add `?.` where non-nullity could not (yet) be guaranteed
- Remove `?` from type lists where non-nullity is guaranteed
- Explicitly convert lists to mutable where necessary
- Delete unused function `findReplyPosition`
* Remove all unnecessary non-null (!!) assertions
The previous change meant some values are no longer nullable. Remove the
non-null assertions.
* Lint ListStatusAccessibilityDelegate call
- Remove redundant constructor
- Move block outside of `()`
* Use `let` when handling compose button visibility on scroll
* Replace a `requireNonNull` with `!!`
* Remove redundant return values
* Remove or rename unused lambda parameters
* Remove unnecessary type parameters
* Remove unnecessary null checks
* Replace cascading-if statement with `when`
* Simplify calculation of `topId`
* Use more appropriate list properties and methods
- Access the last value with `.last()`
- Access the last index with `.lastIndex`
- Replace logical-chain with `asRightOrNull` and `?.`
- `.isNotEmpty()`, not `!...isEmpty()`
* Inline unnecessary variable
* Use PrefKeys constants instead of bare strings
* Use `requireContext()` instead of `context!!`
* Replace deprecated `onActivityCreated()` with `onViewCreated()`
* Remove unnecessary variable setting
* Replace `size == 0` check with `isEmpty()`
* Format with ktlint, no functionality changes
* Convert NotifcationsAdapter to Kotlin
Does not compile, this is the unchanged output of the "Convert to Kotlin"
function
* Minimum changes to get NotificationsAdapter to compile
* Remove unnecessary visibility modifiers
* Use `isNotEmpty()`
* Remove unused lambda parameters
* Convert cascading-if to `when`
* Simplifiy assignment op
* Use explicit argument names with `copy()`
* Use `.firstOrNull()` instead of `if`
* Mark as lateinit to avoid unnecessary null checks
* Format with ktlint, whitespace changes only
* Bare minimum necessary to demonstrate paging in notifications
Create `NotificationsPagingSource`. This uses a new `notifications2()` API
call, which will exist until all the code has been adapted. Instead of
using placeholders,
Create `NotificationsPagingAdapter` (will replace `NotificationsAdapater`)
to consume this data.
Expose the paging source view a new `NotificationsViewModel` `flow`, and
submit new pages to the adapter as they are available in
`NotificationsFragment`.
Comment out any other code in `NotificationsFragment` that deals with
loading data from the network. This will be updated as necessary, either
here, or in the view model.
Lots of functionality is missing, including:
- Different views for different notification types
- Starting at the remembered notification position
- Interacting with notifications
- Adjusting the UI state to match the loading state
These will be added incrementally.
* Migrate StatusNotificationViewHolder impl. to NotificationsPagingAdapter
With this change `NotificationsPagingAdapter` shows notifications about a
status correctly.
- Introduce a `ViewHolder` abstract class that all Notification view holders
derive from. Modify the fallback view holder to use this.
- Implement `StatusNotificationViewHolder`. Much of the code is from the
existing implementation in the `NotificationAdapater`.
- The original code split the code that binds values to views between the
adapter's `bindViewHolder` method and the view holder's methods.
In this code, all of the binding code is in the view holder, in a `bind`
method. This is called by the adapter's `bindViewHolder` method. This keeps
all the binding logic in the view holder, where it belongs.
- The new `StatusNotificationViewHolder` uses view binding to access its views
instead of `findViewById`.
- Logically, information about whether to show sensitive media, or open
content warnings should be part of the `StatusDisplayOptions`. So add those
as fields, and populate them appropriately.
This affects code outside notification handling, which will be adjusted
later.
* Note some TODOs to complete before the PR is finished
* Extract StatusNotificationViewHolder to a new file
* Add TODO for NotificationViewData.Concrete
* Convert the adapter to take NotificationViewData.Concrete
* Add a view holder for regular status notifications
* Migrate Follow and FollowRequest notifications
* Migrate report notifications
* Convert onViewThread to use the adapter data
* Convert onViewMedia to use the adapter data
* Convert onMore to use the adapter data
* Convert onReply to use the adapter data
* Convert NotificationViewData to Kotlin
* Re-implement the reblog functionality
- Move reblogging in to the view model
- Update the UI via the adapter's `snapshot()` and `notifyItemChanged()`
methods
* Re-implement the favourite functionality
Same approach as reblog
* Re-implement the bookmark functionality
Same approach as reblog
* Add TODO re StatusActionListener interface
* Add TODO re event handling
* Re-implementing the voting functionality
* Re-implement viewing hidden content
- Hidden media
- Content behind a content warning
* Add a TODO re pinning
* Re-implement "Show more" / "Show less"
* Delete unused updateStatus() function
* Comment out the scroll listener for the moment
* Re-implement applying filters to notifications
Introduce `NotificationsRepository`, to provide access to the notifications
stream.
When changing the filters the flow is as follows:
- User clicks "Apply" in the fragment.
- Fragment calls `viewModel.accept()` with a `UiAction.ApplyFilter` (new
class).
- View model maintains a private flow of incoming UI actions. The new action
is emitted to that flow.
- In view model, `notificationFilter` waits for `.ApplyFilter` actions, and
ensures the filter is saved, then emits it.
- In view model, `pagingDataFlow` waits for new items from
`notificationsFilter` and fetches the notifications from the repository in
response. The repository provides `Notification`, so the model maps them to
`NotificationViewData.Concrete` for display by the adapter.
- In view model the UI state also waits for new items from
`notificationsFilter` and emits a new `UiState` every time the filter is
changed.
When opening the fragment for the first time:
- All of the above machinery, but `notificationFilter` also fetches the filter
from the active account and emits that first. This triggers the first fetch
and the first update of `uiState`.
Also:
- Add TODOs for functionality that is not implemented yet
- Delete a lot of dead code from NotificationsFragment
* Include important preference values in `uiState`
Listen to the flow of eventHub events, filtered to preference changes that
are relevant to the notification view.
When preferences change (or when the view model starts), fetch the current
values, and include them in `uiState`.
Remove preference handling from `NotificationsFragment`, and just use
the values from `uiState`.
Adjust how the `useAbsoluteTime` preference is handled. The previous code
loaded new content (via a diffutil) in to the adapter, which would trigger
a re-binding of the timestamp.
As the adapter content is immutable, the new code simply triggers a
re-binding of the views that are currently visible on screen.
* Update UI in response to different load states
Notifications can be loaded at the top and bottom of the timeline. Add a
new layout to show the progress of these loads, and any errors that can
occur.
Catch network errors in `NotificationsPagingSource` and convert to
`LoadState.Error`.
Add a header/footer to the notifications list to show the load state.
Collect the load state from the adapter, use this to drive the visibility
of different views.
* Save and restore the last read notification ID
Use this when fetching notifications, to centre the list around the
notification that was last read.
* Call notifyItemRangeChanged with the correct parameters
* Don't try and save list position if there are no items in the list
* Show/hide the "Nothing to see" view appropriately
* Update comments
* Handle the case where the notification key no longer exists
* Re-implement support for showMediaPreview and other settings
* Re-implement "hide FAB when scrolling" preference
* Delete dead code
* Delete Notifications Adapater and Placeholder types
* Remove NotificationViewData.Concrete subclass
Now there's no Placeholder, everything is a NotificationViewData.
* Improve how notification pages are loaded if the first notification is missing or filtered
* Re-implement clear notifications, show errors
* s/default/from/
* Add missing headers
* Don't process bookmarking via EventHub
- Initiating a bookmark is triggered by the fragment sending a
StatusUiAction.Bookmark
- View model receives this, makes API call, waits for response, emits either
a success or failure state
- Fragment collects success/failure states, updates the UI accordingly
* Don't process favourites via EventHub
* Don't process reblog via EventHub
* Don't process poll votes with EventHub
This removes EventHub from the fragment
* Respond to follow requests via the view model
* Docs and cleanup
* Typo and editing pass
* Minor edits for clarity
* Remove newline in diagram
* Reorder sequence diagram
* s/authorize/accept/
* s/pagingDataFlow/pagingData/
* Add brief KDoc
* Try and fetch a full first page of notifications
* Call the API method `notifications` again
* Log UI errors at the point of handling
* Remove unused variable
* Replace String.format() with interpolation
* Convert NotificationViewData to data class
* Rename copy() to make(), to avoid confusion with default copy() method
* Lint
* Update app/src/main/res/layout/simple_list_item_1.xml
* Update app/src/main/java/com/keylesspalace/tusky/components/notifications/NotificationsPagingAdapter.kt
* Update app/src/main/java/com/keylesspalace/tusky/components/notifications/NotificationsViewModel.kt
* Update app/src/main/java/com/keylesspalace/tusky/fragment/NotificationsFragment.kt
* Update app/src/main/java/com/keylesspalace/tusky/viewdata/NotificationViewData.kt
* Initial NotificationsViewModel tests
* Add missing import
* More tests, some cleanup
* Comments, re-order some code
* Set StateRestorationPolicy.PREVENT_WHEN_EMPTY
* Mark clearNotifications() as "suspend"
* Catch exceptions from clearNotifications and emit
* Update TODOs with explanations
* Ensure initial fetch uses a null ID
* Stop/start collecting pagingData based on the lifecycle
* Don't hide the list while refreshing
* Refresh notifications on mutes and blocks
* Update tests now clearNotifications is a suspend fun
* Add "Refresh" menu to NotificationsFragment
* Use account.name over account.displayName
* Update app/src/main/java/com/keylesspalace/tusky/fragment/NotificationsFragment.kt
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
* Mark layoutmanager as lateinit
* Mark layoutmanager as lateinit
* Refactor generating UI text
* Add Copyright header
* Correctly apply notification filters
* Show follow request header in notifications
* Wait for follow request actions to complete, so the reqeuest is sent
* Remove duplicate copyright header
* Revert copyright change in unmodified file
* Null check response body
* Move NotificationsFragment to component.notifications
* Use viewlifecycleowner.lifecyclescope
* Show notification filter as a dialog rather than a popup window
The popup window:
- Is inconsistent UI
- Requires a custom layout
- Didn't play nicely with viewbinding
* Refresh adapter on block/mute
* Scroll up slightly when new content is loaded
* Restore progressbar
* Lint
* Update app/src/main/res/layout/simple_list_item_1.xml
---------
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
* Kotlin 1.8.10
https://github.com/JetBrains/kotlin/releases/tag/v1.8.10
* Migrate onActivityCreated to onViewCreated
* More final modifiers
* Java Cleanups
* Kotlin cleanups
* More final modifiers
* Const value TOOLBAR_HIDE_DELAY_MS
* Revert
* upgrade AndroidX dependencies
* use new @Upsert in InstanceDao
* fix crash because of new Room nullchecks
* make TimelineStatusEntity.reblogAccount a val as well
* 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
* Check for status "type" before casting.
* Update app/src/main/java/com/keylesspalace/tusky/components/viewthread/ViewThreadViewModel.kt
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* Make sure no placeholder is returned as status
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* 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
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
* Add post editing capability
* Don't try to reprocess already uploaded attachments.
Fixes editing posts with existing media
* Don't mark post edits as modified until editing occurs
* Disable UI for things that can't be edited when editing a post
* Finally convert SFragment to kotlin
* Use api endpoint for fetching status source for editing
* Apply review feedback
* Add editedAt field to Status
* Status: Display indicators of edited posts
* Annotate edited posts in the Status description
* Cache info that post has been edited
* Fix duplicated language entries from system and app language sets.
Closes#2900
* Prefer modern language codes.
Closes#2903
* Synchronize per-account default posting language with server.
Closes#2902
* Allow users to post in languages android doesn't know about yet (e.g. toki pona)
* Always put the preselected language at the top of the list
* 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
