Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MVVM and Mobile, don't do it cause someone told you

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.

Mark Wilkinson

April 20, 2017
Tweet

More Decks by Mark Wilkinson

Other Decks in Programming

Transcript

  1. MVVM AND MOBILE
    DON’T JUST DO IT CAUSE SOMEONE TOLD YOU

    View Slide

  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

    View Slide

  3. MVC

    View Slide

  4. MVC in iOS

    View Slide

  5. MVVM

    View Slide

  6. Notice no room for a View
    Controller…

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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)

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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?)

    View Slide

  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.

    View Slide

  16. Lets see some MvvmCross

    View Slide

  17. The most RAGE INDUCING
    feature you will continue to
    forget early on is the .Apply()
    on each binding.

    View Slide

  18. ViewControllers but not
    really.

    View Slide

  19. VC VM
    View
    What Cross winds up doing

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  24. Lets see some Light
    http://www.thexamarinjournal.com/getting-started-with-xamarin/

    View Slide

  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.

    View Slide

  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 and sets
    that as the ViewModel.
    • Also move the List to this ViewController
    base.
    • Ignore the navigation service and navigate from the
    Activities/ViewControllers using the platform instead.

    View Slide

  27. Lets do that.

    View Slide

  28. VC VM
    View
    What Light winds up doing

    View Slide

  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.

    View Slide

  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.

    View Slide

  31. Problem where none existed.

    View Slide

  32. We already get MVC for free.

    View Slide

  33. Use Light then build on it.

    View Slide

  34. Or Roll your own.

    View Slide

  35. Or use SOLID with MVC.

    View Slide

  36. Proof that SOLID can work
    with MVC
    https://github.com/markawil/
    PatternsExampleiPhoneUserGroup
    https://speakerdeck.com/markawil/solid-coding-in-swift-and-
    ios

    View Slide

  37. The End

    View Slide