My app uses iCloud (key-value store) to sync an unique id between multiple devices. This works accept at the point were it really has to work, at the first launch of the app. It looks like the device isn't yet familiar with the values from iCloud at first launch, only after the app is installed and has been running for a while.
I check for the iCloud value in the viewDidLoad function on main view of the app.
So, my questions:
Is this the expected behavior?
If yes, is there another solution?
Could it be the case this is only a problem when running from Xcode, not the shipping version? If so, how to test?
Thanks!
Jasper
I had a similar issue where the NSUbiquitousKeyValueStoreDidChangeExternallyNotification wasn't triggering on the first launch after install, no matter how long I waited. Setting an initial key in the NSUBiquitousKeyValueStore seemed to solve this.
Immediately after adding the observer to the default store, I call:
[[NSUbiquitousKeyValueStore defaultStore] setString:#"testValue" forKey:#"testKey"];
[[NSUbiquitousKeyValueStore defaultStore] synchronize];
I use different keys (i.e. not testKey) for the actual data I want to sync.
When you first run an iCloud enabled App it has to pull all the data from Apple servers. The time it takes to do so depends on many things like what kind of network you're currently on (Edge, 3G, GPRS, WLAN). It also depends on how much traffic the iCloud server currently has to handle so the request to the iCloud server may take a few more seconds, no matter what type of network connectivity you have.
To sum it up: Yes, it sounds absolutely normal.
If running your App depends on those settings consider implementing a "Wait" or "Loading" view that stays on the screen as long as it takes for the App to perform a initial synch and load all needed data from the cloud. To not block the UI forever also implement a timeout for this view (if iCloud data not loaded within X seconds, dismiss the view and notify user).
You have no guarantee NSUbiquitousKeyValueStore would have finished its first synchronization as your app is launched for the first time. (In fact, on iOS 5, it's often starting to sync as you launch your app for the first time).
There is no way to know if the first initial sync has already happened, is ongoing or has finished. You can (in fact should) subscribe to NSUbiquitousKeyValueStoreDidChangeExternallyNotification. The trick is that if your store is empty on the iCloud server, you won't get any notification after the initial sync (since your local store is empty and the cloud store is empty as well, nothing really changed "externally" after the initial sync…)
Normally, you should not rely on the initial sync being done.
Be optimist at launch, even if your store is empty, push your values (e.g. your unique id) right away. If the initial sync happens concurrently or after and there is already some value on the server, your local values will be reset to the server values and you will get the NSUbiquitousKeyValueStoreDidChangeExternallyNotification notification with the NSUbiquitousKeyValueStoreInitialSyncChange reason.
Finally, if you really think knowing about the initial sync being completed or not, please file a bug to bugreport.apple.com and explain why you really need that.
Related
My question somewhat similar to How to have multiple apps - one Core Data?. But I am not unable to replicate as suggested in the answer.
I have two applications. One applications (1st App) allows user to do all sort of things and save in coredata.
Other application (2nd App) is a service application. Here I want the service to get notified everytime the coredata is updated(any changes like create, delete, update done).
If I use following notification in 2nd App, this notification does not get fired:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(modelUpdated)
name:NSManagedObjectContextDidSaveNotification
object:nil];
If I had an UI based application or even a background application in that case I can use NSDistributedNotification.
But I want something better than distributed notifications.
Please give me some hints so that I can move ahead.
NOTE: This app is not going through AppStore, so Sandboxing doesn't come under consideration.
If you are going to distribute your app yourself, you can do almost anything you want.
You can certainly attach a PSC in each application to the same SQLite file. No problem there.
As for knowing when the file has been modified, you can use kqueue or dispatch_source to monitor when the file has changed. However, just knowing that it has changed does not tell you what has changed, meaning your watcher process will need to refetch to get its MOC updated.
If this is sufficient, then it is probably the easiest route to take.
If you need more granular notification, then there is no getting around having to notify any interested parties what specifically has changed in the store. You can roll your own, use XPC, or simply use NSDistributedNotification (remember the latter is neither safe, nor guaranteed).
What you should do is observe NSManagedObjectContextDidSaveNotification on any MOC that is directly attached to the PSC. In that handler, you will create a notification similar to the one you received. Except, you should merely send sets of object IDs in URI representation.
Now, your observers can get detailed information about what objects were inserted, updated, and deleted.
Again, if you don't want to go through all this, you can use traditional OS mechanisms to observe that the file changed, and just refetch. If you choose this route, one thing you can do to help... Keep a "last modified" date for each object, and index on that attribute. Then, you can at least query objects that have changed since the last time you loaded the database. There are a number of other options to use here... the basic idea is that if you monitor via the OS, you only get told that something changed... you have to figure out what... if that matters.
For sandboxed apps, one of the few solutions available is to share data via an XPC launched daemon.
EDIT
distributedNotification I don't want to use, actually this wont work
for a deomon/service app. And your other point MOCDidSaveNoti is not
observed at all. I tried both before posting this question. – Anoop
Vaidya
Of course NSManagedObjectContextDidSaveNotification will not tell you what has changed in another process. It has no idea what changed, and has no idea about MOCs in other processes. I am sorry I wrote so poorly to make you think it would.
That notification is to be observed in any MOC that is changing the data store, for the sole purpose of propagating that information to other processes. The notification handler should then send a remote notification (however you want to do it... SHM, pipe, message queue, XPC, smoke signal, etc), with the object IDs of all the objects that have changed.
Any process that wants to know about the changed data store will then need to watch for the remote notification (however you choose to send it).
It really does not matter what you want to do... you are limited by what's available.
You have two basic choices:
observe a general change notification that the store has changed (kqueue, dispatch_source, etc). However, all you know is that the store changed, meaning that you will have to perform a complete refetch.
Send a remote notification whenever the store is saved, passing the object IDs of what has changed, and have other processes watch for that remote notification and update their MOC accordingly.
When we deactivate a WP app, it can be tombstoned and terminated later by the OS. I need to save some unsaved app data to a persistent storage when the process is terminated, but not before this. Obviously, the Deactivated event cannot be used for this purpose as it is raised immediately when an app is moved to the background; the Close event is also not the event we need as it si not raised when the app process is terminated by the OS. Is there a special Windows Phone app event for that, something like Application_Terminated?
The problem is that the operating system only tombstones your app when it is under severe resource pressure. At the time it is not practical to wake up the app and run app code because it might risk whatever is currently in the foreground. This limitation exists on all modern mobile operating systems (Android, IOS included). This is just the cost of operating in a battery/resource friendly environment.
Having said that, it sounds like your backing store does not disambiguate between data the user "saved" and data that is just being cached until the user can finish the transaction. It would be useful to build the idea in. Think of it the way some of the smarter web sites on the internet now work. You can navigate away while you were in the middle of entering data and when you come back the site presents you with the partially filled form. The site understands that you weren't "done" but it respects the fact that you had provided some of the information you'd need to get "done".
What I'm saying here is that the problem is easily fixed by understanding and accommodating the way your users are likely to use the app. Thinking of your app like a web site (at least in this context) helps out things into perspective. Sorry about the longish answer. I hope it helps :)
There is no such event. You should save your state on Deactivated so that if the application is removed from memory (tombstoned) you can set yourself up again upon reactivation. If your problem is figuring out whether or not you need to restore state on Activated, check out the ActivatedEventArgs.IsApplicationInstancePreserved flag (http://msdn.microsoft.com/en-us/library/windowsphone/develop/microsoft.phone.shell.activatedeventargs.isapplicationinstancepreserved(v=vs.105).aspx). This flag tells you whether your app was tombstoned. If it wasn't, you can throw away the old state or overwrite it the next time you are deactivated.
In my app, I need to share a setting between different devices running the app. I want the first device that install the app to set the master value of the setting, then all other devices should get that setting and not overwrite it.
How do I make sure I first check if iCloud has a value before setting the value? So I don't overwrite an existing one.
Should I wait for NSUbiquitousKeyValueStoreInitialSyncChange event to be sent, and then I can check for an eventual existing value and otherwise set it for the first time? If yes, can I rely on receiving the NSUbiquitousKeyValueStoreInitialSyncChange event? If not, then it might turn out that it don't set the iCloud value at all with this approach.
If I try to set a value before NSUbiquitousKeyValueStoreInitialSyncChange is triggered for the first time, will it be discarded and then the NSUbiquitousKeyValueStoreInitialSyncChange will be triggered with the existing data in the store?
I've heard NSUbiquitousKeyValueStoreInitialSyncChange is not triggered if there is no values in the store when it synces the first time?
I have read the Apple documentation about this and seen answers here on Stack Overflow, but don't understood how to do exactly this.
How can I make sure I don't overwrite an existing value the first time I launch/install the app?
There is no way for you to surely know you have effectively synchronized with the distant store at least once and you should not count on it (imagine there is no iCloud account set up, or no connectivity or iCloud servers are down, etc.: you don't want your user to wait for you to be sure you are in sync with the cloud as it can take forever or even never happen).
What you should do:
when you start, check the store to see if there is a value.
If there is no value, just push your own value.
If the initial sync with the server did not happen yet and there is, in fact, a value in the cloud, this will be considered a conflict by the NSUbiquitousKeyValueStore. In this precise case (initial sync), the automatic policy is to revert your local value and prefer the one in the cloud instead. So your application will be notified by the NSUbiquitousKeyValueStoreDidChangeExternallyNotification of this revert with the NSUbiquitousKeyValueStoreInitialSyncChange reason.
If there was in fact no value in the cloud, your local value will be pushed and everyone will be happy.
I have created a web-service app and i want to populate my view controllers according to the response i fetch(via GET) in main thread. But i want to create a scheduled timer which will go and control my server, if there becomes any difference(let's say if the count of an array has changed) i will create a local notification. As far as i read from here and some google results, i cant run my app in background more then ten minutes expect from some special situations(Audio, Vo-IP, GPS).. But i need to control the server at least one per minute.. Can anyone offer some idea-or link please?
EDIT
I will not sell the app in store, just for a local area network. Let's say, from the server i will send some text messages to the users and if a new message comes, the count of messages array will increment, in this situation i will create a notification. I need to keep this 'controlling' routing alive forever, whether in foreground or background. Does GCD give such a solution do anyone have any idea?
Just simply play a mute audio file in loop in the background, OR, ping the user's location in the background. Yes, that will drain the battery a bit, but it's a simple hack for in-home applications. Just remember to enable the background types in your Info.plist!
Note: "[...] I fetch (via GET) in main thread." This is not a good approach. You should never fetch any network resources on the main thread. Why? Because your GUI, which is maintained by the main thread, will become unresponsive whenever a fetch isn't instantaneous. Any lag spike on the network results in a less than desirable user experience.
Answer: Aside from the listed special situations, you can't run background apps. The way I see it:
Don't put the app in the background. (crappy solution)
Try putting another "entity" between the app and the "server". I don't know why you "need to control the server at least one per minute" but perhaps you can delegate this "control" to another process outside the device?
.
iOS app -> some form of proxy server -> server which requires
"babysitting" every minute.
When my application loads, using the didFinishLaunchingWithOptionsi parse data from the internet to nsarrays. My question is, when the user exists the application by using the 'home' button, and then loads the application again how can the data be re-loaded? (because if the data does not reload - if there are any updates on websites, the new updates will not be seen).
Add an applicationWillEnterForeground method to your app delegate. Load the data there, or start a thread to load it if you like.
You should probably also periodically check for new data even while the app remains open, because the user could go idle for a long time.
As an aside, you shouldn't do anything which might block in applicationDidFinishLaunchingWithOptions. If you are using synchronous NSURLConnection APIs there is a danger the OS might kill your app for taking too long to launch. Best to either use the asynchronous/NSURLConnectionDelegate APIs or do the networking on a background thread and call back to the main thread when you need to update UI (UIKit does NOT like being called from background threads, as it is not thread safe. It might appear to work sometimes, but it will come back to bite you sooner or later).