0

Working with Cocoa-Touch, but this is a general question.

Is it OK for views to keep a references to their view controller and deal with data? I recently came across a code base that does this through out the app - For example, there's a table view controller and it's cells have a weak reference to the view controller (so no retain cycles). The cells present new view controller via

[self.parentVC presentViewController.....];

and dismiss it in similar fashion. Also, they handle changes in data/network operations as well.

Until I saw this, I was accustomed to creating protocols for each cell and talking to the parent view controller via them. Using the approach of directly referencing view controller get rid of all the protocols.

To me this seems really bad but not sure if it's common.

John Topley
  • 113,588
  • 46
  • 195
  • 237
0xSina
  • 20,973
  • 34
  • 136
  • 253

3 Answers3

6

The upcoming answer is regarding Apple way of handling the model view controller which is quite different than other SDKs (ex Qt).

This is definitely bad practice. And it can be sum up into one question, if you think this is a good idea, then why hasn't Apple already added that reference in the UIView class ?

If you look at how Apple uses the model view controller, the model is pretty clear:

enter image description here

The view communicates with the controller to signal a status change, the controller updates the model if needed and update the view accordingly. You will never find a piece of documentation or a sample for Apple where your view would update the stack controllers.

If a UIView subclass starts to hold reference to the controllers that's holding it (and even if it's a weak reference), you are removing the abstraction of the view towards its controller (the reference goes the other way), and therefore strongly encouraging bad practice for those working on the same code.

What would prevent another developer to add a reference this time on the "Model" the view is attached to ?

Now I'm not saying this will turn your code into spaghetti code (you can still probably make a decent app out of it), I'm saying this is really (really!) bad practice.

Hope this was clear enough.

Community
  • 1
  • 1
apouche
  • 9,703
  • 6
  • 40
  • 45
  • Thanks for the detailed response. Believe it or not, the code base I am talking about was programmed by a leading app dev company and I was so surprised how bad it was that I had to ask. – 0xSina Feb 22 '13 at 15:30
  • 1
    "if you think this is a good idea, then why hasn't Apple already added that reference in the UIView class" Very good way of thinking about the framework. Not the answer to everything, of course, but definetely I nice guideline regarding "not fighting the framework" – Cezar Feb 23 '13 at 14:42
0

I think is probably both: really bad and common.

Views should be generic, they don't need to know any details about their controllers. The communication should be limited to delegation (protocol), data source (protocol) or target action.

Odrakir
  • 4,254
  • 1
  • 20
  • 52
0

Well, ... it is not uncommon and not really good style. I did that myself and nearly got lost. When ever it is required, I try do adopt the delegate pattern. That means, yes, I do keep a reference to the delegate which happens to be the view controller. The delegate object does fulfil a protocol in which I summarize all the view controller's (the delegate's) methods that I am about to call.

In that case and your example the cell would inform the view controller about something happened by calling a method and the view controller then would invoke the next view controller that is to be called.

By doing so I achieve the same thing but sort of stick to the MVC pattern and therefore always know where to look for what sort of functionaltiy - even in a year or so.

Hermann Klecker
  • 14,039
  • 5
  • 48
  • 71