This is also a problem for me, so good to hear that it could be addressed.
Is there a way to use a more user friendly folder on Android? I am having trouble with enumerators not being able to find the right place - even before multiple project support (which is great by the way!)
Can ODK Collect access more generic spaces on a device e.g. ODK/layers
I know there are technical reasons for having migrated away from a main ODK folder for instances (not sure I really understand them!), butt drilling down to Android/data/org.odk.collect.android/files/ is more difficult than my folk using ODK Collect are comfortable with.
Personally having multiple places for the mbtiles file to reside would not be great (it sounds like you plan to have a general folder and project specific folder) - because I know that if it can go wrong, it will. And the non-human-readable format of the project names on the device complicates things further (as highlighted by @Florian_May above)... Finding yourself out in the field in the wrong project space needing to move mbtiles on the device is stressful enough, but getting someone to do that while they are on the phone to you asking why they can't see the map (when they've finally got signal) is a nightmare. Speaking from experience!
The other useful thing would be the possibility of downloading mbtiles directly from a Central server (maybe this is a different feature request) - if there were a function to upload mbtile as 'media' with a form definition, and for ODK Collect to download and transfer that to the appropriate folder, that would be a great step forward too. And would solve my hassles above...
Many thanks for your ongoing support and development.
This would really be very useful in order to propagate forms on lot of phones, belonging to non informatics friendly users , without having to manually put the layers at the right place on each phone. Layers could by downloaded from anywhere, not only from central.
We agree that project UUIDs are not friendly. We now write the project name inside the project directory so you list find all project names (find /sdcard/Android/data/org.odk.collect.android/files/projects -type f -maxdepth 2) and grab the UUID from the path.
Yes, we'll eventually let you download mbtiles from Central automatically.
My confusion is probably around why ODK can't write to a device when other Apps seem to do so - for example Viewranger (other navigation apps are available!) appears to be able to read / write data in an arbitrary folder named 'viewranger', so that is the naive assumption I was working on - ODK is the only I use that requires me to delve into the /Android/data.... folder. Apologies if that sounds 'challenging', I'm just revealing my level of stupidity rather than questioning anyone's competence!
My new-best-friend navigation app called Orux Maps allows me to use mbtiles, so if I could point to the folder that ODK used for Layers it would save needing two copies of the file on my device, and then I could navigate efficiently between recording stations...
I understand that putting instances in the /Android/data/... folder means that other apps can't access anything, which is great from a confidentiality or Data Protection perspective, so if that's the main constraint preventing use of other locations on the device for other functions, then that's a compromise worth living with. As always I live in hope of having cake and eating it...
Thanks for the ongoing improvements - they're much appreciated, and don't take our 'impatience' for perfection as negative
As @yanokwa states, we can't access arbitrary files automatically (from a top level ODK directory for instance), but we could potentially have a feature that lets the user choose a reference layer that sits somewhere on their device (like in their Downloads directory) and that layer could be copied into Collect's own storage.
The important difference is that it involves the user going through a UI to that the OS provides to grant permission to the app to access that one file. I'm assuming that's the kind of thing you're seeing with this other app. If not, it's likely they won't support the feature you're talking about much longer because directly writing/reading from your app's designated directories is a not something Android supports any longer. You can read some more details on that in the Android docs if you're interested.
As a point of interest: this is why the Android team removed the ability to just read and write from anywhere on the device. It was incredibly easy to just build an app that looked like a cute face swapper or game that could just grab files from another app's well known directory and upload them somewhere.
Hi @seadowg
Thanks for the clarity of your answer here (a reminder with examples is always helpful!) adding to that provided by @yanokwa. Yes, the other apps I use have settings for 'default' locations for different files - so I guess they use that as a means of gaining permission from the user, but it is always possible that these apps haven't caught up with ODK yet in terms of Android best practice (or functionality).
I'm happy to contribute to the thought processes from a user perspective on different options you might have for storing layers - I have some very stubborn enumerators (usually in a good way), so can vouch for the need for it to be foolproof...
Making use of a common UI method of locating a file or folder would be good, for example, as an alternative to requiring the files to be placed in an ODK folder? Any process that is familiar helps, in my experience.
If we can find a way of getting the files onto a device (maybe Google Drive?) and then point to that from within ODK (possibly whilst using a map widget) then it cuts down the need for 'expert' intervention - possibly also allows reuse of existing tools / functions on Android rather than coming up with a new circular transportational device.
I suspect that in the long run storing tiles in Central is not the ideal solution. Tilesets can be big and unwieldy, and MBTiles are not the right way to store tilesets, rather they're a good way to package up subsets of tiles and serve them to individuals (normally it you're serving MBTiles you actually have a tileset in a database or filesystem, or a GeoTiff that you cut tiles from on the fly).
I'd suggest considering Collect just keep track of Areas of Interest (AOIs) and Tile Mill Servers (TMSs), and delegate the downloading and storage/caching of tiles to Collect.
In the scenario where the tiles come from something external (like Bing Satellite, which is legal for OpenStreetMap editing, and "caching for performance" is allowed by the ToS) this eliminates a great deal of storage and bandwidth requirements for Central. Central just keeps track of which tiles Collect needs and where to get 'em, and Collect gets them from the source.
However; in some cases project managers will want to create custom tiles. Now they need to store them somewhere! Sure, we could implement a tile server in Central, that would work. But I think it's a terrible solution:
it's unlikely that we'll implement as good a tile server as someone who focuses on building tile servers
storage and bandwidth can get out of hand rather quickly, or run into weird issues fairly specific to tilesets (for example, a fun feature of tile serving—and by "fun" I mean horrible and frustrating—is that you can easily run out of disk space while still having lots of free space on your disk; with millions of tiny files you run out of inodes and get "disk full, 1.2 TB of 1.9 TB used" which is baffling unless you know what happened, and frustrating even if you do).
My suggestion? Choose a good Free Software tile server and provide a way (perhaps simply instructions) to install it on either a Collect server, or somewhere else, probably in a in a container. Now we push our tiles, or our GeoTiff that the tiles get cut from onto that server, it takes care of all the complexity of tiles for us, and its maintainers take care of keeping the codebase in shape.
, without having to manually put the layers at the right place on each phone. Layers could by downloaded from anywhere, not only from central.