I just learned the basics of integrating SQLite3 into an iPhone app, but I still don't really know where or when to use it. Is the SQLite database just locally created on the device or will every app have its own database? If I for example want an app where the user can upload a recipe to the database, will other devices be able to fetch that recipe from the database or do I need something else to make that such of app? Sorry for the noob question but I can't find an answer..
An SQLite database, in iOS, is stored locally. That means that every iOS device has his own independent SQLite database.
Usually, in the case of the recipe you mencioned, you need a backend to sync information with other devices. You can update your SQLite database or just browse the information without a SQLite database behind.
Aditionally, in iOS you have one tool under your belt that it can be used to persist information locally : Core Data. There are some tools that can be used to sync core data information with a server like Parse.
Your app will have its own sqlite database. Your app can have 100 sqlite databases if it wants. It's just a file like any other file your app works with. It will be specific to your app in your app's sandbox. It will not be shared across devices. Just like any other file.
A SQLite database is just a file that you would put in your app's directory, and iOS apps are sandboxed so that one app can't read the files of another app.
If you need to share data from your app, you can have your app implement a URL prefix, and you read the data in your app, but share it using the system defined mechanism. Have a look here, here, and here for more guidance on the subject.
Related
I want to keep an apps documents directory that contains sqlite using core data files in sync across users' devices. The sqlite files are the only files in the apps documents directory and simply need to be common to all users' devices
I've tried zipping up the sqlite files to send by email, which works with iTunes file sharing but is not suitable for my needs as it can expose the files to other users' devices.
I've tried using app groups to keep the directory common across devices http://blog.sam-oakley.co.uk/post/92323630293/sharing-core-data-between-app-and-extension-in-ios,
and
Accessing Core Data SQL Database in iOS 8 Extension (Sharing Data Between App and Widget Extension) but that simply did not share the directory across devices for me.
I've sent the file to parse, but pulling them down and reconfiguring the data was the problem there.
I've tried using iCloud and even the Apple engineer gave up on that one.
What I'm after is the simplicity of file sharing through iTunes (being able to replace the sqlite files) with a bit more finesse and without the need to plug in the device.
Some considerations
The whole model can be synced in one go
Data does not need constant syncing facilities, a manual sync option would suffice.
I am familiar with iCloud syncing, but I am new to app groups. There may be a simple answer to this question, but I haven't found it yet. Basically, I have an app in which I have iCloud integration, and now I want to try to add a today extension. I am currently using Core Data as a backend and would like to continue to do so. However, from what I have read, I need to move my data store to a shared location by defining an "App Group". (http://blog.sam-oakley.co.uk/post/92323630293/sharing-core-data-between-app-and-extension-in-ios-8 and Accessing Core Data SQL Database in iOS 8 Extension (Sharing Data Between App and Widget Extension)) I haven't been able to find out if this location is synced using iCloud or not. Or, because I"m using iCloud, do I need an App Group at all? I appreciate any and all help/suggestions.
If you're already using iCloud, you don't need to use app groups, because your extension can access the same iCloud container as your app does. As long as your entitlements and provisioning are configured correctly, you can literally just use the same Core Data stack setup in the extension as in the app.
Apple's Lister demo project does this, but there's nothing special about it. Just use iCloud as usual.
App groups are usually necessary to share data between apps and extensions. But a big exception is when the data is already stored external to the app-- as with iCloud.
I'm developing an iOS app that has to support iOS 5+. I've read the iOS Data Storage Guidelines in order to prepare the app for the submission and read several questions and solutions about those guidelines here in Stackoverflow, but I still have some doubts about how I should handle this.
I have an sqlite database whose tables are defined in an .sqlite file. I copy this file into \Documents folder when app starts, and I keep such file always there in \Documents. This database firstly contains some collections of fixed data that app may need (lists of cities to select and things like that), and the rest is user-dependent data that will be downloaded. I've read this post: Apps must follow the iOS Data Storage Guidelines or they will be rejected in app that contains .sqlite3, but I still don't know what criteria should I apply. The .sqlite is not downloadable, it is included in Supported Files of the Xcode project, and some of the initial data is inserted from inside the app and it is neither downloadable. The user-dependent data, well, I can download it whenever I need. I've not integrated any iCloud stuff in my app. So, should it be correct to keep the .sqlite file always in Documents? AFAIK, you need the file to be there for performing all database operations...
As I said, I've not included any iCloud related code in my app, and in fact I don´t know how iCloud is managed because I've never told to do it, are backups of the app made anyway? Should I use the flags the iOS Data Storage Guidelines says in order to prevent files to be backuped? I need some guidence regarding backups and iCloud considerations.
And there is another thing: my app also downloads some user-dependent images. I show them in several views throughout the app, so I need them to persist while the normal working of the app. However, it is downloadable content. So, where should I place them?
Thanks a lot!
I believe your .sqlite file should be in Documents, this is the correct place for it.
You downloaded images should probably be in Caches, but you could also get away with them in documents as long as you set the "do not backup" attribute.
You can set the skip backup attribute like this:
BOOL success = [url setResourceValue: [NSNumber numberWithBool: skip]
forKey: NSURLIsExcludedFromBackupKey error: &error];
I am creating a quiz style app for iOS using phonegap. The app allows users to create then take the quizzes.
Currently I am using a HTML 5 database using phonegap APIs to store the test and results data. I am concerned though that the database can now be deleted by iOS 5.1 when the device storage gets full.
Is there anyway to mark the webkit cache folder where the database is stored so that it is never deleted? If this is not possible are there any suggestions for another way to store data that will always be persistent.
Yes, it's a pity that Apple did that in iOS5.1
It's possible to change the location of WebKit data calling a private API. You should be able to set the location to a secure folder like Documents. I did not test this solution yet, but look at this post : How do I enable Local Storage in my WebKit-based application?
Phonegap team is also working on that problem: https://issues.apache.org/jira/browse/CB-330
Antoher way is to use SQLite (same as WebSQL) with a phonegap plugin. That plugin save the database in the Document folder, that mean that the DB is not deleted and is saved by iCloud.
Here is the Native SQLite phonegap plugin : https://github.com/davibe/Phonegap-SQLitePlugin
Regarding this plugin, it's a little but slower than WebSQL in some case, and there are some differences between the WebSQL API, but here is an adaptor:
https://gist.github.com/2009518
You should also migrate the old WebSQL db file (stored in Library/WebKit or Caches directory) to the Document folder. Here is a code to do that :
https://gist.github.com/2009491
And if the data are important, you should save it to a server. I wrote a small lib to synchronize the SQlite DB to a server :
https://github.com/orbitaloop/WebSqlSync
There is a fix for both issues with Webkit storage and iOS 5.1
Storage moved from /Webkit to /Cache
Storage is not adjusted to updated folder structure on an App update under iOS 5.1 (WebKit Bug)
https://issues.apache.org/jira/browse/CB-330
This solution seems to be more safe than just changing the location of Webkit data calling a private API. While the App is running the Webkit storage locations are used. On resuming or terminating all data is backuped to the documents folder. Timestamps ensure that ab old backup cannot overwrite newer storage data (if the app crashes...).
The best: Users that are on an older iOS Version using an App with that fix in it, will not suffer damage lost in case of any iOS updates. Thats why one should not wait...
Instead of using an html5 database, I would send/receive the data via ajax (on a remote server, with php and mysql), preferably encrypted (and base64_encoded).
I'm going to need to update my iPhone app on the app store at some point.
I’m using secure storage functions (s3eSecureStoragePut) for save data that creates an appdata.i3d file.
When I update the app I want to preserve the players save data, how can I ensure this done?
s3eSecureStorage is a bit misleading, it is not secure and this is a historical name related to the Brew and Symbian platforms. Essentially all this is doing is writing to a file so it will be preserved on app updates assuming you don't write over it.