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.
- Read license resource using Okio inside a coroutine (instead of the
main thread) in `LicenseActivity`
- Use Okio and its buffer system to copy ContentProvider streams and
files to a temporary file in `MediaUploader.prepareMedia()`
- Properly close the input file after copying it to a temporary file in
`MediaUploader.prepareMedia()`
- Properly close sink in case of null body source during file copy in
`Uri.copyToFolder()` in `DraftHelper.kt`
- Add comment explaining the current value of `DEFAULT_CHUNK_SIZE` in
`UriRequestBody.kt` and indent the file properly
- Replace hardcoded `Charset` and `Int` byte size with the proper
constants, and align the `hashCode()` implementation with other
`BitmapTransformation` implementations in
`CompositeWithOpaqueBackground`
- Properly close `InputStream` in case of error during Bitmap size
decoding in `getImageSquarePixels()`
- return `Int` instead of `Long` in `getImageSquarePixels()`, since the
current code simply converts the `Int` result to a `Long` _after_
multiplication and not before (and `Int.MAX_VALUE` is already way above
the maximum number of pixels a decoded Bitmap could return)
- Simplify `getImageOrientation()`
- Add explicit dependency to the Okio library and upgrade it to its
latest version.
**! ! Warning**: Do not merge before testing every API call and database
read involving JSON !
**Gson** is obsolete and has been superseded by **Moshi**. But more
importantly, parsing Kotlin objects using Gson is _dangerous_ because
Gson uses Java serialization and is **not Kotlin-aware**. This has two
main consequences:
- Fields of non-null types may end up null at runtime. Parsing will
succeed, but the code may crash later with a `NullPointerException` when
trying to access a field member;
- Default values of constructor parameters are always ignored. When
absent, reference types will be null, booleans will be false and
integers will be zero.
On the other hand, Kotlin-aware parsers like **Moshi** or **Kotlin
Serialization** will validate at parsing time that all received fields
comply with the Kotlin contract and avoid errors at runtime, making apps
more stable and schema mismatches easier to detect (as long as logs are
accessible):
- Receiving a null value for a non-null type will generate a parsing
error;
- Optional types are declared explicitly by adding a default value. **A
missing value with no default value declaration will generate a parsing
error.**
Migrating the entity declarations from Gson to Moshi will make the code
more robust but is not an easy task because of the semantic differences.
With Gson, both nullable and optional fields are represented with a null
value. After converting to Moshi, some nullable entities can become
non-null with a default value (if they are optional and not nullable),
others can stay nullable with no default value (if they are mandatory
and nullable), and others can become **nullable with a default value of
null** (if they are optional _or_ nullable _or_ both). That third option
is the safest bet when it's not clear if a field is optional or not,
except for lists which can usually be declared as non-null with a
default value of an empty list (I have yet to see a nullable array type
in the Mastodon API).
Fields that are currently declared as non-null present another
challenge. In theory, they should remain as-is and everything will work
fine. In practice, **because Gson is not aware of nullable types at
all**, it's possible that some non-null fields currently hold a null
value in some cases but the app does not report any error because the
field is not accessed by Kotlin code in that scenario. After migrating
to Moshi however, parsing such a field will now fail early if a null
value or no value is received.
These fields will have to be identified by heavily testing the app and
looking for parsing errors (`JsonDataException`) and/or by going through
the Mastodon documentation. A default value needs to be added for
missing optional fields, and their type could optionally be changed to
nullable, depending on the case.
Gson is also currently used to serialize and deserialize objects to and
from the local database, which is also challenging because backwards
compatibility needs to be preserved. Fortunately, by default Gson omits
writing null fields, so a field of type `List<T>?` could be replaced
with a field of type `List<T>` with a default value of `emptyList()` and
reading back the old data should still work. However, nullable lists
that are written directly (not as a field of another object) will still
be serialized to JSON as `"null"` so the deserializing code must still
be handling null properly.
Finally, changing the database schema is out of scope for this pull
request, so database entities that also happen to be serialized with
Gson will keep their original types even if they could be made non-null
as an improvement.
In the end this is all for the best, because the app will be more
reliable and errors will be easier to detect by showing up earlier with
a clear error message. Not to mention the performance benefits of using
Moshi compared to Gson.
- Replace Gson reflection with Moshi Kotlin codegen to generate all
parsers at compile time.
- Replace custom `Rfc3339DateJsonAdapter` with the one provided by
moshi-adapters.
- Replace custom `JsonDeserializer` classes for Enum types with
`EnumJsonAdapter.create(T).withUnknownFallback()` from moshi-adapters to
support fallback values.
- Replace `GuardedBooleanAdapter` with the more generic `GuardedAdapter`
which works with any type. Any nullable field may now be annotated with
`@Guarded`.
- Remove Proguard rules related to Json entities. Each Json entity needs
to be annotated with `@JsonClass` with no exception, and adding this
annotation will ensure that R8/Proguard will handle the entities
properly.
- Replace some nullable Boolean fields with non-null Boolean fields with
a default value where possible.
- Replace some nullable list fields with non-null list fields with a
default value of `emptyList()` where possible.
- Update `TimelineDao` to perform all Json conversions internally using
`Converters` so no Gson or Moshi instance has to be passed to its
methods.
- ~~Create a custom `DraftAttachmentJsonAdapter` to serialize and
deserialize `DraftAttachment` which is a special entity that supports
more than one json name per field. A custom adapter is necessary because
there is not direct equivalent of `@SerializedName(alternate = [...])`
in Moshi.~~ Remove alternate names for some `DraftAttachment` fields
which were used as a workaround to deserialize local data in 2-years old
builds of Tusky.
- Update tests to make them work with Moshi.
- Simplify a few `equals()` implementations.
- Change a few functions to `val`s
- Turn `NetworkModule` into an `object` (since it contains no abstract
methods).
Please test the app thoroughly before merging. There may be some fields
currently declared as mandatory that are actually optional.
Using saner defaults for R8 while reducing the app size even further.
- Add Kotlin compiler options to skip adding assertions in release
builds
- Remove `optimizations`, `optimizationpasses` and `dontpreverify` rules
that are ignored by R8
- Only keep runtime annotations by default. If other attributes are
needed by a specific library, these will already be provided by the
library rules (for example Retrofit or coroutines)
- Remove the obsolete rule allowing a View to reflectively call any
arbitrary public Activity method accepting a View as argument. This has
always been a bad practice and is not used in this project anyway
- Remove the rules related to enums. R8 already optimizes enums properly
out-of-the-box and keeping these rules may prevent some of these
optimizations
- Add support for the `@Keep` annotation. Even if it's not currently
used in the code base, it can be handy in the future
- Add a missing rule to prevent generic signature of `NetworkResult`
class from being removed in `MastodonApi` so Retrofit works
- Allow obfuscation and shrinking of `kotlin.coroutines.Continuation`,
matching the rule defined in the next release of Retrofit
- Remove the rule forcing the removal of `String.format()`. This method
is actually used in the code (and in third-party libraries) for other
things than logging so forcing its removal can do more harm than good.
This pull request removes the remaining RxJava code and replaces it with
coroutine-equivalent implementations.
- Remove all duplicate methods in `MastodonApi`:
- Methods returning a RxJava `Single` have been replaced by suspending
methods returning a `NetworkResult` in order to be consistent with the
new code.
- _sync_/_async_ method variants are replaced with the _async_ version
only (suspending method), and `runBlocking{}` is used to make the async
variant synchronous.
- Create a custom coroutine-based implementation of `Single` for usage
in Java code where launching a coroutine is not possible. This class can
be deleted after remaining Java code has been converted to Kotlin.
- `NotificationsFragment.java` can subscribe to `EventHub` events by
calling the new lifecycle-aware `EventHub.subscribe()` method. This
allows using the `SharedFlow` as single source of truth for all events.
- Rx Autodispose is replaced by `lifecycleScope.launch()` which will
automatically cancel the coroutine when the Fragment view/Activity is
destroyed.
- Background work is launched in the existing injectable
`externalScope`, since using `GlobalScope` is discouraged.
`externalScope` has been changed to be a `@Singleton` and to use the
main dispatcher by default.
- Transform `ShareShortcutHelper` to an injectable utility class so it
can use the application `Context` and `externalScope` as provided
dependencies to launch a background coroutine.
- Implement a custom Glide extension method
`RequestBuilder.submitAsync()` to do the same thing as
`RequestBuilder.submit().get()` in a non-blocking way. This way there is
no need to switch to a background dispatcher and block a background
thread, and cancellation is supported out-of-the-box.
- An utility method `Fragment.updateRelativeTimePeriodically()` has been
added to remove duplicate logic in `TimelineFragment` and
`NotificationsFragment`, and the logic is now implemented using a simple
coroutine instead of `Observable.interval()`. Note that the periodic
update now happens between onStart and onStop instead of between
onResume and onPause, since the Fragment is not interactive but is still
visible in the started state.
- Rewrite `BottomSheetActivityTest` using coroutines tests.
- Remove all RxJava library dependencies.
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>
I had it happen multiple times recently that I was testing green Tusky
but Android Studio actually put blue Tusky on my device and I wasted a
lot of time until I found out 😣
This change should tell it that greenDebug is the preferred flavor for
developing.
Migrate to touchimageview from photoview, and adjust the touch logic to correctly handle single finger drag, two finger pinch/stretch, flings, taps, and swipes.
As before, the features are:
- Single tap, show/hide controls and media description
- Double tap, zoom in/out
- Single finger drag up/down, scale/translate image, dismiss if scrolled too far
- Single finger drag left/right
- When not zoomed, swipe to next image if multiple images present
- When zoomed, scroll to edge of image, then to next image if multiple images present
- Two finger pinch/zoom, zoom in/out on the image
Behaviour differences to previous code
1. Bug fix: The image can't get "stuck" when zoomed, and impossible to scroll
2. Bug fix: Pinching is not mis-interpreted as a fling, closing the image
3. Bug fix: The zoom state of images is not lost or misinterpreted when the user swipes through multiple images
4. Bug fix: Double-tap zooms all the way, instead of stopping
5. Tapping outside the image does not dismiss it, controls and description show/hide
Fixes https://github.com/tuskyapp/Tusky/issues/3562, https://github.com/tuskyapp/Tusky/issues/2297
* Enforce lint cleanliness when building
The volume of lintable issues is growing. To stem the tide:
1. Add `app/lint-baseline.xml`, which contains the current set of lint issues.
Any issue appearing here will not cause the build to fail.
2. Move lint configuration settings in to `lint.xml`.
3. Update the lint configuration so that any issue (i.e., any issue not
in lint-baseline.xml) causes a build failure.
4. Add the lint tasks as depedency when assembling an APK, to ensure the
lint checks are run.
* lint: Convert launcher images to webp
* Move lint.xml location
* Don't lint when assembling
* Update baseline
* Show the difference between edited statuses
Diff each status against the previous version, comparing the different
HTML as XML to produce a structured diff.
Mark new content with `<ins>`, deleted content with `<del>`.
Convert these to styled spans in `ViewEditsAdapter`.
* Update diffx to 1.1.1
Fixes issue with diffs splitting on accented characters
* Style edited strings with Android spans
Don't use HTML spans and try and format them, create real Android spans.
Do this with a custom tag handler that can add custom spans that set the
text paint appropriately.
* Lint
* Move colors in to theme_colors.xml
* Draw a roundrect for the backoround, add start/end padding
Make the background slightlysofter by drawing it as a roundrect.
Make the spans easier to understand by padding the start/end of each one with
the width of a " " character. This is visual only, the underlying text is not
changed.
* Catch exceptions when parsing XML
* Move sorting in to Dispatchers.Default coroutine
* Scope the loader type
* Remove alpha
* Unmodified output from "Convert Java to Kotlin" on NotificationsFragment.java
* Bare minimum changes to get this to compile and run
- Use `lateinit` for `eventhub`, `adapter`, `preferences`, and `scrolllistener`
- Removed override for accountManager, it can be used from the superclass
- Add `?.` where non-nullity could not (yet) be guaranteed
- Remove `?` from type lists where non-nullity is guaranteed
- Explicitly convert lists to mutable where necessary
- Delete unused function `findReplyPosition`
* Remove all unnecessary non-null (!!) assertions
The previous change meant some values are no longer nullable. Remove the
non-null assertions.
* Lint ListStatusAccessibilityDelegate call
- Remove redundant constructor
- Move block outside of `()`
* Use `let` when handling compose button visibility on scroll
* Replace a `requireNonNull` with `!!`
* Remove redundant return values
* Remove or rename unused lambda parameters
* Remove unnecessary type parameters
* Remove unnecessary null checks
* Replace cascading-if statement with `when`
* Simplify calculation of `topId`
* Use more appropriate list properties and methods
- Access the last value with `.last()`
- Access the last index with `.lastIndex`
- Replace logical-chain with `asRightOrNull` and `?.`
- `.isNotEmpty()`, not `!...isEmpty()`
* Inline unnecessary variable
* Use PrefKeys constants instead of bare strings
* Use `requireContext()` instead of `context!!`
* Replace deprecated `onActivityCreated()` with `onViewCreated()`
* Remove unnecessary variable setting
* Replace `size == 0` check with `isEmpty()`
* Format with ktlint, no functionality changes
* Convert NotifcationsAdapter to Kotlin
Does not compile, this is the unchanged output of the "Convert to Kotlin"
function
* Minimum changes to get NotificationsAdapter to compile
* Remove unnecessary visibility modifiers
* Use `isNotEmpty()`
* Remove unused lambda parameters
* Convert cascading-if to `when`
* Simplifiy assignment op
* Use explicit argument names with `copy()`
* Use `.firstOrNull()` instead of `if`
* Mark as lateinit to avoid unnecessary null checks
* Format with ktlint, whitespace changes only
* Bare minimum necessary to demonstrate paging in notifications
Create `NotificationsPagingSource`. This uses a new `notifications2()` API
call, which will exist until all the code has been adapted. Instead of
using placeholders,
Create `NotificationsPagingAdapter` (will replace `NotificationsAdapater`)
to consume this data.
Expose the paging source view a new `NotificationsViewModel` `flow`, and
submit new pages to the adapter as they are available in
`NotificationsFragment`.
Comment out any other code in `NotificationsFragment` that deals with
loading data from the network. This will be updated as necessary, either
here, or in the view model.
Lots of functionality is missing, including:
- Different views for different notification types
- Starting at the remembered notification position
- Interacting with notifications
- Adjusting the UI state to match the loading state
These will be added incrementally.
* Migrate StatusNotificationViewHolder impl. to NotificationsPagingAdapter
With this change `NotificationsPagingAdapter` shows notifications about a
status correctly.
- Introduce a `ViewHolder` abstract class that all Notification view holders
derive from. Modify the fallback view holder to use this.
- Implement `StatusNotificationViewHolder`. Much of the code is from the
existing implementation in the `NotificationAdapater`.
- The original code split the code that binds values to views between the
adapter's `bindViewHolder` method and the view holder's methods.
In this code, all of the binding code is in the view holder, in a `bind`
method. This is called by the adapter's `bindViewHolder` method. This keeps
all the binding logic in the view holder, where it belongs.
- The new `StatusNotificationViewHolder` uses view binding to access its views
instead of `findViewById`.
- Logically, information about whether to show sensitive media, or open
content warnings should be part of the `StatusDisplayOptions`. So add those
as fields, and populate them appropriately.
This affects code outside notification handling, which will be adjusted
later.
* Note some TODOs to complete before the PR is finished
* Extract StatusNotificationViewHolder to a new file
* Add TODO for NotificationViewData.Concrete
* Convert the adapter to take NotificationViewData.Concrete
* Add a view holder for regular status notifications
* Migrate Follow and FollowRequest notifications
* Migrate report notifications
* Convert onViewThread to use the adapter data
* Convert onViewMedia to use the adapter data
* Convert onMore to use the adapter data
* Convert onReply to use the adapter data
* Convert NotificationViewData to Kotlin
* Re-implement the reblog functionality
- Move reblogging in to the view model
- Update the UI via the adapter's `snapshot()` and `notifyItemChanged()`
methods
* Re-implement the favourite functionality
Same approach as reblog
* Re-implement the bookmark functionality
Same approach as reblog
* Add TODO re StatusActionListener interface
* Add TODO re event handling
* Re-implementing the voting functionality
* Re-implement viewing hidden content
- Hidden media
- Content behind a content warning
* Add a TODO re pinning
* Re-implement "Show more" / "Show less"
* Delete unused updateStatus() function
* Comment out the scroll listener for the moment
* Re-implement applying filters to notifications
Introduce `NotificationsRepository`, to provide access to the notifications
stream.
When changing the filters the flow is as follows:
- User clicks "Apply" in the fragment.
- Fragment calls `viewModel.accept()` with a `UiAction.ApplyFilter` (new
class).
- View model maintains a private flow of incoming UI actions. The new action
is emitted to that flow.
- In view model, `notificationFilter` waits for `.ApplyFilter` actions, and
ensures the filter is saved, then emits it.
- In view model, `pagingDataFlow` waits for new items from
`notificationsFilter` and fetches the notifications from the repository in
response. The repository provides `Notification`, so the model maps them to
`NotificationViewData.Concrete` for display by the adapter.
- In view model the UI state also waits for new items from
`notificationsFilter` and emits a new `UiState` every time the filter is
changed.
When opening the fragment for the first time:
- All of the above machinery, but `notificationFilter` also fetches the filter
from the active account and emits that first. This triggers the first fetch
and the first update of `uiState`.
Also:
- Add TODOs for functionality that is not implemented yet
- Delete a lot of dead code from NotificationsFragment
* Include important preference values in `uiState`
Listen to the flow of eventHub events, filtered to preference changes that
are relevant to the notification view.
When preferences change (or when the view model starts), fetch the current
values, and include them in `uiState`.
Remove preference handling from `NotificationsFragment`, and just use
the values from `uiState`.
Adjust how the `useAbsoluteTime` preference is handled. The previous code
loaded new content (via a diffutil) in to the adapter, which would trigger
a re-binding of the timestamp.
As the adapter content is immutable, the new code simply triggers a
re-binding of the views that are currently visible on screen.
* Update UI in response to different load states
Notifications can be loaded at the top and bottom of the timeline. Add a
new layout to show the progress of these loads, and any errors that can
occur.
Catch network errors in `NotificationsPagingSource` and convert to
`LoadState.Error`.
Add a header/footer to the notifications list to show the load state.
Collect the load state from the adapter, use this to drive the visibility
of different views.
* Save and restore the last read notification ID
Use this when fetching notifications, to centre the list around the
notification that was last read.
* Call notifyItemRangeChanged with the correct parameters
* Don't try and save list position if there are no items in the list
* Show/hide the "Nothing to see" view appropriately
* Update comments
* Handle the case where the notification key no longer exists
* Re-implement support for showMediaPreview and other settings
* Re-implement "hide FAB when scrolling" preference
* Delete dead code
* Delete Notifications Adapater and Placeholder types
* Remove NotificationViewData.Concrete subclass
Now there's no Placeholder, everything is a NotificationViewData.
* Improve how notification pages are loaded if the first notification is missing or filtered
* Re-implement clear notifications, show errors
* s/default/from/
* Add missing headers
* Don't process bookmarking via EventHub
- Initiating a bookmark is triggered by the fragment sending a
StatusUiAction.Bookmark
- View model receives this, makes API call, waits for response, emits either
a success or failure state
- Fragment collects success/failure states, updates the UI accordingly
* Don't process favourites via EventHub
* Don't process reblog via EventHub
* Don't process poll votes with EventHub
This removes EventHub from the fragment
* Respond to follow requests via the view model
* Docs and cleanup
* Typo and editing pass
* Minor edits for clarity
* Remove newline in diagram
* Reorder sequence diagram
* s/authorize/accept/
* s/pagingDataFlow/pagingData/
* Add brief KDoc
* Try and fetch a full first page of notifications
* Call the API method `notifications` again
* Log UI errors at the point of handling
* Remove unused variable
* Replace String.format() with interpolation
* Convert NotificationViewData to data class
* Rename copy() to make(), to avoid confusion with default copy() method
* Lint
* Update app/src/main/res/layout/simple_list_item_1.xml
* Update app/src/main/java/com/keylesspalace/tusky/components/notifications/NotificationsPagingAdapter.kt
* Update app/src/main/java/com/keylesspalace/tusky/components/notifications/NotificationsViewModel.kt
* Update app/src/main/java/com/keylesspalace/tusky/fragment/NotificationsFragment.kt
* Update app/src/main/java/com/keylesspalace/tusky/viewdata/NotificationViewData.kt
* Initial NotificationsViewModel tests
* Add missing import
* More tests, some cleanup
* Comments, re-order some code
* Set StateRestorationPolicy.PREVENT_WHEN_EMPTY
* Mark clearNotifications() as "suspend"
* Catch exceptions from clearNotifications and emit
* Update TODOs with explanations
* Ensure initial fetch uses a null ID
* Stop/start collecting pagingData based on the lifecycle
* Don't hide the list while refreshing
* Refresh notifications on mutes and blocks
* Update tests now clearNotifications is a suspend fun
* Add "Refresh" menu to NotificationsFragment
* Use account.name over account.displayName
* Update app/src/main/java/com/keylesspalace/tusky/fragment/NotificationsFragment.kt
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
* Mark layoutmanager as lateinit
* Mark layoutmanager as lateinit
* Refactor generating UI text
* Add Copyright header
* Correctly apply notification filters
* Show follow request header in notifications
* Wait for follow request actions to complete, so the reqeuest is sent
* Remove duplicate copyright header
* Revert copyright change in unmodified file
* Null check response body
* Move NotificationsFragment to component.notifications
* Use viewlifecycleowner.lifecyclescope
* Show notification filter as a dialog rather than a popup window
The popup window:
- Is inconsistent UI
- Requires a custom layout
- Didn't play nicely with viewbinding
* Refresh adapter on block/mute
* Scroll up slightly when new content is loaded
* Restore progressbar
* Lint
* Update app/src/main/res/layout/simple_list_item_1.xml
---------
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
Not all Robolectric tests interact with activities, so lazy loading the activity can speed them up.
I benchmarked the impact with gradle-profiler. Each test run performed 6 warmup runs, and then 10 benchmarked runs with and without this change.
Without this change (all values rounded to nearest second):
Mean: 151
Median: 149
P75: 157
StdDev: 10
With this change:
Mean: 127
Median: 125
P75: 130
StdDev: 7
So a ~ 18% reduction in median and P75 times,
Conny Duck
Konrad Pozniak
Christophe Beyls
Zongle Wang
charlag
Conny Duck
Levi Bard
Nik Clayton