iOS application architecture: MVVM, behaviors, singletons, subclassing

http://www.objc.io/issue-13

by floriankugler • 12 years ago

126 35 12 years ago

objc.io

wsc981• 12 years ago

Great articles for issue 13 and the rest of the website seems interesting too (past issues included).

Would have been nice to see the actual implementation / code of the Parallax Scrolling Behavior example[0].

[0] http://www.objc.io/issue-13/behaviors.html

kar-kub• 12 years ago

I'm very glad, as iOS developer, that community focus more and more on good iOS architecture. Few years back, in my impression, it was hard to find good article bout this topic, if any. I'm really happy that objc.io is clearing that path with great developers willing to share theirs experience.

joncooper• 12 years ago

Agreed. As you work with the libraries you run across many different ways of doing things, and folks often just use the last one they saw instead of working to understand the options and making a choice on purpose. I'm thinking especially of messaging patterns, event handling (especially gestures), working with the view hierarchy, etc.

tangozulu• 12 years ago

The MVVM and other ideas in the issue are, at the core, about broadening what the definition of "model" means in an app. The authors seem to think "model" currently is just the data store of an app. But that's never been correct.

The model in MVC is the aspect of the real world that's being reflected in the app. This can and should include network communications and business logic. The architectural issues here are that people are mis-using the idea of a model.

mattgreenrocks3• 12 years ago

That's just the fat model approach. It suffers from similar issues as fat controllers, whereby unrelated functionality tends to accumulate.

Why do models know how to persist themselves? Or send themselves over the network? What does that have to do with the concept they represent? It conflates technical concerns ("how do I serialize myself?") with business concerns ("am I valid?").

It doesn't help that Core Data forces you into the framework superclass antipattern: http://michaelfeathers.typepad.com/michael_feathers_blog/201...

AshFurrow• 12 years ago

Hi there – I wrote the MVVM article, and I see your point. There is a line to be drawn somewhere, but that's often up to the developer. However, on iOS, models tend to be very thin, through convention (typically, they're only a Core Data "managed object" and have no logic at all in them). I hope that helps clarify where the article is coming from.

Glide• 12 years ago

Hmm... If I may say so I find that the MVVM pattern in iOS to be very cumbersome when compared to how it can be done in WPF. You essentially need another layer of indirection in iOS where you need none in WPF. That's probably why I personally haven't heard about it before in CocoaTouch land.

And I guess technically it's MVVCVM.

mattgreenrocks3• 12 years ago

It is interesting that iOS apps suffer the same sort of runaway complexity that often plagues Rails apps, whereby the controller absorbs too much responsibility and becomes unmanageable. This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller.

This points to a lack of developer education surrounding architecture and design. Most projects have too few abstractions, and/or a weak domain model. The Internet likes to complain about Java-style over-abstraction, but I've never seen that.

I think devs don't like to think about architecture because it implies they're not doing things well, it is highly subjective, and they don't see the benefits immediately. All of these are poor reasons.

mpweiher2• 12 years ago

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs.

In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller. Hmm...

21echoes• 12 years ago

and you'll also notice that the linked article says the same thing (that the model and view never touch each other but instead communicate through the controller)... I've always learned MVC as strict separation of model and view, but I've recently heard more and more people saying that they think they should talk.

dep_b4• 12 years ago

I think your junior dev shows some promise. Maybe too orthodox in his thinking or taking wrong conclusions from the right info, but at least a hopeful glimmer of understanding.

I think the upper limit of possibilities a View should have interacting with a Model for me is the point where your View and Model map 1:1 and the user is able to update the fields of the Model represented in your View. You might argue that in some cases it's better to just let the View not only read the Model and represent it but also let it change values in the Model or even create a new one.

But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View.

I also like to argue that there could be something between the Controller and the View that handles specific chores like input validation and creation of objects from input fields. You have the opportunity to add Objects to your Storyboards for just that reason.

ktran03• 12 years ago

You are thinking of the traditional conception of MVC, where the model notifies the views of updates and changes (i.e. they can talk to each other)

