I am working on an IOS 5.0+ project that uses the latest RestKit to download, map and persist core data. I am looking for a definitive answer on Apple's iCloud storage guidelines with RestKit. Do I need to take any extra steps to make sure the data downloaded for use in the app is not automatically backed up to an iCloud account.Do I need to alter the default location for the directories used. Thanks in advance.
If your Core Data store is not saved in an ubiquity container (See: URLForUbiquityContainerIdentifier:) it will never be synced.
Also in the Using iCloud in Conjunction with Core Data section of the documentation they state:
Setting up your Core Data store to handle iCloud requires only a
little extra effort on your part. The steps you must follow depend on
whether you are using a single Core Data store as a central library
for your app or whether you are creating separate stores for
individual documents.
You have to do some explicit changes for synchronization. If you read the documents further, they mention some keys like NSPersistentStoreUbiquitousContentNameKey. If you search for this in the RestKit source, you will not find it - this is because RestKit does not sync with iCloud automatically (and they can not because iCloud is an app level synchronization framework).
Our app was just rejected for storing our database in the Documents folder. The seed file or app content in the database has got 3.3MB. We also store user created content in the database of course. The official statement is: 2.23 Apps must follow the iOS Data Storage Guidelines or they will be rejected
So now we are checking out on Technical Q&A QA1719 to prevent the database from being synced to iCloud.
Related
I want to sync data between iPhone and iPad. I am using core data and save the data in Documents of Document Container. Since Documents is backed up by both iTunes and iCloud. Since iCloud is deprecated in latest version of Xcode. Do I have to do anything else to sync data between these iOS devices?
Backups are not a sync mechanism. For one thing, backups are device specific. Data that gets backed up from someone's iPhone is not available to their iPad. There is no device-to-device data mixing through backups.
Putting the persistent store file in iCloud (via the iCloud file API) is not workable either. You can't just read/write the file in iCloud directly, you need to download the file first and later upload changes. Core Data isn't designed to work in that scenario. You might write code to do it, but the data would become corrupted almost immediately because Core Data isn't expecting you to mess with the persistent store like that.
If you want to sync data between devices, there are many options. Apple offers CloudKit, which is free and supported by Apple. Firebase is popular. Parse servers are still extremely common even though Parse itself is shutting down. Add to that Microsoft Azure and many, many others.
We have finished writing an iPhone App that uses coredata.
In further versions we plan to add an iPad App that is able to display the data collected by the iPhone App (and of corse modify, use it) to give more interaction possibilities to the user.
My question is: Is it possible to move existing coredata (of already installed apps on iphones) to the cloud and read that data out with an iPad application?
If yes: can you point me in the right direction of where to start?
If no: is there another alternative to access coredata created with an iPhone App with an iPad app?
When using Core Data's built in iCloud support it doesn't matter what kind of device you're on, only that the Core Data stack is initialized the same way. Any iOS device or Mac can use the same iCloud store, and data created on one can be read on another.
One crucial detail though: If you already have a data store and you add iCloud support, those pre-existing records do not automatically get migrated to the cloud. iCloud works based on transaction logs, and transaction logs are only created when you save changes. Existing data that doesn't immediately change generates no transactions, and therefore doesn't go to the cloud.
If you have existing data when you add iCloud, you'll need to migrate the data to a new data store to force transactions for those existing records. You can do this fairly easily using NSPersistentStoreCoordinator's migratePersistentStore:toURL:options:withType:error: method. It's not hard, but it's not always obvious that it's necessary.
To get started, I first suggest watching Apple's WWDC videos on iCloud-- especially WWDC 2012's session 227, Using iCloud with Core Data. Next, I suggest extreme caution, because as of today Core Data's iCloud support is still, shall we say, far from being the most reliable of Apple's APIs.
looking to make an iOS app where I can take a picture and then send it to a my own searchable database, website or wiki. What would be the easiest service to do this (I can do the iOS programming its just I don't know about the other side of it).
The easiest option would be to use CoreData. If you don't know about CoreData, Apple has a very comprehensive set of documentation located here: https://developer.apple.com/library/ios/#documentation/DataManagement/Conceptual/iPhoneCoreData01/Introduction/Introduction.html
Using CD, you can save the images as NSData in the persistent store, and then turn them back into images as you fetch them from the store. The most common implementation of CoreData uses SQLite as the backing store.
I am not quite sure how to answer your question without building a db for you. If you are just looking for resources on how to build a db, check out this stackoverflow question
I have an app that uses an SQLite database. With the advent of iCloud on the rise I'm trying to figure out a good architecture for syncing data between devices. So lets say my app runs on an iPhone, an iPad, and a Mac. How can I keep data in my DB up-to-date on all devices?
My first thought was, I can put the database in the cloud and send transactions. But the device may not always been online and the users need their content at anytime, so that wont work. My other thought was to continue using the local db, and then when a connection is made, to send the cached data to the central db. The problem is I have no ideal where to even begin on something like that. How would I know which data has been sent and not sent, which data to actually send when a connection is made, etc.
So this is my question (we don't have to get into iCloud specifics), using an SQLite database and iCloud (or any storage medium), how can I sync data between multiple devices, but still have the most recent data stored locally on the device?
You might want to checkout Couchbase Mobile. This would help with the synchronization you are looking for.
If you have a significant investment into CoreData, then you may want to look at writing your own NSIncrementalStore to support writing data to and from a key value store.
iCloud is only going to be a good solution if your data is sandboxed to a specific user. If you have multiple users that want to view the same data then it won't work.
I'm currently in the middle of developing an iPhone app with a big reference database (using Core Data backed with a pre-populated sqlite database). Once the app is live and deployed to a client's iPhone, I need the facility to update/insert a small amount of data. What are best practices / methods for doing this?
There may be occassions when the frequency of updates will be daily for a month or so. Other occassions when a data update happens once every few months.
What is the recommended way of doing this? Note, I don't anticipate any data model changes for these updates -- this is purely an insert/update of data.
At the moment I'm starting to research the use of push data notifications (q:payload size restrictions?), app store updates (q:code/data model only, not data updates?) and the use of my own ad hoc data server (which the app connects to routinely to check for updates).
Can anyone please provide me any pointers on the above?
Thanks in advance
IIRC Push Notifications have a maximum payload of 256 bytes. Enough for notification purposes, but not more. Your app would still have to download the actual data from your own server after receiving the notification.
Note that the app bundle is not writable on the device. So if your app needs to update the data store, you should copy the pre-populated database file from the app bundle to the app's documents directory on first launch.
App Store updates would certainly be feasible (especially now that Apple seems to have gotten its review process down to a few days at most) but note that an App Store update will always replace the entire app bundle (code and data), so if your pre-populated reference database is big, the customer would have to download it in full every time.