I tried to find a solution without using a deprecated api to no avail.
But better a working app than perfect code I guess.
In the end this probably is a bug in the Material component library
https://github.com/material-components/material-components-android/issues/3307.
I also made the insets smaller which improves the dialogs a lot on small
screens.
Several cases of payloads not being forwarded correctly, leading to
unnecessary re-binding of the whole status view. I simplified the logic
by removing the additional list level, making it easier to understand
what is going on.
- Update to Api 35
- Update all dependencies that were blocked because they require Api 35
- fix some deprecation warnings
- implement the now required edge-to-edge mode
Edge-to-edge mode means that we now draw under the status bar and the
navigation bar and need to make sure we don't overlap with them.
Previously the system would do that for us, and we would only provide
the color we want the bars in.
For the edge-to-edge mode there are two Apis that are important:
- `fitsSystemWindows` - some Widgets, mostly from the Material library,
automatically handle system insets if you set this attribute on them to
true
- `ViewCompat.setOnApplyWindowInsetsListener` - this allows you to
manually handle the various insets. By returning new insets from the
callback it is possible to tell the system which ones are handled and
which ones should be taken care of by another view.
In most places edge-to-edge was straightforward to implement, except in
`ComposeActivity`, `AccountActivity` and `MainActivity` which required a
more custom approach, and a hacky solution to make landscape mode work
in `BaseActivity`.
There is also the `ViewCompat.setWindowInsetsAnimationCallback` Api
which allows animating with moving insets. I used that in
`LoginActivity` and `ComposeActivity` to animate the Views together with
the keyboard.
On Android Versions below 15 (Api <= 34) Tusky will look almost the same
as before. I think the only exception is the main bottom bar, which is
now slighty larger. We customized it to be smaller than the default, but
in edge-to-edge mode the height needs to be `wrap_content` or it won't
handle insets correctly.
Screenshots:
<img
src="https://github.com/user-attachments/assets/2a1bf5d9-79fb-48eb-affc-1cbb1164d5f0"
width="280"/>
<img
src="https://github.com/user-attachments/assets/9edccdf2-c0e9-4881-a6df-bd0872934f28"
width="280"/>
<img
src="https://github.com/user-attachments/assets/2916a271-f53e-4d38-a83a-69083eb3053f"
width="280"/>
`EXTRA_RESTART_ON_BACK` is never set on the Intent extras, but
`intent.extras?.getBoolean(EXTRA_RESTART_ON_BACK)` will return `false`
as long as there are any extras, hiding the actual value from the
`savedInstanceState`.
closes https://github.com/tuskyapp/Tusky/issues/4887
And some other small improvements like better paddings and font sizes.
Also the `status_info` in `item_status` now looks nicer in rtl mode.
Without this fix, the vote goes through but the poll in the app doesn't
update.
Fixed by using `updateStatusByActionableId`, which automatically handles
boosted & regular posts. Also handle poll votes the same way as in the
home timeline, by listening to the `PollVoteEvent`.
- Move all database queries off the ui thread - this is a massive
performance improvement
- ViewModel for MainActivity - this makes MainActivity smaller and
network requests won't be retried when rotating the screen
- removes the Push Notification Migration feature. We had it long
enough, all users who want push notifications should be migrated by now
- AccountEntity is now immutable
- converted BaseActivity to Kotlin
- The header image of Accounts is now cached as well
Instead of just "Hashtags".
Actually, this was a bug. The code to generate the correct title is
already here, but it wasn't called. 🤷
closes https://github.com/tuskyapp/Tusky/issues/4867
In https://github.com/tuskyapp/Tusky/pull/4851 I changed the theme of
`AccountsInListFragment`, which accidentally turned its background white
for the dark theme.
Additionally this fixes the color for the preference dialogs, which I
think have been incorrect since the Material3 redesign.
I also wondered if we should make dialogs darker for the black theme,
but looks like there is not much interest in that
https://chaos.social/deck/@ConnyDuck/113802937491059461
(Currently they are just the same as the dark theme)
A hashtag picker dialog was implemented twice, with slight differences.
Now there is only one
- with hashtag validation - no more api errors when following an invalid
one
- The dialog can now be closed with the keyboard, for extra fast hashtag
selection
- with autocomplete
I also added a new snackbar when following a hashtag was succesfull.
Although I'm not sure about the auto complete, it can be very annoying
as the drop down covers the buttons. I found no way to make it size to
its content: https://chaos.social/@ConnyDuck/113803457147888844
Should we get rid of it?
Do summary notifications like the Api defines it:
* Schedule and summarize without delay (in order for summerization to
work)
* Always have a summary notification: simplify code with this and make
more reliable
* Do not care about single notification count (the system already does
that as well)
* **Bugfix: Schedule summary first: This avoids a rate limit problem
that (then) not groups at all**
Testing this is probably the most difficult part.
For example I couldn't get any notification to ring with older Api
versions in the debugger. (Same as for current develop)
However one hack to always get notifications: Fix "minId" in
"fetchNewNotifications()" to a somewhat older value.
Next possible step: Have only one summary notification at all (for all
channels/notification types). You can still configure single channels
differently.
Or: For very many notifications: Only use a true summary one (something
like "you have 28 favorites and 7 boosts").
Generally: The notification timeline must be improved now. Because that
must be the go-to solution for any large number of notifications. It
must be easy to read. E. g. with grouping per post.
There were network calls inside a database transaction. That basically
locked the database for the duration of the network call, causing the
app to freeze if the call took to long.
This restructures the code so that all picked media will be added to the
upload queue in the correct order and also does some other code cleanup.
closes#4754
The problem is that the MaterialAlertDialog uses a layout with
"wrap_content" around the custom view. Even though the dialog was
stretched to the whole window size, the content was never shown.
The fix reverts to the default dialog and styles it as if it was a
MaterialAlertDialog, which works and also looks better on smaller
screens.
fixes#4850
We want multi line titles so they are readable on small screens or with
large font sizes, and setting the attribute on every single preference
individually is annoying (and we forgot one).
https://pawb.fun/@keeri/113772067202381363
Mastodon "normalizes" tag text for latin characters when storing tag
names, so the hashtag object it sends for `#Über` has the name `uber`.
With the new trailing hashtag bar, this was causing nonascii hashtags
from the post content to be duplicated with their normalized versions,
e.g. `#Über #uber`.
This change ensures that we're always comparing normalized tag names.
We do this in other ViewHolders as well
Seen in this crash report on Google Play:
```
Exception java.lang.IndexOutOfBoundsException: Index: -1, Size: 0
at androidx.paging.PageStore.checkIndex (PageStore.kt:56)
at androidx.paging.PageStore.get (PageStore.kt:66)
at androidx.paging.PagingDataPresenter.peek (PagingDataPresenter.java:290)
at androidx.paging.AsyncPagingDataDiffer.peek (AsyncPagingDataDiffer.java:476)
at androidx.paging.PagingDataAdapter.peek (PagingDataAdapter.kt:312)
at com.keylesspalace.tusky.components.notifications.NotificationsFragment.onViewThread (NotificationsFragment.kt:409)
at com.keylesspalace.tusky.components.notifications.StatusNotificationViewHolder.bind$lambda$0 (StatusNotificationViewHolder.java:104)
at android.view.View.performClick (View.java:7684)
at android.view.View.performClickInternal (View.java:7661)
at android.view.View.-$$Nest$mperformClickInternal (Unknown Source)
at android.view.View$PerformClick.run (View.java:30344)
at android.os.Handler.handleCallback (Handler.java:1000)
at android.os.Handler.dispatchMessage (Handler.java:104)
at android.os.Looper.loopOnce (Looper.java:242)
at android.os.Looper.loop (Looper.java:362)
at android.app.ActivityThread.main (ActivityThread.java:8393)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:552)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:992)
```
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.
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
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"/>
```
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)
```
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
closes https://github.com/tuskyapp/Tusky/issues/4725
I checked with examples from https://github.com/tuskyapp/Tusky/pull/2743
and looks like nothing broke. Not sure why the `.dontTransform()` was
there. It prevents Glide from correctly sizing the image, leading to a
crash.
<details>
<summary>Stacktrace</summary>
```
java.lang.RuntimeException: Canvas: trying to draw too large(401361624bytes) 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 android.widget.ImageView.onDraw(ImageView.java:1446)
at com.google.android.material.imageview.ShapeableImageView.onDraw(ShapeableImageView.java:188)
at android.view.View.draw(View.java:23266)
at android.view.View.updateDisplayListIfDirty(View.java:22133)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.draw(View.java:23269)
at android.view.View.updateDisplayListIfDirty(View.java:22133)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at androidx.constraintlayout.widget.ConstraintLayout.dispatchDraw(ConstraintLayout.java:1994)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at androidx.recyclerview.widget.RecyclerView.drawChild(RecyclerView.java:5545)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.draw(View.java:23269)
at androidx.recyclerview.widget.RecyclerView.draw(RecyclerView.java:4944)
at android.view.View.updateDisplayListIfDirty(View.java:22133)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.draw(View.java:23269)
at android.view.View.updateDisplayListIfDirty(View.java:22133)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at androidx.coordinatorlayout.widget.CoordinatorLayout.drawChild(CoordinatorLayout.java:1277)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at androidx.fragment.app.FragmentContainerView.drawChild(FragmentContainerView.kt:232)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at androidx.fragment.app.FragmentContainerView.dispatchDraw(FragmentContainerView.kt:222)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at androidx.coordinatorlayout.widget.CoordinatorLayout.drawChild(CoordinatorLayout.java:1277)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.updateDisplayListIfDirty(View.java:22124)
at android.view.View.draw(View.java:22997)
at android.view.ViewGroup.drawChild(ViewGroup.java:4529)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4290)
at android.view.View.draw(View.java:23269)
at com.android.internal.policy.DecorView.draw(DecorView.java:821)
at android.view.View.updateDisplayListIfDirty(View.java:22133)
at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:689)
at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:695)
at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:793)
at android.view.ViewRootImpl.draw(ViewRootImpl.java:4789)
at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:4500)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3687)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2371)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9297)
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:832)
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:7924)
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)
```
</details>
