If a user installs an an app which uses iCloud with a UI(Managed)Document, then uses the app, creates data which is saved to iCloud and then deletes the app on his phone, the iCloud data will stay on the device (transaction logs etc.). If the user reinstalls the app it will try to use these old files.
I have the following two problems with that:
The iCloud documents could have changed in the meanwhile and there might be problems when the user has no network connection on the first launch after reinstalling the app.
The iCloud documents for this app could have been deleted by the user (via settings or in Mac OS Finder in the user library). Now, when the user has no network on the first launch after reinstalling the app, the app might think that there is an ubiquity container with data even though it's already deleted (app might crash).
This is not very easy to test but I have definetely crashes and malfunctions for those two issues. E.g. NSMetadataQuery shows me results for documents which do not exist in iCloud because they have been deleted (but they existed on the deletion of the app).
Is there any easy solution to this? I thought about deleting the local iCloud data on the device when the app is launched for the first time - but how can this be done?
It can't be done. If you delete an iCloud document locally, you delete it everywhere-- eventually. The iCloud APIs have no concept of managing local copies independently of the iCloud service, so if you delete one-- even with the network down-- the iCloud ubiquity daemon will send a delete command to the service at the first opportunity.
The closest approximation that current APIs would allow would be:
Check whether the network is reachable
If it's not reachable, do not attempt to access any iCloud documents (because as you note, the information might be stale).
If and when the network comes up, try to open all existing iCloud documents. (On iOS, iCloud updates are only downloaded on demand, so you need to create that demand).
If that's not good enough (and let's face it, it's not good enough), file a bug with Apple and hope for the best.
Related
I worked on app in which user can add images and make notes about those images, which i stored in sqlite and i store cards in document directory. I have enabled file Sharing option in app so user can keep backup of app's data manually in her PC via iTunes.
Please consider this scenario: the user connects the device from time to time to iTunes, and the synch process takes place. however, she does NOT go into the File Sharing option which is one way to backup manually the data in PC. now, she drops the phone in the bathtub and it does not work or due to some other reason she lost her device.
my question: when she gets a new phone, can she recover her data?
if yes, then how could we do this?
if no, then what is the correct way now to backup the third party app data.
My App can work with or without iCloud support.
If a user connects a device to iCloud and then wants to disconnect it, it's pretty easy for me to copy all data back to the local sandbox and stop using iCloud, and this device won't contribute anything new to iCloud anymore. However, changes from other devices will still be received (although not handled) on this device.
Is there a way to completely disconnect the device from iCloud, so that new changes won't be received?
iCloud stores data in a folder called "Mobile Documents." Your app's container resides in this folder. iOS devices know about new files and changes immediately. However, they do not actually download the file until the app specifically requests it. Here's an example scenario:
Someone is running your app on their iPhone and their iPad. They use iCloud on both. However, on their iPhone they disable your app's iCloud but leave their iCloud account active. This means that their device always knows about changes. But since your app never requests those documents, they are never downloaded to the device and therefore do not take up space. Also, iOS will automatically remove the local copy of an iCloud file to free up space if necessary.
For more information, see developer.apple.com/icloud, specifically the videos on how to use iCloud.
You can simply stop responding to the NSNotifications received by your app. You can either unregister your views from these notifications, or ignore them when they're received.
I have an iPhone (iOS) app that keeps data in a local SQLite database on each device. The app is used to manage a virtual bank account for kids to track their allowance, spending, savings, etc. (KidsBank and KidsBank Free). I am getting a lot of requests from parents to provide a sync capability between parents and possibly even their children's iOS devices.
I have considered several options, but all are tedious and non-trivial since this basically requires database replication or a new architecture. Any transaction on any device ideally should appear (sync) to all devices in the family (as immediately as possible).
Ideally, I would like the sync to be automatic & hands off
Options include
(1) Use of iCloud
(2) Use a direct network connection between devices (wifi)
(3) Use of a server side database and web service (JSON/RESTFul)
(1) iCloud
PRO: iCloud provides distributed file sync
CON: iOS 5 required, SQLite database files can not be synced via iCloud, classic database replication (and non-trivial)
Using iCloud is a strong consideration. Devices can write a custom transaction log to an iCloud file where there is one file for each device identified by a unique device ID. Global unique ids (GIDs) and last change timestamps are added to each table. All participating devices will write a unique device ID to a separate file in iCloud. Upon app launch or upon log file change, the app running on a specific device will load all transactions but not those generated on their own device from the files via iCloud. The last participating device to load the transaction will remove the transaction from the file. If the device is not the last participating device, it simply signs off on the transaction and allows the file to sync via iCloud. There may be better algorithms, but the basic idea is the same - using iCloud to push around change logs.
(2) A direct wifi connection will allow two devices to manually sych.
PRO: Not as complicated to manage the sync process
CON: Users must both select to sync from their apps while connected on wifi
(3) Move the entire database or manage transactions on a server.
PRO: Sync is no longer required
CON: Typical issues for a web-driven app. Would need to rewrite the database service layer (currently in SQL) to use a remote web service. Cost of running a server (I would use AWS).
Can anyone offer some experience in syncing SQLite between multiple devices? I'm leaning in the direction of using iCloud to push around transaction logs. I'm trying to minimize cost and complexity.
Moving to iCloud is probably the best solution, as it is proven and made by Apple. You don't need to worry to much about the iOS 5 requirement, as according to most stats over 90% use it. iOS 5 is free to upgrade to. You could then rename your old version as Lite, and continue without syncing.
Syncing is probably one of the hardest things you do.
One solution I made is that all changes to a database leave a log, with timestamp, uniqueid and couple of other things to make sure the transaction is totally anonymous and totally unique. I have made an extremely simple web service that has two operations, you can add transaction to it, so I sync whenever the user is on wifi, so I push all changes, receive a result from the server, then delete the transaction records as they are synced.
The other action is to fetch the records, send the timestamp of last sync, userid and other.
All data is sent using JSON and received as such. It can easily handle tens of thousands of users, running on a small Amazon EC2 server.
This is pretty much how iCloud works, but I made this solution before iCloud. Now I am going to iCloud, but probably need to keep the server running for 1 more year or so, depends on usage.
Hope this helps you.
After finding time to get back to working on the app and also with time passing and Core Data iCloud replication maturing, I converted my app to Core Data (NSSQLiteStoreType) and monitor notifications such as persistentStoreDidImportUbiquitousContentChanges. Using lightweight migrations too. Working well.
My app is going to save a flag in the database (core data) saying whether the user is authenticated or not. How easy or difficult is to someone to access the "core data" database and change the information there without going through the App?
I am going to save a flag there saying "this user is authenticated" so he never has to authenticate again. This is a fun app, not a bank app, so I wonder if that's ok.
Putting in other words: Should I assume that a regular iPhone user (not jailbroken of course) will not be able to mess with the "core data" database and this database can only be accessed through its intended iphone app?
This isn't the kind of thing you should use Core Data for anyway. You should instead use NSUserDefaults or the keychain (depending on if you're just storing that flag, or associated user/password information).
The user defaults are there for storing settings, the keychain for private data. Use the right screwdriver for the right screw.
The iOS app sandbox is quite tight on-device. As such other apps won't be able to access your database, nor will the user on-device.
Application data in the app's Documents directory is backed up through iTunes, however. Though I've never tried such a thing, I can imagine a scenario where the user installs and runs your app but is not authenticated. He syncs and the user data is written to his computer. He opens the backed-up resource on his PC (iTunes does encrypt or obfuscate it) and figures out how to change the sqlite database or plist to show himself as authenticated. He then uninstalls the app on his device, then reinstalls it through iTunes, authenticating himself.
If the scenario is possible, you could potentially store the database in the cache directory instead, a directory that's not backed up when the device is synced with iTunes. It means the database would vanish if the user had to restore his device, but that might be an acceptable loss in your scenario, I don't know.
Edit
I agree with jer that the database isn't the best place to store such info, and if you're targeting iOS 3.2 and above, keychain is definitely the better place.
I don't believe a user on a non jailbroken phone would be able to mess with the data.
When does data get restored for an app? What if I save data in the app's document directory. Then they sync with iTunes. Now iTunes has a backup. Will that data be populated to another device when they sync that new device to their iTunes or will they just get a clean install of my app? I'm trying to figure out how to keep track of a subscription in app purchase and was wondering if I could keep record in NSUserDefaults or some other local store.
Backups are per-device. So a backup of your iPod will not be restored to your iPhone. In other words, there is no sync.
Many times iTunes fails to create complete backup of all the iPhone data say it be contacts, message, mails etc. This type of problem may occur due to not installing iTunes properly. So, you should check whether iTunes have been installed correctly or not. In case there is no problem with iTunes then it is possible that you are trying to create backup of the files which can not be backed with the help of iTunes. To overcome with this issue you need to make use of iPhone backup application. By using this tool you will be able to prepare backup of all the files within minutes safely.
If the user backs up to iTunes, and then restores their backup to another device (maybe they lost their original iPhone), the contents of the app Documents directory will be put on the new device. Anything in the tmp folder won't be backed up or restored like this, but the Documents folder will.
However, that's not the best way to store the in-app purchase information. You should be storing that on your own server and keeping a count of the number of times the purchased content has been used. Inform the user that they can use it a certain number of times (say three) and after that they will have to buy it again. I'm not exactly sure of any details beyond that (like how to verify their identity) but it should get you started.