Messages

[@michaelbechtold]

@michaelbechtold
you lost some maps or how should I understand your post?

That was a happy fun message, documenting success. They were gone from the old location /1st line) and ended up at the target (2nd) sentence.

Sorry for the confusion.

Summarizing the experience and discussions from the last weeks:
- the current support for SRTM, mapsVector, maps for both, INT and EXT SD private space is powerful enough to help all use cases, i.e. map storage needs, capacities etc. - well done! A big THANK YOU!
- the backup to ANY folder, even outside private space is great - although I do not understand how you could escape the Android 11+/API 30 limitations. Well, these are not files with need for random access (like DBs and maps); maybe that helped. Will it survive Google "fixes" (below the level of yet another storage model) ?
- the GPX export to the backup location would be really nice
- guiding the community of users who are not able to help themselves to make the right choices is the gap I see
Fingers crossed ...
Cheers
Michael

@Menion: after rereading carefully I understood that the backup folder can be outside of the private Android/data realms.
I tried and it worked.
From your earlier explanations I do not understand why such would work. And why not for all the other needs.
Can you pls enlighten me?
TXs and cheers
Michael

English is OK. Translation error ...

@Menion:
I could not wait until next week because I am so curious ...
So I started trying, not on my S10 for daily use, but on the Tab S6 light (64 GB total internal space, large external SD) and found some essential problems.
My plan was to use the private section of internal SD (/Android/data/menion/...) as the main Locus location, then set the external SD for mapsVector and SRTM.
What happens?
1 long start - question: do or postpone
2 offers move
3 LMP loss of access warning
4 selection private - long pause 3 GB free - not enough - cancel
See attached for the situation: need for 1 GB (see external SD option), 3 GB free on internal SD.
Why is that? Most probably because of the SRTM and mapsVector that sit on external SD and require 75 GB in total. So I should have unchecked the two choices, right?

Which brings me to an overall judgement:
1) the steps and explainations are quite OK, but
2) it lacks overview for the user and
3) a plan

And there is a good chance that a user has ONE view of the storage reality, while Locus has another. Recipe for disaster, pain and discussions.

Hence I propose you do not offer the migration immediately, but produce a full storage picture how Locus sees it.
All the elements, with their sizes, and the options how and where to move them. And send this as a mail (share ...)
Something like:

Current Locus storage layout
=======================
Locus main: internalSD/Locus 1 .5 GB
Locus mapsVector: externalSD/LocusMaps/mapsVector 20 GB
Locus mapsVector: externalSD/LocusMaps/SRTM 55 GB

Internal SD capacity total/free: 64 GB / 3 GB
External SD capacity total/free: 256 GB / 151 GB

Next: what should a non-IT person do with a non-trivial situation?
1) understand the picture
2) understand the options

Can people derive that themselves? Hardly, hence they need advise.

A text that explains the options given various scenarios should be added to above report:
1) the total Locus storage fits fully into internalSD: do whatever you want, but internal preferred for data safety and performance reasons
2) current data on externalSD does not fit into internalSD: ...
3) ...
some homework here for all potential cases.

My setup above would need the following actions:
1) /Locus goes to internalSD
2) AT THE SAME TIME (!!!) current SRTM and mapsVector need a choice for their final target (I know you could uncheck both and doe manual stuff later, but that is not good, because it leaves a number of people stranded, in particular as the file managers fail so far)

Also: give warnings about long wait times for steps that take long, and tell users to click "Wait", not abort. Some of the steps 1-4 take unexpectedly long. I trust for a good reason, but people may wonder ...

So far my 2c

Cheers
Michael

Same country, same ideology, same stupidity.

Menion, I have tons of large maps on SD card, even on older devices. There is no performance problem using them in higher ZLs (although for sure you can MEASURE a significant difference).
A DATABASE on SD however, I would not even try, because the effect is obvious.

Menion,
I am not sure you understand the risk Locus and Asamm are in.
Pointing to voting is denying intelligence. Why?
Take the max voted topic, and divide it by the number of users you have. How many zeroes behind the dot - before a non-zero digit appears?
In other words: your risk is the unknown, and the invisible. And pointing to a hence meaningless voting is slapping those unseen > 1000000 users in the face.
Now, let's employ some intelligence. Proposing people buy new phone with more capacity - even as a joke - is not. Do you agree?
Another fact is, that most Androids are NOT Pixels. But rather the majority employs external SD card support, to allow for cheaper storage extension. For mass storage eaters like maps, e.g.
Then take Michal's advise (no DBs on SD, please). Put everything together, and employ your own proven intellect.