Cocoa does not use the traditional notion of MVC.

All documented here very clearly

MVC as a Compound Design Pattern: https://developer.apple.com/library/ios/documentation/genera...

"The controller object in this compound design pattern incorporates the Mediator pattern as well as the Strategy pattern; it mediates the flow of data between model and view objects in both directions. Changes in model state are communicated to view objects through the controller objects of an application."

coldtea• 12 years ago

This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller.

Well, you're supposed to have a different controller for every major view.

And said controller can always delegate to some object model specific to your app.

matwood• 12 years ago

I completely agree. Years ago when starting an iOS app I suggested a few abstractions to the other devs and got the response that 'this is not an enterprise application.' The problem is that a complex iOS application can quickly become a lot of code. It is compounded by the fact that a lot of that code ends up in the view controllers.

simplestyle• 12 years ago

This is great.

Is there something equivalent for Android?

tunesmith• 12 years ago

Skimming the MVVM article from a web programmer perspective is really interesting because it is conceptually the same thing as introducing a "service" layer between your controller layer and your dao/repository layer.

Which is generally a good idea, and has lots of benefits, including better testability.

It's another example of how "Model" is a vastly overloaded term, to the point of being almost meaningless. Depending on who's talking, a model is: a database entity representation, a domain logic container, an everything-but-controller-logic holder, a DTO from dao to service, a message from service to controller, a command object from controller to view.

taspeotis2• 12 years ago

If you're enamoured with MVVM and know C# you might consider trying out Xamarin + MvvmCross [1]. I'm using it on a few projects and the code shared across platforms is (ballpark) 70-90% depending on the size of the project.

Xamarin's come out with Xamarin.Forms which looks like it could supersede MvvmCross but I gave it a shot and it's pretty immature right now. Plus its dependency injection leaves a little to be desired [2].

[1] http://www.codeproject.com/Articles/566270/

[2] Out-of-the-box it appears to have a global service locator and no constructor injection.

mstromb• 12 years ago

I prefer ReactiveUI: https://github.com/reactiveui/ReactiveUI (though you can use it together with MvvmCross)

It might be an unfair comparison as MvX is a much older project but it felt more like something cobbled together over time than something really thought out. I also really like the reactive approach - your view model describes the relationships between its properties as they change rather than have a morass of interlinked event handlers.

Paul Betts is pretty active within the portable-C# community, with multiple active projects: https://github.com/paulcbetts and has a pretty good blog, where at the moment he's going back through the RxUI docs: http://log.paulbetts.org/

tobinharris• 12 years ago

Do I need still need to spend $17,091 a year to equip 3 developers with reasonably unrestricted Xamarin on 3 iOS, Android and Windows Phone? Or $8,991 if I don't care for hot fixes.

taspeotis2• 12 years ago

Xamarin doesn't cost anything for Windows Phone. Xamarin Indie is reasonably unrestricted, but let's just go with Business for now:

    Order Summary
    Xamarin.Android Business    999    × 3    2997.00
    Xamarin.iOS Business        999    × 3    2997.00
                                            $5,994.00
    Multiple Licenses                  10%    –599.40
                                               Total:
                                            $5,394.60

cmicali• 12 years ago

I think part of the reason that most apps don't use these techniques is that there are not enough examples.

The examples that are available on SO, the apple docs, and IB generated/influenced code work great for the simple case but fall down a bit when your app grows. there are much better and simpler ways to handle some of the common patterns in large apps, for example the great thin view controllers article.

Objc.io is a fantastic resource.

adamconroy• 12 years ago

Where I come from, friends don't let friends use singletons (drugs are okay though).

Show me a singleton and I'll show you a doubleton, no wait, its a tripleton....

pistle• 12 years ago

"Instead of focusing on the historical context of where MVVM came from, let’s take a look at what a typical iOS app looks like and derive MVVM from there..."

because that would turn off the readers.

iOS application architecture: MVVM, behaviors, singletons, subclassing

Related Stories