regression from https://github.com/tuskyapp/Tusky/pull/4978
I'm sure this `BottomSheetCallback` business had a reason, but it works
fine without on all the devices I tried it with 🤷
[A user made me aware of the fact that we have varying spacing between
post content and the
buttons](https://mstdn.games/@Sven/114104502703573482), so I
investigated 🧐
Indeed, there were some problems:
- The trailing hashtags bar was sometimes visible, despite not showing
any content.
- The media container was visible despite showing no media
- The buttons where layed out differently when showing a conversation
This change fixes those problems and adds an additional 2dp space
between buttons and contents because without these issues the buttons
and the content are quite close otherwise.
- Fixes the background of the ComposeActivity in table mode which looked
weird since https://github.com/tuskyapp/Tusky/pull/4897
- The ComposeActivity in tablet mode will now resize when the keyboard
expands, the previously used fixed height would cause the bottom bar to
hide entered text on some devices, closes
https://github.com/tuskyapp/Tusky/issues/4973
- The bottom sheets in the compose view will now be in fully hidden
state by default, as some weirdness on some devices caused them to peek
over the bottom bar in half collapsed state. Please test @fin-w
- The bottom sheet in the image viewer will now expand a bit more in
edge-to-edge mode so it doesn't look it is deliberately obscured by the
system bar. The image also moves up a bit so it won't be covered by the
bottom sheet as much.
- The "Performing lookup…" bottom sheet won't be covered by the nav bar
anymore
Glide compares the previous load with the current load, and if they are
identical, does basically nothing. Thats what we want, because otherwise
it flickers when the requested image is not in the memory cache.
The problem is, we decode the blurhash we use as placeholder everytime.
And the BitmapDrawables we get don't have a proper equals
implementation.
So Glide is like: Aha, different placeholder, better load again ->
Flicker
I added a BlurhashDrawable with custom equals/hashCode and now the
flickering is gone.
This changes the notification channel names back to what they were pre
https://github.com/tuskyapp/Tusky/pull/4929 so users don't lose their
settings and the channels won't be duplicated. Tusky nightly users that
installed a in-between version will still have duplicate channels, they
will need to reinstall.
On my device the status info was just slighty misaligned, so I
investigated. Turns out the dp values were correct, but the
`Utils.dpToPx` method calculates with the exact density of the device,
whereas everything else uses the density buckets Android defines. And on
some devices that makes a visible difference. Did a little refactor and
now everything should always be aligned correctly.
And in `item_follow` the padding was just different from other
notification items.
```
Exception java.lang.IllegalStateException:
at androidx.fragment.app.Fragment.requireActivity (Fragment.java:1005)
at com.keylesspalace.tusky.fragment.ViewImageFragment.getPhotoActionsListener (ViewImageFragment.java:58)
at com.keylesspalace.tusky.fragment.ViewImageFragment.access$getPhotoActionsListener (ViewImageFragment.java:48)
at com.keylesspalace.tusky.fragment.ViewImageFragment$ImageRequestListener.onResourceReady$lambda$0 (ViewImageFragment.java:335)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8751)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
```
re: https://chaos.social/@jannik/114059313885014801
Not sure why I didn't use `onPrepare` previously 🤔 . Makes more sense
this way.
The difference between `onStart` and `onPrepare` is that `onPrepare` is
called before the `OnApplyWindowInsetsListener` and the other after. So
with `onPrepare` it is easy to detect that an animation is starting. The
keyboard only seems to animate initially, not when it changes size
later, but the previous code always expected an animation.
Closes#3095
---
Since I had to add `visibility` on the `onReblog` method, it is possible
that I have broken something. Also, I kept the old method signature
(which calls the new one), but it's possible that it is not needed.
~~I'm not 100% sure that unlisted boost works, as the visibility of the
boost is not shown anywehere.~~ I've confirmed that private
(followers-only) boosts are not visible on private browsing on the
browser.
EDIT: Confirmed visibility in devtools on web browser.
Screenshots:
… as requested in #4219
No unit tests failed because of this change, as far as I could see.
However, one could add some if necessary.
Co-authored-by: Paul Weber <paul@apollo.ai>
Besides the refactoring these improvements:
* Track last push distributor and reset settings and subscription on any
incompatible change (ie. uninstall)
* Only update (push) notification settings on server if needed
* Allow to only fetch notifications for one account (the one for which a
push message was received)
This is (also) the revival of
https://github.com/tuskyapp/Tusky/pull/3642
It's not really well tested so far. (Ie. with two or more accounts or
two or more push providers.)
The setOnApplyWindowInsetsListener callback is not always excecuted,
e.g. because there are no insets to consume on older api levels. This
fixes the problem and makes sure our RecyclerViews always have the
correct bottom padding and are not covered by other views.
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
