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:
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.
