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.

Transcript

1. MVVM AND MOBILE DON’T JUST DO IT CAUSE SOMEONE TOLD YOU
2. MVVM History • Came from Microsoft, mainly to help sell 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
3. MVC
4. MVC in iOS
5. MVVM
6. Notice no room for a View Controller…
7. What’s the difference? 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 properties.
8. 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 StackOverflow. A lot of the times, it’s not worth the extra hours and days just to have a popular design pattern.
9. MVVM Overkill • Remember it was specifically created for Xaml 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.
10. Some options • Mvvm Cross (generally the most popular, more features, but more complexity) • MvvmLight (name says it all, I like this one) • Caliburn Micro (what I originally learned as a .NETer)
11. Mvvm Cross • 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
12. Cross continued… • 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 filling in their dependencies.
13. 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 app crashes.
14. Navigation • 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 default. (lulzWat?)
15. 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 workflows NOT needing a custom presenter. • Storyboards are pointless, might as well just use xibs that you get for every new view you create.
16. Lets see some MvvmCross
17. The most RAGE INDUCING feature you will continue to forget early on is the .Apply() on each binding.
18. ViewControllers but not really.
19. VC VM View What Cross winds up doing
20. Lessons Learned • Debugging can get rough, many exceptions seem 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.
21. Continued • You can’t use Segues, you’ll literally just have floating 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.
22. Mvvm Light • 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 definitely prototype faster with Light than my previous experience with Cross and Caliburn.
23. 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 dependencies.
24. Lets see some Light http://www.thexamarinjournal.com/getting-started-with-xamarin/
25. WooT! • No Xibs! • Storyboard Segues are fine 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.
26. Light means more work • But that’s a good thing, 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.
27. Lets do that.
28. VC VM View What Light winds up doing
29. 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.
30. Final thoughts • On-boarding for Cross was difficult 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 framework, etc). • If you’re team is new to either mobile or Mvvm there will be some hurdles. • You’ll spend time fighting with the framework to figure out basic things like navigation.
31. Problem where none existed.
32. We already get MVC for free.
33. Use Light then build on it.
34. Or Roll your own.
35. Or use SOLID with MVC.
36. Proof that SOLID can work with MVC https://github.com/markawil/ PatternsExampleiPhoneUserGroup https://speakerdeck.com/markawil/solid-coding-in-swift-and- ios
37. The End