Skip to main content
A
Anonymous
February 22, 2012
Answered

iOS - Library/Cache - Database question

  • February 22, 2012
  • 2 replies
  • 4067 views

Hello there,

Some time ago I've read on this forum that the correct directory to use on iOS for storing data is Library/Cache and since then I've fixed my app to use that directory.

Here it is the link to an article written by "our" Saumitra:

http://www.saumitrabhave.com/2011/11/air-ios-solving-apps-must-follow-ios.html

My app has 2 db files (and some xml files).

The struct looks like this:

[root] my main app

├──data

│  └──dbtemplates  (this dir contains my two db files)

└──xml

   ├──en (this dir contains english localization)

   └──it (this dir contains italian localization)

When my app starts, it copies these 2 db files in Library/Cache directory and then the app fills them with data generated on the fly: from that moment my app will use these two new databases for reading and saving datas.

My questions are:

1) With this struct, is it true that my app won't be rejected by Apple? (I mean with data/dbtemplates, xml/it and xml/en subdirectories)

2) Is the Library/Cache the right directory to copy my new db in?

3) If Apple accepts my app, sooner or later I will develop an update to my app: in that case, if the user has not uninstalled my app, when he updates the app from the apple store, the db files that I stored in Library/Cache won't be deleted from the update process, true?

Unilt today I was pretty sure that the answers to my questions were "yes", "yes" and "yes" but today I've spoken with a friend of mine that told me that I need also to flag my dbfiles as "do not backup" and the only wat to accomplish this is to use a native extension:

http://www.jampot.ie/ane/ane-ios-data-storage-set-donotbackup-attribute-for-ios5-native-extension/

Can someone clear my doubts?

Thanks in advance

This topic has been closed for replies.
Correct answer

Hi Saumitra,

Thanks for your reply.

Let's see if I have understood well.

1) Seen that my application creates new db files from scratch and seen that files are essential for my app to work, I can place them on applicationStorageDirectory exactly as I do in Android.

2) By placing these db files there, my app won't be rejected by Apple (however maybe it will be better to explain in the note textfield, during the upload process, that my app really needs these files).

3) Then when I will make a version 1.1 and the users (that have previously installed my app) install the update won't loose the content in the applicationStorageDirectory (exactly as in Android).

4) So I do not need to flag these files as "do not backup" because I want these files to be backed-up (and it would be nice too if they were put automatically in the iCloud)

5) And they lived happily ever after


Correct?

Thanks in advance

2 replies

A
Anonymous
March 9, 2012

Okay, I can confirm that my app has been accepted by the Apple Store.

And they lived happily ever after.

A
Anonymous
January 17, 2013

With AIR 3.6 latest prerelease,

A new property, preventBackup is introduced in the File API, which when set prevents a file or a folder from getting backed up on the iCloud. This property works on iOS 5.1 devices and later.

Another static property, File.cacheDirectory has been added, which points to the <APPLICATION_HOME>/Library/Caches directory on iOS devices, and files in this directory are not backed up. So, the above workaround is not required.

You can find additional details on this feature here<http://labsdownload.adobe.com/pub/labs/flashruntimes/shared/air3-6_fla shplayer11-6_releasenotes.pdf>

A
Anonymous
February 23, 2012

1) With this struct, is it true that my app won't be rejected by Apple? (I mean with data/dbtemplates, xml/it and xml/en subdirectories)

     Its seems absolutely fine. data and xml are the folders you package as assets right?

2) Is the Library/Cache the right directory to copy my new db in?

     As I see your use case, I think you should rather use the applicationStorageDirectory. Because thes files are essential for your application to work.

3) If Apple accepts my app, sooner or later I will develop an update to my app: in that case, if the user has not uninstalled my app, when he updates the app from the apple store, the db files that I stored in Library/Cache won't be deleted from the update process, true?

     No. As per Apple QnA "the entire <Application_Home>/Library directory has always been preserved during updates and backups, except for <Application_Home>/Library/Caches." See this . So if you store the XMLs in Caches they will be deleted but Not if you store them in applicationStorageDirectory which is (Library/Application Support/....) See recommended usage of this directory here

About "Do Not Backup Attribute".

As you can see that above link mentions adding the do not backup extended attribute to "Application Support". You should set it if you dont need those files to be backed up but, You should not set this attribute if it is essential for your application to have those files when restored from backup to function properly or get "restored" completely.

A
Anonymous
Correct answer
February 23, 2012

Hi Saumitra,

Thanks for your reply.

Let's see if I have understood well.

1) Seen that my application creates new db files from scratch and seen that files are essential for my app to work, I can place them on applicationStorageDirectory exactly as I do in Android.

2) By placing these db files there, my app won't be rejected by Apple (however maybe it will be better to explain in the note textfield, during the upload process, that my app really needs these files).

3) Then when I will make a version 1.1 and the users (that have previously installed my app) install the update won't loose the content in the applicationStorageDirectory (exactly as in Android).

4) So I do not need to flag these files as "do not backup" because I want these files to be backed-up (and it would be nice too if they were put automatically in the iCloud)

5) And they lived happily ever after


Correct?

Thanks in advance

A
Anonymous
February 23, 2012

Yes. Thats right!!

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices