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)
