You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GetDocumentsPath uses getCacheDir to return a storage location.
However as explained here in the section "Saving cache files" any files put in that location are considered temporary and are subject to deletion by the OS when it needs to reclaim space. Also note the explicit suggestion that the data be limited to no more than 1 MB and be regularly cleaned up by the app.
That is the exact polar opposite of what GetDocumentsPath says it does (and should be doing). GetDocumentsPath should be all about giving the app a place to persistently store data. Not a temporary location where data can and will disappear without notice!
I would argue that the correct behavior is:
First, GetDocumentsPath should return getFilesDir(). That is, after all, the location where files persistent to the app are supposed to be stored.
Second, we need some way, when creating files in the getFilesDir() location to pass in the Context.MODE_PRIVATE flag so that the app can control the visibility of the files it creates. This is a really big deal. For example, in Thali we are creating files that contain public keys. We really don't want those stored in a world readable location!
Ideally mobile would present a consistent interface that lets developers choose if they are:
Creating data that should go into a temporary cache
Creating permanent data that should be private on the device
Creating permanent data that should be public on the device
And this model would be the same (at the mobile layer) for both iOS and Android.
The text was updated successfully, but these errors were encountered:
GetDocumentsPath uses getCacheDir to return a storage location.
However as explained here in the section "Saving cache files" any files put in that location are considered temporary and are subject to deletion by the OS when it needs to reclaim space. Also note the explicit suggestion that the data be limited to no more than 1 MB and be regularly cleaned up by the app.
That is the exact polar opposite of what GetDocumentsPath says it does (and should be doing). GetDocumentsPath should be all about giving the app a place to persistently store data. Not a temporary location where data can and will disappear without notice!
I would argue that the correct behavior is:
First, GetDocumentsPath should return getFilesDir(). That is, after all, the location where files persistent to the app are supposed to be stored.
Second, we need some way, when creating files in the getFilesDir() location to pass in the Context.MODE_PRIVATE flag so that the app can control the visibility of the files it creates. This is a really big deal. For example, in Thali we are creating files that contain public keys. We really don't want those stored in a world readable location!
Ideally mobile would present a consistent interface that lets developers choose if they are:
And this model would be the same (at the mobile layer) for both iOS and Android.
The text was updated successfully, but these errors were encountered: