iOS Trying to keep the MVC dream alive

[KnightWRX]

Let's take a bit of a rest on code issues for this one.

So in working a bit more on my "super secret project that will never see the light of day", I have stumbled on a kind of a design issue and I'd like some input on.

Basically, I have a ViewController that does about nothing except initialize my view and add it to the Window and makes sure to remove everything once this is done. All my drawing code then happens inside a heavily modified UIImageView. The problem I have stumbled upon is the M part of MVC. I'm at the point where I need to feed Model data into the view for display. The problem is, since the view is doing everything, I don't quite understand how to keep the M and V part talking to each other only through the Controller.

How do you guys feed information for display to your view when all the drawing/animation code is done in a view, as is the input ? Should I simply cave in and make my UIImageView the sort of "engine" of the whole app where everything happens in there and just say "screw it" to MVC best practices ?

 

[RonC]

Use a delegate!

Create a delegate for the view to provide a means for it to pull semantically meaningful information from the model. There is a very good description of this in the Fall 2010 Stanford classes on iTunes U (videos at HD and SD respectively, and all of the class lectures, homework assignments, and other code files are available here.

Do this by defining a protocol for that delegate interface in the view, and have the model implement that protocol. This protocol should contain the types of questions the view needs to ask of the model to display it properly (a good example of this kind of delegate is seen in UITableView's "dataSource" protocol/delegate). Create a ivar & property in the view that allows the ViewController to set the delegate property to be the model object. Now the view and model are connected in a way that the view can ask semantically meaningful questions of the model without having to be connected to the internals of the model.

Lecture 5 has discussion of the concept, and Lecture 6 shows how the "delegate" property is used. Lecture 10 shows how 2 delegates ("delegate" and "dataSource") can be used in a single UIView subclass.

Off topic: overall this course provides an outstanding discussion on what's, how's, and why's of iOS. After viewing these videos, my iOS coding has become much more straightforward and more importantly better structured.

 

[KnightWRX]

I use a similar method between my AppDelegate and my ViewControllers to signal when I'm done and want to switch viewcontrollers (since I have modularized the application a bit and use different view types each with their own controller). I guess it was something I was wanting to avoid because these protocols tend to get a bit convulted, but it's much better than simply using the view to also process the model part of the application.

I'll give those classes a go I think.

 

[PhoneyDeveloper]

Some views just need a lot of connection to the data.

Consider UITextView. You provide it with its text, which is the main, if not only, part of the data model. Also, font, frame, make it draw the way you want. Internally the text view must also do some kind of layout of the text so it probably stores a list of line starts, other stuff related to the selection. You may need to update your data model text on every key stroke. So there is a complete duplication of the text, which doesn't seem to be great.

For a more sophisticated text view where multiple instances of the text view could display the same text in different views it would be almost required that there be a single text store data model object that would be shared. This would then be more like UITableView.

Anyway, even if it's a game you probably do want to separate the view and the model, if only to have control over the structure of the model. But sometimes the view does have to have a lot of state information of its own.