* Add Apollo for GraphQL interactions
* Migrate AniList to use Apollo
* Migrate Shikimori to use Apollo
Not all Shikimori requests can be served by their GraphQL API (notably
they do not offer any mutations), so those remain as-is.
* Migrate Suwayomi to use Apollo
Includes leveraging some slightly newer Suwayomi features,
specifically the Double/Float filter fixes first pre-released in
2.1.1985 on 2025-10-26 and first fully released in 2.1.2100 on
2026-05-08.
Considering the tachiyomix 1.6 extension lib changes were added in
Suwayomi 2.3.2223 on 2026-06-30, I think it is fair to depend on such
sorta-recent behaviour.
* Fix temp migration names and leftovers
* Create ApolloResponse.dataOrElse extension
Because Apollo doesn't throw exceptions and instead just provides them
as response attributes, the current ApolloResponse.awaitSuccess() is
useless and will be removed shortly.
This new extension function should wrap the basic handling of an
ApolloResponse object neatly.
Co-authored-by: Mitchell Syer <6090655+Syer10@users.noreply.github.com>
* Use dataOrElse in AnilistApi.kt
* Use dataOrElse in ShikimoriApi.kt
* Use dataOrElse in SuwayomiApi.kt
* Delete obsolete ApolloCall.awaitSuccess
* Migrate Kitsu to use Apollo
Kitsu has some unfortunate edges in its GraphQL API (such as returning
nonstandard bodies which don't play well with Apollo) but this should
be an equivalent implementation.
* Extract a MangaFragment for AniList
This simplifies the queries and the converters (which can now delegate
to the MangaFragment.toTrackSearch() method internally and adjust the
track as needed).
Also move the toALUser converter to AnilistUtils.kt to keep all
converters together.
Added a scalar-mapper for AL's CountryCode type.
* Minor consistency cleanup of the queries
* Store list entry ID not title ID for Shikimori
* Extract common MangaFragment for Shikimori
Also map the ISO8601Date to a Kotlin String in the service config.
* Map Kitsu's ISO8601DateTime to kotlin.time.Instant
Utilises Apollo's own adapter-core library which provides the mapper.
Requires opting in to ExperimentalTime until the library resolves the
outdated annotation.
Co-authored-by: Mitchell Syer <6090655+Syer10@users.noreply.github.com>
* Replace Kitsu TODO comment
So much for STOPSHIP preventing me shipping this...
* Bump Apollo version to 5.1.0
* Bump apollo-adapters-core to 0.8.0
Freshly released just earlier.
This resolves having to opt in to ExperimentalTime.
* Make new utils internal to align with #3908
* Fix leftover issues from merged #3828
This PR restructured the AniList and Kitsu user objects.
* Bump apollo to 5.2.0
* Remove unused attributes from queries
* Allow custom exception handler in dataOrElse
Enables callers to manually handle specific non-200 responses.
Callers MUST close the `ApolloHttpException.body` attached to the
passed exception to avoid resource and socket leaks.
Defaults to current behaviour of (re)throwing the status code with our
HttpException.
Utilized in KitsuApi.kt to specially handle Kitsu sending a 500 error
response when deleting library IDs not actually in a user's library
and falling back to the "throw as HttpException" if it's any other
error response.
* Rethrow networking/IO exceptions
This helps to avoid masking networking problems as "This isn't in your
list" problems.
Currently, the app shows "Failed to connect to ..." when the remote
server is unreachable (e.g. downtime, DNS block, etc) because that's
the message provided by the ConnectException thrown by Android's
network stack.
This change restores that behaviour, approximately.
Not the most elegant solution but it _should_ avoid false-positive
toasts.
---------
Co-authored-by: Mitchell Syer <6090655+Syer10@users.noreply.github.com>
app no longer touches the database directly. Backup restore's queries move into a new RestoreRepository in :data, which restores a batch of entries all or nothing, stopping between entries if cancelled, as before. The remaining direct calls (excluded scanlators, clear database, backup creation, store and category restore) go through their repositories, and the database bindings move from AppBindings into :data.
* Continuous background color
* Use ImageDecoder instead of Kim
* Only get tag when in dual mode
* Update libs.versions.toml
* Make progress circle smaller and animate progress
* Fix long strip showing the menu at ends
- Spoof `Sec-CH-UA` client hints to match the user agent
- Fix `X-Requested-With` spoofing leaking to unrelated callers
- Update default user agent to Chrome 149
* Replace java.time APIs with kotlin(x).(date)time
kotlinx-datetime explicitly says in its README that it does not cover
i18n, so we have to stick with using their toJavaX converters wherever
we localise dates and times.
Yes, some of these replacements are... questionable. But I wanted to
try and maximise the replacement for now.
* Bump kotlinx-datetime to 0.8.0
* More kotlin.time/kotlinx-datetime replacements
* Remove redundant init block & make attributes val
* Replace new use of java.time.Instant
* Replace deprecated rememberPlainTooltipPositionProvider
* Remove superfluous when branch
This when is marked as exhaustive.
* Replace deprecated LibrariesContainer call
AboutLibraries now wants us to produce the libraries ourselves.
* Replace deprecated ClipboardManager with Clipboard
Clipboard uses suspend functions, hence the coroutine scope addition.
* Use multi-dollar strs to simplify GraphQL queries
These have been available since Kotlin 2.1.
* Remove various redundant casts & conversions
- WebViewScreenContent: loadingState is in the LoadingState.Loading
branch, no need to cast at all
- Bangumi: username is not modified, make val
- Kavita: token is already a String
- PagerViewerAdapter: insertPageLastPage is already null-checked
- PagerViewerAdapter: use reified filterIsInstance
- ReaderViewModel: chapter IDs are already Longs
- CloudflareInterceptor: webview is smart-cast to non-null here
* Replace deprecated MenuAnchorType
Literally just a typealias for ExposedDropdownMenuAnchorType anyway.
* OptimizeNonSkippingGroups is enabled by default
* Suppress shadowing warning
This is explicitly intentional according to the KDocs.
* Migrate Context Receivers to Context Parameters
Requires changing the compiler arg, but that is part of the migration:
https://blog.jetbrains.com/kotlin/2025/04/update-on-context-parameters
Apparently, the only visible change is that names are required now.
"_" can be used for anonymous context parameters.
* Fix expression bodies with explicit return
Naming conflict resolved by aliasing.
From 2.4/2.5 onward, these will only be allowed with explicit return
types, or have to be turned into a block body. I opted for the latter
since the function is reasonably dense already.
see: https://youtrack.jetbrains.com/issue/KTLC-288
* Suppress deprecation of non-AutoMirrored icons
We use these arrows for navigation in the Upcoming screen.
I strongly doubt the AutoMirrored versions would make sense for our
use-case.
* Explicitly opt-in to new annotation default rules
affects the following annotated value-parameters:
- Preference.SliderPreference.steps (`@IntRange`)
- ReaderViewModel.State.brightnessOverlayValue (`@IntRange`)
- ReadingMode.iconRes (`@DrawableRes`)
- MigrationListScreenModel.Dialog.Progress.progress (`@FloatRange`)
see: https://youtrack.jetbrains.com/issue/KT-73255
see: https://github.com/Kotlin/KEEP/blob/change-defaulting-rule/proposals/annotation-target-in-properties.md
Warning message was the following:
This annotation is currently applied to the value parameter only, but in the future it will also be applied to field.
- To opt in to applying to both value parameter and field, add '-Xannotation-default-target=param-property' to your compiler arguments.
- To keep applying to the value parameter only, use the '@param:' annotation target.
w