Currently, every title will be added as READING, even if no chapter
has been read.
For consistency with every other tracker, I added the hasReadChapters
check as seen in other tracker implementations.
User list mutation aren't available via GraphQL, so that will still be
done with the v2 API.
Shikimori API docs say to prefer the GraphQL API when possible:
https://shikimori.io/api/doc
Allows adding some additional data in the search results, namely:
- Authors & Artists
- Description
As a nice bonus, this reduces the number of requests to Shikimori
because the findLibManga method no longer needs to do 2 calls to fetch
both list and title data.
There is a redirect from the .one domain to the .io domain but it uses
code 301 for redirecting on the token POST request, meaning the
followup request tries to use GET which returns a 404.
* perf(backup): batch database operations during restore
Reduce overhead by chunking manga and repo restoration into
transactions of 100 entries. Categories now restored in a single
transaction. Optimized DatabaseHandler to reuse existing transaction
contexts instead of creating redundant nested ones.
Changed TransactionElement to internal to allow AndroidDatabaseHandler
to check transaction state from the same package.
* fix(backup): make restore progress and errors thread-safe
Use AtomicInteger for progress and synchronizedList for errors to
prevent race conditions during concurrent restoration coroutines.
* perf(backup): update progress notification only once per chunk
Reduce UI/IPC overhead by moving notification updates out of the inner
loop, triggering them only after each 100-item transaction chunk.
Reduced on my emulator from 46 seconds to 27
* fix: remove invalid awaitAsOne() call on insert() return type
categoriesQueries.insert() returns Long (the inserted row ID), not an
ExecutableQuery<T>, so awaitAsOne() is not applicable.
* fix(feedback): Use `CopyOnWriteArrayList` and kotlin `AtomicInt`, add a changelog entry
Note that using kotlin `AtomicInt` instead of java `AtomicInteger` requires opting into an experimental API.
---------
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
* fix(telemetry): prevent Google Play Services spam notifications
Check for Google Play Services availability before initializing Firebase
to prevent system notifications when GPS is disabled or uninstalled.
- Add GPS availability check using GoogleApiAvailability
- Wrap Firebase initialization in try-catch for additional safety
- Skip Firebase initialization gracefully when GPS unavailable
- Add proper logging for debugging purposes
- Add core.common dependency to telemetry module for logcat support
Fixes#3135
* docs: add changelog entry for Google Play Services notification fix
---------
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
MAL has a concept of "titles waiting for approval". These titles
cannot be added to user lists, but they do show up on the website and
crucially, in search results.
However, trying to add such an "unapproved" title will return a 400
error response with the error "invalid_content".
Previously, the awaitSuccess() call would mean the generic "HTTP 400"
toast would be shown. Now, a dedicated informative error message is
shown instead.
MajorTanya