Caused by #1748.
Two different issues actually.
Firstly, the getUsername API call uses the authClient, which uses the
BangumiInterceptor to get the current OAuth data and attach the
Authorization header. However, on login, #1748 did not try to set the
new auth details until after attempting to call getUsername.
This would cause Mihon to think the user was not authenticated with
Bangumi and cancel the process.
This is fixed by having Mihon store the OAuth credentials in the
interceptor first before attempting to call getUsername.
The second issue is a simple trailing dollar sign in the API URL for
the getUsername method. This was removed.
Most if not all other trackers do this too. Technically this causes
some request duplication (since things like the BaseTracker's
setRemoteLastChapterRead fire anyway due to the tracker sheet being
open. But considering the reduced number of requests in other places,
I think this is still acceptable.
This change will allow #1736 to proceed, hopefully.
This comes with many benefits:
- Starting dates are now available and shown to users
- Lays groundwork to add private tracking for Bangumi, e.g. in #1736
- Mihon makes approximately 2-4 times fewer calls to Bangumi's API
- Simplified interceptor for the access token addition
- v0 does not allow access tokens in the query string
- There is actively maintained documentation for it
Also shrunk the DTOs for Bangumi by removing attributes we have no
use for either now or in the foreseeable future. Volume data remains
in case Mihon wants to ever support volumes. But attributes such as
user avatars, nicknames, data relating to Bangumi's tag & meta-tag
systems, etc. have been removed or just not added to the DTOs.
* Add missing @EncodeDefault annotation to MALOAuth
Similar to the situation with Bangumi, the missing annotation means
kotlinx.serialization would _provide_ the default value upon
instantiation but not serialise it to disk. This means the isExpired()
calculation would effectively rarely/never do its job correctly,
leading to Mihon sending expired tokens to MAL and causing problems
for everyone involved.
Overall, this change _could_ (should) lead to a drastic reduction in
MAL requests failing, leading to users having to relink their MAL
accounts.
Also switched createdAt to be in seconds instead of milliseconds as
all other trackers use seconds for timestamps (except for AniList,
which uses milliseconds but doesn't use a createdAt timestamp anyway).
* Add CHANGELOG.md entry
* Fix Bangumi tracking losing track of login state
kotlinx.serialization does NOT serialize default values (like
createdAt in BGMOAuth.kt), so every time the Bangumi tracker
deserialized the tracker OAuth, createdAt was set to the time of the
read, not the time of issuance.
Separately, BangumiInterceptor did correctly fetch new OAuth
credentials upon detected expiry of the stored credentials and saved
them, but did not use them for the current request (the new
credentials were used for all subsequent requests only). This led to
401 errors from Bangumi because the expired access_token was provided.
A subsequent request using the newly acquired access_token would end
up being successful.
* Add CHANGELOG.md entry
* Fix MAL manga cover nullability
If a manga doesn't have a cover, MAL doesn't provide the
`main_picture` element in the API response at all.
* Add CHANGELOG.md entry
In short:
- fetch & show actual summary
- fallback to "name" if "name_cn" is empty
- request larger responseGroup to get & display the summary & rating
- add type filter query param to make Bangumi filter, not us
Previously, we only displayed the "name" in the summary area and used
"name_cn" as the entry name. However, "name_cn" (Chinese name) can be
an empty string at times, resulting in an awkward looking search
result list where some, many, or even all the results have no title
displayed and only show the "name" (Japanese name) in the summary
area. This has been solved by using "name" as a fallback value should
"name_cn" be empty.
If a Chinese name is available, the original name is prepended to the
summary with the addition "作品原名：" (meaning "original series title").
By using the "responseGroup=large" query parameter, we can request
the required data we need to display the actual summary for an entry
and the entry's average rating.
The "name" is prepended to the summary contents, if any exist, so it
is still accessible for series identification if a "name_cn" exists
too and was used for the result title.
Adding the "type=1" filter query parameter means Bangumi will only
return entries of type 1 ("book") instead of all types and Mihon
needing to filter, resulting in potentially missed entry matches.
This time, the Kitsu API docs are silent on whether this field (or
any other field) can be null/undefined/etc, but it can happen and
caused an error during search and update. This change just ensures the
attribute is nullable and is set to an empty String when it is null.
The API docs and the responses type `ratingTwenty` as a "number" (Int
in Kotlin, it's divided by 2 for a .5 step scale 0-10). It's nullable
because an entry without a user rating returns `null` in that field.
* Migrate tracking APIs to DTOs
Changes the handling of tracker API responses to be parsed to DTOs
instead of doing so "manually" by use of `jsonPrimitive`s and/or
`Json.decodeFromString` invocations.
This greatly simplifies the API response handling.
Renamed constants to SCREAMING_SNAKE_CASE.
Largely tried to name the DTOs in a uniform pattern, with the
tracker's (short) name at the beginning of file and data class names
(ALOAuth instead of OAuth, etc).
With these changes, no area of the code base should be using
`jsonPrimitive` and/or `Json.decodeFromString` anymore.
* Fix wrong types in KitsuAlgoliaSearchItem
This API returns start and end dates as Long and the score as Double.
Kitsu's docs claim they're strings (and they are, when requesting
manga details from Kitsu directly) but the Algolia search results
return Longs and Double, respectively.
* Apply review changes
- Renamed `BangumiX` classes to `BGMX` classes.
- Renamed `toXStatus` and `toXScore` to `toApiStatus` and `toApiScore`
* Handle migration from detekt to spotless
Removed Suppressions added for detekt.
Specifically removed:
- `SwallowedException` where an exception ends as a default value
- `MagicNumber`
- `CyclomaticComplexMethod`
- `TooGenericExceptionThrown`
Also ran spotlessApply which changed SMAddMangaResponse
* Fix Kitsu failing to add series
The `included` attribute seems to only appear when the user already
has the entry in their Kitsu list.
Since both `data` and `included` are required for `firstToTrack`, a
guard clause has been added before all its calls.
* Fix empty Bangumi error when entry doesn't exist
Previously, the non-null assertion (!!) would cause a
NullPointerException and a Toast with
"Bangumi error: " (no message) when the user had removed their list
entry from Bangumi through other means like the website.
Now it will show "Bangumi error: Could not find manga".
This is analogous to the error shown by Kitsu under these
circumstances.
* Fix Shikimori ignoring missing remote entry
The user would see no indication that Shikimori could not properly
refresh the track from the remote. This change causes the error Toast
notification to pop up with the following message
"Shikimori error: Could not find manga".
This is analogous to Kitsu and Bangumi.
* Remove usage of let where not needed
These particular occurrences weren't needed because properties are
directly accessible to further act upon. This neatly simplifies these
clauses.
* Remove missed let
* Add query to get chapter count by manga and chapter number
* Add functions to get chapter count by manga and chapter number
* Only count read chapters
* Add interactor
* Savepoint
* Extract new chapter logic to separate function
* Update javadocs
* Add preference to toggle new functionality
* Add todo
* Add debug logcat
* Use string resource instead of hardcoding title
* Add temporary logcat for debugging
* Fix detekt issues
* Update javadocs
* Update download unread chapters preference
* Remove debug logcat calls
* Update javadocs
* Resolve issue where read chapters were still being downloaded during manual manga fetch
* Apply code review changes
* Apply code review changes
* Revert "Apply code review changes"
This reverts commit 1a2dce78acc66a7c529ce5b572bdaf94804b1a30.
* Revert "Apply code review changes"
This reverts commit ac2a77829313967ad39ce3cb0c0231083b9d640d.
* Group download chapter logic inside the interactor GetChaptersToDownload
* Update javadocs
* Apply code review
* Apply code review
* Apply code review
* Update CHANGELOG.md to include the new feature
* Run spotless
* Update domain/src/main/java/mihon/domain/chapter/interactor/FilterChaptersForDownload.kt
---------
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
The previous approach would always throw an Exception because
`SimpleDateFormat.format()` expects the input to be of type `Date` or
`Number`, not `String`.
* Backup/Restore Extension Repos
* Refactor
* Moving to Under App Settings
* Sort by URL, Check existing by SHA and Error Logging
Untested. Currently in a lecture and can't test if the changes really work.
* Changes to logic
* Don't ask me what's happening here
* Renaming Variables
* Fixing restoreAmount & changes to logic
Co-Authored-By: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
---------
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
* Fix unsupported mime type error when saving images
Avoid using platform mime type map to get extensions as it may not have
all mime types we support.
* Fix jxl images downloading/reading
* Refactor archive support with libarchive
* Revert string resource changs
* Only mark archive formats as supported
Comic book archives should not be compressed.
* Fixup
* Remove epub from archive format list
* Move to mihon package
* Format
* Cleanup
AntsyLich