Discussion: merging with fork SadGare/OpenTagViewer

[parawanderer]

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.

[SadGare]

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:

1. AMap support for mainland China

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 .

2. Updating the FindMy.py-related network logic

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:

• tag tracking / location update issue: should be fixed in my fork
• old app data migration: handled inside the app, no re-export needed
• removing the initial VM/Mac export requirement: not solved yet

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:

• AMap / map-provider support
• Chinese localization and startup UI
• FindMy.py network / tag location update fix
• old data format migration
• smaller UI fixes / bug fixes

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]

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.