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.
Related
I am working on a Win8-UI-App (previously called Metro...) and trying to implement Periodic (Documentation for different methods) Tile Updates (Live Tiles) for the first time.
I found a couple of very good resources on the internet and was able to do it. Unfortunately the question of where I should register for the notifications remained unsolved:
Do I have to register for Notifications every time the app starts (e.g. in the App.xaml.cs OnLaunched() Method)? - Or is there an other, more professional way to do so? (I could imagine to save if I already registered for the service or is there a variable I can access to see whether notifications are registered?)
thank you!
PS: For everyone who is also new to this see this StackOverflow post, this example, the tile template types and the Dev Center for quick starting :)
Periodic updates will continue until they are explicitly stopped or your app is uninstalled. Technically, you only have to do that once. But, the Guidelines and checklist for periodic updates states
Call the StartPeriodicUpdate or StartPeriodicUpdateBatch method each
time your app is launched or brought into focus. This ensures that the
tile content will be updated each time the user launches or switches
to the app.
According to that, App launch and App resume are good candidates for a call to StartPeriodicUpdate.
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.
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.
I have a Web-Service application, i need to send scheduled GET methods to my server and if a change has happened with my incoming data i have to inform my user about the changes. When my app is in the foreground(in min thread) i fetch some data and pıpulate my tableview, my problem is, i can't realize how to create a scheduled method to the same data source(mean server) and if a new thing has been added, either my app is on bacground or not, inform user(alert) about the changes. Can anyone please share any idea-link.. Thanks in advance
This is exactly what push notifications were designed for, and are, technically the best way to solve the problem.
It does mean the task of 'checking' for new data is shifted to your server but the user is better suited as a push notification will happen, even if your app is not running.
I recommend using a system like Urban Airship.
I am building one application on Mac OS X (10.6). In this application, I have one screen where user will provide input and that will be saved as a plist in local folder. This plist file needs to be trasferred to server using HTTP POST service. There should be check for server connectivity and if connections fails the files will be saved in local folder. With certain time duration, again the server connection will be checked and if found, then send all the files store in local folder one by one.
Basically, The GUI application will run continously to get input from user and in another thread there should be check for server connectivity and sending the files.
So my question is what might be the good approach to solve the problem and if any one can send some sample code, it would be great to me.
Thanks,
Barun
There are several approaches to threading in Objective-C! The easiest strategy is NSOperationQueue. Override NSOperation to handle your HTTP request, optionally set a completion block if you need to be notified when it's done, add an instance of it to an NSOperationQueue object and you're good to go. Set up an NSTimer to reschedule the upload if it fails the first time. You can use NSURLConnection to handle the web stuff. Note that NSURLConnection can make connections asynchronously or blocking. Since your NSOperation subclass runs in a separate thread already, you probably want to use the blocking method (if you don't you have to create a concurrent NSOperation subclass, which is a lot more work).
You can also use Grand Central Dispatch's API, detach a new thread to methods you specify, or use plain old c (I wouldn't recommend the last two but it's good to mention them). As a bonus, NSOperationQueue and Grand Central Dispatch both know "what's right" when you have multiple operations running at once, and will scale the number of threads to fit the number of core's in the user's computer to obtain the best performance.
Check the docs for NSOperationQueue, NSOperation, and NSURLConnection. The guides and example projects will have all the source code you need to get you started in the right direction.