So I’ve been working on some projects recently. One of the big ones is iPhone development. When I got my iPhone, I was thrilled by all of the apps that I could get. What Apple says really does seem to be true. 

There’s an app for that.

So why bother? After all, I did miss the first wave opportunity. Well, besides the thrill of learning something that’s quite challenging. There are still some great tools that aren’t out there yet. Some that maybe only I would find useful. Some that everyone might find useful. So why can’t I be the one to make them? All I need is an idea, the right tools, some knowledge, and a little motivation. Well, I’ve got some ideas. I’ve got most of the right tools. And I definitely have motivation. All I need is knowledge, and I’m slowly gaining that too. That’s where the world wide web comes in handy. I’ll share my knowledge with you if you share with me. When I learn something new (and handy), I’ll post it here, and you can add comments that will help me and everyone else learn just a little bit more.

So I used to work in software development. Most of my days were spent coding on PCs in languages that hardcore programmers wouldn’t even call true programming languages. For them, it’s not programming unless you’re writing in C, Fortran, or some other hard to learn language. Well, I’m one step closer to becoming a hardcore programmer. I’ve learned Objective-C. At least the basics anyway. Before you go on, I should mention that if you don’t feel like learning C and Objective-C (you really should learn at least a little C), then forget about programming for the iPhone (unless you want to build Web Apps.) As far as I can tell, there is no alternative language you can use to build a native app.

Which finally brings me to my first little tidbit of knowledge: MVC (Model-View-Controller) Architecture. A little disclaimer: outside of an intro programming class (where I learned MATLAB scripting and a little C++), I’ve had no formal training. Most everything I know if self-taught, learned on the job, or picked up from friends or the internet. So if I’m wrong, I’m sorry. I’m not an expert.

Model-View-Controller philosophy is a big thing with Apple. The idea is that your abstract concept (the model, such as a calculation engine to do math) should be independent from the interface (the view) you use to interact with it. So much so that you should always have a middle-man (the controller). What this means to us beginners and noobs is that everything belongs in a class and there is no direct communication between the heart of your app and the interface. This a little different from what I’m used to. My classes tend to encapsulate model components (database access, for example), but I never used classes to differentiate between my gui and the code that controlled it. So you might say that I was using the M-(VC) architecture for coding.

Because Apple believes in a very controlled environment, you really have to play things their way. Maybe when you’ve become an expert, you can break free of this coding philosophy. Until then study it, and study it well. The fact is, its really hard to understand the tutorials and documentation out there unless you grasp this basic concept: Model speaks to Controller which speaks to View. So if you want to manipulate a view in an iPhone app, then you need to understand its controller. This unfortunately means that there is just one more class for you to figure out.

The last thing to mention is the concept of a delegate. Its one that I’m still working to grasp, but the idea is exactly what the word implies. You can appoint an object to act as the middle-man for certain classes. The thing is, that sounds like the definition of a controller. So what’s the difference? I’m still not sure. So far, assuming that they are one in the same (conceptually) has been working for me, but I’ll tell you when that’s stops being the case.

Before too long, you’ll be building your own views and controllers (I’m already doing it), but it was a struggle to clearly delineate my classes to stick to the MVC concept. To be fair, I’m probably making it sound a little harder than it is, but its definitely not a cake walk. Just don’t plan on taking the leap from a simple tutorial found through the Apple Developers Connection (ADC, the Apple equivalent to MSDN) or the web to a full-featured app in a short time. Unless, of course, if you’re already a developer for Mac applications.

Until next time, keep it fuzzy….


3 Responses to “Programming my iPhone – A Brave New World – MVC Architecture”

  1. Matt Says:

    “Model speaks to Controller which speaks to View”

    Actually, the model should not understand any of the other constituent parts in the MVC pattern. The view holds a reference to the model. The controller will reference both the model and view. Sometimes the view and controller are conflated into just the view. The model is unaware of anything but itself. It may, however, trigger events for other classes who are in an Observer relationship with it.

    So you’ll have pseudocode that looks like this:

    Model theModel = new Model(); //notice how it doesn’t know about any other classes?
    View theView = new View(theModel); // to get state from the application
    Controller theController = new Controller(theModel, theView0; // to control application logic and flow

    I’m still figuring out MVC in iPhone-land because it looks a bit different in this environment than in others (which is actually how I found your blog post). Best of luck!

  2. Merryl Says:

    Matt, thanks for the clarification. I think you’ve stated what I was trying to communicate more clearly. When I said that the model talks to the controller, I simply meant that messages are sent between the model and controller, not that that the model has a reference to the controller object.

    I like your pseudocode, but I’m not sure that I completely agree with it. When I’m developing my iPhone apps, the View does not recieve a reference to the Model. I think this has to do with the idea that each of the three key objects in MVC should be portable and message based. This allows the view to be applied to other models.

    I would look at the difference between figures 4-5 and 4-6 at this site:
    http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html

    4-5 sounds like the MVC design pattern that you’re referring to, where the View has a reference to the Model. However, Cocoa (and I believe Cocoa Touch) use what is in 4-6, where the Model only interacts with the Controller.

    This is the type of discussion I’ve been looking for. Thanks!

  3. mek_man Says:

    the blog needs an update… asap! : )

Leave a Reply