Where to store the SQLite database file? - ios

I have a SQlite database file with records which comes with my app.
I just used the file I added to my project to make my INSERT and UPDATE statements.
After uploading it to my test device I got the exception that the file is read only.
After a bit of research I found out, that I have to copy the db file to the users directory to make an insert. This works for now. But I have a view questions about it, which i didn't get answered through google:
Where should I put my copy process?
I implemented it in the AppDelegates FinishedLaunching, where I check if it already exists.
Where should I copy the file to?
I used the MyDocuments folder for now, is this ok?
Since the file cannot be encrypted, can another app access the database file?
When the user decides to delete the app from the device. Will the database file get deleted,too?
Thanks!

Where should I put my copy process? I implemented it in the AppDelegates FinishedLaunching, where I check if it already exists.
That really depends, but finishedLaunching is OK from my point of view.
Where should I copy the file to? I used the MyDocuments folder for now, is this ok?
I'm not sure what you mean by "MyDocuments" folder. Each Application has a dedicated Document directory. That's where you should copy it.
Since the file cannot be encrypted, can another app access the database file?
No, they run sand-boxed (unless the device is jailbroken)
When the user decides to delete the app from the device. Will the database file get deleted,too?
Yes, since the whole document directory will be deleted.

Where should I put my copy process? I implemented it in the AppDelegates FinishedLaunching
Keep in mind that you have a limited amount of time to complete FinishedLaunching execution (around 15 seconds) before the iOS watchdog kills your application.
Depending on the size of your database, the speed of device and other processing you need to do then you might want to consider only checking if it already exists (that should be quick) then do the copy (if required) from to another thread.
I used the MyDocuments folder for now, is this ok?
Yes, using Environment.GetFolderPath (Environment.SpecialFolder.MyDocuments) is correct.
Everything else from #Lightforce answer covers the rest.

Related

Keeping a bundled realm up to date using REST

I have an app that uses a database of about 5000 entries.
This database is bundled in the app as a realm file.
I want to be able to update/add entries to this database regulary using REST and I think I have done it correctly - I just want to make sure.
This is how I have done it:
When the app is installed I copy the bundled database from the mainBundle to the Documents directory for read/write access. I then delete the database from the mainBundle.
When I update/add new entries to the database, they are pushed to the user using REST and inserted into the database located in the Documents directory.
When an update is released of the app, I make a check to see if the database already exists in the Documents folder - if it does I automatically remove the database in the mainBundle as it is not needed.
Am I on the right track with this? Is there a better way of doing it?
Appreciate any input!
Regards,
Erik
When I update/add new entries to the database, they are pushed to the user using REST and inserted into the database located in the Documents directory.
Technically, you can't push via REST. So I guess, you're either sending a background push notification to all installations or you're checking at application launch, whether there is a new version of the database available. That's at least what I would propose, but your requirements for getting new data out may vary.
When an update is released of the app, I make a check to see if the database already exists in the Documents folder - if it does I automatically remove the database in the mainBundle as it is not needed.
This doesn't work. The main bundle is the signed app bundle. If you would tamper the contents, that would prevent your app from launching. For that reason the access to it is limited by the OS to read-only. So this operation will always fail with an error. Instead you might properly just want to skip seeding the database from the main bundle.

Deleting 20000 files in applicationWillTerminate

