Objective C Communicating to one view controller that another has changed - objective-c

Question

I have two view controllers - one "main" view controller which displays the main content and one "settings" table view controller which is held in a container within a slide-out view. The concept is this:
User taps an item on settings panel.
Settings TVC creates a "Button States" dictionary object with all of the button settings.
Button States dictionary is passed to a class that converts the button states to a dictionary of settings that the main model object can understand.
_______???
At this point, I need to inform the main view controller (which holds the instance of my main model object) that the settings have been updated and it needs to update the settings on its model object. How do I go about doing this? Should I have a class method on the main view controller and include the header file in my settings conversion class?

Answer 1

Contrary to the other answers, there's really no need to use a singleton here. All you need is an object that's shared between the main view controller and the settings view controller, or some way to pass information between them. Here are some options that don't require a new singleton class:
shared model: If you're using a model class to keep track of your settings, both your main view controller and settings view controller can access the model if you simply tell them both about the model. For example, if you create both view controllers when your app starts up, you can create the model at the same time and pass the model to both controllers:
MyModel *model = [[MyModel alloc] initWithFilePath:somePath];
MainViewController *mainVC = [[MainViewController alloc] initWithNibName:nil bundle:nil];
SettingsViewController *settingsVC = [[SettingsViewController alloc] initWithNibName:nil bundle:nil];
mainVC.model = model;
settingsVC.model = model;
shared object: If you don't need/want a whole model class that sticks around and you only need to communicate some changes between the two controllers, let them share just a simple data container, like a dictionary. Let's say, for example, that the main view controller is responsible for creating the settings view controller and then pushing it onto the navigation stack. It can easily say: "Here's a mutable dictionary; use this to get any settings you need, and to record any changes." The code in the main view controller would look something like this:
self.settings = [NSMutableDictionary dictionary];
// ...code to add all the settings to the dictionary...
SettingsViewController *settingsVC = [[SettingsViewController alloc] initWithNibName:nil bundle:nil];
settingsVC.settings = self.settings;
[self.navigationController pushViewController:settingsVC];
delegation: Consider the previous situations, but instead of passing a mutable dictionary or a model object to the settings view controller, pass the main view controller itself as the shared object. If the settings are properties of the main view controller, the settings view controller can access those properties (using accessors, please) to get and set the settings. Or turn it around and have the main view controller keep maintain a reference to the settings view controller so that it can ask for the values for any settings it needs. Either way, one view controller is acting as a helper for the other, and that's the delegate pattern in a nutshell.
NSUserDefaults: The shared user defaults object is already a singleton, so you don't really need a different one. Both view controllers can simply access the shared user defaults object to get/set the settings they need.
Whichever one you choose, you'll want to make sure that you read the settings in the -viewWillAppear for each controller and update the UI as necessary.
Your question is mostly about how to get two view controllers to talk to each other. There are many ways to do that, and a singleton is never required for any of them.

Answer 2

I have an app that does something similar. In my settings view, whenever a setting is modified, I have the settings view call a singleton object that keeps track of the settings in the settings view. Upon switching back to the main view, in the viewWillAppear method I check the singleton to see what settings were set and update my UI accordingly.

Answer 3

You can create singleton class for settings.
here is link how to do it Care and Feeding of Singletons
Let's say that yours singleton is called SharedSettings.
Each time you are changing settings in view you should change them in your SharedSettings singleton and tell view to apply this changes. To "tell the view" there are 2 most common methods in objective-c: delegate and NSNotificationCenter.
Here is tutorial for delegate Example for delegate
And here is the link for notifications NSNotificationCenter Tutorial
The difference between delegate and notifications is that delegate is used to notify one class e.g. like cellForRowAtIndexPath and notification is used to notify many observers with one notification e.g. let's assume that you have 5 view controllers and in the setting you change background from red to green and you need to notify all 5 views to change their colors.
also notifications are considered to be a bit slowlier than delegates.
If you will have questions about singleton, delegates or notifications feel free to ask.

Answer 4

You don't need to restrict the communication with your model to just the "main" view controller, your settings table view controller can directly access the model too! Funnelling all the model access through the one place doesn't usually get you much benefit, and instead demands you invent pointless parallel systems to communicate the model values to & from that main controller.
Make the model object(s) a singleton instead and allow access from any controller.
However if you really need to keep your architecture, you need a way of signalling back that the main view controller that the settings view is closing. Perhaps post a notification that the main view controller observes, the updated settings dictionary can be the notification object.