Posts Tagged ‘iOS Patterns’
MVC, MVP and MVVM Patterns on iOS
A software pattern is a template for solving a repeatable problem. Any user facing client app can be broadly composed of three main layers –
· The Presentation / UI Layer: Layer that a user interacts with.
· The Business Logic Layer: Layer that handles the data model and interactions for local/remote databases
· The Application Logic Layer : The glue between the Presentation and Business Logic Layers.
The Model View Controller (MVC):
The MVC is a well-known architectural pattern used for building iOS Apps.
· The View , which is generally not passive, corresponds to the Presentation Layer
· The Model , corresponds to the Business Logic Layer
· The Controller sits between the View and the Model , corresponds to the Application Logic Layer.
However, the controller becomes the catch-all for everything that isn’t exactly a UI control or a data model, leading to the “Massive View Controller” issue.
Two popular alternatives to the MVC pattern are the MVP and MVVM patterns, both of which are essentially variants of the MVC pattern.
The Model View Presenter (MVP):
The MVP defines the following
· The View , which is generally passive, corresponds to the Presentation Layer
· The Model , corresponds to the Business Logic Layer and is identical to the MVC pattern
· The Presenter sits between the View and the Model , corresponds to the Application Logic Layer.
A View is typically associated with one Presenter.
In iOS, the interaction between the View and Presenter can be implemented using the Delegation Pattern (https://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html). The Delegation Pattern allows one object to delegate tasks to another object. In iOS, the pattern is implemented using a Protocol. The Protocol defines the interface that is to be implemented by the delegate.
In the MVP pattern, the View and Presenter are aware of each other. The Presenter holds a reference to the view it is associated with.
The PresenterProtocol defines the base set of methods that any Presenter must implement. Applications must extend this Protocol to include application specific methods.
|
1 2 3 4 |
protocol PresenterProtocol: class{ func attachPresentingView(_view:PresentingViewProtocol) func detachPresentingView(_view:PresentingViewProtocol) } |
The PresentingViewProtocol defines the base set of methods that View must implement. By providing default implementation of the methods in this interface, the conformant view does not have to provide its own implementation. This interface can be extended to define application specific methods.
|
1 2 3 4 5 6 |
protocol PresentingViewProtocol: class{ func dataStartedLoading() func dataFinishedLoading() func showErrorAlertWithTitle(_title:String?, message:String) func showSuccessAlertWithTitle(_title:String?, message:String) } |
The Model View View Model (MVVM) :
.png)
The MVVM defines the following
· The View , which is generally passive, corresponds to the Presentation Layer
· The Model , corresponds to the Business Logic Layer and is identical to the MVC pattern
· The View Model sits between the View and the Model , corresponds to the Application Logic Layer.
The key aspect of the MVVM pattern is the binding between the View and the View Model. In other words, the View is automatically notified of changes to the View Model.
In iOS, this can be accomplished using Key-Value-Observer (KVO) Pattern. In the KVO Pattern (https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html) , one object is automatically notified of changes to the state of another object. In Objective C, this facility is built into the run-time. However, it’s not as straightforward in Swift. One option would be to add the “dynamic” modifiers to properties that need to be dynamically dispatched. However, this is limiting as objects now need to be of type NSObject. The alternate is to simulate this behavior by defining a generic type that acts as a wrapper around properties that are observable.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
public struct DynamicType<T> { typealias ModelEventListener = (T)->Void typealias Listeners = [ModelEventListener] private var listeners:Listeners= [] var value:T? { didSet{ for(_,observer) inlisteners.enumerated() { if let value = value{ observer(value) } } } } mutating func bind(_listener:@escaping ModelEventListener) { listeners.append(listener) if let value = value{ listener(value) } } } |
The View can “bind” an appropriate callback to the ViewModel by using the “bind” method on the DynamicType. Every time the property value changes, the callback is automatically invoked.
Code and More:
A sample app that showcases the implementation of the MVC, MVP and MVVM pattern is available on GitHub at https://github.com/rajagp/iOS_MVC_MVP_MVVM_SampleApp
Slides from a related talk on supporting the MVP and MVVM patterns in iOS apps can be downloaded from iOS_MVP_MVVM_Patterns .