system.ApplicationSupportDirectory vs system.DocumentsDirectory

Solar2D General Questions/Discussion
#1

hi guys,

what’s the differences about this 2 directories?

I usually save player scores, gender, levels completed, etc. on system.DocumentsDirectory. Should i move to the system.ApplicationSupportDirectory.

another question,

saving files on any of this folders are safe from deletion from the user or i need to save this data to a remote server to be 100% sure? i don’t want the game to be online, but if this is the only case i can be safe, i will do it. i don’t want the user to be upset because they played a game for 1month then is record was deleted.

regards,

Carlos.

#2

Hi Carlos,

The quick anser is yes, you should move your setting files to the applicationSupportDirectory.

On device it works fine to use both these directories, as both are persistent, but the latter is supposedly not visible to the user, as the documentation states.

Storing on a remote server is even safer and cross device compatible but then again, it depends on what level of security your app really needs.

If you want a simple backend solution for online storage as a service and much more, take a look at app42 (google it). They also provide corona code for the entire API. Beyond that, its setting up and configuring your own server, which is taking it to a whole different level.

Cheers!

#3

hi anaqim,

What I was wonder was exactly that, why system.DocumentsDirectory is visible? always thought that none of those “cache” directories where visible and accessible to the end user. not to a root device android ofc. but to all others none could access then (sandbox). with this difference on applicationSupportDirectory, that made me think i’m wrong in my thinking and a little enlight how they really work would be good for us making decisions when to use them.

#4

Hi Carlos,

I’m by far no expert in this so this is just my thoughts based on what the documentation says, and some logic thinking.

We know the resource directory is prohibited from writes so its like your apps read only root folder.

The documents directory is the the opposite, like the “my documents” folder in windows.

It’s there, its persistent and its available for users who want to peek around.

The caches directory is good for storing files that need to be persistent between sessions.

I’m not sure how accessible it is to the user but perhaps it was not safe enough…

…and someone decided to do something about it by adding the application support directory.

The temporary directory isnt supposed to be persistent although it doesnt clear between sessions either, or not that I have noticed. I used it for storing temporary files, and each time the app is run, it starts by emptying it.

Dont know if this helps but anyway  :stuck_out_tongue:

#5

i can be wrong anaqim, but your thinking is way off what i read in this forum, for the last 3 years.

with a little search i found this post:

https://forums.coronalabs.com/topic/60774-android-documentsdirectory-or-other-file-storage/

where Robs say:

But your question, where are things stored: They are stored in the App’s sandbox on the device in a place we reference as system.DocumentsDirectory. This is locked in the apps protected sandbox and you can’t access them unless your device has been “rooted”. (Note: we don’t support rooted devices).

other more recent post:

https://forums.coronalabs.com/topic/61861-device-system-file-access/

he says:

Officially, out of the box, Corona SDK is only going to give you access to four sandboxed folders:

 

system.ResourceDirectory – Your apk file, read only

system.DocumentsDirectory – where your app should store permanent files

system.CachesDirectory – where you should store files that can be re-downloaded from the Internet

system.TemporaryDirectory – where you can store files that you don’t care if the system deletes them on you. Android doesn’t really have a concept of a CachesDirectory, I think it maps to system.TemporaryDirectory.

now they added another one (that only found out today) that confused me because they say is a hidden directory?? the others weren’t? 

#6

the only think i can think of is the new directory is still in the sandbox, like the others, not  accessible to normal user like the others, on not rooted device, but hidden from a normal (dir), to low-level hackers could not find it easy.

#7

i stand corrected  :wink:

when searching for the new directory I found that its an apple concept.

perhaps its just corona adapting to iOS features.

https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/ManagingFIlesandDirectories/ManagingFIlesandDirectories.html

anyway I store stuff on a server so only really use the temporary directory myself.

#8

your link does not have nothing about the problem here. i’m not talking of creating new folders or files. we are talking about the directories corona provide and the differences about the new system.ApplicationSupportDirectory and the old one system.DocumentsDirectory.

if it was a matter of security why didnt they upgrade the DocumentsDirectory or even all to hidden state. 

#9

that leaves us both wondering im afraid mate.

#10

In our cross-platform world we have to deal with four distinct operating systems:  iOS, macOS, Windows and Android (tvOS is really close to iOS, Android TV is basically Android).  Each of these have different ways of handling files. They are broken down into different classifications of data:

