API 31+ devices don't need to install the compat SplashScreen because
they have their own native splash screen implementation. Furthermore, we
don't need to customize the splash screen so there is no need to call
the library.
On API 31+, the SplashScreen compat library registers some kind of
listener which causes display bugs with the Tusky theme on some Android
versions. Disabling the library on API 31+ solves this issue.
Fixes#4446.
Loading the image as a `Drawable` allows using the Drawable API to
abstract the drawing.
This way, any kind of `Drawable` (including the fallback vector
drawable) can be drawn in one pass to the Bitmap, without having to be
converted to a `Bitmap` first.
Also, `BitmapDrawable` will automatically use
[`Paint.FILTER_BITMAP_FLAG`](https://developer.android.com/reference/android/graphics/Paint#FILTER_BITMAP_FLAG)
when drawing, ensuring the resized image is high-quality even when using
a Bitmap-backed Canvas.
Currently some vector drawables are loaded using the AppCompat library
and others are loaded using the framework.
This pull request uniformizes this to use AppCompat to load them all.
Other changes:
- Set all compound drawables using relative positioning, since all XML
layouts are also using relative positioning.
- Remove unnecessary layer list drawable used to center
`R.drawable.ic_play_indicator` icon and use
`ImageView.setForegroundGravity()` instead.
- Merge layers in toolbar icons `ic_arrow_back_with_background` and
`ic_more_with_background` into a single vector drawable. Note that the
AppCompat implementation of vector drawables is unable to load vector
drawables inside layer-list drawables, so this change also makes these
images compatible with older Android versions.
**Note**: technically, AppCompat will always delegate to the framework
to load vector drawables on API 24+ which is the current minSDK version
of the app. But at least this gives the option to lower the minSDK
version in the future.
This means a popup will appear if you have that option enabled in the
preferences which will have a popup similar to the unfollow dialog
asking you if you want to follow the user.
The Androidx SplashScreen library is added as a dependency to the
project but isn't properly enabled in the current code. This pull
request configures the splash screen properly.
- Remove `SplashScreenActivity` which is not needed and use
`MainActivity` as main entry point to the application. `MainActivity`
inherits from `BaseActivity` which already detects if no account is
configured and redirects to `LoginActivity` if needed, just like
`SplashScreenActivity`.
- Initialize the SplashScreen library in `MainActivity.onCreate()`.
- Instead of letting the SplashScreen library set the final theme from
the `postSplashScreenTheme` attribute in SplashTheme, let `BaseActivity`
set it according to the user settings.
- When no account is available in `MainActivity.onCreate()`, keep the
splash screen shown until `LoginActivity` appears.
- Disable the slide-in animation when launching `LoginActivity` when no
account is available because the detection happens in `onCreate()` and
an Activity that finishes itself in `onCreate()` will not be drawn, so
the slide-in animation will not be visible either and only
`LoginActivity` will appear.
- Upgrade `core-splashscreen` to 1.2.0-alpha01 which contains a fix for
corrupted app theme on API 31+.
`RequestListener.onResourceReady()` may also be called to provide the
placeholder image when the request is starting or when it is cleared.
Check if the current request is complete (its status set to COMPLETE) to
determine if the Glide resource is for a thumbnail/placeholder or the
final image, and resume the coroutine only for the final image (or in
case of error).
This logic is [borrowed from the Glide Flow
API](a7351b0ecf/integration/ktx/src/main/java/com/bumptech/glide/integration/ktx/Flows.kt (L378)).
The main benefit of upgrading to version 1.2.0 of `DrawerLayout` is ~~to
properly support **predictive back animations**: when initiating a back
gesture on API 33+, the DrawerLayout will animate automatically~~ to
handle back navigation automatically. The predictive back animation of
the menu however depends on `NavigationView` which is not used in the
project.
In addition to the upgrade, simplify DrawerLayout integration:
- Forward key events to the DrawerLayout so it can intercept them and
close itself when needed.
- Don't handle the DrawerLayout closing manually using the
`OnBackPressedCallback` anymore. This is not necessary since the back
event will now be intercepted by the DrawerLayout when needed before
reaching the `OnBackPressedDispatcher`.
- Remove legacy fix for DrawerLayout staying open after Activity
recreation.
Hilt is an annotation processor built on top of Dagger which allows to
remove all the Android dependency injection boilerplate code (currently
around 900 lines) by writing it for us.
Hilt can use KSP instead of Kapt so Kapt can be completely removed from
the project. Kapt is slow, deprecated and has a few compatibility
issues. Removing Kapt will improve build times since no Java stubs have
to be generated for Kotlin classes anymore (Note that KSP also processes
annotations in Java classes so it can completely replace Kapt).
- Remove all modules related to manual dependency injection
configuration.
- Rename `AppModule` to `StorageModule` since it now only contains
configuration to retrieve the DataBase and SharedPreferences.
- Annotate all entry points (Activities, Fragments, BroadcastReceivers
and Services) with `@AndroidEntryPoint`.
- Annotate all injected ViewModels with `@HiltViewModel` and replace the
custom ViewModel Factory with the default one (which integrates with the
one generated by Hilt).
- Add a public field to allow overriding the default
ViewModelProvider.Factory in `BaseActivity` in tests.
- Annotate tested Activities with `@OptionalInject` since Activity tests
currently rely on the Activities not being injected automatically.
- Annotate injected `Context` arguments with `@ApplicationContext`. Hilt
provides the `Context` binding automatically but requires to specify if
the Application or Activity Context is wanted.
- Add WorkManager Hilt integration so all Workers are injected by Hilt
automatically using `HiltWorkerFactory`.
- Lazily initialize WorkManager in `TuskyApplication`.
- Remove Kapt and Kapt workarounds.
- ~~Remove toolchain configuration for Java 21. Toolchains force the
Java bytecode to match the JDK version used to build the project, and
apparently Hilt doesn't run inside the toolchain so cannot process the
source code if the JDK version of the toolchain is higher than the JDK
used to run Gradle. [And configuring a toolchain for an older Java
version causes other
issues](https://jakewharton.com/gradle-toolchains-are-rarely-a-good-idea/).
**Removing toolchains configuration doesn't prevent the project from
being built using JDK 21** or more recent versions but allows to build
the project using older JDKs as well.~~
Added a fix to allow Hilt to properly use the JDK toolchain.
- ~~Set the Java and Kotlin bytecode target to Java 17. The standard
bytecode target for Android projects is usually Java 8 or 11 (any higher
version doesn't provide any benefit but may cause compatibility issues).
However, since the app currently uses a library built against Java 17
bytecode (`networkresult-calladapter`), it needs to target at least Java
17 bytecode as well.~~
- Update the Dagger 2 URL in the licenses screen. Hilt is part of Dagger
2 so the label wasn't changed.
Currently translated at 100.0% (641 of 641 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (639 of 639 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
Fixes: #3477
This tweaks two colors:
* for the dark theme a new slightly darker (timeline) background is
used.
* for the light theme a darker shade of blue is used as highlight color
(`colorPrimary` and `colorSecondary`)
Additional change:
* Use green and red more consistent: use existing colors for the diff
display; move the new light variants to colors.xml like all colors
This pull request adds `overrideActivityTransitionCompat()`, a
backwards-compatible version of `Activity.overrideActivityTransition()`
to be called in `Activity.onCreate()` in all Android versions.
This avoids duplicating the transition logic in different places of the
app to support older Android versions (in the activity launching code,
in `Activity.onCreate()` or in `Activity.finish()`).
- On API 34+, the implementation simply delegates to
`Activity.overrideActivityTransition()`.
- On API < 34, the implementation calls
`Activity.overridePendingTransition()` either immediately (opening
transition) or schedules it to be called later when the Activity is
finishing (closing transition).
- Rename `ActivityExensions.kt` to `ActivityExtensions.kt` (fix typo).
Steps to reproduce: When viewing an account list, very quickly rotate
the screen multiple times. I found this easier to do with an emulator,
just spam the rotation buttons.
```
java.lang.IllegalStateException: Fragment AccountListFragment{50bbc6c} (8a3e6922-e855-45a7-8a49-c9d16e21e438) did not return a View from onCreateView() or this was called before onCreateView().
at androidx.fragment.app.Fragment.requireView(Fragment.java:2063)
at com.keylesspalace.tusky.util.ViewLifecycleLazy.getValue(ViewBindingExtensions.kt:32)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.getBinding(AccountListFragment.kt:75)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.onFetchAccountsFailure(AccountListFragment.kt:390)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.access$onFetchAccountsFailure(AccountListFragment.kt:63)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment$fetchAccounts$2.invokeSuspend(AccountListFragment.kt:333)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:230)
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)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@260dcb1, Dispatchers.Main.immediate]
```
Glide sometimes calls the callback more than once (for the placeholder,
then for the actual image), but a coroutine can only resume once.
```
Exception java.lang.IllegalStateException:
at kotlinx.coroutines.CancellableContinuationImpl.alreadyResumedError (CancellableContinuationImpl.kt:555)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl (CancellableContinuationImpl.kt:520)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default (CancellableContinuationImpl.kt:493)
at kotlinx.coroutines.CancellableContinuationImpl.resumeWith (CancellableContinuationImpl.kt:364)
at com.keylesspalace.tusky.util.GlideExtensionsKt$submitAsync$2$target$1.onResourceReady (GlideExtensions.kt:39)
at com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:650)
at com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:596)
at com.bumptech.glide.request.SingleRequest.begin (SingleRequest.java:243)
at com.bumptech.glide.manager.RequestTracker.resumeRequests (RequestTracker.java:115)
at com.bumptech.glide.RequestManager.resumeRequests (RequestManager.java:339)
at com.bumptech.glide.RequestManager.onStart (RequestManager.java:364)
at com.bumptech.glide.manager.ApplicationLifecycle.addListener (ApplicationLifecycle.java:15)
at com.bumptech.glide.RequestManager$1.run (RequestManager.java:84)
at android.os.Handler.handleCallback (Handler.java:958)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:230)
at android.os.Looper.loop (Looper.java:319)
at android.app.ActivityThread.main (ActivityThread.java:8893)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:608)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1103)
```
While removing the placeholder fixes the problem here, we should
probably put some safeguards into `submitAsync` so that this can't
happen again elsewhere. Any ideas how to do that, @cbeyls?
This should save quite some memory, but most importantly it gets rid of
this crash:
```
java.lang.RuntimeException: Canvas: trying to draw too large(121969936bytes) 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 com.keylesspalace.tusky.util.EmojiSpan.draw(CustomEmojiHelper.kt:131)
...
```
Steps to reproduce: When viewing an account list, very quickly rotate
the screen multiple times. I found this easier to do with an emulator,
just spam the rotation buttons.
```
java.lang.IllegalStateException: Fragment AccountListFragment{50bbc6c} (8a3e6922-e855-45a7-8a49-c9d16e21e438) did not return a View from onCreateView() or this was called before onCreateView().
at androidx.fragment.app.Fragment.requireView(Fragment.java:2063)
at com.keylesspalace.tusky.util.ViewLifecycleLazy.getValue(ViewBindingExtensions.kt:32)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.getBinding(AccountListFragment.kt:75)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.onFetchAccountsFailure(AccountListFragment.kt:390)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment.access$onFetchAccountsFailure(AccountListFragment.kt:63)
at com.keylesspalace.tusky.components.accountlist.AccountListFragment$fetchAccounts$2.invokeSuspend(AccountListFragment.kt:333)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:230)
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)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@260dcb1, Dispatchers.Main.immediate]
```
Glide sometimes calls the callback more than once (for the placeholder,
then for the actual image), but a coroutine can only resume once.
```
Exception java.lang.IllegalStateException:
at kotlinx.coroutines.CancellableContinuationImpl.alreadyResumedError (CancellableContinuationImpl.kt:555)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl (CancellableContinuationImpl.kt:520)
at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default (CancellableContinuationImpl.kt:493)
at kotlinx.coroutines.CancellableContinuationImpl.resumeWith (CancellableContinuationImpl.kt:364)
at com.keylesspalace.tusky.util.GlideExtensionsKt$submitAsync$2$target$1.onResourceReady (GlideExtensions.kt:39)
at com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:650)
at com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:596)
at com.bumptech.glide.request.SingleRequest.begin (SingleRequest.java:243)
at com.bumptech.glide.manager.RequestTracker.resumeRequests (RequestTracker.java:115)
at com.bumptech.glide.RequestManager.resumeRequests (RequestManager.java:339)
at com.bumptech.glide.RequestManager.onStart (RequestManager.java:364)
at com.bumptech.glide.manager.ApplicationLifecycle.addListener (ApplicationLifecycle.java:15)
at com.bumptech.glide.RequestManager$1.run (RequestManager.java:84)
at android.os.Handler.handleCallback (Handler.java:958)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:230)
at android.os.Looper.loop (Looper.java:319)
at android.app.ActivityThread.main (ActivityThread.java:8893)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:608)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1103)
```
While removing the placeholder fixes the problem here, we should
probably put some safeguards into `submitAsync` so that this can't
happen again elsewhere. Any ideas how to do that, @cbeyls?
This should save quite some memory, but most importantly it gets rid of
this crash:
```
java.lang.RuntimeException: Canvas: trying to draw too large(121969936bytes) 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 com.keylesspalace.tusky.util.EmojiSpan.draw(CustomEmojiHelper.kt:131)
...
```
- Remove empty file `ExampleInstrumentedTest.java`.
- Replace deprecated `MigrationTestHelper` constructor call.
- Add reified inline extension methods for `Bundle` and `Intent` to
retrieve `Parcelable` and `Serializable` objects by calling the core
`BundleCompat` and `IntentCompat` methods, to allow shorter syntax and
removing the need to pass the class explicitly.
- Replace deprecated `drawable.setColorFilter()` with simpler
`drawable.setTint()` (uses blend mode `SRC_IN` by default, has the same
effect as `SRC_ATOP` when the source is a color).
- Rename shadowed variables (mostly caught exceptions).
- Remove unnecessary `.orEmpty()` on non-null fields.
- Replace `.size() == 0` with `.isEmpty()`.
- Prevent `NullPointerException` when `account.getDisplayName()` is
`null` in `StatusBaseViewHolder.setDisplayName()`.
- Declare `customEmojis` argument as non-null in
`StatusBaseViewHolder.setDisplayName()` because it calls
`CustomEmojiHelper.emojify()` which now requires it to be non-null.
- Prevent `NullPointerException` when no matching filter is found in
`StatusBaseViewHolder.setupFilterPlaceholder()`.
- Remove deprecated call to `setTargetFragment()` (target fragment is
not used anyway).
- Remove deprecated call to `isUserVisibleHint()` and test if the view
has been destroyed instead.
- Remove some unused imports.
- Remove unnecessary casts.
- Rename arguments to supertype names when a warning is shown.
- Prevent a potential memory leak by clearing the
`toolbarVisibilityDisposable` reference in `onDestroyView()`.
I made a mistake in https://github.com/tuskyapp/Tusky/pull/4389🙄
With `addDynamicShortcuts` the limit can still be exceeded,
`setDynamicShortcuts` is what we want.
Also, `setLongLived` says:
> Sets if a shortcut would be valid even if it has been
unpublished/invisible by the app (as a dynamic or pinned shortcut). If
it is long lived, it can be cached by various system services even after
it has been unpublished as a dynamic shortcut.
I don't think we want that so I removed it.
The app currently uses a custom callback system for requesting
permissions, located in `BaseActivity`.
This code doesn't work when the activity gets re-created before the
permission is granted: the callback will be lost with the Activity and
no action will be performed after the permission is granted.
To avoid these issues while still simplifying the code, Google
recommends to use the ActivityResultContract APIs to request
permissions, which allow to register persistent callbacks. This pull
request removes the legacy API and replaces the calls with
`registerForActivityResult(ActivityResultContracts.RequestPermission())`.
- `ActivityResultContracts.RequestPermission` will check if the
permission is already granted and call the callback synchronously when
possible. So this check doesn't need to be performed anymore.
- In `SearchStatusesFragment` and `SFragment`, the download action to
launch after granting the permission requires an argument (a list of
media URLs). This argument is temporarily stored in a Fragment field and
saved and restored as part of the instance state, so the action can
properly resume after an Activity re-creation.
