This fixes two issues, but I tested them together to make sure this time
everything works as expected.
1) The fix in #4813 went into the right direction, but the condition was
a bit too broad. When sharing something to Tusky so that Tusky switches
accounts, sometimes nothing would happen.
2) fixes#4766. There are two possibilities here (I think it depends
mostly on API level):
2a) Sharing starts a new task. `android:maxRecents="1"` makes sure old
tasks disappear and are not left in the weird in-between state.
3a) Sharing starts a new `MainActivity` in an existing task.
`Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK` makes
sure old `MainActivity` instances are removed. On newer Android versions
this has the sideeffect of changing the switch animation, but whatever.
Basically this gives us the behavior I wanted to achieve with the
`android:launchMode="singleTask"` without the unintended side effects.
Currently translated at 100.0% (677 of 677 strings)
Co-authored-by: Anna (cybertailor) Vyalkova <cyber@sysrq.in>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/ru/
Translation: Tusky/Tusky
closes#4789 this time for real, hopefully, maybe
also set `alwaysRetainTaskState` for good measure
> `android:alwaysRetainTaskState`
Whether the state of the task that the activity is in is always
maintained by the system. `"true"` if it is, and `"false"` if the system
can reset the task to its initial state in certain situations. The
default value is `"false"`. This attribute is meaningful only for the
root activity of a task. It's ignored for all other activities.
> Normally, the system clears a task, removing all activities from the
stack above the root activity, in certain situations when the user
re-selects that task from the home screen. Typically, this is done if
the user hasn't visited the task for a certain amount of time, such as
30 minutes.
> However, when this attribute is `"true"`, users always return to the
task in its last state, regardless of how they get there. This is useful
in an application like a web browser where there is a lot of state, such
as multiple open tabs, that users don't want to lose.
https://developer.android.com/guide/topics/manifest/activity-element#always
Currently translated at 100.0% (677 of 677 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (677 of 677 strings)
Co-authored-by: Danial Behzadi <dani.behzi@ubuntu.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/fa/
Translation: Tusky/Tusky
Currently translated at 99.1% (671 of 677 strings)
Translated using Weblate (Dutch)
Currently translated at 99.1% (671 of 677 strings)
Co-authored-by: joenepraat <joenepraat@posteo.org>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/nl/
Translation: Tusky/Tusky
Currently translated at 100.0% (677 of 677 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (677 of 677 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
This was so much work wow. I think it works pretty well and is the best
compromise between all the alternative we considered. Yes the
pull-to-refreh on the notifications works slightly different now when
the new bar is visible, but I don't think there is a way around that.
Things I plan to do later, i.e. not as part of this PR or release:
- Cache the notification policy summary for better offline behavior and
less view shifting when it loads
- try to reduce some of the code duplications that are now in there
- if there is user demand, add a "legacy mode" setting where this
feature is disabled even if the server would support it
closes#4331closes#4550 as won't do
closes#4712 as won't do
<img
src="https://github.com/user-attachments/assets/de322d3c-3775-41e7-be57-28ab7fbaecdf"
width="240"/> <img
src="https://github.com/user-attachments/assets/1ce958a4-4f15-484c-a337-5ad93f36046c"
width="240"/> <img
src="https://github.com/user-attachments/assets/98b0482b-1c05-4c99-a371-f7f4d8a69abd"
width="240"/>
- use `runTest` instead of `runBlocking`, where possible
- run all Robolectric tests on Api 34 (where we have most users)
- some new testcase for `TimestampUtilsTest`
- move our only instrumented Android Test, `MigrationsTest`, to unit
test so it runs in CI and expand it to test all migrations
- upgrade Robolectric
- removed truth and espresso as they are no longer needed
```
java.lang.StringIndexOutOfBoundsException
at android.text.SpannableStringBuilder.<init>(SpannableStringBuilder.java:63)
at android.text.SpannableStringBuilder.subSequence(SpannableStringBuilder.java:1198)
at com.keylesspalace.tusky.util.LinkHelper.setClickableText(LinkHelper.kt:99)
at com.keylesspalace.tusky.adapter.StatusBaseViewHolder.setTextVisible(StatusBaseViewHolder.java:289)
at com.keylesspalace.tusky.adapter.StatusBaseViewHolder.setSpoilerAndContent(StatusBaseViewHolder.java:244)
at com.keylesspalace.tusky.adapter.StatusBaseViewHolder.setupWithStatus(StatusBaseViewHolder.java:820)
at com.keylesspalace.tusky.adapter.StatusViewHolder.setupWithStatus(StatusViewHolder.java:91)
at com.keylesspalace.tusky.components.timeline.TimelinePagingAdapter.bindViewHolder(TimelinePagingAdapter.kt:100)
at com.keylesspalace.tusky.components.timeline.TimelinePagingAdapter.onBindViewHolder(TimelinePagingAdapter.kt:82)
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.GapWorker.prefetchPositionWithDeadline(GapWorker.java:288)
at androidx.recyclerview.widget.GapWorker.flushTaskWithDeadline(GapWorker.java:345)
at androidx.recyclerview.widget.GapWorker.flushTasksWithDeadline(GapWorker.java:361)
at androidx.recyclerview.widget.GapWorker.prefetch(GapWorker.java:368)
at androidx.recyclerview.widget.GapWorker.run(GapWorker.java:399)
at android.os.Handler.handleCallback(Handler.java:959)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loopOnce(Looper.java:232)
at android.os.Looper.loop(Looper.java:317)
at android.app.ActivityThread.main(ActivityThread.java:8705)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:580)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:886)
```
Currently translated at 99.0% (646 of 652 strings)
Co-authored-by: Anna (cybertailor) Vyalkova <cyber@sysrq.in>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/ru/
Translation: Tusky/Tusky
Currently translated at 100.0% (652 of 652 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (652 of 652 strings)
Co-authored-by: Rhoslyn Prys <post@meddal.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
Before we would not send `expires_in` when "indefinite" was selected.
But that left the expiration at the value it was before. To actually set
it to indefinite we need to send `expires_in`, but leave it empty.
With a value class this was actually really nice to fix, the code now
self-documents what the special values mean.
Also fixes a regression from the Material 3 redesign where the filter
duration drop down would not get populated when creating a filter.
Found while working on https://github.com/tuskyapp/Tusky/pull/4742
This is to match Mastodon web behavior.
Also, make revealing filtered boosts in non-cached timelines work (can
only happen on user profiles, other timelines don't have boosts).
found thanks to this: https://tech.lgbt/@darkfox/113378644538792719
