
iOS application architecture: MVVM, behaviors, singletons, subclassing - floriankugler
http://www.objc.io/issue-13
======
mattgreenrocks
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.

~~~
mpweiher
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...

~~~
dep_b
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.

~~~
mpweiher
Hmm..you are talking letting the view "change the values in the Model".

I thought "the view was not allowed to talk to the model, instead it _had to
be fed pre-digested info by the controller_ " made it clear that I was talking
about updating the view from the model, not vice versa.

In MVC, the controller initiates changes in the model, not the view. However,
the view updates itself from the model.

Whether that's good or bad is a different story, but that's how MVC is
defined.

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

~~~
AshFurrow
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
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.

------
kar-kub
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
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.

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

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

------
taspeotis
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/](http://www.codeproject.com/Articles/566270/)

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

~~~
tobinharris
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.

~~~
taspeotis
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

------
wsc981
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](http://www.objc.io/issue-13/behaviors.html)

------
simplestyle
This is great.

Is there something equivalent for Android?

------
pistle
"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.

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

