[](https://renovatebot.com)
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [gradle](https://gradle.org)
([source](https://togithub.com/gradle/gradle)) | minor | `8.8` -> `8.9`
|
---
### Release Notes
<details>
<summary>gradle/gradle (gradle)</summary>
### [`v8.9`](https://togithub.com/gradle/gradle/compare/v8.8.0...v8.9.0)
[Compare
Source](https://togithub.com/gradle/gradle/compare/v8.8.0...v8.9.0)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/tuskyapp/Tusky).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoiZGV2ZWxvcCIsImxhYmVscyI6W119-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
re: https://infosec.exchange/@webhat/112745609655586468
Boost were not correctly handled here, probably because they are only on
profile timelines which I rarely check. This makes sure likes and boosts
get correctly set to posts even when they are boosts.
```
Exception java.lang.NullPointerException: Attempt to invoke virtual method 'void android.view.View.setClipToOutline(boolean)' on a null object reference
at com.keylesspalace.tusky.adapter.StatusBaseViewHolder.<init> (StatusBaseViewHolder.java:150)
at com.keylesspalace.tusky.adapter.StatusViewHolder.<init> (StatusViewHolder.java:55)
at com.keylesspalace.tusky.components.notifications.UnknownNotificationViewHolder.<init> (UnknownNotificationViewHolder.java:27)
at com.keylesspalace.tusky.components.notifications.NotificationsPagingAdapter.onCreateViewHolder (NotificationsPagingAdapter.kt:139)
at androidx.recyclerview.widget.RecyclerView$Adapter.createViewHolder (RecyclerView.java:7788)
at androidx.recyclerview.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline (RecyclerView.java:6873)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition (RecyclerView.java:6757)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition (RecyclerView.java:6753)
at androidx.recyclerview.widget.LinearLayoutManager$LayoutState.next (LinearLayoutManager.java:2362)
at androidx.recyclerview.widget.LinearLayoutManager.layoutChunk (LinearLayoutManager.java:1662)
at androidx.recyclerview.widget.LinearLayoutManager.fill (LinearLayoutManager.java:1622)
at androidx.recyclerview.widget.LinearLayoutManager.onLayoutChildren (LinearLayoutManager.java:687)
at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep2 (RecyclerView.java:4645)
at androidx.recyclerview.widget.RecyclerView.dispatchLayout (RecyclerView.java:4348)
at androidx.recyclerview.widget.RecyclerView.onLayout (RecyclerView.java:4919)
...
```
A user still on Mastodon 3 complained that since my change in
https://github.com/tuskyapp/Tusky/pull/4539 the timeline reloads on
starting Tusky. Well, we need to do some reloading of the timeline after
loading the v1 filters or they won't work. Changing the `fullReload` to
`invalidate` improves the situation by not loading everything from the
network again (just the database) but there is still some noticeable
loading.
(I'm not willing to invest any more time to support these old instances)
This is way more efficient than before as less views need to be inflated
and bound for a filtered status to be rendered. It also should fix the
bug where sometimes a `StatusViewHolder` that is set up for showing a
status gets bound to a status that is filtered, leading to a crash.
Instead of calling the endpoint every time filters are needed, it will
be called only once and the result cached. This will result in quite
some requests less on instances supporting v2.
I also tested v1 filters and made some small improvements. We should
[remove filters v1
support](https://github.com/tuskyapp/Tusky/issues/4538) some time in the
future though.
```
java.lang.NullPointerException: Attempt to invoke virtual method 'void android.widget.TextView.setText(java.lang.CharSequence)' on a null object reference
at com.keylesspalace.tusky.adapter.StatusBaseViewHolder.setupFilterPlaceholder(StatusBaseViewHolder.java:894)
at com.keylesspalace.tusky.adapter.StatusBaseViewHolder.setupWithStatus(StatusBaseViewHolder.java:825)
at com.keylesspalace.tusky.adapter.StatusViewHolder.setupWithStatus(StatusViewHolder.java:91)
at com.keylesspalace.tusky.components.notifications.StatusViewHolder.bind(StatusViewHolder.kt:46)
at com.keylesspalace.tusky.components.notifications.NotificationsPagingAdapter.bindViewHolder(NotificationsPagingAdapter.kt:150)
at com.keylesspalace.tusky.components.notifications.NotificationsPagingAdapter.onBindViewHolder(NotificationsPagingAdapter.kt:143)
at androidx.recyclerview.widget.RecyclerView$Adapter.bindViewHolder(RecyclerView.java:7847)
at androidx.recyclerview.widget.RecyclerView$Recycler.tryBindViewHolderByDeadline(RecyclerView.java:6646)
at androidx.recyclerview.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline(RecyclerView.java:6917)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:6757)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:6753)
at androidx.recyclerview.widget.LinearLayoutManager$LayoutState.next(LinearLayoutManager.java:2362)
at androidx.recyclerview.widget.LinearLayoutManager.layoutChunk(LinearLayoutManager.java:1662)
at androidx.recyclerview.widget.LinearLayoutManager.fill(LinearLayoutManager.java:1622)
at androidx.recyclerview.widget.LinearLayoutManager.onLayoutChildren(LinearLayoutManager.java:687)
at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:4645)
at androidx.recyclerview.widget.RecyclerView.dispatchLayout(RecyclerView.java:4348)
at androidx.recyclerview.widget.RecyclerView.consumePendingUpdateOperations(RecyclerView.java:2106)
at androidx.recyclerview.widget.RecyclerView$1.run(RecyclerView.java:468)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1231)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239)
at android.view.Choreographer.doCallbacks(Choreographer.java:899)
at android.view.Choreographer.doFrame(Choreographer.java:827)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214)
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)
```
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)
Currently translated at 100.0% (648 of 648 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (647 of 647 strings)
Co-authored-by: fin-w <fin-w@tutanota.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
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).
Konrad Pozniak
renovate[bot]
Connyduck
Conny Duck
Hồ Nhất Duy
Ihor Hordiichuk
fin-w
Ümit Solmaz
Weblate
autay27
XoseM
Mārtiņš Bruņenieks
Manuel
Danial Behzadi
Christophe Beyls