App data – i.e. the App Bundle/APK/Directory with the Win32 .exe file. This is read only and on Android the .apk is a .zip file and not an actual directory. There are extra steps needed to access some files here. Should be in the docs for system.ResourceDirectory.

User data: For iOS and macOS  Apple tries to describe the rules here: https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html

Basically what we call system.DocumentsDirectory is the Documents directory from that doc. It’s backed up. All user data should go here. Content here, when tethered (physically or by WiFi) to iTunes can be accessed from iTunes. There may be a little bit of magic needed to turn it on. 

system.ApplicationSupportDirectory is backed up and is used to store configuration items you don’t want exposed in Documents. It seems a game settings file would be appropriate here. On macOS this is the /User/yourname/Library/Application Support folder. We of course will make a folder for your project in there and map that to your system.ApplicationSupportDirectory. On Windows this ends up in /Users/yourname/AppData/Roaming/Appname I believe.  I don’t know that Android has this concept so we may just make a folder for it in the sandbox. I’ll have to research that further.

Apple want’s files that can be downloaded from the Internet in a “Caches” folder. I believe this is part of the Library part of the system and not in the physical app bundle (based on reading  the app doc.) For the other OS’s I’m not 100% sure were we physically put them and the same for the system.TemporaryDirectory where the system’s all handle tmp files a bit differently.

But at the end of the day:

system.ResourceDirectory: Read-Only, your app bundle/.apk

system.DocumentsDirectory: Store user created files here. Backed up to iCloud on Apple devices, potentially visible to iTunes.

system.CachesDirectory: If you can fetch it from the Internet, put it here, subject to periodic purging. You can always re-download it!

system.TemporaryDirectory: Put temp files here, purged frequently

system.ApplicationSupportDirectory: Like Documents directory will be backed up to iCloud on Apple devices. Hidden from iTunes. Configuration files are typically stored here.

Hope that clears it up.

Rob

Saving And Restoring State
#11

one question,

can we trust that Temporary and Cache dirs will be purged when needed cross platform?

or is it better to take care of it ourselves?

thx

#12

iOS and Android should purge them. Windows and macOS I’m not sure about. But that said it’s always best to keep a clean house. 

Rob

#13

thanks Rob, for your excelent enlight of this matter. it should go strait to documentation.

i will start to use system.ApplicationSupportDirectory to save users data.

#14

The game I’m currently working on, I switched from using a config file to using the new system.getPreference() option to store them in a native way. I have code like:

myData.settings.gamesPlayed = system.getPreference( "app", "gamesPlayed", "number" ) or 0

and

local result = system.setPreferences( "app", myData.settings ) print("result of setting preferences is", result)

It’s perhaps a little more work, but it works for me. The drawback is that you can’t store tables in your settings table… only numbers, strings and booleans. This required me to do some extra work where I wanted to save number number of stars per level.

But yea, I would use system.ApplicationSupportDirectory to save configuration stuff.

#15

just tried to use system.ApplicationSupportDirectory, and it failed on ipad mini 2 with IOS 10.3.2. I’ve the latest version of corona 2017.3108. it crashed my app saying the string was nil trying to copy to that folder.

it worked fine on android 7.1.1 device, windows simulator and mac simulator.

edit: changed the code to use the same old “system.DocumentsDirectory” and it worked fine on all devices.

#16

Can you put together a simple test case that demonstrates this?

Thanks

Rob

#17

sure, it’s really just sending data to that Directory.

Test on device please not in simulator.

Tested right now on another ipad mini 4 still failed.

local origin=system.ResourceDirectory local dest=system.ApplicationSupportDirectory local dbName="saldo.png" local pathSource = system.pathForFile( dbName, origin ) local fileSource = io.open( pathSource, "rb" ) local contentsSource = fileSource:read( "\*a" ) local pathDest = system.pathForFile( dbName, dest ) local fileDest = io.open( pathDest, "wb" ) fileDest:write( contentsSource ) io.close( fileSource ) io.close( fileDest ) local image=display.newImageRect(dbName,dest,200, 90) image:translate(display.contentWidth\*.5,display.contentHeight\*.5)
#18

I ran it on my iPhone 6, running iOS 10.3.2 and it worked as expected.

Rob

#19

like i told you i tested on 2 ipads, mini 2 and 4 both with IOS 10.3.2. failed. i don’t have an iphone to test it.

#20

What OS versions are on those devices?

It failed on my iPad too. Weird. Can you take this project and file a bug report? Use this link to submit the bug report:

https://portal.coronalabs.com/bug-submission

Thanks

Rob