MVVM is an overrated pattern that is abused more than used properly, forcing it on native mobile projects like Xam.ios and Xam.And makes little sense, when good quality clean coding practices with MVC are sufficient.
MVVM AND MOBILE
DON’T JUST DO IT CAUSE SOMEONE TOLD YOU
• Came from Microsoft, mainly to help sell the Xaml/
• MVC is kind of weak, and doesn’t promote good
practices, iOS-Cocoatouch is an example.
• Winforms was from the Devil, so anything new was
• Winforms had binding, but impossible (almost) to
MVC in iOS
Notice no room for a View
What’s the diﬀerence?
MVC is a little less strict in it’s requirements, in reality MVC is
more like VC.
Most of the time all work is done in the controller, the controller
then has the responsibility to update the View.
In MVVM, the View has the power to bind to properties on the
ViewModel (not the model).
This frees up responsibilities of the VM (the middle layer)
When properly used, the VM simply hosts bindable/observable
Caveats of MVVM
It’s always a new framework you have to learn, and
setup can be a pain.
Each one is differently opinionated.
on Xamarin, exceptions get swallowed up, you’ll
probably be married to their docs and StackOverﬂow.
A lot of the times, it’s not worth the extra hours and days
just to have a popular design pattern.
• Remember it was speciﬁcally created for Xaml
• Forcing it on other platforms (like Xamarin
Classic) isn’t a guarantee of any kind of app
• In fact, it could be a hinderance in getting a
quality app out the door when there’s a deadline.
• Mvvm Cross (generally the most
popular, more features, but more
• MvvmLight (name says it all, I like this
• Caliburn Micro (what I originally
learned as a .NETer)
• Feels like you have little control from the
get-go, intensive on-boarding
• But handles everything you can imagine
you’d need in an Mvvm Architecture
• Strictly follow it’s rules or you have to
create your own implementations, and
they can get complex.
• It’s a View -> ViewModel order
• Views are associated with ViewModels by naming
convention out of the box, much like Caliburn.
• You can ignore this and use the Generics version of
View-ViewModel binding which I highly recommend.
• In Summary, you build your Views and corresponding
ViewModels, then hand the keys (and whole car) over
to MvX to let it handle creating views, binding their
view models and ﬁlling in their dependencies.
• You also are advised to use Interfaces and Dependency
Injection powered by their IoC container.
• Not a bad thing, most Mvvm frameworks do this.
• Just know that if you are not Interface-Dependency-driven
savvy you have some steep learning to do.
• Remember, you’re not in control of creating a ViewModel, so
the dependencies it needs (if in it’s constructor) come from the
framework’s service locator.
• You must in turn register those dependencies at startup or the
• It completely controls the navigation in the app and
how views are presented, no segues allowed, only
transition for free is the navigation push.
• Any, and I mean ANY change you want in presentation
and you need to roll your own presenter.
• Embeds every view it creates inside a NavController by
Cross Nav continued
• Nav from View to View is really ViewModel to
ViewModel, one ViewModel asks another to be shown.
• The Presenter will become the brain of the app
(cough… God class), and you will become intimately
familiar with their presentation logic.
• I cannot imagine a real functioning app with multiple
views and navigation workﬂows NOT needing a
• Storyboards are pointless, might as well just use xibs
that you get for every new view you create.
Lets see some MvvmCross
The most RAGE INDUCING
feature you will continue to
forget early on is the .Apply()
on each binding.
ViewControllers but not
What Cross winds up doing
• Debugging can get rough, many exceptions seem to get
swallowed and just say to the effect of “something bad
• The Presenter will occupy a good chunk of your time if you
have a SplitViewController, TabController, Slide Out (Hamburger
• You will have to create a ViewsContainer and tell the framework
the Storyboard for EVERY ViewModel it is requested to make.
• You’ll end up with a very large method and a ton of if-elseif
statements depending on how many Views you have.
• You can’t use Segues, you’ll literally just have ﬂoating
Views inside Storyboards (negating the power of SBs).
• MvX handles all navigation even if you’re using a
• UITableViews and binding for custom cells can get
tricky, depending on how complex your cell is.
• Need to be comfortable with Generics,
INotifyPropertyChanged usage, lambdas, and Inversion
• The Light in the title is honest.
• Although you still give over most control of the app to
the framework, much like Cross, but this optional.
• Minimalist intrusion is the aim, and you can deﬁnitely
prototype faster with Light than my previous
experience with Cross and Caliburn.
Basics of Light
• NavigationService - Seems to be the brain of handling
viewModel to viewModel transitions.
• ViewModelLocator - Junk drawer for all your
references and registrations of your viewModels.
• SimpleIoC - does what it says, handles your
Lets see some Light
• No Xibs!
• Storyboard Segues are ﬁne but you have to forgo their
Navigation stack. View-ViewModel binding still works.
• ViewControllers do not need a Base
• Can focus just on building good ViewModels, let the
platform handle View creation and navigation.
Light means more work
• But that’s a good thing, plenty of room for early on
• First obvious improvement is to make a ViewController
base class that uses a Generic Parameter and sets
that as the ViewModel.
• Also move the List to this ViewController
• Ignore the navigation service and navigate from the
Activities/ViewControllers using the platform instead.
Lets do that.
What Light winds up doing
What do you want?
• Are you already familiar with powerful Mvvm
frameworks like Cross and Caliburn? You should
probably use those.
• Are you new to Mvvm or dislike giving up control for
complexity? You’ll like MvvmLight.
• There seems to be a correlation to power and
complexity with these frameworks.
• On-boarding for Cross was difﬁcult with the last team I was
on, no one was familiar with it.
• Took about 2-3 weeks for the 5 of us (2 Android, 3 iOS) to get
comfortable and start knocking out complex stories (like
custom navigation, learning UIKit integration with the
• If you’re team is new to either mobile or Mvvm there will be
• You’ll spend time ﬁghting with the framework to ﬁgure out
basic things like navigation.
Problem where none existed.
We already get MVC for free.
Use Light then build on it.
Or Roll your own.
Or use SOLID with MVC.
Proof that SOLID can work