In my iPhone app, I am downloading files from server and storing them locally (user's document directory). The path of each file downloaded is subsequently updated in database.
If user tries to delete a file, first the file is deleted from local path using removeItemAtPath: (NSFileManager), then corresponding record is deleted from database.
Now I have one of the requirements according to which user can turn on a UISwitch to delete all data on app exit.
Now my question is -
suppose user downloaded 20000 files, say small images, and user turned
on the switch to delete all data on app exit. Is it good to handle
this task in applicationWillTerminate? What is the best way to
accomplish this scenario?
Please suggest.
Don't delete the files individually, delete and recreate the folder.
Your database could be handled differently by version tagging so that you can batch delete the items on the next run.
applicationWillTerminate will only be called if your app goes background (the only option by pressing Home button of the device) and "Application does not run in background" key is set in your app's info.plist file to "YES". Otherwise it won't ever be called.
If you are planning deploy app with similar functionality, you can use applicationWillTerminate for removing so many files. However, I would never recommend you that. Instead, my recommendation is to remove the files as soon as they are processed, if possible at all.
Another thing you must consider is not to save so many files in Document directory, however small those are. Document directory is backed up by iTunes and iCloud and if you store so many files there, you are gonna possibly violate Apple's Data Storage Guideline that would reject your app from App Store. It is always a good idea to store transient files in application's "tmp" directory and delete them when not required anymore.

Core data solution for read-write separate

I am doing something with core data. Since the original sqlite file contains the data in the application. I decide to do the following:
Separate the reading and writing action. Make all the reading from one data source of one sqlite file and make all the writing in another file.
Since there are some rules in the directory in iOS application, I plan to copy all the reading data from bundle to the cache directory and put the writing data in the document directory.
The question is that, is it possible to use the reading file in the bundle resource directly. Which means I don't have to copy it into the cache file and that will save some space for the device.
Or you guys have any other better idea, please tell me.
I put the write data into the document because the file in it can be backuped by icloud, which could act as a feature in my program.
You ask if what you want to do is a good idea, but first you need to think through some possible pitfalls.
I suppose the file in your bundle was also created with Core Data, and it has a MOM. The new file you write - it probably uses the same MOM. What will you do if you ever need to update the MOM? The file on iCloud will be say version 1, and maybe the users iPhone uses Version 1, but your new version 2 is loaded onto the users iPad. Now what? The ipad should not update the repository as that would make the iPhone fail when it tries to use the data - the ipad has no way of knowing if all other devices have updated or not.

iOS storing files rules - Storing audio files on iOS app

I need to be sure I am doing the right thing:
In my app the user can download audio files from the server. I don't want those big file to be backed up as he can re download them when ever he needs to.
My app is addressed for iOS 4.0 and above.
So as I understand I need to store the files is the documents directory and set a flag for the directory to not back up ?
Am I correct ?
Instead of putting them into the "Documents" directory (which gets backed up to the cloud), why not put your audio files into a "Cache" directory (specifically "/Library/Cache", which does not get backed up)?
Here's another question here on Stackoverflow that may help give a further answer to your question.
You can also prevent files to backed up:
https://developer.apple.com/library/ios/qa/qa1719/_index.html

How can I ship my app with a pre-populated Core Data database?

My app uses Core Data and I want some default entries to be inside.
What's best practices of how to do that?
If you're already loading the pre-load data via a temporary routine for testing in your current code there's no reason you can't use the sqlite file it creates in the simulator's directory (no need to write a separate Mac app).
If you're not already filling that db you can still write an iOS app that does it. Odds are you've already written the methods for adding data to your store so you can use them to import the pre-load data as well.
Either way you'd grab the sqlite file from the simulator's directory and add it to your app's bundle; on first launch you'll copy it into the appropriate place in the app's directory before pointing Core Data to it. If it's really large the downside is that there will be a copy in the bundle and another on disk, but there's not much you can do about that other than grabbing the data over the network.
As others have suggested, if the amount of data is small you can just import it at first launch, using the methods you've already written for adding data as part of the normal app's workflow.
See the CoreDataBooks example, which has sample code for copying a database at first launch.
EDIT: I've created a Core Data framework (read about it here: http://bikepress.org/?p=1120) that includes this feature.
I would just create a database and put add it to my target so that Xcode copies it into the app bundle. At the first launch just copy it from the app bundle to eg. the documents directory or wherever your app expects the database.
There is Core Data Editor at the app store. Alternatively you could build your own simple mac app just for this particular DB and manage it from there. If the amount of default entries is small, then you're better off storing it in a plist or something and loading it into DB after the first launch.
In iOS 5, my app was rejected if I put a database file into resource bundle. So, I have to download the database from internet instead.

Resources