Currently, media types like "one_shot" will turn into "One_shot" in
the search display due to Mihon capitalising the `publishing_type`
attribute of `Track` for display.
It is common for other tracker implementations to replace the
underscore with a space which results in "One shot".
This makes Hikka more consistent with other trackers.
I added the nullability check since the docs do say `string | null`
but that's neither here nor there.
* Fix Hikka search failing due to unclosed response
This closes#3547.
I have also included a precautionary refactor of the `getRead` method
in HikkaApi.kt, which by the looks of it _could_ leak an unclosed
response as well.
The try/catch with awaitSuccess pattern has been used in this same way
in the Bangumi and MangaBaka implementations as well. The benefit here
is that `awaitSuccess()` closes the response on error before throwing
an `HttpException`.
* Show toast on remote-removed list entries
* Add support for MangaBaka
Note: missing a client ID which should be added by the project owner.
* Fix typo causing token refresh to fail
The field is called `refresh_token` not `refreshToken`, so all
token refreshes would fail with a 401.
* Use user-preferred score type
Currently, this only set once on login. When selecting a different
score type on MangaBaka, users (currently) will have to log out and
log in again in order for Mihon to refetch the score setting.
This appears to be what Mihon's AniList implementation does as well,
so I followed that.
* Fix score preference
Didn't get caught during the rebase.
* Fix finish_date
* Fix dates appearing offset
Timezone shenanigans meant Mihon was sending an ISO 8601 string for
the UTC timezone which lead to issues in non-UTC timezones.
For example:
1. User in UTC+1 selects 2026-03-22
2. Date picker returns 2026-03-22T00:00:00+01:00
3. MangaBakaApi converts that to an instant, converting it to UTC:
2026-03-21T23:00:00Z
4. MangaBaka receives that and sets all time components to 0
5. Mihon (when opening the track sheet next) receives:
2026-03-21T00:00:00Z
6. Mihon renders that as 2026-03-21
I figured out that MangaBaka accepts date-only strings as well, so we
just send those now.
* Remove fetching of total_chapters from MangaBaka
Currently, this information is not what Mihon needs for automatic
marking as COMPLETED since MangaBaka considers this an ongoing tally
of volume-published chapters rather than the final chapter number of a
title.
If anyone other than me used this code: Probably will have to unlink
& relink MB entries to get rid of the total_chapters data, not sure.
MangaBaka is currently considering a request from me to potentially
change this, but currently it's not what we need.
* Fix start date being reset on each read chapter
Admittedly a silly oversight. The other date-supporting trackers (AL,
MAL, Kitsu) use this check as opposed to `>= 0.0`.
* Add id: prefix search for MangaBaka
* Use new /v1/my/profile endpoint
Kindly added by the developers after my request <3.
* Change tracker ID to 11
* Remove unused import
* Identify Mihon in UA on all requests
* Use new `published.start_date` field for search
* Change Mihon's User Agent string for MangaBaka
- use MR.strings.app_name to avoid manual work for forks
- include app ID & commit sha for further distinction
* Add Changelog entry
* Add Mihon client ID
* Add OAuth state query param
This is?/will be? required by MangaBaka's auth provider and caused
linking issues for anyone who tried to link with MB in the past two
weeks or so.
* Update MangaBaka API URL
Changed as per MB announcement from 2026-05-27
* Use `titles` instead of old `title`
* Make title selection a method on MangaBakaItem
* Include ID in fallback title for easier reporting
Makes it a lot more intuitive for users.
Also reworded the message to more clearly direct users to the
Mangabaka Discord server instead of sounding like an instruction to
contact some "mangabaka" user in the Mihon Discord.
* `titles` is nullable
At least I noticed this before it was merged...
* Fix MangaBaka brand name
Co-authored-by: BrutuZ <7104931+BrutuZ@users.noreply.github.com>
* Remove Hikka comment
* Put MangaBaka at the top of the tracker list
AntsyLich decreed it to be like this.
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
* Add display name support from #3533
* Fix changelog
* Rename MB icon to brand_mangabaka.webp
---------
Co-authored-by: BrutuZ <7104931+BrutuZ@users.noreply.github.com>
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
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.
The code as-is accepts _any_ non-.tmp file as a match for the given
page file.
Changing the condition to "not .tmp" AND (either page prefix pattern)
results in the correct behaviour and chapters download again.
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>
AntsyLich