Repository navigation
Discussion: merging with fork SadGare/OpenTagViewer #44
Description
So this is mainly directed at @SadGare, who I saw forked this repo and is either in the process of or successfully implemented a bunch of features requested in the issue list, as well as potentially fixed some of the issues related to the old version of FindMy.py that is a dependency of this project. I saw that he worked on enabling migration from the old version of the app to the new one, and I also saw him implement the AMap Chinese map provider to make this app actually useful to Chinese users.
Overall (without testing it myself) I am super impressed by the work including the amount of work that he's put into his fork, and I was wondering if he would be interested in merging his changes into the main repo here where they can have more visibility. I would be open to giving @SadGare commit access to the project too so he can merge his changes here in the future!
Another question was how far along and which problems from the issues list he ended up covering, as for example a big one for me is the fact that you need the janky VM export approach to get the tag files, which is what the people in the FindMy.py repo were working on trying to get to work without the VM and using the rustpush OpenBubbles code. I was thus wondering where we stood on that.
Otherwise I suppose the question might be whether the changes are stable and tested enough to release as a version for all users who have the old/latest version of the app from here. Or whether that's an effort that still would need to be undertaken.
I'll try to drop @SadGare an email regarding this, but I was curious if anybody is tracking this project and interested to chip in.
Activity
SadGare commentedon May 13, 2026
Hi, thanks for opening this issue and for the kind words!
Yes, I’m definitely interested in merging my changes back into the main repo. I worked on this fork mainly because OpenTagViewer solved a real pain point for me, and I wanted to keep using it. Since you seemed busy and some useful features had been pending for a while, I thought I might as well try to implement the things I needed myself.
The two main things I worked on are:
This was the biggest thing for me. Google Maps is not really usable in mainland China, so AMap support makes the app much more useful for Chinese users. This should be related to #16 and I also requested for this feature previsouly at #33 .
This is related to #30. My understanding is that the old FindMy.py dependency caused problems with tag tracking / location updates. In my fork, I updated the FindMy.py-related network part, and tag location updates now work on my side.
One thing I want to clarify: this does not solve the “janky VM export approach” problem. I did not remove the need for the initial export process.
The thing I handled is different: after updating the FindMy-related backend in the app, the backend expects a slightly different data format. But users should not need to export everything again from Mac just because of that. The app can handle the old-to-new format conversion internally.
So, roughly speaking:
I haven’t really followed the FindMy.py / rustpush / OpenBubbles work closely, so I don’t want to overclaim anything there. But I agree that removing that onboarding barrier would be very valuable, and I can look into it when I have time.
There are also some smaller changes, like Simplified/Traditional Chinese translations, startup language/map-provider selection, map-provider switching fixes, dark-mode fixes, large-font UI clipping fixes, and other small bug fixes.
About stability: I’ve been using my fork myself, and I haven’t noticed any obvious bugs in my own daily usage. But it has not been widely tested across many devices or user setups, so I wouldn’t say it is already ready for a general upstream release without review.
Also, I should be very clear about one thing: I really know almost nothing about Android / Java / Kotlin. I’m mainly a Python user. Most of this work was written with Codex, and I tested it by actually using the app myself. So the features may work, but I can’t guarantee the code style or architecture is good enough for upstream without your review.
I think the safest way would be to split the work into smaller PRs instead of merging the whole fork at once. Maybe something like:
I’m happy to prepare PRs when I have time. I may be slow because I’ve been quite busy, but I do want these changes to go back upstream if they are useful.
parawanderer commentedon Jun 18, 2026
Hi @SadGare, thanks for the exhaustive update on this! I've been busy with my own problems so I wasn't able to get back to this but I will try to get your set of changes merged since this app still seems to have community interest and I still have the context. I however also saw recently that the people on this thread have made some progress in accomplishing making the standalone exporter program not requiring MacOS usable at last: malmeloo/FindMy.py#173
So maybe this is a nice opportunity to get all this merged and integrated together in this app, since this would close the main most annoying issues from the initial versions of the app. Anyways for now I am still dealing with some of my own health issues etc but I will try to get around checking all of this together sometime since I still have an interest in making a smooth end-to-end experience if all the components exist now.
parawanderer commentedon Aug 12, 2026
Hi @SadGare , so more recently I found myself with some time to go through this and extract the changes back out to the main app and make fixes while testing it, which I just did in a big batch while having Claude Code generate tests and such for me. You can find the changes back in this PR #49 and further this release: https://github.com/parawanderer/OpenTagViewer/releases/tag/android-app-v1.0.5
From the point of view of main app functionality and compatibility with the newer FindMy.py library, I managed to verify that this is all without regressions, so I went ahead and merged it for the sake of getting your nice contribution out to the users of this app (among which myself!).
For your AMap changes, as I do not a mainland Chinese account, I am unable to create a permanent API key for this and add it to the app. Consequently I ended up making a separate screen in the settings where users can provide their own API key to enable the feature. If you have any more insight on how the app could support AMap out of the box for all users with no further configuration by the users, please do let me know as that would be much appreciated, and would reduce friction for those users
I was furthermore wondering if you would have the time to check out the release and report if the way your AMap related changes were integrated still works here: #52 (which should be less work than initially expected)
Add a map provider abstraction and an AMap implementation
Update FindMy backend to 0.9.x, stub unicorn, add locales and startup…