Models used in iOS programming, with a focus on MVVM

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 eﬀectively 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 • deﬁnes 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

• God object • Responsible for the actual UI (whether that means UIView code, storyboards, or xibs), any view speciﬁc logic, and reaction to user input • This includes a lot of the responsibilities handled by the UIViewController in iOS, not just UIView code and ﬁles 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

• This leaves the view (controller) with a more clearly deﬁned 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

• 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 oﬀ 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 deﬁnes 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: • conﬁguring 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 ﬁts 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?

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

Models used in iOS programming, with a focus on MVVM

More Related Content

What's hot

Similar to Models used in iOS programming, with a focus on MVVM

Recently uploaded

Models used in iOS programming, with a focus on MVVM