Another topic: The export filename is not kept any more. Example:
- create a short test route
- export route with name “test77.kurviger”
- just do next export: File name proposal is “20201116_204141.kurviger”, but should be “test77.Kurviger”.
Another topic: The export filename is not kept any more. Example:
Overwrite is not supported (at least officially).
If want to overwrite and is supported on your Android can click an existing route file and save.
But automatic addition of number on route file extension is not nice and should not be default.
Yes, I know - but from my point of view nevertheless the original name should be kept - especially in this case:
The GPX with that name does not exist yet - and when using long “speaking” file names, just copying name of imported file to name proposal for export would improve useability a lot.
But also when just “developing” a route - usually I save several versions with nearly the same filename, just increasing an index at the end.
Well I proposed the change for security reasons 2 weeks ago and all this time no one said otherwise:
Sorry - I have to admit that I did not get that or overread it - my fault!
I still think adding an index suffix to the base filename as proposed in App: Storage access framework would be the best solution.
If the android interface does not provide such an interface, perhaps it is possible to check, if target name exists - if yes - and add / increase an index to the base name suffix.
From my point of view searching the name of the previous version in a file list and tap on it just to copy the name is quite uncomfortable.
As far as I understood the old export interface with overwrite hint will not work with future Android - but for my use cases that solution had several advantages.
I am not familiar with android programming, but just doing a google search for “android storage access framework overwrite” there is a hit on stackoverflow, that describes a possibility to overwrite existing files:
So perhaps a combination of the old system with overwrite warning and the SAF might be possible…but perhaps I misunderstood that or even did not understand the problem.
If you all find so useful the route name, I could revert that change for Kurviger.
Regarding storage access framework, it works with streams, not real file paths.
Official API has less surprises and only Google can improve it in new Android.
For my opinion the route name is more comfortable, especially if I save .kurviger for me and .gpx for my friends. I’d like it.
No reaction ? The changes with Android seems too intense to me (user !) to immediately respond just like that in a ‘wild’ way without sufficient knowledge about the new situation. I suppose many users do not know what exactly is coming to us with the newest Android policy. The message so far does not seem attractive to me. Once again it seems that Android is cutting the legs from under their own chair. Causing the same misery as ever with that A 4.4 Kit Kat version with the barely accessible external sd card. As a normal Android user, I fear the worst and nothing to cheer about. For developers probably a lot of headaches to keep existing apps workable. No? The first question about the adoptable storage if someone is aware of it. What are those damn ‘streams’ then ?
Android’s storage access framework should allow full SD card access.
Apps struggled with its integration, until it will become mandatory now.
It means that apps cannot know regular file names or paths, as we all know them.
Apps are allowed to only process content as stream, i.e. directly the internal bytes.
And since the framework is external to the apps, we can only call it, not change it.
Kurviger 1.14.4 (Beta) was released.
I just tried it, the name is kept
If filename already exists and I do not tap on old file, index is attached behind extension (-> xyz.GPX (1) ) as expected.
Tapping on old file leads to overwriting
Tapping on .Kurviger file in Total Commander did not open it in Kurviger (I do not know why - worked with previous Kurviger versions). I fixed that by adding an internal association also for .kurviger files as described in
I had opened other local map files yesterday - then Kurviger used my map folder to store my GPX export - would it be possible to keep 2 paths in mind - one for local maps and one for import/export? I like separating them: Maps on SD card due to memory consumption, import/export in Kurviger folder to be able to open from Total Commander.
I found a workaround: There is also a Kurviger folder on SD Card, in that folder I added two folders for my import/export (“GPX”) and my maps (“maps”), so navigating from one folder to the other is just 2 taps - and opening files in that folders out of Total Commander in Kurviger works
Could be a regression, see also the report here.
(I will check it)
Like mentioned above, the storage access framework - and now apps - do not know paths.
It’s not like users open maps every day. The framework has its own life, we’ll get used to it.
Or can use a file manager (like Google Files app) that works everywhere in all storage locations.
Total Commander seems to work better on newer Android versions.
yes please, if overwriting is not working with the new framework (and it doesn’t work, not official and not inofficial, even if a file is selected before) and adding counters to the extension is so boring.
There is a solution better than my workaround :
Implemented in Kurviger 1.14.13.
Maybe others also have troubles to overwrite existing files with the new framework. At least I didn’t succeed til now. The overwriting of an existing route is working in the following way when exporting a route:
Delete the name
Then I first have to change the sorting to descending by date (newer files first) in order to quickly find the last route
Then tip 1x on the file that should be replaced. Now the question occurs to overwrite the file with OK
Android’s storage access framework is handled by the operating system (not the applications).
If it can offer more options for apps to call, then I could see if any improvements are available.
“…the developers highlight how Android’s Scoped Storage changes will limit the emulator’s functionality. It notes that because of the poor performance of the Storage Access Framework API, game list loading times have been increased by more than tenfold. While that doesn’t affect actual emulation performance, it will take a toll on user experience. Additionally, the API’s limitations will force the developers to drop some features, like customizing paths…”