6 ms·

iOS application architecture: MVVM, behaviors, singletons, subclassing

126 points by floriankugler 12y ago

tunesmith 12y 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.
wsc981 12y 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 http://www.objc.io/issue-13/behaviors.html
kar-kub 12y 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 12y 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 12y 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.
- mattgreenrocks 12y 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/2013/01/the-framework-superclass-anti-pattern.html http://michaelfeathers.typepad.com/michael_feathers_blog/201...
- AshFurrow 12y 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 12y 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.
mattgreenrocks 12y 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.
- mpweiher 12y 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 12y 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_b 12y ago
      There's no silver bullet method. If you do MVVM on an app that is sparse on input controls or text labels it's overkill. MVVM shines where you have a lot of data going back and forth in screens combined from different models and you want to be able to test everything you see. If you are doing an app that is much more graphical in nature and the models that feed it are not really mapping to databases or web services they gel much more natural with your UI and mixing them up with each other is no problem at all. I enjoyed MVVM a lot in WPF especially because of the two-way binding it provided. That was in an application that managed health care records so it was very text heavy and a lot of screens were taking context from Models left and right. We went with full MVVM for complex screens and direct Model mapping when we had a screen where you would edit just a support table, like a list of doctors or treatment types.
simplestyle 12y ago
This is great. Is there something equivalent for Android?
taspeotis 12y 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/ http://www.codeproject.com/Articles/566270/ [2] Out-of-the-box it appears to have a global service locator and no constructor injection.
- mstromb 12y ago
  I prefer ReactiveUI: https://github.com/reactiveui/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 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/ http://log.paulbetts.org/
- tobinharris 12y 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.
  - taspeotis 12y 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 12y 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 12y 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 12y 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.

126 points by floriankugler 12y 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.

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

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

mattgreenrocks 12y 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/2013/01/the-framework-superclass-anti-pattern.html http://michaelfeathers.typepad.com/michael_feathers_blog/201...
AshFurrow 12y 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 12y 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.

mattgreenrocks 12y 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.

mpweiher 12y 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 12y 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_b 12y ago
    There's no silver bullet method. If you do MVVM on an app that is sparse on input controls or text labels it's overkill. MVVM shines where you have a lot of data going back and forth in screens combined from different models and you want to be able to test everything you see. If you are doing an app that is much more graphical in nature and the models that feed it are not really mapping to databases or web services they gel much more natural with your UI and mixing them up with each other is no problem at all. I enjoyed MVVM a lot in WPF especially because of the two-way binding it provided. That was in an application that managed health care records so it was very text heavy and a lot of screens were taking context from Models left and right. We went with full MVVM for complex screens and direct Model mapping when we had a screen where you would edit just a support table, like a list of doctors or treatment types.

simplestyle 12y ago

This is great. Is there something equivalent for Android?

taspeotis 12y 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/ http://www.codeproject.com/Articles/566270/ [2] Out-of-the-box it appears to have a global service locator and no constructor injection.

mstromb 12y ago
I prefer ReactiveUI: https://github.com/reactiveui/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 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/ http://log.paulbetts.org/
tobinharris 12y 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.
- taspeotis 12y 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 12y 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 12y 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 12y 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.