Menion, that is not what your users can expect from you.
I am the most outspoken on that one - easy as a Locus user of many years and a comp.science person since 40 years.
But you should be scared of the silent mass who is not even aware of the pot. tsunami hitting them.

As a partial remedy you should establish the possibility to have both /Andoid/data locations used. Following Michal's point, the right approach would be to have the app function and performance critical parts on the internal private location, while the mostly readonly data like maps and SRTM and alike are allowed on external SD private folder as well.
Then capacity INSIDE the Locus only world will not bite - users do not have to buy a bigger phone :-)
My other challenges are not met, but for the mass of users above should be safe - and keep peace in the user base. And Asamm ...

Good luck.
Cheers
Michael

To be honest, I would rather not rely on SD card with its "ability" to handle database fast random read/writing, its stability etc. Not long ago I lost all my data on an SD card due to its malfunction and the necessity of formatting.

I appreciate your twofold warning, Michal!

Question to Menion:
I saw that many apps have a /Android/data folder on external SD, BUT their working directory in fact is on internal storage.
Are you able to access BOTH of them simultaneously? E.g. SRTM and large maps on external SD, while databases and other essential objects with high performance and reliability needs are kept on the internal /Android/data storage.

Hast Du zufällig den Track mitschreiben lassen? Und "springt" der dann auch mit einer langen geraden Linie zu einer älteren Position?
Dann kann eine Android-Batterie-Optimierung schuld sein. Je nach Hersteller und Android-Version gibt es da verschiedene Einstellungen. Meist kann man auszuwählende Apps von der "Optimierung" ausnehmen.
Bei Huawei z.B. hat es nur bedingt geholfen. Bei meinen Galaxies hatte ich bei o.g. Ausnahme-Einstellung keine Probleme mehr.

All geo App developers should unite and kickk Google's ass.
Now all of them - and their customers and users are suffering separately.

Unacceptable.

TXs for the additional details, Menion.

I think you have to take the bull by the horns head-on!

The whole scoped storage thing is for the Instagram world, only good enough for images and videos.

All other big data sets suffer by deadly performance issues.

So, to summarize your (and similar apps) scenario:
- huge data sets
- random access needed (database and alike)
- shared between different apps
Forgot something?

If I were Asamm, I would create a dummy geo app with request for MANAGE_EXTERNAL_STORAGE, with above justification. Hence no danger to Locus itself, just for the battle with Google.

Quote from : https://support.google.com/googleplay/android-developer/answer/10467955#zippy=%2Cexceptions

Google Play may provide a temporary exception to apps that do not qualify as permitted use designated above, when;

    Use of the permission enables the app's core functionality; and
    There is currently no alternative method to provide the core functionality; or

use of the privacy friendly alternatives (e.g., MediaStore API, or Storage Access Framework) has a substantially detrimental impact on the critical features of the app that are tied to the core functionality.

    The impact on user privacy is mitigated by security and privacy best practices

The developer must justify in their Console declaration why the Storage Access Framework or MediaStore API is not sufficient for their app's purpose.

You can fulfil all three conditions. And if Google finally comes up with an enhanced framework that goes beyond Instagram (and alike) use cases, such exception can be ceeded. But not before!

Good luck and kind regards
Michael

I found it as the second topic of the maps section in expert settings.
You can also go into settings top page and then search for "dual".

PS: a sustainable support of the Locus team is easily manageable: they now offer LM4 via subscription.
https://www.locusmap.app/premium
I have both, LM Pro and LM4 installed and they share the maps (LoMaps plus OAM) as well as the track/points DB.
PPS: and the hiding works - "INTERNAL THEMES" - "Hike&Bike" - "Hiking Trails" - nice place near Mt. Rainier, WA :-)
Cheers
Michael

Trying the latest Beta today: the new track naming I consider a joke, sorry ;-)
Pls. bring back the time stamp naming, and if someone needs the location of the latest point in the default naming for their peace of mind - pls. add it AFTER the time stamp.
TXs for your understanding.