Forum

[Abel]

Actually the view controllers are allowed access to w.e the heck they want, when using MVC we simply care about having reusable models and views. Heck if you make a reusable controller then many props to you but thats barely ever possible unless you are working on doing something very generic. The view however shouldn't have direct access to the delegate, any info it needs to display or deal with should be passed to it by its view controller.

Originally Posted by cDima

I watched the video, implemented it, I get what you are doing. I'd give you a medal for doing it too.

I may have exaggerated a bit, but let me explain why I don't like that line. The view or view controller in MVC shoudn't know about the TwoViewAppAppDelegate, right?
Because it will never be reusable.

Lets take the UITextView, for example. To send messages UP the view hierarchy, as I understand it, the UITextView defines a prototype called UITextViewDelegate, and a public property called delegate. I believe this is the proper way to create view controllers that send signals to their parents. Right?

So the MVC way of doing that code is:
- define a prototype for the specific ViewController;
- after creating the ViewController in the app delegate, hook the TwoViewAppViewController.delegate to "self" (the app delegate);
- and in the app delegate, implement the prototype;

then from the ViewController you can do this code:

- (void) someMethod {
    if ([delegate respondsToSelector: @selector(flipToBack)]) {
          [delegate flipToBack]; // do something appropriate
    }
}

...or not? =)
I'm new in all of this, and come from a C# background. Maybe I'm implementing event-based development to make it more familiar.