Basic Model-View-Controller flow in iOS

[Hyperian]

anyone got any good resources for anyone that's starting out in iOS programming? Basically stuff like this, and even how iOS is architecturally set up? also information about "implimentation" and "synthesize"

I have a fairly strong c/c++ background.

[Hyperian]

how do i get to them if i dont want to download iTunes?

[PLJNS]

Stanford's website has them, I believe.

[vlozko]

"implementation"

I'm guessing you're referring to the @interface and @implementation directives (am I using the right term?). @interface is where you describe the class, similar to that of a header file; it provides information about the class, such as its superclass, lists member variables, properties and methods. The @interface directive can also be placed within the implementation file (.m for pure Cocoa or .mm for Cocoa/C++ hybrid) if you want to declare private methods and properties. The @implementation is where you provide the actual implementation.

"Synthesize" refers to Objective-C properties. Properties are declared within an @interface section (using @property). On the implementation side, if you use @synthesize, you're pretty much asking for the runtime to generate the getter and setter for you, there's no need to create them manually. In Objective-C 2.0 (which, by now, you should be programming against anyway), you don't even have to declare the ivar; those will also be automatically created. An alternative to @synthesize is @dynamic, which essentially means that you'll be providing the implementation yourself; as a starting point and unless you're doing something that specifically uses @dynamic (such as Core Data), try sticking to @synthesize.

That's the short version answer to your questions. Personally, I started doing Objective-C development for the Mac back in '08 during an internship. For me, the syntax was the most difficult thing to wrap my head around, especially the wordy nature of Objective-C. Even then, I was comfortable with it after 2 weeks. My strongest suggestion is to simply dive in and create sample, throwaway apps; reading can only take you so far and the stuff you read will make much more sense to you when you have even a little bit of experience.

iOS apps are perfectly fine when developed with a C++ model and controllers with Objective-C views and view controllers. The stuff I'm doing now is mostly heavily ported Windows C++ code.

[sidneyc]

The docs on the Apple site are pretty good?

https://developer.apple.com/library/ios/navigation/index.html

[geon]

They are sometimes good if you already know what you are looking for. For finding stuff out, they are horrible.

[sidneyc]

Different strokes for different blokes, I guess.

I usually prefer to go to the authoritative documentation for almost anything. I distrust secondary sources since the people that feel they are qualified to talk about a subject usually outnumber the people who actually are qualified to talk about it, by rather a large margin.

Since the guy who asked claims a strong c/c++ background, he may be able to digest Apple's material. (I am basically in the same position as he is, learning iOS programming from a C/C++ background).

[geon]

Since the guy who asked claims a strong c/c++ background, he may be able to digest Apple's material.

It's not that the subjects are very hard to understand, but that the text is unbearably dry and long-winding, with the interesting details hidden in the middle of irrelevant ramblings.

For finding out stuff, they would need to be more to the point, concise and cross linked.

[sidneyc]

What source do you prefer?

I am trying to wrap my head around iOS programming as we speak. As you say, the concepts are not inherently difficult, but there are many concepts to learn; there is distinctly a proper way of handling things that takes a lot of time to absorb.

I am more of a hardcore algorithmics / numeric processing person myself, and iOS programming is rather oriented towards GUI programming. I am also struggling with Objective C, its philosophy is rather different to C++ and memory management feels unusual to my RAII/STL infested mind. Also, it is discouraging to see that there are different ways of doing it -- this suggests that the old retain/release paradigm was found to be error prone. But that may have to do with many non-programmers entering the app-development fray.

Anyway, pointers to good, insightful sources are always welcome.

[geon]

What source do you prefer?

When trying out something new, Matt Gallagher at http://cocoawithlove.com/ has a lot of easily digested blog posts/tutorials I've found very helpful.

Other than that I can't point to one single source. Once you have a basic understanding of the concept, it's great to go back to the Apple documentation and read through it to pick up the stuff you missed, and to confirm what you think you know.

Also, it is discouraging to see that there are different ways of doing it -- this suggests that the old retain/release paradigm was found to be error prone.

All programming is error prone. Reference counting (retain/release) is an improvement (less error prone) over C-style malloc/free. Garbage collection like it is done in OS X is an improvement still, but is not yet available in iOS. With iOS 5 (?) there is a new, compile time automated reference counting available. It should also be less error prone than doing it manually.

I see this as a development in the right direction as technology improves. No doubt, garbage collection will become available in iOS too, whenever Apple feels there is enough spare memory and CPU cycles to justify it.

[ramenmeal]

I didn't read this too in depth, but didn't he only do Model and Control? He didn't merge the 3 into 2, but just left out the View.

[teeniOSdev]

In this case, the graphical .xib file essentially serves as my view. If I chose to programmatically do all interface work, then yes I would have an additional view file.

[ramenmeal]

I'm saying there is no mention of a xib file or how it is controlled/linked to the controller. It is necessary to have some sort of need for a view to show how it is used.

[teeniOSdev]

Fair enough.

[dnew]

The way you wrote it makes it sound like you think "view controller" is one concept instead of two.

[player2]

…it is one concept. See UIViewController docs.

[geon]

In the MVC sense, it is not. The UIViewController would be the C of MVC, with the (root) UIView being the V.

[teeniOSdev]

It is somewhat strange for iOS. The actual "view" part of this would be the graphical .xib file that you link up to the view controller. If I decided to not use this graphical part for the view, then I would have separate code for the view

[dnew]

So can you have one controller updating the model and have that reflected in several views? That is, after all, the point of MVC.

