Messages

Got two small observations:

• The new "minimized point/track pull-up" is nice, but I would prefer if that flag is "sticky". Let's say I have several tracks close to each other and click one, then click the pull-up title to make it small, to just see the name. Now I click another track, but I get the big pull-up again. It would be nicer if the pull-up stayed minimized while clicking through points and tracks. Once I unselect everything, the flag is cleared, so next time I click something I get the full size again. In short: "When track/point clicked && already a pull-up shown && pull-up minimized => show new pull-up minimized"
• I never before saw this "Show View" function. It's nice, but - at least on HD screens - basically useless, because it's so small. On my screen the >50% transparency part is ca. 3x3mm, and when I'm e.g. on a motorway, which is usually yellow or orange, it's almost invisible. Could you add a %-size selection in settings? Btw, when I long-click the button in Quick Settings and chose "Information", an empty message is displayed.

Android is really weird since A11.
"Android/media"

App create directory with the package name, so /Android/media/menion.android/locus/x
- app may read and write here without limits
- directory is deleted together with the app!!

So the main difference to the folder in data is that at least file manager apps have full access here, whereas in data they only have on the intSd (which may or may not actually be a bug that Google decided not to fix in A11 in order not to break something).

App may also create any! directory here, so for example /Android/media/maps
- app can not read any content from this directory. Simply request "get files" return "nothing" even I've just put few maps there.
- directory is not deleted together with the app

Well, that really makes no sense, granted. Being able to create directories you can't read from - oo-whee!

Then we're back to the question whether generic folders like Android/media/maps would work, i.e. Locus can access them the way it needs, and they're not removed by any deinstallation (which I'm pretty optimistic about, there's no way for Android, at least on ExFAT, to be sure which app created a folder, if it doesn't conform to a specific naming scheme).

Without harm means that the app is not important to me.

Ah, OK, thx, now I understand.

I just checked /Android/media and found an app that puts a folder there and that I could dispose of without harm: the app specific folder in media will go with the deinstallation.

I'm sorry, but you're also contradicting yourself: Can you dispose of the app without harm (= without the folder being deleted) or will the folder in media go (=be removed) with the deinstallation.

Anyway, because I create app directories manually, there is a change, this dir won't be deleted ... what a stupid Google decision, omg.

This contradicts what I answered me above - so did you try it out or otherwise came to the conclusion that the folder under media is not deleted?
I'm totally confused now.

As an aside:
I do understand and kinda support that Google doesn't allow everyone to write directly to the root folder of intSd or extSd (incl. not creating directories) - that only led to chaos with tons of folders like "backup", "Backup", "backups", "bak", "tmp", "temp", "tempAppName", etc. Their "solution" approach, however, goes much too far, obviously, and is too restrictive.

[@slarti76]

@slarti76
sorry, any alternative to "default maps dir" is not possible. Technically it is really forced to core defined directory. And why not simply setup "mapsVector" to the private directory on the SD card?

Yeah, I'll do that now. Still unsure about the performance impact, especially on that slower phone. Perhaps I'll do some tests.

And yes, Android/media directory should be deleted as well once app is un-installed.

That's a inconvenient, but at least we get full access with all file managers, so can just move the folder before uninstall (if it's really unavoidable).

Was this question answered?
> Will content of Android/media/<appid> also be deleted when app is uninstalled?

Sorry if I overlooked something, can't find an answer...

[@slarti76]

@slarti76
only the default "mapsVector" directory is used for such checks. All other places work the same as "external maps" > so only a source of maps side-loaded during init, nothing more.

Would it be very complicated to also check at least the default locations on extSd? The problem is, obviously, if you have a phone with not much intSd space, and you're trying to download LoMaps from the store, this might fail, even if you have enough space on an extSd. For example, on my Outdoor Phone I have enough space for the LoMaps of my home country - and I want to keep it there for speed -, but if I need additional maps for a holiday, I first have to delete that map, then download holiday map, move that to extSd, then download home country again.
Even worse, I might have to delete previous map also when just updating, if both download ZIP and map don't fit on phone together.

Beta version: MapGooglePlay_4.5.4.1_1053_beta
- app now automatically create & scan "X/Android/media/menion.android.locus/maps(Vector)" directories for a maps. Give it a try and let me know ...

I moved my LoMaps I had on the extSd to that folder (on extSd). Maps are found fine, but they were old, and when I went to the store and did "Check for Updates", Locus didn't offer to update those maps. When I look for them manually in the store, they're not shown as installed, and downloading them - expectedly - saves them on the intSd.
I think if LoMaps are stored in any of those default directories, Locus should find them and update them in place.

[deleted that post about not being able to re-set custom directory - I overlooked the new beta that's supposed to fix this. sorry]

"_themes" is an ugly name, also having all user content beside each other (themes, vectormaps, srtm...) is good for external backup. Better order, easier to find...

Theme attached.

I agree. It's more complicated to set up automatic backups (e.g. with FolderSync) if data like this (that I want to backup) is in different base directories, together with other data like maps (that are too big for regular backups). Same applies for mapsOnline/custom directory. Why not put all this under "data", and only the actual maps under "maps*" ?

Menion, I was wondering:
You're not the first to suffer under Google restrictions. I know quite some apps that offer a "Google-impaired" version on Google Play, and another without those restriction on their website.
I mean, I'm not an expert on Android development, but if I remember correctly, you can request any Android right from the user if the app is sideloaded. So you could tell the user: "Play version only allows to store map and other extra data in internal app dir. If you need to access data stored anywhere on your system, please install the version from the website (sideload): <link here>".
Wouldn't that be a compromise to appease Google and the power users at the same time?

If it wasn't so braindead, it would even be funny that Google allows app X to access internal data files of app Y on intSd, which cannot be accessed without Android, while disallowing it on an extSd, which you can always just yank out and attach to a Windows machine where due to exFAT you can do whatever you like wherever you like...

But it would be up to Menion to always look at int SD mapsVector for themes, even if the maps are on ext SD.
@Menion: what is your judgement, pls. ?

Sounds reasonable, and I additionally think the theme folder name is just a historical, but ugly thing (mapsVector\_themes). I'd even drag them up one level, so that we may have all extra content on one level...

Maps\
MapsOnline\
MapsVector\
MapsVectorThemes\
SRTM\
..

+1
It's always a pain to set up syncs (e.g. with FolderSync) that sync the themes but not the (big) map files.