Feature: Track entries privately if supported by the tracker#1736
Feature: Track entries privately if supported by the tracker#1736AntsyLich merged 31 commits intomihonapp:mainfrom NarwhalHorns:main
Conversation
|
I'm currently trying to find prior art on properly keeping track of private/not private with AL.
Edit 3: I'll clone this and see if I can figure out why it's not handling properly |
|
Good luck, I'll keep digging too |
…LManga.kt Co-authored-by: MajorTanya <39014446+MajorTanya@users.noreply.github.com>
|
The Row should look pretty much identical but now it's the normal Row scope used in other places. FlowRow, according to its docs, would also start overflowing if the content didn't fit and make another row (not desirable here Haven't taken a super detailed look at everything but considering it worked perfectly fine once we found that sneaky little thing, it seems to be good work. Specifically, I checked an entry that I had already added as private through the AL website and then connected that to Mihon, which got kept correctly now. (Mihon show "Private" and AL still has the checkbox ticked). Others may have other suggestions but the feature itself appears to be working. Nice job! 👍 |
|
I don't quite like the UI. Are you able to provide any alternative designs? |
Mmm, I wasn't really sure what to go with and just winged what came to me first. what aspects of it don't you like or any suggestions? |
|
In the tracker sheet the private toggle has more visual space given it's likely a one time toggle. And there being 2 type of track button in search |
|
yeah, on the 2 buttons I'm not sure what would be good. Like we could have the track button as is but have a private toggle checkbox or something on there somewhere, but it's just adding more steps. whereas 2 buttons keep both to a one step interaction. on the setting toggle, not sure what you mean. I could move it to the bottom of the screen? or perhaps put it in advanced settings and just stick it in a tracking section? |
I guess it can also be moved to the overflow/kebab menu thing right? And show like the incognito icon as a badge on the tracker logo or next to the name |
|
ohhhh i see what you mean now right. yeah good idea |
I've checked the other non-enhanced trackers:
Has support:
Whether these supporting trackers have a (good) way to do this via API, I have no clue. I just checked whether they have any sort of title-level privacy.
|
|
Checking Kitsu Docs, the change for it could be extremely simple, just adding the In KitsuApi.kt, in updateLibManga and addLibManga, you should be able to just add the private attribute to the JSON object being built. |
|
And Bangumi is looking similarly simple. But their docs are not only incomplete and in Chinese, they also contradict themselves and are out of date in places, so no links there. Aside from DTO changes, just adding the Edit: Wait no, BGM is not working with us here, I'll see how to actually do it. |
|
if we can think of way to make the search private as unintrusive as this we probably don't need the full setting toggle tbh but i feel like that will be a harder task |
…d private icon to title
It's done using the same add/update methods currently used for adding/updating a library entry. Should just be one copy of |
I think that should do it, i'm not 100% tho. Been a week since my brain ejected the finer details of this. Can you give it a quick test if you have bangumi? |
|
Okay, so it works fine for newly added entries, and switching between public/private in linked entries also works. What doesn't work right now is tracking something as private if it's already in the user's list as a public entry. (i.e. I have EntryA in my list as public already but when I search it in Mihon, I select private tracking. This is not reflected on Bangumi's website until I switch to public tracking, then back to private tracking.) That's because we don't update Bangumi at all if we find remote data for a track: Not sure what the best approach would be here. When I removed the update call here, it made sense to me but apparently it wasn't that smart. Edit: Filed #1771 which "fixes" this situation. Already tried it out by adding that patch to your PR locally and yeah, it works properly now, as far as I can tell. 👍 These issues are all on me, apologies. |
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 mihonapp#1736 to proceed, hopefully.
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 mihonapp#1736 to proceed, hopefully.
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.
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
|
Can you also add kitsu support? |
no idea, can look into it but i only use anilist so can't test it and would be going in blind wtf are these API docs o.O would probably be best to leave kitsu to someone else that knows it better tbh. Should be simple once this framework is in tho |
|
Kitsu's docs are probably the best ones we have 😅 but I've heard the call, I'll make a separate one for Kitsu. |
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 mihonapp/mihon#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. Co-authored-by: cuong-tran <cuongtran.tm@gmail.com> (cherry picked from commit a96fbba)
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 mihonapp/mihon#1736 to proceed, hopefully. (cherry picked from commit 277d8ba)
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 mihonapp/mihon#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. Co-authored-by: cuong-tran <cuongtran.tm@gmail.com> (cherry picked from commit a96fbba)
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 mihonapp/mihon#1736 to proceed, hopefully. (cherry picked from commit 277d8ba)
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 mihonapp/mihon#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. Co-authored-by: cuong-tran <cuongtran.tm@gmail.com> (cherry picked from commit a96fbba)
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 mihonapp/mihon#1736 to proceed, hopefully. (cherry picked from commit 277d8ba)




Features in #1735
This will include only the tracker abstraction and AniList implementation
supportsPrivateTrackingto Trackers