closes#4631closes#4629
and other weirdness introduced in Tusky 26.1.
I did a lot of testing on 2 physical devices and multiple emulators. It
definitely is better than before, but probably still not perfect.
Adds feature if user clicks on toolbar, on the pages box, or on the tabs
buttons that the keyboard will minimize and focus will be taken off of
search bar.
Further addresses issue #4573
Currently translated at 99.3% (647 of 651 strings)
Translated using Weblate (Occitan)
Currently translated at 98.3% (640 of 651 strings)
Co-authored-by: Quentí <quentinantonin@free.fr>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/oc/
Translation: Tusky/Tusky
This fixes a bug where the timeline would jump to the position of a
previously clicked "load more" when new post are inserted at the top
after swiping to refresh.
This only happens when "Reading order" is set to "Oldest first".
The problem is that updateReadingPositionForOldestFirst (which consumes
the marker to which it should jump) is called from onItemRangeInserted.
But onItemRangeInserted is not called everytime a "load more" is
clicked, leaving the marker active, causing a jump the next time
onItemRangeInserted is called.
I am not sure this fixes all cases of the various jumping bugs that have
been reported recently as this was the only one I could reliably
reproduce.
Related to https://github.com/tuskyapp/Tusky/issues/4493
I don't know why exactly, but when the ViewHolder gets recycled and the
ProgressBar is set to visible again, it just doesn't show anything. It
seems to be a bug in the platform ProgressBar, and it doesn't happen on
all devices. Replacing it with a CircularProgressIndicator fixes the bug
and looks the same.
Reported here:
https://github.com/tuskyapp/Tusky/issues/4493#issuecomment-2182407513
This does 2 things:
- Removes `AccountSwitchInterceptor`, the main culprit for the bug. APIs
can no longer change their base url after they have been created. As a
result they are not Singletons anymore.
- Additionally, I refactored how MainActivity handles Intents to make it
less likely to have multiple instances of it active.
Here is how I could reliably reproduce the bug:
- Be logged in with account A and B
- Write a post with account A, cancel it before it sends (go into flight
mode for that)
- Switch to account B
- Open the "this post failed to send" notification from account A,
drafts will open
- Go back. You are in the MainActivity of account A, everything seems
fine.
- Go back again. You are in the old, now broken MainActivity of account
B. It uses the database of account B but the network of account A.
Refreshing will show posts from A.
closes#4567closes#4554closes#4402closes#4148closes#2663
and possibly #4588
[Let's encrypt had to make some changes to their
signing](https://letsencrypt.org/2023/07/10/cross-sign-expiration.html),
as a result Android 7 doeesn't have the root certificates necessary to
trust Let's encrypt signed certificates anymore. Since most Fedi
instances use Let's encrypt, that is a problem. To work around we can
add the certificates to Tusky directly.
Details [here](https://stackoverflow.com/a/78309587).
closes#4607
Currently translated at 100.0% (651 of 651 strings)
Translated using Weblate (German)
Currently translated at 99.8% (650 of 651 strings)
Co-authored-by: Connyduck <weblate@connyduck.at>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/de/
Translation: Tusky/Tusky
This will make it less likely that data from different accounts will get
mixed up.
I checked the codepaths and we shouldn't hit viewModel if account is not
there but this is still a bit of risk to assume that so I'll investigate
if we can pass in more things and use DI to make it more secure
---------
Co-authored-by: Conny Duck <git@connyduck.at>
Addresses issue #4573. Updates searchView in SearchActivity to clear
focus when a user makes a search. This allows the keyboard to not keep
popping up after a user goes back to search screen after clicking on a
searched item.
This is the third attempt to fix `RequestBuilder.submitAsync()`. For the
rationale, see the comments of #4436.
We now clear the continuation reference after resuming it, to make sure
that:
1) It will only be resumed once
2) It will not leak the coroutine when Glide keeps the `Request` around.
Without the `isPersistent = false` flag the preference is saved to
SharedPreferences in addition to the account and overrides the shown
value. So it would always show the value of the last account it was set
to. It was working fine though, only the shown value was wrong.
https://social.sitedethib.com/@Claire/112769984398891581
https://social.froonix.org/@cs/112767747835228296
We were caching the instance info with the instance name as the key and
then look it up with the actual domain and those do not always match so
the check if translation is supported fails. fnx.li vs
social.froonix.org in this case.
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).
Currently translated at 100.0% (647 of 647 strings)
Translated using Weblate (Italian)
Currently translated at 100.0% (645 of 645 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% (647 of 647 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (645 of 645 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (645 of 645 strings)
Co-authored-by: fin-w <fin-w@tutanota.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
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
Konrad Pozniak
andrewhamilton0
Quentí
XoseM
Ihor Hordiichuk
Weblate
Ümit Solmaz
fin-w
Manuel
Hồ Nhất Duy
Eric
Danial Behzadi
Cathal Garvey
GunChleoc
Deleted User
Deleted User
Connyduck
Deleted User
Willow
Christophe Beyls
Conny Duck
Mārtiņš Bruņenieks
autay27
Anonymous
Deleted User
Eliot Lash
Levi Bard
