Emojis are sorted by category within the emoji picker. The original
alphabetical sorting is preserved within categories.
This partially addresses #1868 and is only a small part of what is done
in #3300, but I think it is still enough to improve quality of life for
users.
When investigating #4517, I found that sharing to Tusky sometimes just
does nothing.
This is because when `MainActivity` is already open, it isn't always
restarted (`onCreate` not called) but instead the Intent is delivered to
`onNewIntent` of the existing `MainActivity`. This fixes the issue by
overriding `onNewIntent`.
The problem does not always reproduce, it seems to depend on what is
shared from where and on the Android version. `MainActivity` must be
open for the problem to occur though.
This probably also fixes the issue that sometimes Tusky does not show
the right tab when clicking on a notification
(https://github.com/tuskyapp/Tusky/issues/2691)
Found this crash in the Google Play reports:
```
Exception java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0
at jdk.internal.util.Preconditions.outOfBounds (Preconditions.java:64)
at jdk.internal.util.Preconditions.outOfBoundsCheckIndex (Preconditions.java:70)
at jdk.internal.util.Preconditions.checkIndex (Preconditions.java:266)
at java.util.Objects.checkIndex (Objects.java:359)
at java.util.ArrayList.get (ArrayList.java:434)
at java.util.Collections$UnmodifiableList.get (Collections.java:1394)
at com.keylesspalace.tusky.components.compose.MediaPreviewAdapter.onMediaClick (MediaPreviewAdapter.java:45)
at com.keylesspalace.tusky.components.compose.MediaPreviewAdapter.access$onMediaClick (MediaPreviewAdapter.java:32)
at com.keylesspalace.tusky.components.compose.MediaPreviewAdapter$PreviewViewHolder._init_$lambda$0 (MediaPreviewAdapter.java:144)
at android.view.View.performClick (View.java:7535)
at android.view.View.performClickInternal (View.java:7512)
at android.view.View.-$$Nest$mperformClickInternal
at android.view.View$PerformClick.run (View.java:29488)
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:8118)
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)
```
Can't reproduce, but seems to be some kind of race condition where the
view is clicked at the same time as it is being removed from the
`RecyclerView`. Not using the index in the click listener should resolve
the problem. Also refactored to `ListAdapter` to not deal with the
`AsyncListDiffer` manually.
Follow up to https://github.com/tuskyapp/Tusky/pull/3921
- no more hardcoded `tusky_blue`, instead the `colorPrimary` attribute
is used. This will help us when adding more themes, e.g a dynamic color
one.
- The `colorPrimary` of the dark theme is now lighter for more contrast
and subsequently the `colorOnPrimary` is now dark grey instead of white.
- `tusky_red_lighter` is now a bit more red than before
- Tweaked color usage in a few places for better contrast
I think this looks a bit unfamiliar but overall better and the higher
contrast makes things noticeably easier to read.
<img
src="https://github.com/tuskyapp/Tusky/assets/10157047/4cbb92d8-b772-4e94-bc15-c4baf0e5473f"
width="260"/>
This pull request aims to dramatically improve the performance of
`BlurHashDecoder` while also reducing its memory allocations.
- Precompute cosines tables before composing the image so each cosine
value is only computed once.
- Compute cosines tables once if both are identical (for square images
with the same number of colors in both dimensions).
- Store colors in a one-dimension array instead of a two-dimension array
to reduce memory allocations.
- Use a simple `String.indexOf()` to find the index of a Base83 char,
which is both faster and needs less memory than a `HashMap` thanks to
better locality and no boxing of chars.
- No cache is used, so computations may be performed in parallel on
background threads without the need for synchronization which limits
throughput.
## Benchmarks
Simple: 4x4 colors, 32x32 pixels output. (This is what Mastodon and
Tusky currently use)
Complex: 9x9 colors, 256x256 pixels output.
**Pixel 7 (Android 14)**
```
365 738 ns 23 allocs Trace BlurHashDecoderBenchmark.tuskySimple
109 577 ns 8 allocs Trace BlurHashDecoderBenchmark.newSimple
108 771 647 ns 88 allocs Trace BlurHashDecoderBenchmark.tuskyComplex
12 932 076 ns 8 allocs Trace BlurHashDecoderBenchmark.newComplex
```
**Nexus 5 (Android 6)**
```
4 600 937 ns 22 allocs Trace BlurHashDecoderBenchmark.tuskySimple
1 391 487 ns 7 allocs Trace BlurHashDecoderBenchmark.newSimple
1 260 644 948 ns 87 allocs Trace BlurHashDecoderBenchmark.tuskyComplex
125 274 063 ns 7 allocs Trace BlurHashDecoderBenchmark.newComplex
```
Conclusion: The new implementation is **3 times faster** than the old
one for the current usage and up to **9 times faster** if we decide to
increase the BlurHash quality in the future.
The source code of the benchmark comparing the original untouched Kotlin
implementation to the new one can be found
[here](https://github.com/cbeyls/BlurHashAndroidBenchmark).
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"/>
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
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.
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)
...
```
- 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.
