Opinions on Google Play Store release?

[rdoeffinger]

Mostly out of curiosity on the process (i.e. I won't take it too seriously and it won't look particularly polished) I'd be somewhat interested in putting the app on the Play Store.
But I think I should get your ok, especially as I'd prefer to keep the MapEver name.
I'd probably base it on my repository, mostly due to the small build system changes needed (like signing key config, app ID).
I'd use my own app ID, both to allow installing alongside the F-Droid version (for testing), to allow someone else to take over without app ID conflicts and because me using the name of a university I've not had anything to do with feels wrong :)
Tell me if you have any objections or concerns, I have no problems even dropping this plan, it just seems like something interesting to try.

[diedricm]

I think it's basically a nice idea. We should just coordinate our releases so that they are not forks. A fork having the same name but different version and features would be somewhat confusing.
Having two versions of MapEver on the same device wouldn’t work right now. The TrackDB files would overwrite one another. You could change the ext memory folder name, but then one couldn’t switch between markets any more while keeping the maps.

Regarding that: I was planing to release a new version to fdroid in the coming week. I still want to replace the current serialization system and make opencv completely optional.

[rdoeffinger]

We should just coordinate our releases so that they are not forks. A fork having the same name but different version and features would be somewhat confusing.

It would probably be not that bad as not that many people use both Play Store and F-Droid I'd guess. Also a different AppID and signing key (thus F-Droid not seeing the Play Store version for example) will probably cause some confusion anyway. For myself I decided I don't consider a bit of messiness a real issue.
But I have no intention of having a fork at all, more taking a release tag and making minor changes if needed.
I was mostly thinking of, as said, any build system changes that might be needed, and potentially bugfix releases in case of bug reports. Synchronizing that kind of thing seems a bit too much overhead, at least if it's small things that hardly affect anyone and/or I'd need user feedback on whether it fully fixes the issue.

Having two versions of MapEver on the same device wouldn’t work right now. The TrackDB files would overwrite one another.

Shouldn't they just use the same one? I meant having both of them use the same data. Though an option to select between SD card (current behaviour) and app data store (the .datadir thing) that also copies (moves?) the data would fully resolve this.

make opencv completely optional.

I'd probably make only a "light" release without OpenCV to start because
a) that is all I use and test currently
b) I haven't built OpenCV yet
(I am also wondering if the OpenCV footprint could be reduced somehow by disabling more of its features, we should still be using only a tiny subset)

[diedricm]

Yeah I just meant that both versions should be somewhat near the same tag.

Shouldn't they just use the same one? I meant having both of them use the same data. Though an option to select between SD card (current behaviour) and app data store (the .datadir thing) that also copies (moves?) the data would fully resolve this.

They could run concurrently and then everything will break ;) If they would not run concurrently then we wouldn’t have a lot problems. Will solve this together with the serialization issue however.

I'd probably make only a "light" release without OpenCV to start because
a) that is all I use and test currently
b) I haven't built OpenCV yet

That's totally okay.

(I am also wondering if the OpenCV footprint could be reduced somehow by disabling more of its features, we should still be using only a tiny subset)

Probably. I just do not know what for.

Aiming to merge my stuff and test everything tomorrow.

[rdoeffinger]

They could run concurrently and then everything will break ;)

I don't think so actually. The only think breaking is if they actually write state at the same time.
Mostly if adding maps to both "at the same time".
The other cases where it would break are actually caused by the code not being robust against e.g. crashes.
The safe way to write data is

1. create a unique temporary file in same directory
2. write new data to temporary file
3. fsync file
4. atomically move the temporary file over the file to be overwritten
   Not sure if/how Java supports fsync, though generally I'd expect that step not to be that critical on file systems designed for mobile use.

[diedricm]

Yeah or we just remove the central file and make the maps name the filename of the trackfile. Pretty much like it is used in testloc. We just have to create unique names when a map is created and add some kind of popup if the changing of a name would be collide with another file.
I'd guess reading the filenames of all files in a directory is more efficient than the current approach. Also this would solve the import/export problem really easily.

[rdoeffinger]

Not sure if I maybe misunderstood... Removing the central file would be good for general robustness and would allow adding maps from multiple apps safely.
But to ensure data consistency of e.g. a single map the scheme I mentioned before would still be necessary.

[diedricm]

Yes I think we misunderstood each other. I was thinking about the problems with TrackDB being modified in two different places, so my solution to this was to just use the OS functions for renaming/deleting and creating files.
This however does not solve the problem of modifying the actual .track files in two places simultaneously. This whole scenario also strikes me as kinda useless, but whatever.
Actually I'd like to put at least the track files and the thumbnails into the applications private memory, but than it cannot be easily copied to another device without implementing that in MapEver :/