I have developed a custom ios framework for achieving some task, which is working perfectly but I have to add my sqlite database separately in my test app. I want to bind my sqlite database with my custom framework so that it will automatically added in any app where user want to user that framework.
I also don't want to show sqlite database to anyone. can anyone please tell me the best way to achieve this.
I believe you're looking to ship a sqlite database with your app, and have it installed invisibly to the user. Just add the database to your NSBundle, by including it in the application. The important part is that you must copy this bundled database to the file system (you probably want to also mark it as not being in the cloud), because the NSBundle'd files are read-only. So, here's your strategy: 1) on startup, check to see if the database is in the file system. 2) if not, copy it from the NSBundle to the file system, 3) open the database in the file system.
Maybe there is a better solution to your question but here is a suggestion on what you could: Programmatically create the database in your framework. As for hiding the database here is the solution to that! You may also encrypt the sqlite file.
Cheers
Related
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.
I am updating an old iOS app which used sqlite database. I changed the database structure adding columns to existing tables. Now, I am testing it on my device. If I clear my old app from iPad and then run this new updated version on it, it is working fine. But if I have the old version installed on ipad already and test this updated version, it is somehow using the old database instead of the one updated. Can some one help me why it is doing this?
My guess and to try and make a simple answer for you is this. It's likely you updated the database in the project file - which means when you run it, your new db will exist in the bundle. files in the bundle cannot be updated, so its common practice to copy the database out of the bundle and store it somewhere in the ios sandbox. I usually use the documents directory to keep it simple.
Most likely what is happening is that when you run it over a pervious install, it see's that the file is already copied over to the device so it does not touch it, however on new installs, it probably sees the database is missing so it copies it there and that is why on new installs it works fine but existing ones it does not.
Look in the app delegate or your root view controller for code that checks for the existing database and copies the database over if needed on startup.
If you need to update the database on existing installs, you would need to force the copy.
Beware though if you have data in the existing database not to overwrite it if its important. If important data is stored there, you have to either do a little shell game of getting the data and importing into the new database, or maybe a simpler way, is to run the database schema modification commands on the existing database so it is the same.
again, beware and make a copy of the local database file before you run those commands, just in case.
best of luck
In iOS, a SQLLite database is really just a file. When you used the old app, it created the schema in the database file. When you load the new app, the data remains, untouched. If you want to use the new schema, you will have to detect the old schema and update the existing data. I believe that there are documented ways to deal with this. Bryanmac's question reference seems to be a good place to start.
When you install a new version of your app, iOS actually installs it in a new directory and then copies the contents of the documents folder from the older version to the one in the newer version. If you want to just use your new db, the best way is to have this db renamed or stored in a different directory inside your app's document store.
Here's a relevant article on updating An sqlite CoreData backing store on iOS:
http://www.musicalgeometry.com/?p=1736
I am creating a database application using the SQLite3 library.
I have created a database file using each of the file extensions: .db, .sqlite, and .sql.
All are working fine for me, but my question is which extension should I use in general?
Is there any difference between these file extentions?
The Sqlite documentation seems to use the '.db' extension consistently, but I've seen plenty of Sqlite files that use '.sqlite' instead. Use whatever is meaningful to you. For example, if you're using Core Data to create the database, you might use '.cd' or .'coredata' to remind yourself not to modify the database outside of Core Data. Unless you're planning to transfer the file to some other machine (and really, even then) it won't matter.
The database will live in your application's sandbox, so users will never have to know about the filename or the extension, and other applications typically won't ever see it either. Just give it a distinct name so you can tell it apart from other files that your app might be saving to the same location.
This is the first time I'm developing for iOS. I need my app to ship with a pre-filled sqlite database which a user will read from and write to. How should I go about deploying this? Can experienced developers help me?
What I thought was this:
I create and pre-fill the database in my development machine, add it to my app bundle. During app initialization in device, I check if I have a database in NSDocumentDirectory of my app. If not, I copy the database in the bundle to NSDocumentDirecory and read from/write into it. If I have a db there, I just use it.
Is this a bad idea? Any pitfalls I'm falling in here?
I have an app that does something pretty similar to that. Mine doesn't allow writing to the database, but I don't see why it would be hard.
I have a dataset that I import into a SQLite database, copy it into the apps directory, put the DB filename into a constant and it seems to work really well.
I change the SQLite filename each time I put it in there (MyDB62020111.sqlite -> MyDB62020112.sqlite) just to make sure that I avoid a problem where it thinks that the file is already in the NSDocumentDirectory and not update it.
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.