iOS application architecture: MVVM, behaviors, singletons, subclassing
1–10 of 36 posts
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#2Great 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].
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#3I'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.
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#4I'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.
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.
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#5The 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.
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#6It 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.
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#7The 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 t…
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...
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#8The 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 t…
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.
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#9This is great.
Is there something equivalent for Android?
Re: iOS application architecture: MVVM, behaviors, singletons, subclassing
#10It 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 abs…
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...