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.
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.
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.
I'm testing a library-based iPhone app with iCloud enabled. With such app, changes to the core data persistent store are propagated across multiple devices.
What interests me is: Do iCloud "documents and data" changes are propagated across devices when the app that needs to be updated is closed?
Scenario: Device A makes changes, Device B's app is closed. Once the user restarts device B some time later, the changes are already present.
or
Does the app have to be open on additional devices to request data model updates?
Scenario: Device A makes changes to iCloud based core data stack. Device B's app comes online, checks if there are changes, requests changes to be downloaded.
Thank you for the clarification!
The former option is closer to the reality, but neither of your options describes the situation correctly.
The point is, if you use CoreData with the iCloud, the update will come whenever
your app is running
and the OS decides it's the right time to tell the app.
Your app then passively respond to what the OS tells you, as in any event-driven app development. Read Apple's documentation and/or related WWDC slides available again on Apple's developer website.
Also, Drew McCormack has a series of great blog posts on this topic, called "Under the sheets with iCloud and CoreData", starting here.
Switching to custom generated device UUID's is turning out to truly be a nightmare! I am hoping someone has come across this before and might know a way to deal with it.
Assume a user has an application with a data set of 500,000 (small) records, its not feasible to simply copy the entire db of a device and merge them. A user has this application installed on an:
iPhone,
MacBook
Android tablet.
When connected to the same physical network, each device can see each other and can initiate a synchronisation.
To achieve three way data synchronisation (that does not depend on a central server or an internet connection).
Each device keeps a list of timestamped changes.
Each device knows the last time it synchronised with each of the other two devices.
When a device sees another device, it sends through all known changes since the last time they spoke to that device.
If a new device is discovered, no problem just send through all data ever entered.
The problem comes along if a user backs up their iphone or ipad, and restores it onto another iphone or ipad. Under this scenario we are ending up with a user that has two devices on the local network with the same UUID. Updates end up (randomly) going to one or the other identically identified devices.
I know we can continue to use the device unique identifier for now, but I am worried whats going to happen once its gone!
On application start you search for a file in the applications documents folder called udid.txt. If this file is not available create it and generate your custom UDID, save it to this file. Use the following function to add a flag to this file, to exclude it from the backup and sync routines.
#include <sys/xattr.h>
- (void) AddSkipBackupAttributeToFile: (NSURL*) url
{
u_int8_t b = 1;
setxattr([[url path] fileSystemRepresentation], "com.apple.MobileBackup", &b, 1, 0, 0);
}
The problem with this solution is that a user might use iPhoneExplorer or something similar to change the UDID. Try to encrypt or hide the file to prevent him from doing this.
Note: Works only since iOS 5.0.1.
You can instead store your generated device UDID in a file in the Caches directory, where it will not be backed up. When a backup is restored onto a new device, the database will be present but there will be no UDID file. In this case create a new UDID; the other instances will see this as a new instance and can push any recent changes across. You might want to change the logic so the other instances will query the timestamp on a new UDID instead of assuming the new instance is totally empty.
Before iOS 5.0, your UDID file will not be automatically deleted by the system. However in iOS 5.0 you will need to put up with the fact that it may get purged in low disk space situations. If that happens, just follow the same procedure as when restored onto a new device: create a new UDID; the other instances will see this as a new instance and push recent changes across.
As Floix said, there is a new mechanism in iOS 5.0.1 (yet to be released) which will let you specify that the file should be neither backed up nor purged.
Everytime I get a call my old wallpaper shows even though I have a new one. I'm trying to find it on my iOS but I cannot seem to figure out where. So I'm trying to track down what folders gets backed up when i backup my iPhone since I have restored it and it's still there.
(I'm using a jailbroken device)
I know this isn't the actual folder names and etc but it will give you an idea what it's backing up though. Good Luck.
With iOS 1.1 and later
Safari bookmarks, cookies, history,
and currently open pages
Map bookmarks, recent searches, and
the current location displayed in
Maps
Application settings, preferences,
and data
Address Book and Address Book
favorites
Calendar accounts
Wallpapers
Notes
Call history
Mail accounts
YouTube bookmarks
SMS messages
Saved suggestion corrections (these
are saved automatically as you reject
suggested corrections)
Camera Roll (photos and screenshots
taken by the iPhone)
Voicemail token (This is not the
Voicemail password, but is used for
validation when connecting. This is
only restored to a phone with the
same phone number on the SIM card.)
Web clips
Network settings (saved Wi-Fi
hotspots, VPN settings, network
preferences)
Paired Bluetooth devices (which can
only be used if restored to the same
phone that created the backup)
Keychain (this includes email account
passwords, Wi-Fi passwords, and
passwords you enter into websites and
some other applications. The keychain
can only be restored from backup to
the same iPhone or iPod touch. If you
are restoring to a new device, you
will need to fill in these passwords
again.)
With iOS 2.0 and later (in addition to the above)
Managed Configurations/Profiles
List of External Sync Sources (Mobile Me, Exchange ActiveSync)
Microsoft Exchange account configurations
Nike + iPod saved workouts and settings
App Store application data (except the application itself, its tmp and caches folder).
With iOS 3.0 and later (in addition to the above)
Videos in Camera Roll
Per app preferences allowing use of location services
Offline web application cache/database
Voice Memos
Autofill for webpages
Trusted hosts having certificates that cannot be verified
Websites approved to get the location of the device
In-app purchases
New with iOS 3.1: Videos in the Camera Roll that are 2 GB or larger are not backed up (iOS 4 and later will back up videos 2 GB and larger)
All user documents and settings get backed up, Application settings as well as system settings.
Applications each have a Documents folder that user data can be saved to, so thats pretty much what gets backed up for applications, including app preferences.
These are the Wallpaper locations:
/private/var/mobile/Library/SpringBoard/HomeBackground.jpg
/private/var/mobile/Library/SpringBoard/HomeBackgroundPortrait.jpg
/private/var/mobile/Library/SpringBoard/LockBackground.jpg
/private/var/mobile/Library/SpringBoard/LockBackgroundPortrait.jpg
I have manually managed to find out what gets backed up and managed to solve the problem :)
I downloaded the trial of iphone packup extractor http://www.iphonebackupextractor.com/ and found what I was looking for.
Also it seems like I just had to change the lockscreen in the iPhone since the file called LockScreen.jpg was the picture I was looking for but since I had another lockscreen using winterboard I didnt think of this.
Good luck to anyone else who has problems similar to this.