I have searched through SO looking for different ways to share data between view controllers. I see that delegation to pass back data are the most common way ppl suggest, and that some ppl use singletons for the information to be available from anywhere in the app. I am not familiar with Core Data yet, but from what i’ve looked at so far, it seems like Core Data is similar to a Singleton in that from the ManagedObjectContext, you can access the data. So as long as you have a reference to that object, you can access that data (feel free to correct me if that understanding is wrong).
In this scenario, I was wondering if delegation or singletons should be used. I basically have a tab bar controller with two tabs. One tab passes data back and forth between the views using delegation or assigning a property on the view to be presented.
The second tab is a summary view of the first tab. So on a completely different stack of views, I need that same data that was in Tab one. In that scenario, should I be using a Singleton so it can be accessed from everywhere in the app? Or is there a better solution?
Also, I’m wondering what you would do about archiving your data if your application is about to be closed. It seems like to me, if I did implement a singleton, when I receive the notification that my app is going to enter the background, I can look in my singleton and save the data. But if I don’t use a singleton, how would I save the data when the app enters the background. Do I put that saving code in the app delegate instead.
I guess in the end I’m trying to understand what design pattern is better in this scenario for archiving and sharing data between the app. Thanks!
I went through this nice tutorial on Core data:
http://timroadley.com/2012/02/09/core-data-basics-part-1-storyboards-delegation/
The approach used there is: your ManagedObjectContext is initialized for the first time in your AppDelegate. Then in my root view controller, i retrieve the ManagedObjectContext from the appdelegate. Then in prepareForSegue, pass the managedObjectContext to the pushed view Controllers.
The AppDelegate has the readonly accessor property for the __managedObjectContext, which is responsible for creating this singleton object for the first time.
In each view controller, I set up the fetchedResultsController on viewWillAppear with the entities I want from core data. I then write directly to core data when the user hits the save button. In my particular application, i have an explicit “Cancel” button, because the user can make mistakes, or wipe out the editable text data accidentally. But you could persist changes immediately, upon each control’s changed value, like in the “Settings” menu in iOS. I prefer the Cancel/Save approach simply because of the nature of my data. Some research is in order to see if you must re-save the whole object, or can only update individual fields in coredata.
Core data pretty much takes care of your questions, if you read/write directly from managedObjectContext. Data is persisted right away, and updated right away. If you have data that is not persisted on purpose, then delegation is a good way to pass it between screens. If you need to notify a whole bunch of view controllers that you don’t want to know about with non-persisted data, consider using NSNotificationCenter with object or with dictionary.
Send and receive messages through NSNotificationCenter in Objective-C?