Models in iOS programming describing MVVM as MCV’s natural evolution step Andrei Popa
Modelsin iOS programming describing MVVM as MCV’s natural evolution step
Andrei Popa
Agenda1) Separation of Concerns 2) MVC 3) Problems with MVC 4) MVVM - describing MVVM as MCV’s natural evolution step 5) ReactiveCocoa as binding solution in iOS 6) Android correspondence, MVP
Andrei Popa
In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern.
When concerns are well-separated, individual sections can be reused, as well as developed and updated independently.
Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.
separation of concerns
Separation of concerns is an important design principle in many other areas as well, such as urban planning, architecture and information design.
The goal is to more effectively understand, design, and manage complex interdependent systems, so that functions can be reused, optimized independently of other functions, and insulated from the potential failure of other functions.
separation of concerns
MVC or MVP can separate content from presentation
MVVM can separate data gathering / logic / transforming from the complexities of a view controller.
separation of concerns
M-V-C (Model View Controller)• a proven pattern for organizing your code in complex
application design, also the Apple recommended way of programming an app
• defines the roles objects play in the application
• It’s also proven to have a second meaning in iOS development: Massive View Controller
• Apple hasn’t provided any real guidance on how to solve the Massive View Controller problem
M-V-C
• God object
• Responsible for the actual UI (whether that means UIView code, storyboards, or xibs), any view specific logic, and reaction to user input
• This includes a lot of the responsibilities handled by the UIViewController in iOS, not just UIView code and files
Massive View Controller
M-V-VM• MVVM stands for Model View View-Model, and it’s here to
help us create more manageable, better designed code.
• The testability and separation of concerns are some of the good things that come out of this particular pattern.
• MVVM is a pattern to separate the concern of presentation from domain.
• Developed by Microsoft's for WPF and Silverlight architecture, and currently the pattern of choice for Windows Phone Development
M-V-VM
M-V-VM
• This leaves the view (controller) with a more clearly defined task of presenting the data supplied by the view-model.
• The view-model exposes the minimum information necessary to our view controller, and the view controller really doesn’t care how the view-model got that information.
M-V-VM
M-V-VM
• View independent representation of business entities
• Represents the data layer
• Responsible for fetching / storing the data • CoreData / Realm / Parse / … • JSON • Encryption
M-V-VM (Model)
M-V-VM (viewModel)• In some of the WWDC videos this year, viewModels were actually
spotted in the sample code apple engineers had on screen.
• One of its responsibilities is that of a static model representing the data necessary for the view to display itself; but it’s also responsible for gathering, interpreting, and transforming that data.
• Kicking off network or database requests • Determining when information should be hidden or shown • Localization • Date and number formatting
• It is NOT acting directly on the view controller in any form or notifying it directly of changes
M-V-VM (viewModel)
• MVVM and MVC share a common weakness: neither defines where the network logic of an app should go.
• Add the networking logic in the viewModel
• View models are (mostly) platform-agnostic.
• It applies logic and massages the data from the model into presentation data for the view (controller).
• It exposes (usually via properties) only the information the view controller needs to know about to do its job of displaying the view (ideally you are not exposing your data-model objects).
• It is NOT acting directly on the view controller in any form or notifying it directly of changes
M-V-VM (viewModel)
• The view controller’s only concerns are: • configuring and managing the various views with data from the
view-model
• letting the view-model know when relevant user input occurs that needs to change data upstream
• Layout / Animations / Device rotations / View transitions
• Inject viewModel to viewController during init
• The view controller doesn’t need to know about anything else
M-V-VM (view / UIViewController)
• ViewModel becomes extremely unit testable. If you have methods that should generate the same output every time they are supplied the same input (pure functions), that fits extremely well into the world of unit tests.
• We now have our data gathering / logic / transforming extracted away from the complexities of a view controller.
• When the view model needs to communicate something to the view, it does so through a system of data bindings
M-V-VM (Advantages)
Data bindingsWhat about when data on the view-model changes?
Data bindings
Data bindings
A signal takes all those async methods for controlling the flow of information through your app (delegates, callback blocks, notifications, KVO, target/action event observers, etc) and unifies them under one interface.
Stateless binding using ReactiveCocoa
In some cases you can eliminate even more state on your view-model by exposing RACSignals instead of properties like strings and images.
Then your view controller wouldn’t have to create its own with RACObserve, and could just leverage those signals straightaway.
ReactiveCocoa
• By modeling changes as signals, the view model can communicate to the view without actually needing to know that it exists
• similarly for model → view model communication
• This decoupling is why view models can be tested without a view in place — the test simply needs to connect to the VM's signals and verify that the behavior is correct.
M-V-VM
• Framework inspired by Functional Reactive Programming
• Fancy bindings
• Event streams unify all of Cocoa’s common patterns for asynchrony and event handling
• Mature, production-ready framework
• Wide-adoption by top-class developers
ReactiveCocoa
• The Model-View-Presenter-pattern (MVP) has been the dominating trend lately when it comes the UI-layer architecture of Android applications.
• Data Binding, as announced on Google I/O 2015 changes everything.
• https://developer.android.com/tools/data-binding/guide.html
• https://github.com/ReactiveX/RxAndroid
MVVM on Android
• Data Binding framework will take over the main responsibilities of the Presenter (“acting upon the model and the view”), while the remainder is left to the enhanced Model – the ViewModel (“retrieving data from repositories and formatting”).
• The ViewModel is a standard Java class whose sole responsibility is to represent the data behind a single View. It can merge data from multiple sources (Models) and prepare that data for presentation.
MVVM on Android
Thank you!Q&A