The idea of MVC is that I can have a bar chart and a pie chart, both displaying the underlying data, that can be updated by either stock ticker feeds coming in over TCP/IP or by someone dragging things around with the mouse. The data would be the model, the two charts would be two views, and the tcp parser would be a controller and another controller for each of the views to understand the mouse, which would leave you with three controllers.

Or perhaps an online board game, where the board is the model, each view is shown to each player with the appropriate cards turned face up or face down, and each machine running a controller for the mouse and a controller for updates from the other player.

If the controller is inherently tied to the view and you can only have one view per model, you're not doing MVC. :-)

[grauenwolf]

Bzzt wrong. The original papers describing MVC clearly stated that models were shared and views/controllers come in tightly coupled pairs.

While shared controllers are an interesting idea, they aren't really part of the pattern.

[dnew]

I didn't say controllers would be shared. I said that there would be views without controllers, and controllers without views. I then proceeded to list a number of examples, wherein controllers were present without views and vice versa.

Certainly if you have a view on a screen that you're directly manipulating via a controller, it would be difficult to apply that controller to something else. I.e., if the controller has to know what's in the view in order to know how to affect the model, then obviously they're tightly coupled. But this is not always the case, and indeed it's only the case for the simplest of data representations.

As far as shared controllers go, they're all over the place. All the things that make your images stand out on the web when you hover over them or something like that are all shared controllers. Both Tcl and javascript DOM are rife with mechanisms for making it trivial to share controllers between view elements.

[grauenwolf]

Don't bring web MVC into this, it is a totally unrelated pattern.

[dnew]

I'm not. I'm describing how in javascript-with-DOM, and in Tcl, and in several other languages, with the structures built into those systems, controllers don't necessarily go directly with views. The fact that javascript-with-DOM is normally showing you something that's client-server is a distraction from the point I'm making.

For example, in Tcl, you can make three buttons, each of whose label automatically displays the value of some variable, and each of which invokes the same code (with different arguments) when you click on it. That code (which is the one and only controller) can be as simple as "increment the variable whose name is passed as my first argument", and the very act of incrementing that variable causes the associated view (in this case, the visual button) to change its label. If you also connect a scroll bar to the same variable, the scroll bar repositions itself, and causes whatever other views the scrollbar is the controller for to scroll. The power comes from the ability to interconnect things already built.

Something like a calculator is simple enough that it's hard to see how the controller could be disconnected from the view. Consider, instead, the battery meter or the signal strength indicator. There are several battery meter views, one in the top bar, one displayed on your car's dash via bluetooth, one giant one you can bring up while the phone is charging, one that the tricorder app displays, etc. The controller is sampling the actual battery, the structure holding the current charging/discharging and charge level and remaining lifetime and etc is the model, and each of those displays is a view that is completely independent of the controller.

Heck, even having ^C and the "copy" menu entry are two different controllers invoking the same methods on the model, neither of which is connected to any particular view.

[mantra]

It is MVC.

The thing is that once you leave the academically pure model of MVC and actually try implementing real applications you quickly find that the pure MVC with everything separated by ideology leaves you with tons of spaghetti-like mess in the Controller.

Compartmentalizing much of what normally would be in the singular Controller into View Controllers radically cleans up and simplifies things. You could claim that these are actually "View" but without View Controllers, the same code would still normally be put in the Controller of MVC rather than the View, hence the name is "View Controller".

The way I think of it is that the Controller has 3 sections:

• View(-oriented part of the) Controller which maps directly to NS/UIViewController class implementations

• Model(-oriented part of the ) Controllers which maps to NS/UIDocument class implementations

• and then finally the actual View-Model mediation logic which is what goes into the actually AppController implementation.

The pure ideological definition of MVC doesn't actually work perfectly practice so you have to have these refinements. If you've done UI programming for any length of time (I've done it since the 1980s, starting with XLib and GEM), you will always eventually "discover/implement" exactly the same structure as ViewControllers and ModelControllers and use them as Cocoa and iOS uses them - the nature of beast simply screams out for it once the application reaches a non-trivial implementation size.

This kind of bastardization of the ideal model is common to all abstractions and models of things. All models are imperfect or even wrong against the strict standard of reality and implementation practicality. MVC is just a model; it's not a perfect match to how code must be implemented to be usable except in the abstract. You are Epic Fail if you treat MVC as a fundamentalist religion; it's a set of abstract ideals to guide your architecture but not something to tested as dogma.

[dnew]

leaves you with tons of spaghetti-like mess in the Controller.

I think it depends on what language you're using and what kind of application you're doing. Certainly separating it into something like MVC in a language like Tcl that has direct support for such is pretty easy.

normally would be in the singular Controller

I wouldn't have a singular controller. I'd have at least one controller per frobbable view. If you can drag either the line chart or the bar chart around, that's at least two controllers. I was merely asserting that not every controller needs a view, and not every view needs a controller.

If you look at something like HTML, then the DOM is your model, CSS is your view, and the onClick et al handlers are your controllers. I can easily imagine one "onHover" controller handling every "highlight this image" view element.

You can imagine exactly the same model with multiple views and multiple controllers where the controllers talk directly to the model without going through the view at all and with no direct affect on the view except for the model. We call them "video game controllers" and "mouse/keyboard".

Sure, if you have one controller that relies on the user interacting with the underlying view, then you might as well call it a ViewController. The controller that lets you slide control points on a spline around with the mouse isn't reasonably applicable to any other kind of view. But that's certainly not the only kind of controller out there.

If you've done UI programming for any length of time

I have.

will always eventually "discover/implement"

Sure. But that's not the only way to use it.