closes#4499
This restores support for v1 filters. The problem was that the state was
uncoditionally set to error instead of checking the v1 response.
While checking the code I found some other problems:
- Two error messages that were shown to users were not translatable
- When filters were updated sometimes `PreferenceChangedEvent` was sent
instead of `FilterUpdatedEvent`
- The notifications fragment was not listening to the
`FilterUpdatedEvent`
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>
As discussed in our contributors meeting.
Advantages:
- last element of list never obscured by action button
- less code that runs on every scroll
- less settings to worry about
Additionally:
- Added a (smaller) padding to the bottom of lists without action
button, I think it looks nice if there is a bit of white space and the
nav bar divider and the last list divider don't touch.
- The list of filters had no dividers, I added them.
- Recyclerviews with fixed height (Drafts, Filters, edits) now have
scrollbars
- code formatted all touched xml files
closes https://github.com/tuskyapp/Tusky/issues/1563
<img
src="https://github.com/tuskyapp/Tusky/assets/10157047/cd50199f-e84f-4402-93e4-a5a1beba2a08"
width="280"/>
Currently translated at 100.0% (645 of 645 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (645 of 645 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
Currently translated at 100.0% (645 of 645 strings)
Translated using Weblate (Italian)
Currently translated at 100.0% (643 of 643 strings)
Co-authored-by: Manuel <mannivuwiki@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/it/
Translation: Tusky/Tusky
At first I thought simply changing the regex might help, but then I
found more and more differences between Mastodon and Tusky, so I decided
to reimplement the thing. I added 74 testcases that I all compared to
Mastodon to make sure they are correct.
On an Fairphone 4 the new implementation is faster, on an Samsung Galaxy
Tab S3 slower.
Testcases for the benchmark:
```
test of a status with #one hashtag http
```
```
test
http:// #hashtag https://connyduck.at/http://example.org
this is a #test
and this is a @mention@test.com @test @test@test456@test.com
```
```
@mention@test.social Just your ordinary mention with a hashtag
#test
```
```
@mention@test.social Just your ordinary mention with a url
https://riot.im/app/#/room/#Tusky:matrix.org
```
FP4:
```
11.159 ns 15 allocs Benchmark.new_1
119.701 ns 43 allocs Benchmark.new_2
21.895 ns 24 allocs Benchmark.new_3
87.512 ns 32 allocs Benchmark.new_4
16.592 ns 46 allocs Benchmark.old_1
134.381 ns 169 allocs Benchmark.old_2
28.355 ns 68 allocs Benchmark.old_3
45.221 ns 77 allocs Benchmark.old_4
```
SGT3:
```
43,785 ns 18 allocs Benchmark.new_1
446,074 ns 43 allocs Benchmark.new_2
78,802 ns 26 allocs Benchmark.new_3
315,478 ns 32 allocs Benchmark.new_4
42,186 ns 45 allocs Benchmark.old_1
353,570 ns 157 allocs Benchmark.old_2
72,376 ns 66 allocs Benchmark.old_3
122,985 ns 74 allocs Benchmark.old_4
```
benchmark code is here: https://github.com/tuskyapp/tusky-span-benchmark
closes https://github.com/tuskyapp/Tusky/issues/4425
This pull request fixes the following issues:
- `FiltersActivity` launches a new coroutine to collect the ViewModel
state every time the Activity is resumed, without cancelling the
previous coroutine.
- `FiltersActivity` reloads the filters in `onResume()`, even if loading
is already in progress (without cancelling the current loading). This
can lead to inconsistent state.
List of improvements:
- Implement `launchAndRepeatOnLifecycle()` to combine
`coroutineScope.launch()` with `repeatOnLifecycle()` for the same
`Lifecycle`. Use it in `FiltersActivity` to update the view only when
the Activity is visible.
- Optimize the filters loading: load them when `FiltersViewModel` is
created and when returning from `EditFilterActivity` (when receiving the
Activity result). Cancel the load already in progress, if any.
- use `MutableStateFlow.update()` to update the state in a thread-safe
way.
- Turn `FiltersViewModel.deleteFilter()` into a suspending function in
order to perform the update in the coroutinescope of the Activity
lifecycle, so the View passed as argument doesn't leak.
- Wait for an ongoing load operation to complete before performing a
delete filter operation, so the state stays consistent.
- Add `Intent.withSlideInAnimation()` as a simpler and more flexible
alternative to `Activity.startActivityWithSlideInAnimation(Intent)`.
Two things changed here:
The check for `positionStart`only in `onItemRangeInserted` is not always
correct - we only want to jump up when something is inserted at the top,
if we already are at the top.
`enablePlaceholders = false` has unintended side effects - the
recyclerview adapter sometimes receives an "onItemRangeRemoved" followed
by an "onItemRangeInserted", instead of just "onItemRangeChanged".
Together they should make sure the timelines stay were they are.
This pull request has main 2 goals related to improving the handling of
View lifecycles in Fragments:
- **Use viewLifecycleOwner when applicable**: every coroutine touching
Views in Fragments must be launched in the `coroutinescope` of
`viewLifecycleOwner` to avoid the following issues:
1. The code will crash if it references a View binding that is no more
available and keeps running after the Fragment view hierarchy has been
destroyed.
2. The code will leak Views if it references Views from its parent scope
after the Fragment view hierarchy has been destroyed.
3. Multiple instances of the same coroutine will run at the same time,
if the coroutine is launched in `onViewCreated()` from the wrong scope
and the view hierarchy is destroyed then re-created in the same Fragment
instance.
- **Clear View-related references in Fragments**: it is an error to keep
a reference to Views or any other class containing View references in
Fragments after `onDestroyView()`. It creates a memory leak when the
Fragment is added to the back stack or is temporarily detached. A
typical object that leaks Views is a RecyclerView's Adapter: when the
adapter is set on the RecyclerView, the RecyclerView registers itself as
a listener to the Adapter and the Adapter now contains a reference to
the RecyclerView that is not automatically cleared. It is thus
recommended to clear all these view references one way or another, even
if the Fragment is currently not part of a scenario where it is detached
or added to a back stack.
In general, having a `lateinit var` not related to Dagger dependency
injection in a Fragment is a code smell and should be avoided:
- If that `lateinit var` is related to storing something View-related,
it must be removed if possible or made nullable and set to `null` in
`onDestroyView()`.
- If that `lateinit var` is meant to store fragment arguments, it can be
turned into a `val by lazy{}`.
- If that `lateinit var` is related to fetching some information from
the Activity, it can be turned into a `val` with no backing field that
will simply call the activity when accessed. There is no need to store
the value in the Fragment.
When possible, View-related values must not be stored as Fragment
fields: all views should be accessed only in `onViewCreated()` and
passed as arguments to various listeners down the chain.
However, it's still required to use nullable fields **when the Fragment
exposes public methods that are called directly by an external entity**,
and these methods use the View-related value. Since the Fragment has no
control over when the external entity will call these public methods,
the field must never assumed to be non-null and null checks must be
added for every call. Note that exposing public methods on a Fragment to
be called directly is an antipattern, but switching to a different
architecture is out of scope of this pull request.
- Use `viewLifecycleOwner` in Fragments where applicable.
- Remove view-related fields and instead declare them in
`onViewCreated()` when possible.
- When not possible, declare view-related fields as nullable and set
them to `null` in `onDestroyView()`.
- Pass non-null View-related fields as arguments when possible, to not
rely on the nullable Fragment field.
- Replace `lateinit var` containing an Activity-related value with `val`
accessing the Activity directly on demand.
- Remove some unused fragment fields.
- Replace `onCreateView()` with passing the layout id as Fragment
constructor argument when possible.
- Replace `isAdded` checks with `view != null`. A Fragment being added
to an Activity doesn't mean it has a View hierarchy (it may be detached
and invisible).
- Remove `mediaPlayerListener` field in `ViewVideoFragment` and turn it
into a local variable. It is then passed into a
`DefaultLifecycleObserver` that replaces the `onStart()`/`onStop()`
overrides and is unregistered automatically when the view hierarchy is
destroyed.
The pull request to integrate the SplashScreen library (#4413) required
overriding the theme before setting the layout in
`MainActivity.onCreate()`, in order to switch from `SplashTheme` to
`TuskyTheme`. Since the parent `BaseActivity` already contained code to
override the theme in case the user selects the "black" theme, that
logic was added at the same spot in `BaseActivity`.
However, since other Activities inherit from `BaseActivity` and
sometimes declare a different default theme than `TuskyTheme` in the
Manifest, the wrong theme was set for those Activities when not in Black
theme mode.
This pull request ensures that the theme will only be overridden to
`TuskyTheme` in `MainActivity`, the only Activity that uses a splash
screen.
The current code loads emojis using Glide into basic custom `Target`s
and doesn't keep a hard reference to the Target. This creates a few
problems:
- Unlike images loaded into `ImageViewTarget`s, Emoji animations are not
paused when the Activity/Fragment becomes invisible. GIF decoding use
resources in the background.
- When `TextView`s get recycled in a RecyclerView, the loading of emojis
for the previous bind are not canceled when binding the new text and
starting the load of the new emojis. This is also handled automatically
when using `ImageViewTarget` but not for custom targets. Also, when the
obsolete emojis complete loading, the `TextView` will be unnecessarily
invalidated and redrawn.
- Since Glide's `RequestManager` doesn't keep hard references to Targets
after they are loaded and the emoji Target is currently not stored in
any View, emojis don't get an opportunity to clean up (at least stop
their animation) when the Activity/Fragment is destroyed. Depending on
the Drawable implementation, animations may run forever in the
background and cause memory leaks.
This pull request aims to properly track the lifecycle of emoji Targets,
cancel their loading an stop animations when appropriate. It also
reimplements `emojify()` to be more efficient.
- Add extension functions `View.setEmojiTargets()` and
`View.clearEmojiTargets()` to store and clear lists of emoji targets in
View tags, keeping a hard reference to them as long as the View is used.
When clearing emoji targets, pending requests will be canceled and
animations will be stopped to free memory. This is similar to what
`ImageViewTarget` does, except here multiple Targets are stored for a
single View instead of one.
- Add helper extension function `View.updateEmojiTargets()` to
automatically clear the View emoji targets, then allowing to call
`emojify()` one or more times in the `EmojiTargetScope` of that View,
and finally store all the pending targets of the `EmojiTargetScope` in
the View.
- Reimplement `CharSequence.emojify()` using
`View.updateEmojiTargets()`. This is used in RecyclerViews as well and
will automatically cancel previous emoji loadings for the same View and
stop animations.
- The main logic of `emojify()` has been moved to `EmojiTargetScope`.
Replace usage of slow regex `Matcher` with faster
`CharSequence.indexOf()`. Use `SpannableString` (with `toSpannable()`)
instead of `SpannableStringBuilder` to store the `EmojiSpan`s.
- Rename `EmojiSpan.getTarget()` to `EmojiSpan.createGlideTarget()` and
improve the target to stop/resume the animation according to the parent
component lifecycle, and stop the animation when clearing the target.
Use a hard reference to the view instead of a weak reference, since the
lifecycle of the Target now matches the one of the View and the Target
will be cleared at the latest when the View is destroyed.
- Use `View.updateEmojiTargets()` in `ReportNotificationViewHolder` in
order to store the targets of 2 separate sets of emojis into the same
TextView.
- Fix: reimplement the code to merge the 2 emoji sets into a single
`CharSequence` in `ReportNotificationViewHolder` using
`TextUtils.expandTemplate()`. The current code uses `String.format()`
which returns a String instead of a Spannable so the computed emojis are
lost.
- Store the emoji targets in `AnnouncementAdapter` in the parent view
after clearing the previous ones. It is a better location than storing
one emoji target in each child `Tooltip` view because tooltips are not
recycled when refreshing the data and the previous targets would not be
canceled properly.
- Bonus: update `ViewVideoFragment` to use `CustomViewTarget` instead of
`CustomTarget` to load the default artwork into `PlayerView`. The
loading will also automatically be canceled when the fragment view is
detached.
Using `Either<Throwable, T>` is basically the same as `Result<T>` with a
less friendly API. Futhermore, `Either` is currently only used in a
single component.
- Replace `Either` with `Result` in `AccountsInListFragment` and
`AccountsInListViewModel`.
- Add a method to convert a `NetworkResult` to a `Result` in
`AccountsInListViewModel`. Alternatively, `NetworkResult` could be used
everywhere in the code but other classes are already using `Result`.
- Replace `updateState()` method with `MutableStateFlow.update()` in
`AccountsInListViewModel`.
- Store the current search query in a `MutableStateFlow` collected by a
coroutine. This allows automatically cancelling the previous search when
a new query arrives, instead of launching a new coroutine for each query
which may conflict with the previous ones.
- Optimize `ListUtils`.
This does 4 things:
- Alt text is now translated when opening media of translated posts.
Previously only the long-press alt text was translated.
- The translate button is now hidden on non-public posts. The Mastodon
api returns 403 there.
- Translated posts will only be collapsible when the original was
collapsible as well. It is just weird when an "show more" button
suddenly appears because the post got longer by translating it.
- The translation status and the untranslate button are now shown below
each other instead of next to each other. Looks way better on smaller
display or long texts.
Before / After
<img
src="https://github.com/tuskyapp/Tusky/assets/10157047/2cadd15b-2e28-4989-9bd3-d3bdd4c75329"
width="320"/> <img
src="https://github.com/tuskyapp/Tusky/assets/10157047/0ecab094-6c96-49a5-bc99-aa56b7fe2ec2"
width="320"/>
Found a post with this weird media focus in the wild on chaos.social:
```
"focus": {
"x": 0.0,
"y": null
}
```
```
com.squareup.moshi.JsonDataException: Expected a double but was NULL at path $[0].media_attachments[0].meta.focus.y
at com.squareup.moshi.JsonUtf8Reader.nextDouble(JsonUtf8Reader.java:787)
at com.squareup.moshi.StandardJsonAdapters$6.fromJson(StandardJsonAdapters.java:167)
at com.squareup.moshi.StandardJsonAdapters$6.fromJson(StandardJsonAdapters.java:164)
at com.keylesspalace.tusky.entity.Attachment_FocusJsonAdapter.fromJson(Attachment_FocusJsonAdapter.kt:37)
at com.keylesspalace.tusky.entity.Attachment_FocusJsonAdapter.fromJson(Attachment_FocusJsonAdapter.kt:20)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.keylesspalace.tusky.entity.Attachment_MetaDataJsonAdapter.fromJson(Attachment_MetaDataJsonAdapter.kt:54)
at com.keylesspalace.tusky.entity.Attachment_MetaDataJsonAdapter.fromJson(Attachment_MetaDataJsonAdapter.kt:23)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.keylesspalace.tusky.entity.AttachmentJsonAdapter.fromJson(AttachmentJsonAdapter.kt:66)
at com.keylesspalace.tusky.entity.AttachmentJsonAdapter.fromJson(AttachmentJsonAdapter.kt:22)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:81)
at com.squareup.moshi.CollectionJsonAdapter$2.fromJson(CollectionJsonAdapter.java:55)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.keylesspalace.tusky.entity.StatusJsonAdapter.fromJson(StatusJsonAdapter.kt:195)
at com.keylesspalace.tusky.entity.StatusJsonAdapter.fromJson(StatusJsonAdapter.kt:26)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:81)
at com.squareup.moshi.CollectionJsonAdapter$2.fromJson(CollectionJsonAdapter.java:55)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at retrofit2.converter.moshi.MoshiResponseBodyConverter.convert(MoshiResponseBodyConverter.java:46)
at retrofit2.converter.moshi.MoshiResponseBodyConverter.convert(MoshiResponseBodyConverter.java:27)
at retrofit2.OkHttpCall.parseResponse(OkHttpCall.java:246)
at retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:156)
at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
```
(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)
...
```
This does four things
- set `enablePlaceholders = false` on `PagingConfig`s to avoid Paging
Data that contains null placeholders, we don't want them (everywhere,
not just in notifications)
- make sure NotificationsPagingAdapter does not crash when it encounters
a null placeholder
- makes sure the notifications refresh correctly when the filters change
- the filters are now also respected when loading a gap
closes#4433
Currently translated at 100.0% (643 of 643 strings)
Translated using Weblate (Italian)
Currently translated at 99.3% (639 of 643 strings)
Co-authored-by: Manuel <mannivuwiki@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/it/
Translation: Tusky/Tusky
Currently translated at 100.0% (643 of 643 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (643 of 643 strings)
Co-authored-by: fin-w <fin-w@tutanota.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
API 31+ devices don't need to install the compat SplashScreen because
they have their own native splash screen implementation. Furthermore, we
don't need to customize the splash screen so there is no need to call
the library.
On API 31+, the SplashScreen compat library registers some kind of
listener which causes display bugs with the Tusky theme on some Android
versions. Disabling the library on API 31+ solves this issue.
Fixes#4446.
Loading the image as a `Drawable` allows using the Drawable API to
abstract the drawing.
This way, any kind of `Drawable` (including the fallback vector
drawable) can be drawn in one pass to the Bitmap, without having to be
converted to a `Bitmap` first.
Also, `BitmapDrawable` will automatically use
[`Paint.FILTER_BITMAP_FLAG`](https://developer.android.com/reference/android/graphics/Paint#FILTER_BITMAP_FLAG)
when drawing, ensuring the resized image is high-quality even when using
a Bitmap-backed Canvas.
Currently some vector drawables are loaded using the AppCompat library
and others are loaded using the framework.
This pull request uniformizes this to use AppCompat to load them all.
Other changes:
- Set all compound drawables using relative positioning, since all XML
layouts are also using relative positioning.
- Remove unnecessary layer list drawable used to center
`R.drawable.ic_play_indicator` icon and use
`ImageView.setForegroundGravity()` instead.
- Merge layers in toolbar icons `ic_arrow_back_with_background` and
`ic_more_with_background` into a single vector drawable. Note that the
AppCompat implementation of vector drawables is unable to load vector
drawables inside layer-list drawables, so this change also makes these
images compatible with older Android versions.
**Note**: technically, AppCompat will always delegate to the framework
to load vector drawables on API 24+ which is the current minSDK version
of the app. But at least this gives the option to lower the minSDK
version in the future.
This means a popup will appear if you have that option enabled in the
preferences which will have a popup similar to the unfollow dialog
asking you if you want to follow the user.
The Androidx SplashScreen library is added as a dependency to the
project but isn't properly enabled in the current code. This pull
request configures the splash screen properly.
- Remove `SplashScreenActivity` which is not needed and use
`MainActivity` as main entry point to the application. `MainActivity`
inherits from `BaseActivity` which already detects if no account is
configured and redirects to `LoginActivity` if needed, just like
`SplashScreenActivity`.
- Initialize the SplashScreen library in `MainActivity.onCreate()`.
- Instead of letting the SplashScreen library set the final theme from
the `postSplashScreenTheme` attribute in SplashTheme, let `BaseActivity`
set it according to the user settings.
- When no account is available in `MainActivity.onCreate()`, keep the
splash screen shown until `LoginActivity` appears.
- Disable the slide-in animation when launching `LoginActivity` when no
account is available because the detection happens in `onCreate()` and
an Activity that finishes itself in `onCreate()` will not be drawn, so
the slide-in animation will not be visible either and only
`LoginActivity` will appear.
- Upgrade `core-splashscreen` to 1.2.0-alpha01 which contains a fix for
corrupted app theme on API 31+.
`RequestListener.onResourceReady()` may also be called to provide the
placeholder image when the request is starting or when it is cleared.
Check if the current request is complete (its status set to COMPLETE) to
determine if the Glide resource is for a thumbnail/placeholder or the
final image, and resume the coroutine only for the final image (or in
case of error).
This logic is [borrowed from the Glide Flow
API](a7351b0ecf/integration/ktx/src/main/java/com/bumptech/glide/integration/ktx/Flows.kt (L378)).
The main benefit of upgrading to version 1.2.0 of `DrawerLayout` is ~~to
properly support **predictive back animations**: when initiating a back
gesture on API 33+, the DrawerLayout will animate automatically~~ to
handle back navigation automatically. The predictive back animation of
the menu however depends on `NavigationView` which is not used in the
project.
In addition to the upgrade, simplify DrawerLayout integration:
- Forward key events to the DrawerLayout so it can intercept them and
close itself when needed.
- Don't handle the DrawerLayout closing manually using the
`OnBackPressedCallback` anymore. This is not necessary since the back
event will now be intercepted by the DrawerLayout when needed before
reaching the `OnBackPressedDispatcher`.
- Remove legacy fix for DrawerLayout staying open after Activity
recreation.
Currently translated at 100.0% (641 of 641 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (639 of 639 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
Hilt is an annotation processor built on top of Dagger which allows to
remove all the Android dependency injection boilerplate code (currently
around 900 lines) by writing it for us.
Hilt can use KSP instead of Kapt so Kapt can be completely removed from
the project. Kapt is slow, deprecated and has a few compatibility
issues. Removing Kapt will improve build times since no Java stubs have
to be generated for Kotlin classes anymore (Note that KSP also processes
annotations in Java classes so it can completely replace Kapt).
- Remove all modules related to manual dependency injection
configuration.
- Rename `AppModule` to `StorageModule` since it now only contains
configuration to retrieve the DataBase and SharedPreferences.
- Annotate all entry points (Activities, Fragments, BroadcastReceivers
and Services) with `@AndroidEntryPoint`.
- Annotate all injected ViewModels with `@HiltViewModel` and replace the
custom ViewModel Factory with the default one (which integrates with the
one generated by Hilt).
- Add a public field to allow overriding the default
ViewModelProvider.Factory in `BaseActivity` in tests.
- Annotate tested Activities with `@OptionalInject` since Activity tests
currently rely on the Activities not being injected automatically.
- Annotate injected `Context` arguments with `@ApplicationContext`. Hilt
provides the `Context` binding automatically but requires to specify if
the Application or Activity Context is wanted.
- Add WorkManager Hilt integration so all Workers are injected by Hilt
automatically using `HiltWorkerFactory`.
- Lazily initialize WorkManager in `TuskyApplication`.
- Remove Kapt and Kapt workarounds.
- ~~Remove toolchain configuration for Java 21. Toolchains force the
Java bytecode to match the JDK version used to build the project, and
apparently Hilt doesn't run inside the toolchain so cannot process the
source code if the JDK version of the toolchain is higher than the JDK
used to run Gradle. [And configuring a toolchain for an older Java
version causes other
issues](https://jakewharton.com/gradle-toolchains-are-rarely-a-good-idea/).
**Removing toolchains configuration doesn't prevent the project from
being built using JDK 21** or more recent versions but allows to build
the project using older JDKs as well.~~
Added a fix to allow Hilt to properly use the JDK toolchain.
- ~~Set the Java and Kotlin bytecode target to Java 17. The standard
bytecode target for Android projects is usually Java 8 or 11 (any higher
version doesn't provide any benefit but may cause compatibility issues).
However, since the app currently uses a library built against Java 17
bytecode (`networkresult-calladapter`), it needs to target at least Java
17 bytecode as well.~~
- Update the Dagger 2 URL in the licenses screen. Hilt is part of Dagger
2 so the label wasn't changed.
Fixes: #3477
This tweaks two colors:
* for the dark theme a new slightly darker (timeline) background is
used.
* for the light theme a darker shade of blue is used as highlight color
(`colorPrimary` and `colorSecondary`)
Additional change:
* Use green and red more consistent: use existing colors for the diff
display; move the new light variants to colors.xml like all colors
This pull request adds `overrideActivityTransitionCompat()`, a
backwards-compatible version of `Activity.overrideActivityTransition()`
to be called in `Activity.onCreate()` in all Android versions.
This avoids duplicating the transition logic in different places of the
app to support older Android versions (in the activity launching code,
in `Activity.onCreate()` or in `Activity.finish()`).
- On API 34+, the implementation simply delegates to
`Activity.overrideActivityTransition()`.
- On API < 34, the implementation calls
`Activity.overridePendingTransition()` either immediately (opening
transition) or schedules it to be called later when the Activity is
finishing (closing transition).
- Rename `ActivityExensions.kt` to `ActivityExtensions.kt` (fix typo).
Steps to reproduce: When viewing an account list, very quickly rotate
the screen multiple times. I found this easier to do with an emulator,
just spam the rotation buttons.
```
java.lang.IllegalStateException: Fragment AccountListFragment{50bbc6c} (8a3e6922-e855-45a7-8a49-c9d16e21e438) did not return a View from onCreateView() or this was called before onCreateView().
at androidx.fragment.app.Fragment.requireView(Fragment.java:2063)
at com.keylesspalace.tusky.util.ViewLifecycleLazy.getValue(ViewBindingExtensions.kt:32)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.getBinding(AccountListFragment.kt:75)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.onFetchAccountsFailure(AccountListFragment.kt:390)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.access$onFetchAccountsFailure(AccountListFragment.kt:63)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment$fetchAccounts$2.invokeSuspend(AccountListFragment.kt:333)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:230)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7872)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@260dcb1, Dispatchers.Main.immediate]
```
Glide sometimes calls the callback more than once (for the placeholder,
then for the actual image), but a coroutine can only resume once.
```
Exception java.lang.IllegalStateException:
at kotlinx.coroutines.CancellableContinuationImpl.alreadyResumedError (CancellableContinuationImpl.kt:555)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl (CancellableContinuationImpl.kt:520)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default (CancellableContinuationImpl.kt:493)
at kotlinx.coroutines.CancellableContinuationImpl.resumeWith (CancellableContinuationImpl.kt:364)
at com.keylesspalace.tusky.util.GlideExtensionsKt$submitAsync$2$target$1.onResourceReady (GlideExtensions.kt:39)
at com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:650)
at com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:596)
at com.bumptech.glide.request.SingleRequest.begin (SingleRequest.java:243)
at com.bumptech.glide.manager.RequestTracker.resumeRequests (RequestTracker.java:115)
at com.bumptech.glide.RequestManager.resumeRequests (RequestManager.java:339)
at com.bumptech.glide.RequestManager.onStart (RequestManager.java:364)
at com.bumptech.glide.manager.ApplicationLifecycle.addListener (ApplicationLifecycle.java:15)
at com.bumptech.glide.RequestManager$1.run (RequestManager.java:84)
at android.os.Handler.handleCallback (Handler.java:958)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:230)
at android.os.Looper.loop (Looper.java:319)
at android.app.ActivityThread.main (ActivityThread.java:8893)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:608)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1103)
```
While removing the placeholder fixes the problem here, we should
probably put some safeguards into `submitAsync` so that this can't
happen again elsewhere. Any ideas how to do that, @cbeyls?
This should save quite some memory, but most importantly it gets rid of
this crash:
```
java.lang.RuntimeException: Canvas: trying to draw too large(121969936bytes) bitmap.
at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:266)
at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:94)
at android.graphics.drawable.BitmapDrawable.draw(BitmapDrawable.java:549)
at com.keylesspalace.tusky.util.EmojiSpan.draw(CustomEmojiHelper.kt:131)
...
```
Steps to reproduce: When viewing an account list, very quickly rotate
the screen multiple times. I found this easier to do with an emulator,
just spam the rotation buttons.
```
java.lang.IllegalStateException: Fragment AccountListFragment{50bbc6c} (8a3e6922-e855-45a7-8a49-c9d16e21e438) did not return a View from onCreateView() or this was called before onCreateView().
at androidx.fragment.app.Fragment.requireView(Fragment.java:2063)
at com.keylesspalace.tusky.util.ViewLifecycleLazy.getValue(ViewBindingExtensions.kt:32)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.getBinding(AccountListFragment.kt:75)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.onFetchAccountsFailure(AccountListFragment.kt:390)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.access$onFetchAccountsFailure(AccountListFragment.kt:63)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment$fetchAccounts$2.invokeSuspend(AccountListFragment.kt:333)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:230)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7872)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@260dcb1, Dispatchers.Main.immediate]
```
Glide sometimes calls the callback more than once (for the placeholder,
then for the actual image), but a coroutine can only resume once.
```
Exception java.lang.IllegalStateException:
at kotlinx.coroutines.CancellableContinuationImpl.alreadyResumedError (CancellableContinuationImpl.kt:555)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl (CancellableContinuationImpl.kt:520)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default (CancellableContinuationImpl.kt:493)
at kotlinx.coroutines.CancellableContinuationImpl.resumeWith (CancellableContinuationImpl.kt:364)
at com.keylesspalace.tusky.util.GlideExtensionsKt$submitAsync$2$target$1.onResourceReady (GlideExtensions.kt:39)
at com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:650)
at com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:596)
at com.bumptech.glide.request.SingleRequest.begin (SingleRequest.java:243)
at com.bumptech.glide.manager.RequestTracker.resumeRequests (RequestTracker.java:115)
at com.bumptech.glide.RequestManager.resumeRequests (RequestManager.java:339)
at com.bumptech.glide.RequestManager.onStart (RequestManager.java:364)
at com.bumptech.glide.manager.ApplicationLifecycle.addListener (ApplicationLifecycle.java:15)
at com.bumptech.glide.RequestManager$1.run (RequestManager.java:84)
at android.os.Handler.handleCallback (Handler.java:958)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:230)
at android.os.Looper.loop (Looper.java:319)
at android.app.ActivityThread.main (ActivityThread.java:8893)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:608)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1103)
```
While removing the placeholder fixes the problem here, we should
probably put some safeguards into `submitAsync` so that this can't
happen again elsewhere. Any ideas how to do that, @cbeyls?
This should save quite some memory, but most importantly it gets rid of
this crash:
```
java.lang.RuntimeException: Canvas: trying to draw too large(121969936bytes) bitmap.
at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:266)
at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:94)
at android.graphics.drawable.BitmapDrawable.draw(BitmapDrawable.java:549)
at com.keylesspalace.tusky.util.EmojiSpan.draw(CustomEmojiHelper.kt:131)
...
```
- 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()`.
I made a mistake in https://github.com/tuskyapp/Tusky/pull/4389🙄
With `addDynamicShortcuts` the limit can still be exceeded,
`setDynamicShortcuts` is what we want.
Also, `setLongLived` says:
> Sets if a shortcut would be valid even if it has been
unpublished/invisible by the app (as a dynamic or pinned shortcut). If
it is long lived, it can be cached by various system services even after
it has been unpublished as a dynamic shortcut.
I don't think we want that so I removed it.
The app currently uses a custom callback system for requesting
permissions, located in `BaseActivity`.
This code doesn't work when the activity gets re-created before the
permission is granted: the callback will be lost with the Activity and
no action will be performed after the permission is granted.
To avoid these issues while still simplifying the code, Google
recommends to use the ActivityResultContract APIs to request
permissions, which allow to register persistent callbacks. This pull
request removes the legacy API and replaces the calls with
`registerForActivityResult(ActivityResultContracts.RequestPermission())`.
- `ActivityResultContracts.RequestPermission` will check if the
permission is already granted and call the callback synchronously when
possible. So this check doesn't need to be performed anymore.
- In `SearchStatusesFragment` and `SFragment`, the download action to
launch after granting the permission requires an argument (a list of
media URLs). This argument is temporarily stored in a Fragment field and
saved and restored as part of the instance state, so the action can
properly resume after an Activity re-creation.
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>
- Use `TooltipCompat.setTooltipText()` instead of setting an
`OnLongClickListener` showing a Toast, to show the attachment
description. This method will display native tooltips on API 26+, and
set an `OnLongClickListener` on older versions to display a special
Toast anchored to the view. In both cases this provides a better user
experience.
- Simplify `Attachment.getFormattedDescription()` by using Kotlin's
`Duration`. Since it's an inline class, no extra memory will be
allocated on the heap. Also, ensure that the calculation of minutes and
hours use the rounded number of seconds instead of the non-rounded one.
Steps to reproduce: Quickly unfollow a bunch of hashtags, try clicking
unfollow buttons multiple times. If you are faster than the network, the
app crashes.
```
java.lang.ArrayIndexOutOfBoundsException: length=20; index=-1
at java.util.ArrayList.remove(ArrayList.java:506)
at com.keylesspalace.tusky.components.followedtags.FollowedTagsActivity$unfollow$1.invokeSuspend(FollowedTagsActivity.kt:152)
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:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7872)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
```
Fragments don't necessarily have the same lifecycle as their views, so
their is a rare race condition when collecting a Flow from the
`lifecycleScope` of the Fragment where the view is already disposed but
the collect lambda is still executed. Accessing the view from such a
lambda can therefore led to a crash.
Collecting from the `viewLifecycleOwner.lifecycleScope` fixes the
problem.
```
Exception java.lang.IllegalStateException:
at androidx.fragment.app.Fragment.requireView (Fragment.java:2062)
at com.keylesspalace.tusky.util.ViewLifecycleLazy.getValue (ViewBindingExtensions.kt:32)
at com.keylesspalace.tusky.components.viewthread.ViewThreadFragment.getBinding (ViewThreadFragment.kt:79)
at com.keylesspalace.tusky.components.viewthread.ViewThreadFragment.access$getBinding (ViewThreadFragment.kt:67)
at com.keylesspalace.tusky.components.viewthread.ViewThreadFragment$onViewCreated$3$1.emit (ViewThreadFragment.java:250)
at com.keylesspalace.tusky.components.viewthread.ViewThreadFragment$onViewCreated$3$1.emit (ViewThreadFragment.java:248)
at kotlinx.coroutines.flow.SharedFlowImpl.collect$suspendImpl (SharedFlow.kt:392)
at kotlinx.coroutines.flow.SharedFlowImpl$collect$1.invokeSuspend (SharedFlow.kt:13)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTaskKt.resume (DispatchedTask.kt:231)
at kotlinx.coroutines.DispatchedTaskKt.resumeUnconfined (DispatchedTask.kt:187)
at kotlinx.coroutines.DispatchedTaskKt.dispatch (DispatchedTask.kt:159)
at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume (CancellableContinuationImpl.kt:470)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl (CancellableContinuationImpl.kt:504)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default (CancellableContinuationImpl.kt:493)
at kotlinx.coroutines.CancellableContinuationImpl.resumeWith (CancellableContinuationImpl.kt:364)
at kotlinx.coroutines.flow.SharedFlowImpl.tryEmit (SharedFlow.kt:409)
at kotlinx.coroutines.flow.SharedFlowImpl.emit$suspendImpl (SharedFlow.kt:414)
at kotlinx.coroutines.flow.SharedFlowImpl.emit (SharedFlow.kt:1)
at com.keylesspalace.tusky.components.viewthread.ViewThreadViewModel$loadThread$1.invokeSuspend (ViewThreadViewModel.kt:172)
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:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:210)
at android.os.Looper.loop (Looper.java:299)
at android.app.ActivityThread.main (ActivityThread.java:8319)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:556)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1038)
```
Currently translated at 100.0% (639 of 639 strings)
Translated using Weblate (Turkish)
Currently translated at 100.0% (639 of 639 strings)
Co-authored-by: Ümit Solmaz <usnotv@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/tr/
Translation: Tusky/Tusky
Akkoma does not always set all attributes for Cards and when they are
loaded from the database, the app crashes. When they are loaded from the
network, Tusky displays an error. Adding more default values fixes the
problem.
```
com.squareup.moshi.JsonDataException: Required value 'authorName' (JSON name 'author_name') missing at $
at com.squareup.moshi.internal.Util.missingProperty(Util.java:660)
at com.keylesspalace.tusky.entity.CardJsonAdapter.fromJson(CardJsonAdapter.kt:122)
at com.keylesspalace.tusky.entity.CardJsonAdapter.fromJson(CardJsonAdapter.kt:22)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.squareup.moshi.JsonAdapter.fromJson(JsonAdapter.java:70)
at com.keylesspalace.tusky.components.timeline.TimelineTypeMappersKt.toViewData(TimelineTypeMappers.kt:168)
at com.keylesspalace.tusky.components.timeline.viewmodel.CachedTimelineViewModel$statuses$2$1.invoke(CachedTimelineViewModel.kt:110)
at com.keylesspalace.tusky.components.timeline.viewmodel.CachedTimelineViewModel$statuses$2$1.invoke(CachedTimelineViewModel.kt:108)
at androidx.paging.PagingDataTransforms$map$2$1$1.invokeSuspend(PagingDataTransforms.kt:58)
at androidx.paging.PagingDataTransforms$map$2$1$1.invoke(Unknown Source:8)
at androidx.paging.PagingDataTransforms$map$2$1$1.invoke(Unknown Source:2)
at androidx.paging.PageEvent$Insert.map(PageEvent.kt:128)
at androidx.paging.PagingDataTransforms$map$2$1.invokeSuspend(PagingDataTransforms.kt:58)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:585)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:802)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:706)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:693)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@de2cbd5, Dispatchers.Main.immediate]
```
closes#4393
Mastodon returns different reponses when posting normally and when
scheduling. This was previously ignored silently, but Moshi is more
correct than Gson and fails, which causes the `SendStatusService` to
retry sending forever and a lot of posts are scheduled.
Mastodon should actually ignore multiple attempts at scheduling the same
post, but doesn't so I filed this
https://github.com/mastodon/mastodon/issues/30039
cc @cbeyls
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)
```
All subtitle formats used to be enabled by default in older versions of
media3.
After the media3 library was upgraded to 1.3.0, Extractors should
specify a `SubtitleParser.Factory` explicitly. By default, no subtitle
formats are supported when using the now deprecated empty constructor of
Extractors.
Limit support to **WebVTT** and **TTML** which are the only true web
standards amongst all the subtitle formats supported by ExoPlayer.
Note that only subtitles embedded in MP4 and WebM files are supported
until Mastodon provides a way to upload subtitles separately.
- Read license resource using Okio inside a coroutine (instead of the
main thread) in `LicenseActivity`
- Use Okio and its buffer system to copy ContentProvider streams and
files to a temporary file in `MediaUploader.prepareMedia()`
- Properly close the input file after copying it to a temporary file in
`MediaUploader.prepareMedia()`
- Properly close sink in case of null body source during file copy in
`Uri.copyToFolder()` in `DraftHelper.kt`
- Add comment explaining the current value of `DEFAULT_CHUNK_SIZE` in
`UriRequestBody.kt` and indent the file properly
- Replace hardcoded `Charset` and `Int` byte size with the proper
constants, and align the `hashCode()` implementation with other
`BitmapTransformation` implementations in
`CompositeWithOpaqueBackground`
- Properly close `InputStream` in case of error during Bitmap size
decoding in `getImageSquarePixels()`
- return `Int` instead of `Long` in `getImageSquarePixels()`, since the
current code simply converts the `Int` result to a `Long` _after_
multiplication and not before (and `Int.MAX_VALUE` is already way above
the maximum number of pixels a decoded Bitmap could return)
- Simplify `getImageOrientation()`
- Add explicit dependency to the Okio library and upgrade it to its
latest version.
This pull request takes advantage of the Okio library to simplify, fix
or improve performance of some I/O related code in Tusky.
- Return early or throw `FileNotFoundException` early in case
`contentResolver.openInputStream()` returns `null` instead of throwing
`NullPointerException` later. Change the signature of
`Closeable.closeQuietly()` to only accept a non-null `Closeable`.
- Reimplement `Uri.copyToFile()` using Okio. This takes advantage of the
built-in high-performance buffers of the library so a buffer doesn't
need to be allocated or managed manually. The new implementation also
makes sure that the input and output streams are always closed, as the
original code could in some cases return without properly closing a
stream.
- Reimplement `ProgressRequestBody` as `Uri.asRequestBody()` (adding to
the existing extension functions available in the Okio library to create
a `RequestBody`). The new implementation uses Okio's `Buffer` instead of
a manually managed byte array, which allows to avoid copying bytes from
one buffer to the next. The max number of bytes read at once was
increased from 2K to 8K to improve performance. Avoid division by zero
in case `contentLength` is `0`. Finally, this implementation now takes a
`Uri` as input instead of an `InputStream`, because a `RequestBody` must
be replayable in case Okio retries the request, and an `InputStream` can
only be used once.
This also improves randomness by avoiding to reinitialize the random
number generator repeatedly from a seed based on the current time.
Typically, if the number generator is reinitialized repeatedly at
non-random times (like multiple times in a row), then generated numbers
have a higher chance of repeating.
The Kotlin Random object is only initialized once, using the best seed
available for the current Android version.
closes#4361
```
com.squareup.moshi.JsonDataException: Required value 'width' missing at $.statuses[0].media_attachments[0].meta.original
at com.squareup.moshi.internal.Util.missingProperty(Util.java:660)
at com.keylesspalace.tusky.entity.Attachment_SizeJsonAdapter.fromJson(Attachment_SizeJsonAdapter.kt:81)
at com.keylesspalace.tusky.entity.Attachment_SizeJsonAdapter.fromJson(Attachment_SizeJsonAdapter.kt:23)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.keylesspalace.tusky.entity.Attachment_MetaDataJsonAdapter.fromJson(Attachment_MetaDataJsonAdapter.kt:64)
at com.keylesspalace.tusky.entity.Attachment_MetaDataJsonAdapter.fromJson(Attachment_MetaDataJsonAdapter.kt:23)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.keylesspalace.tusky.entity.AttachmentJsonAdapter.fromJson(AttachmentJsonAdapter.kt:66)
at com.keylesspalace.tusky.entity.AttachmentJsonAdapter.fromJson(AttachmentJsonAdapter.kt:22)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:81)
at com.squareup.moshi.CollectionJsonAdapter$2.fromJson(CollectionJsonAdapter.java:55)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.keylesspalace.tusky.entity.StatusJsonAdapter.fromJson(StatusJsonAdapter.kt:195)
at com.keylesspalace.tusky.entity.StatusJsonAdapter.fromJson(StatusJsonAdapter.kt:26)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:81)
at com.squareup.moshi.CollectionJsonAdapter$2.fromJson(CollectionJsonAdapter.java:55)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.keylesspalace.tusky.entity.SearchResultJsonAdapter.fromJson(SearchResultJsonAdapter.kt:51)
at com.keylesspalace.tusky.entity.SearchResultJsonAdapter.fromJson(SearchResultJsonAdapter.kt:21)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at retrofit2.converter.moshi.MoshiResponseBodyConverter.convert(MoshiResponseBodyConverter.java:46)
at retrofit2.converter.moshi.MoshiResponseBodyConverter.convert(MoshiResponseBodyConverter.java:27)
at retrofit2.OkHttpCall.parseResponse(OkHttpCall.java:246)
at retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:156)
at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
at java.lang.Thread.run(Thread.java:1012)
```
This helps playing some media even if there is a problem with the
primary decoder.
E.g. [this
video](https://mastodon.social/@krzyzanowskim/112208964123517040) fails
on my Fairphone 4 without this change.
<img
src="https://github.com/tuskyapp/Tusky/assets/10157047/215d932c-9ed1-4ee8-8be7-e6ca28ddec23"
width="200"/>
<details>
<summary>Stacktrace</summary>
```
androidx.media3.exoplayer.ExoPlaybackException: MediaCodecVideoRenderer error, index=0, format=Format(1, null, null, video/avc, avc1.640034, -1, null, [1920, 1440, 119.99593, ColorInfo(BT709, Limited range, sRGB, false, 8bit Luma, 8bit Chroma)], [-1, -1]), format_supported=YES
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:620)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: androidx.media3.exoplayer.mediacodec.MediaCodecRenderer$DecoderInitializationException: Decoder init failed: OMX.qcom.video.decoder.avc, Format(1, null, null, video/avc, avc1.640034, -1, null, [1920, 1440, 119.99593, ColorInfo(BT709, Limited range, sRGB, false, 8bit Luma, 8bit Chroma)], [-1, -1])
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.maybeInitCodecWithFallback(MediaCodecRenderer.java:1114)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.maybeInitCodecOrBypass(MediaCodecRenderer.java:551)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.onInputFormatChanged(MediaCodecRenderer.java:1560)
at androidx.media3.exoplayer.video.MediaCodecVideoRenderer.onInputFormatChanged(MediaCodecVideoRenderer.java:1152)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.readSourceOmittingSampleData(MediaCodecRenderer.java:994)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:814)
at androidx.media3.exoplayer.video.MediaCodecVideoRenderer.render(MediaCodecVideoRenderer.java:940)
at androidx.media3.exoplayer.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:1102)
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:541)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: android.media.MediaCodec$CodecException: Error 0xfffffff4
at android.media.MediaCodec.native_configure(Native Method)
at android.media.MediaCodec.configure(MediaCodec.java:2215)
at android.media.MediaCodec.configure(MediaCodec.java:2131)
at androidx.media3.exoplayer.mediacodec.AsynchronousMediaCodecAdapter.initialize(AsynchronousMediaCodecAdapter.java:174)
at androidx.media3.exoplayer.mediacodec.AsynchronousMediaCodecAdapter.access$100(AsynchronousMediaCodecAdapter.java:54)
at androidx.media3.exoplayer.mediacodec.AsynchronousMediaCodecAdapter$Factory.createAdapter(AsynchronousMediaCodecAdapter.java:119)
at androidx.media3.exoplayer.mediacodec.DefaultMediaCodecAdapterFactory.createAdapter(DefaultMediaCodecAdapterFactory.java:117)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.initCodec(MediaCodecRenderer.java:1195)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.maybeInitCodecWithFallback(MediaCodecRenderer.java:1103)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.maybeInitCodecOrBypass(MediaCodecRenderer.java:551)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.onInputFormatChanged(MediaCodecRenderer.java:1560)
at androidx.media3.exoplayer.video.MediaCodecVideoRenderer.onInputFormatChanged(MediaCodecVideoRenderer.java:1152)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.readSourceOmittingSampleData(MediaCodecRenderer.java:994)
at androidx.media3.exoplayer.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:814)
at androidx.media3.exoplayer.video.MediaCodecVideoRenderer.render(MediaCodecVideoRenderer.java:940)
at androidx.media3.exoplayer.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:1102)
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:541)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.os.HandlerThread.run(HandlerThread.java:67)
```
</details>
**! ! 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.
The flow must emit every update even if the values are the same, so use
SharedFlow instead of StateFlow.
Regression from https://github.com/tuskyapp/Tusky/pull/4337 cc @Goooler
Currently translated at 100.0% (639 of 639 strings)
Co-authored-by: fin-w <puf@users.noreply.weblate.tusky.app>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
Konrad Pozniak
Anonymous
Quentí
Deleted User
Eliot Lash
Weblate
Levi Bard
Ihor Hordiichuk
Ümit Solmaz
fin-w
Hồ Nhất Duy
Danial Behzadi
Manuel
XoseM
Christophe Beyls
Salif Mehmed
Stavros
fries1234
Mārtiņš Bruņenieks
Connyduck
UlrichKu
Conny Duck
Balázs Meskó
Zongle Wang
xzFantom
Deleted User
Sveinn í Felli
fin-w
Gera, Zoltan
cuithon
fin-w
Willow
