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.
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).
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.
This refactors the NotificationsFragment and related classes to Kotlin &
paging.
While trying to preserve as much of the original behavior as possible,
this adds the following improvements as well:
- The "show notifications filter" preference was added again
- The "load more" button now has a background ripple effect when clicked
- The "legal" report category of Mastodon 4.2 is now supported in report
notifications
- Unknown notifications now display "unknown notification type" instead
of an empty line
Other code quality improvements:
- All views from xml layouts are now referenced via ViewBindings
- the classes responsible for showing system notifications were moved to
a new package `systemnotifications` while the classes from this
refactoring are in `notifications`
- the id of the local Tusky account is now called `tuskyAccountId` in
all places I could find
closes https://github.com/tuskyapp/Tusky/issues/3429
---------
Co-authored-by: Zongle Wang <wangzongler@gmail.com>
builds upon work from #4082
Additionally fixes some deprecations and adds support for [predictive
back](https://developer.android.com/guide/navigation/custom-back/predictive-back-gesture).
I also refactored how the activity transitions work because they are
closely related to predictive back. The awkward
`finishWithoutSlideOutAnimation` is gone, activities that have been
started with slide in will now automatically close with slide out.
To test predictive back you need an emulator or device with Sdk 34
(Android 14) and then enable it in the developer settings.
Predictive back requires the back action to be determined before it
actually occurs so the system can play the right predictive animation,
which made a few reorganisations necessary.
closes#4082closes#4005
unlocks a bunch of dependency upgrades that require sdk 34
---------
Co-authored-by: Goooler <wangzongler@gmail.com>
Set the "System Design" as the default theme.
This ensures that the app's initial behaviour respect's the user's system-wide theme choice, while still allowing the user to adjust it later.
This is only done for new installs of Tusky. If the user is upgrading from a previous release and they did not have an explicit theme set then the dark theme is used, and the UX does not change.
Before, intent creation was scattered across multiple sites, with account switching logic in both `ComposeActivity` and `MainActivity`.
Now, intents are only created in `MainActivity` Companion, and account switching only occurs in `MainActivity`
Fixes#3695
Font scaling is applied in addition to any scaling set in Android system preferences. So if the user set the Android font size to largest (a 1.3x increase) and then sets the preference to 120%, the total change is 1.56x.
Create SliderPreference to adjust the preference.
- Use Slider, which supports float values and step sizes > 1
- Display the selected value in the preference's summary
- Provide buttons to increment / decrement the value
Restart the activity if the preference changes so that the user sees the impact of the change immediately. Fix a bug in PreferencesActivity where the "EXTRA_RESTART_ON_BACK" intent was never processed. Fix this to ensure that other activities are restarted so the new font scale takes effect.
Implement the scaling in BaseActivity by overriding onAttachBaseContext, and providing a wrapped context with the font scaling applied.
Fixes https://github.com/tuskyapp/Tusky/issues/2982, https://github.com/tuskyapp/Tusky/issues/2461
Don't use `accountManager.activeAccount` throughout the code.
Instead, get the active account once, and use that over the life of the viewmodel.
As shown in https://github.com/tuskyapp/Tusky/issues/3689#issuecomment-1567219338 the active account can change before the view model is destroyed, and if that happens account information for the account will be written to the wrong account.
* Kotlin 1.8.10
https://github.com/JetBrains/kotlin/releases/tag/v1.8.10
* Migrate onActivityCreated to onViewCreated
* More final modifiers
* Java Cleanups
* Kotlin cleanups
* More final modifiers
* Const value TOOLBAR_HIDE_DELAY_MS
* Revert
* Fix off-by-one error in HttpHeaderLink
Link headers with multiple URLs with multiple parameters were being parsed
incorrectly.
Detected by adding unit tests ahead of converting to Kotlin.
* Convert util/HttpHeaderLink from Java to Kotlin
* Convert util/ThemeUtils from Java to Kotlin
* Convert util/TimestampUtils from Java to Kotlin
* Add tests for PairedList
* Convert util/PairedList from Java to Kotlin
* Implement feedback from PR
* Relicense as GPL
These aren't necessary for the app, and are overwritten with the actual style
in `BaseActivity.onCreate()`.
But if they're missing the Android Studio layout preview renderer crashes.
* update to Api 33, fix some deprecations
* fix deprecated serializable/parcelable methods
* ask for notification permission
* fix code formatting
* add back comment in PreferencesActivity
* Improve login process with newer APIs
* Implement login with WebView instead of browser tab or external browser
Oauth process requires us to open login prompt for correct instance and
we need to receive the result back. Usually it is done with redirect
parameter.
Previously we've been using BrowserTabs API and have been falling back
to just opening browser. This mostly worked but is very clumsy:
- It relies on few system mechanisms for opening URLs in both
directions
- Browsers do weird things and tend to break quite a bit
- There's a good chance that the app can die in the process and we need
to recover our state.
So instead we are now using WebView. It has disadvantages (users have
to trust us to show correct page, logins are not shared w/ browser) but
it should be more reliable.
* Changes to login after review
* Move login classes to their own package
* Fix linting issues
* Theme refactoring
* disable the automatic tinting of surfaces with elevation in dark mode
* make the media warning visible again with the dark theme
* fix nav bar on api 27+
* use correct color for all media warnings
* upgrade api level to Android 10, resolve compile errors
* use androidx.preference.PreferenceManager instead of deprecated platform class
* add hyphenation to important TextViews
* setBottomSheetCallback -> addBottomSheetCallback
* implement new sharing api
* improve TuskyTileService so it shows account picker when multiple accounts are present
* delete unused AccountChooserService
* fix test
* improve ShareShortcutHelper
* remove debug log statement
* improve image loading fallback behavior in ShareShortcutHelper
* improve behavior on foldable devices
* Add theme system
A theme which follows system design.
See: https://www.xda-developers.com/samsung-galaxy-s9-update-night-mode-schedule/
* update
to be in line with https://github.com/tuskyapp/Tusky/pull/1060/files
* Update ThemeUtils.java
* update
* Cleanup
* Update Deps
* Cleanup
* Update PreferencesActivity.kt
* Workaround to make MODE_NIGHT_FOLLOW_SYSTEM work
* Update ThemeUtils.java
* Use ThemeUtils.THEME_SYSTEM
* Update SplashActivity.kt
* Update strings.xml
* Update Deps
* Update build.gradle
* Update build.gradle
* fix tests
* upgrade to AndroidX, upgrade libraries
* move to MaterialComponents theme
* make sure the compose button looks good everywhere
* fix tollbar title/button alignment on tablet
* move to new material color theming, consolidate colors and themes
* fix build, fix imports
* set error on TextInputLayout instead of EditText
* fix imports, TootButton when
* improve snackbar style
* fix task description color
* Migrate ImagePagerAdapter to kotlin
* Migrate ViewMediaFragment to kotlin
* Make images and videos share the same activity/pager
* Show descriptions above videos
* Cleanup
* Address code review feedback
* Migrate media fragments to constraint layout
* Add black theme
On amoled screens a completely black theme helps save battery,
besides looking awesome!
* Fix first set of merge request issues except the dialog.
* Black theme inherits from dark and only the different values
are declared
* Make nav bar translucent (for some reason content does not
go behind it in main activity. Need to investigate)
* Remove nav bar line
* Fix toolbar color
* Fix dialog issue with black theme.
Revert translucent navigation.
* Translations updated, as well as possible from online sources.
* Make login screen respect black theme
