MVVM and Mobile, don't do it cause someone told you
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.
the Xaml/ WPF stack • 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 appreciated • Winforms had binding, but impossible (almost) to test
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 properties.
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.
and .NET • Forcing it on other platforms (like Xamarin Classic) isn’t a guarantee of any kind of app stability. • In fact, it could be a hinderance in getting a quality app out the door when there’s a deadline.
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
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.
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 app crashes.
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 default. (lulzWat?)
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 custom presenter. • Storyboards are pointless, might as well just use xibs that you get for every new view you create.
to get swallowed and just say to the effect of “something bad happened.” • The Presenter will occupy a good chunk of your time if you have a SplitViewController, TabController, Slide Out (Hamburger Menu), etc. • 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.
ﬂoating Views inside Storyboards (negating the power of SBs). • MvX handles all navigation even if you’re using a custom Presenter. • 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 of Control.
• 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.
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 dependencies.
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.
plenty of room for early on customization. • First obvious improvement is to make a ViewController base class that uses a Generic Parameter <T> and sets that as the ViewModel. • Also move the List<Binding> to this ViewController base. • Ignore the navigation service and navigate from the Activities/ViewControllers using the platform instead.
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.
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 framework, etc). • If you’re team is new to either mobile or Mvvm there will be some hurdles. • You’ll spend time ﬁghting with the framework to ﬁgure out basic things like navigation.