I'm new to iOS and Objective-C and the whole MVC paradigm and I'm stuck with the following:
I have a view that acts as a data entry form and I want to give the user the option to select multiple products. The products are listed on another view with a UITableViewController
and I have enabled multiple selections.
My question is, how do I transfer the data from one view to another? I will be holding the selections on the UITableView
in an array, but how do I then pass that back to the previous data entry form view so it can be saved along with the other data to Core Data on submission of the form?
I have surfed around and seen some people declare an array in the app delegate. I read something about Singletons but don't understand what these are and I read something about creating a data model.
What would be the correct way of performing this and how would I go about it?
I have seen a lot of people over complicating this using the
didSelectRowAtPath
method. I am using Core Data in my example.4 lines of code inside the method and you are done.
I find simplest and most elegant version with passing blocks. Let's name view controller that waits for returned data as "A" and returning view controller as "B". In this example we want to get 2 values: first of Type1 and second of Type2.
Assuming we use Storyboard, first controller sets callback block, for example during segue preparation:
and "B" view controller should declare callback property, BViewController.h:
Than in implementation file BViewController.m after we have desired values to return our callback should be called:
One thing to remember is that using block often needs to manage strong and __weak references like explained here
Delegation is the only one solution to perform such operations when you are using .xib files however all answers described above are for
storyboard
for .xibs files you need to use delegation. that's only solution you can.Another solution is use singleton class pattern initialize it once and use it in your entire app.
There is some good information in many of the answers given, but none address the question fully.
The question asks about passing information between view controllers. The specific example given asks about passing information between views, but given the self-stated newness to iOS, the original poster likely meant between viewControllers, not between views (without any involvement from the ViewControllers). It seems that all the answers focus on two view controllers, but what if the app evolves to need to involve more than two view controllers in the information exchange?
The original poster also asked about Singletons and the use of the AppDelegate. These questions need to be answered.
To help anyone else looking at this question, who wants a full answer, I'm going to attempt to provide it.
Application Scenarios
Rather than having a highly hypothetical, abstract discussion, it helps to have concrete applications in mind. To help define a two-view-controller situation and a more-than-two-view-controller situation, I am going to define two concrete application scenarios.
Scenario one: maximum two view controllers ever need to share information. See diagram one.
There are two view controllers in the application. There is a ViewControllerA (Data Entry Form), and View Controller B (Product List). The items selected in the product list must match the items displayed in the text box in the data entry form. In this scenario, ViewControllerA and ViewControllerB must communicate directly with each other and no other view controllers.
Scenario two: more than two view controllers need to share the same information. See diagram two.
There are four view controllers in the application. It is a tab-based application for managing home inventory. Three view controllers present differently filtered views of the same data:
Any time an individual item is created or edited, it must also synchronize with the other view controllers. For example, if we add a boat in ViewControllerD, but it is not yet insured, then the boat must appear when the user goes to ViewControllerA (Luxury Items), and also ViewControllerC (Entire Home Inventory), but not when the user goes to ViewControllerB (Non-insured Items). We need be concerned with not only adding new items, but also deleting items (which may be allowed from any of the four view controllers), or editing existing items (which may be allowed from the "Add New Item Form", repurposing the same for editing).
Since all the view controllers do need to share the same data, all four view controllers need to remain in synchronization, and therefore there needs to be some sort of communication to all other view controllers, whenever any single view controller changes the underlying data. It should be fairly obvious that we do not want each view controller communicating directly with each other view controller in this scenario. In case it is not obvious, consider if we had 20 different view controllers (rather than just 4). How difficult and error-prone would it be to notify each of the other 19 view controllers any time one view controller made a change?
The Solutions: Delegates and the Observer Pattern, and Singletons
In scenario one, we have several viable solutions, as other answers have given
In scenario two, we have other viable solutions:
A singleton is an instance of a class, that instance being the only instance in existence during its lifetime. A singleton gets its name from the fact that it is the single instance. Normally developers who use singletons have special class methods for accessing them.
Now that we understand what a singleton is, let's discuss how a singleton fits into the observer pattern. The observer pattern is used for one object to respond to changes by another object. In the second scenario, we have four different view controllers, who all want to know about changes to the underlying data. The "underlying data" should belong to a single instance, a singleton. The "know about changes" is accomplished by observing changes made to the singleton.
The home inventory application would have a single instance of a class which is designed to manage a list of inventory items. The manager would manage a collection of household items. The following is a class definition for the data manager:
When the collection of home inventory items changes, the view controllers need to be made aware of this change. The class definition above does not make it obvious how this will happen. We need to follow the observer pattern. The view controllers must formally observe the sharedManager. There are two ways to observe another object:
In scenario two, we do not have a single property of the HouseholdInventoryManager which could be observed using KVO. Because we do not have a single property which is easily observable, the observer pattern, in this case, must be implemented using NSNotificationCenter. Each of the four view controllers would subscribe to notifications, and the sharedManager would send notifications to the notification center when appropriate. The inventory manager does not need to know anything about the view controllers or instances of any other classes which may be interested in knowing when the collection of inventory items changes; the NSNotificationCenter takes care of these implementation details. The View Controllers simply subscribe to notifications, and the data manager simply posts notifications.
Many beginner programmers take advantage of the fact that there is always exactly one Application Delegate in the lifetime of the application, which is globally accessible. Beginning programmers use this fact to stuff objects and functionality into the appDelegate as a convenience for access from anywhere else in the application. Just because the AppDelegate is a singleton doesn't mean it should replace all other singletons. This is a poor practice as it places too much burden on one class, breaking good object-oriented practices. Each class should have a clear role that is easily explained, often just by the name of the class.
Any time your Application Delegate starts to get bloated, start to remove functionality into singletons. For example, the Core Data Stack should not be left in the AppDelegate, but should instead be put in its own class, a coreDataManager class.
References
This is not the way to do it, you should use delegates, I'll assume we have two view controllers ViewController1 and ViewController2 and this check thing is in the first one and when its state changes, you want to do something in ViewController2, to achieve that in the proper way, you should do the below:
Add a new file to your project (Objective-C Protocol) File -> New, now name it ViewController1Delegate or whatever you want and write these between the @interface and @end directives
Now go to ViewController2.h and add
then change its definition to
Now go to ViewController2.m and inside the implementation add:
Now go to ViewController1.h and add the following property:
Now if you are creating ViewController1 inside ViewController2 after some event, then you should do it this way using NIB files:
Now you are all set, whenever you detect the event of check changed in ViewController1, all you have to do is the below
Please tell me if there's anything that's not clear of if I didn't understand your question properly.
You can save data in App delegate to access it across view controllers in your application. All you have to do is create a shared instance of app delegate
For Example
if you declare a
NSArray object *arrayXYZ
then you can access it in any view controller byappDelegate.arrayXYZ