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.
Related
My iOS app uses CoreData and some tables need to be filled with default values every first time the app is opened since CoreData device-dependent.
So I am using NSUserDefaults to check whether it is first time open. If it is first time, I fill tables (on CoreData) with the values which I have already created and formatted lines from the txt file by reading line by line and separating in a way.
And my question is, is it safe and fastest way to use txt file for such operation?
A better option would be to keep a "canned" sqlite file in your app bundle and check for the existence of the SQLite file in your documents directory. If the file does not exist, copy the canned data from the app bundle to your documents directory.
That will skip the entire parsing logic and will allow your application to launch faster.
Marcus' approach is also what I would recommend. But you can still keep using your parsing code during development in order to have a convenient way to create the seed SQLite file. When you ship your app, package the newest seed store as a bundle resource and disable / delete your parsing code.
I got an app I'm working on that uses static data from a sqlite database to do various things, While I only need read only access to the database, depending on the episode they pick from the first screen I want it to use a different database file and I want the list of available episodes to be updateable on the fly. and I got help to get the list of available episodes updated, and the proper content downloaded and stored in separate folders, So I know I could when the episode is selected delete the sql file in the documents folder and copy in the new one each time and that would work well enough for what I'm trying to do. but it seems like a bit much extra work to have to check for file, delete file, copy in new one. then open it from there each time the user wants to pick a different episode. and I don't want to put all the sql files together as that will be a bigger hassle then the first route especially if this app stays around long enough to have a long list of episodes.
so my question here is: can I get at least read-only access to an sql file that I've downloaded (or one in the bundle for testing) with out having to first copy it to the documents? and if so how would i open the file?
Can I get at least read-only access to an SQL file that I've downloaded (or one in the bundle for testing) without having to first copy it to the documents directory?
Yes. Files in the app bundle are readable (if they weren't, there would be no point in storing files in the bundle).
And if so, how would I open the file?
It's not clear what you're asking here - if you want to perform SQL queries on the file, you should use the sqlite3 library which is available on 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.
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.
I need to store some data files for my blackberry app. These are usually small png files that I download and store locally for performance reasons. Also I need to store an xml file locally.
My question is where are these files supposed to be saved on a blackberry? Is there such a thing as an application's home folder or settings folder in the blackberry filesystem?
What would be the path to such a folder?
This is for blackberry os 4.7 or later.
Thanks!
If it's not a huge amount of data (and by the sounds of it, it's not), take a look at the PersistentStore mechanism. You can store many types of data including native types (String, Integer, etc.) and even byte[] data (for images) using PersistentContent. The nice thing about PersistentStore is that it doesn't require any sort of filesystem access -- it doesn't leave files hanging around -- and if you include a custom class in the persistent store for your app (even a simple subclass of an existing persistible class such as Hashtable), it will automatically delete your persisted data if the app is deleted.
There's no official home folder for your application. In blackberry you can basically read/write just about anything/anywhere (well, you might get a SecurityException/IOException if you'll try do change some files).
You can write to the SDCard/Internal memory using the paths described here.
If you're worried about someone seeing and altering your data there's not much you can do except setting your files and directories as hidden using FileConnection.setHidden(true) but this is very lame since they can still be seen even from the native BlackBerry file browser if the user chooses to show hidden files from the menu.
Edit: You could of course encrypt/decrypt your data but this won't prevent someone from deleting it.