Is prepareForSegue right way of passing value between view controllers

Question

I\'m trying to learn Swift and I\'m trying to develop the famous note application.

There is an array bound to a tableview and another view for adding notes. At secon

Answer 1

I would recommend passing data via prepareForSegue in most cases. It's pretty simple to set up and easy to understand.

However, I would recommend never updating UI elements (labels, text fields, etc.) on the destination view directly. In my opinion, this is bad coupling that creates a lot of problems.

Instead, create a property or properties on the destination view controller that the caller can set in prepareForSegue to pass data to it. These should be special purpose properties used exclusively for passing data. The destination view controller is then in charge of using the data in these properties to update its UI or internal state.

Delegation is a valid approach, but I find it to be overkill for most situations. It requires more setup and is more abstract. This abstraction isn't needed in a lot of view controller relationships. If you discover you need to reuse a view controller, you can always refactor to use delegation later.

Answer 2

I do not believe that the prepareSegue is the ideal way for passing data between view controllers...at least not directly.

I share your concerns about using prepareForSegue to pass values between view controllers. The source view controller shouldn’t know anything about the destination view controller (and the other way around, for that matter). Ideally view controllers should be separate islands with no visibility into one another.

To address the coupling that storyboards seem to encourage, I’ve often used some form of the mediator pattern to pass data between view controllers. Here is a pretty good blog post on how to implement a version of this pattern around storyboards: http://coding.tabasoft.it/ios/mediator-pattern-in-swift/ . As always, this pattern may not be the best fit for all situations, but I feel it has been a good solution in a lot of my past projects.

Basically, how the mediator pattern would work within the storyboard paradigm is that in each view controller’s prepareForSegue method, the the segue object is passed to the mediator object. The view controller doesn’t care what’s inside or where the navigation is going next; it just knows it’s about to not be visible. The mediator, which has just been passed the segue object (containing the source and destination view controllers), is then responsible for passing data between the source and destination view controllers.

Using this pattern, each view controller is blissfully unaware of the existence of the other. The mediator class, on the other hand, must know about the relationships between the view controllers (and the view controllers' interfaces) in the navigation path. Obviously if the navigation changes, or the view controllers themselves change, the mediator class will need to adjust. Each view controller, however, need not have any dependence on each other, and therefore need not be updated to to accommodate changes in the navigation path or changes to the other view controllers along that navigation path.

Answer 3

Your question is not really about prepareForSegue but the relationship between view controllers. The reason that your design "feels wrong" is that it is. The problem is that your note writing view controller knows too much about the view controller that is using it because it is directly manipulating a variable from the calling view controller. In order to directly manipulate the variable, it must know the class of the caller.

Why is this a problem? It makes your note writing view controller less reusable. If you write the note writing view controller correctly, then you could reuse it in other apps. To make it reusable, you need to decouple the note writing view controller from the caller - it must not know who exactly is calling it.

So the question becomes, how do I pass data back to the caller if I don't know who called me? The answer is delegation.

Delegation works like this:

1. You create a protocol which describes a method or methods that the implementor of that protocol will implement. In your case, you could use a protocol like NoteWriterDelegate that implements the method takeNote(note: String).

   protocol NoteWriterDelegate {
       func takeNote(note: String)
   }
   

   Define this in the file along with your note writing view controller.

2. Your note writer will have an optional pointer to the delegate:

   weak var delegate: NoteWriterDelegate?
   

3. You need to declare your first view controller as a NoteWriterDelegate:

   class ViewController: UITableViewController, NoteWriterDelegate
   

4. And then implement the required method in your first view controller:

   func takeNote(note: String) {
       notes.append(note)
   }
   

5. When you call prepareForSegue in preparation for moving to the note writing view controller, you pass yourself as the delegate:

   destinationViewController.delegate = self
   

6. In the note writing view controller, when you have a note to pass back to the caller, you call takeNote on the delegate:

   delegate?.takeNote(self.ourTextField?.text ?? "")
   

By doing it this way, your note writer only knows that it is talking to a NoteWriterDelegate. If you want to reuse this in the future, you just drop your note writer class into another project, implement the delegate, and it works without you having to touch the code in the note writer class.

Answer 4

It is not 'the' right way, but it is a right way. Especially in storyboard applications.

Here is an alternative way of passing value and calling the view.

var myNewVC = NewViewController()
myNewVC.data = self
navigationController?.presentViewController(myNewVC, animated: true, completion: nil)