I have been looking for tutorials to help me to understand how I can add background app refresh for swift into my watch app, so that my Glance will have fairly up to date data (like the weather app).
So far I haven't found anything and wondered if anyone knew of any advice/examples/tutorials that might benefit me.
You could update your watch app with func updateApplicationContext(_ applicationContext: [String : AnyObject]) throws.
Use this method to transfer a dictionary of data items to the counterpart app. The system sends context data when the opportunity arises, with the goal of having the data ready to use by the time the counterpart wakes up. The counterpart’s session delivers the data to the session:didReceiveUpdate: method of its delegate. A counterpart can also retrieve the data from the receivedApplicationContext property of its session.
updateApplicationContext:error:
This method sends the data in a background task. When the data arrives you could save it inuserDefault or in a class that could be read from your Glance, when your Glance willActivate is called just update the UI with the latest data that arrived in the context.
Related
Recently, I'm working with a timetable app in iOS, and i get trouble with Core Data.
My app has a main user interface kind of like the original calendar app created by Apple, and i save all my events data in the Core Data database.
I create a UIManagedDocument in order to fetch data from database by using its NSManagedObjectContext, and everything works just fine.
However, i need to use the NSManagedObjectContext to fetch data several times in several different view controllers during the runtime. And every time i do this, i need to reopen the UIManagedDocument, but open the document take too much time(it may take 2 seconds or even more, i have to display a spinner in view).
So here are my questions:
What's the right way to open a managedDocument?(I mean like open it during the lunch image time?)
Is there a way to only open the managedDocument once and keep it open during runtime?(So i can use its context all the time)
Does data store in the managedDocument i create?(I found that if i delete the document, data was gone)
Thanks.
You will get lots of different opinions on how to do this but basically you should only have to open the document once. This is done by some object that does the work and stores it so it can return it again when asked by a different view controller.
Many people create singleton's for this or put it in the App Delegate. I have implemented a protocol that lets me put it where ever it is convenient for a particular application without my other code having to know anything about the object that returns the information. As long as it responds to the protocol it can be the App Delegate, a singleton class, or any other object type.
See importing AppDelegate
The protocol that I put in the above example just returns information about where the database is. In my actual implementation I have an openDatabase method with a call back to let me know when it is done plus automatic initialization and updating methods.
You can also improve your performance by having the open operation happen off the main thread. This keeps your UI responsive but does not show the data any faster and you have to be carefull about managed object contexts and the threads they are in.
Good luck...
In my app requirement is, when the app is launch for the first time it will send request to server to get data, parse it and save it in document folder which will be used across entire project.Again after particular time interval the app will send request to server to get updated data(if any) and update that data in document folder, which again will be updated across entire project.All this process is happening in background thread.This process will repeat until the app is running in foreground once the user close the app, the app will get terminate, it will not go in background.
This repeated request I am creating in app delegate as well as doing xml parsing once the data is received and saving after parsing. Now my question is, Is this proper means doing too much stuff in app delegate is safe or there is some limitation or is this bad programming?
What is the correct way of doing this?
I disagree with torrey.lyons to an extent. I think creating singletons is bad practice generally speaking and should be avoided where possible. One thing you should never do is code a class so that it has to be a singleton. Purpose built singletons tend to increase coupling and can be really problematic when it comes to unit testing where you might want to replace your singleton with a stub class or you might need it to be reinitialised for each unit test.
If this task of getting data is an application level task, there is absolutely no reason why it can't logically be located in the application delegate. I would however create a "connection manager" as torrey.lyons suggests and have one as a property of the app delegate.
I would also not use an explicit background thread to do the data update but I would use a subclass of NSOperation. This is a whole lot easier than managing your own thread.
It is bad practice. Your app delegate should ideally be concerned purely with its own responsibilities, i.e.. responding to the messages the application sends its delegate. It is much better to split off other discrete responsibilities into other objects. For example, you could have a "connection manager" object that is responsible for periodically communicating with the server. If you are sure the app will only connect to one server at a time you probably want to use the singleton pattern so that there only one instance of the object in your application and it can be easily reached by any other class. A good discussion of the proper role of the app delegate and singletons can be found on at Singletons, AppDelegates and top-level data. A good general overview on writing singletons can be found under the Care and Feeding of Singletons.
I'm developing a project for iDevice. I'll explain the architecture of my project, and I would like some feedback.
My project is a typical iPhone application : list of item --> detail.
STEPS:
I made a singleton to store information .
I send an asynchronous request to receive list of items (not detailed), when the request finishes loading, I store the result in a string in singleton and I post a notification ("loading terminated").
In other object I "catch" this notification, parse the result stored in singleton, store the parse result in an array in singleton and I post notification ("parse terminated").
In other object, I "catch" the notification and I display result in a table view.
When a cell is selected, I do the same thing (with other name of notification and other variable in the singleton for detailed item)
I use this architecture because my project needs to be generic and extensible.
It is a good idea to do it in this way? Are there better options?
Sounds a bit like a Model View Controller http://maniacdev.com/2009/10/a-quick-explanation-of-mvc/
I don't know if you need another object to do step 3. The data is just going into the singleton anyway. Might be best to have a response processor handle getting the results from 2 and then do the processing from 3 and then send it to the singleton.
Essentially:
- make the synch request and set a delegate to handle the response
- perform all the processing and formatting of the response and save to singleton
- singleton notifies it's delegates of a change
- objects subscribed as a delegate to the singleton perform their action, in this case, display data
check out the link and read up a bit on MVC
I am storing some objects in core data that have inherent life spans. I was scheduling local notifications on object creation for this lifespan and then handling the object went the notification fired.
The problem is that the objects can end early. But the local notifications don't know this and still fire at their respective time which leads to confusion. Is there a way to store a pointer to the notification in with the object? So if it ends early it can just cancel it.
I would like to stick with notifications as I need the user to know when it is finished, if it finishes normally. And notifications don't depend on the app running.
Basic question can you store pointers to objects in core data. Second question is if local notifications change memory addresses during their lifespan
I know I could just cancel them all and reschedule the ones needed if one ends early but that just seems wasteful and hopefully there's a better way.
UILocalNotification is not serializable (it doesn't implement NSCoding), so you can't store it persistently with Core Data. I suggest you add the Core Data entities' managedObjectID in serializable form (e.g. as an URL) to the notifications' userInfo property. If you need to delete a specific notification, you search your UIApplications' scheduledLocalNotifications array for the local notification with the corresponding managed object ID in its userInfo property and then cancel that one via cancelLocalNotification:.
Heads up - I've been reviewing this topic, and I'm seeing some conflicting information with the answer from #MrMage :
UILocalNotification does conform to NSCoding per the Apple doc
Here's an answer on stackoverflow that describes how to store the local notification in nsdata which should enable you to store the localnotification as a property in an entity: Delete a particular local notification
Not an expert on this topic though, so any feedback would be great.
The question is quite simple: when should I use the save:(NSError **)error method of NSManagedObjectContext? From what I understand the only thing it does it save changed data to the persistent store. The Xcode template-generated application delegate calls the save: method on applicationWillTerminate, is that sufficient?
Details about my code:
Multi-threaded (doing operations in the background, thus using multiple NSManagedObjectContext's)
I'm using a single NSPersistentStoreCoordinator
Data changed on background threads is merged using mergeChangesFromContextDidSaveNotification:
If you need to know more, please do ask!
I couldn't find a guideline on when to call it, so I decided to ask you all. Thanks in advance for your replies!
You always need to call save: when you want your data to save. You can't always guarantee that applicationWillTerminate will be called. For example, if your application crashes due to memory issues (or due to one of a handful of other things) then this won't be called.
I would save data when the user completes the action that is actually generating the data to save.