I'm an iOS developer and I'm guilty of having Massive View Controllers in my projects so I've been searching for a better way to structure my projects and came across the MVVM (Model-View-ViewModel) architecture. I've been reading a lot of MVVM with iOS and I have a couple of questions. I'll explain my issues with an example.
I have a view controller called LoginViewController
.
LoginViewController.swift
import UIKit class LoginViewController: UIViewController { @IBOutlet private var usernameTextField: UITextField! @IBOutlet private var passwordTextField: UITextField! private let loginViewModel = LoginViewModel() override func viewDidLoad() { super.viewDidLoad() } @IBAction func loginButtonPressed(sender: UIButton) { loginViewModel.login() } }
It doesn't have a Model class. But I did create a view model called LoginViewModel
to put the validation logic and network calls.
LoginViewModel.swift
import Foundation class LoginViewModel { var username: String? var password: String? init(username: String? = nil, password: String? = nil) { self.username = username self.password = password } func validate() { if username == nil || password == nil { // Show the user an alert with the error } } func login() { // Call the login() method in ApiHandler let api = ApiHandler() api.login(username!, password: password!, success: { (data) -> Void in // Go to the next view controller }) { (error) -> Void in // Show the user an alert with the error } } }
My first question is simply is my MVVM implementation correct? I have this doubt because for example I put the login button's tap event (loginButtonPressed
) in the controller. I didn't create a separate view for the login screen because it has only a couple of textfields and a button. Is it acceptable for the controller to have event methods tied to UI elements?
My next question is also about the login button. When the user taps the button, the username and password values should gte passed into the LoginViewModel for validation and if successful, then to the API call. My question how to pass the values to the view model. Should I add two parameters to the login()
method and pass them when I call it from the view controller? Or should I declare properties for them in the view model and set their values from the view controller? Which one is acceptable in MVVM?
Take the validate()
method in the view model. The user should be notified if either of them are empty. That means after the checking, the result should be returned to the view controller to take necessary actions (show an alert). Same thing with the login()
method. Alert the user if the request fails or go to the next view controller if it succeeds. How do I notify the controller of these events from the view model? Is it possible to use binding mechanisms like KVO in cases like this?
What are the other binding mechanisms when using MVVM for iOS? KVO is one. But I read it's not quite suitable for larger projects because it require a lot of boilerplate code (registering/unregistering observers etc). What are other options? I know ReactiveCocoa is a framework used for this but I'm looking to see if there are any other native ones.
All the materials I came across on MVVM on the Internet provided little to no information on these parts I'm looking to clarify, so I'd really appreciate your responses.
Benefits of MVVMBy moving data manipulation to the ViewModel, MVVM makes the testing much easier. Unit testing of ViewModel is easy now, as it doesn't have any reference to the object it's maintained by. Similarly, testing of ViewController also becomes easy since it no longer depends on the Model.
Model-View-ViewModel (MVVM) is a client-side design pattern. It guides the structure and design of your code to help you achieve “Separation of Concerns.” Implementing MVVM requires a bit of a mind-shift in the way you think about the functionality of your application.
The MVVM pattern introduces a fourth component, the view model. The view model is responsible for managing the model and funneling the model's data to the view via the controller. This is what that looks like. Despite its name, the MVVM pattern includes four major components, model, view, view model, and controller.
KEY DIFFERENCE In MVC, controller is the entry point to the Application, while in MVVM, the view is the entry point to the Application. MVC Model component can be tested separately from the user, while MVVM is easy for separate unit testing, and code is event-driven.
waddup dude!
1a- You're headed in the right direction. You put loginButtonPressed in the view controller and that is exactly where it should be. Event handlers for controls should always go into the view controller - so that is correct.
1b - in your view model you have comments stating, "show the user an alert with the error". You don't want to display that error from within the validate function. Instead create an enum that has an associated value (where the value is the error message you want to display to the user). Change your validate method so that it returns that enum. Then within your view controller you can evaluate that return value and from there you will display the alert dialog. Remember you only want to use UIKit related classes only within the view controller - never from the view model. View model should only contain business logic.
enum StatusCodes : Equatable { case PassedValidation case FailedValidation(String) func getFailedMessage() -> String { switch self { case StatusCodes.FailedValidation(let msg): return msg case StatusCodes.OperationFailed(let msg): return msg default: return "" } } } func ==(lhs : StatusCodes, rhs : StatusCodes) -> Bool { switch (lhs, rhs) { case (.PassedValidation, .PassedValidation): return true case (.FailedValidation, .FailedValidation): return true default: return false } } func !=(lhs : StatusCodes, rhs : StatusCodes) -> Bool { return !(lhs == rhs) } func validate(username : String, password : String) -> StatusCodes { if username.isEmpty || password.isEmpty { return StatusCodes.FailedValidation("Username and password are required") } return StatusCodes.PassedValidation }
2 - this is a matter of preference and ultimately determined by the requirements for your app. In my app I pass these values in via the login() method i.e. login(username, password).
3 - Create a protocol named LoginEventsDelegate and then have a method within it as such:
func loginViewModel_LoginCallFinished(successful : Bool, errMsg : String)
However this method should only be used to notify the view controller of the actual results of attempting to login on the remote server. It should have nothing to do with the validation portion. Your validation routine will be handled as discussed above in #1. Have your view controller implement the LoginEventsDelegate. And create a public property on your view model i.e.
class LoginViewModel { var delegate : LoginEventsDelegate? }
Then in the completion block for your api call you can notify the view controller via the delegate i.e.
func login() { // Call the login() method in ApiHandler let api = ApiHandler() let successBlock = { [weak self](data) -> Void in if let this = self { this.delegate?.loginViewModel_LoginCallFinished(true, "") } } let errorBlock = { [weak self] (error) -> Void in if let this = self { var errMsg = (error != nil) ? error.description : "" this.delegate?.loginViewModel_LoginCallFinished(error == nil, errMsg) } } api.login(username!, password: password!, success: successBlock, error: errorBlock) }
and your view controller would look like this:
class loginViewController : LoginEventsDelegate { func viewDidLoad() { viewModel.delegate = self } func loginViewModel_LoginCallFinished(successful : Bool, errMsg : String) { if successful { //segue to another view controller here } else { MsgBox(errMsg) } } }
Some would say you can just pass in a closure to the login method and skip the protocol altogether. There are a few reasons why I think that is a bad idea.
Passing a closure from the UI Layer (UIL) to the Business Logic Layer (BLL) would break Separation of Concerns (SOC). The Login() method resides in BLL so essentially you would be saying "hey BLL execute this UIL logic for me". That's an SOC no no!
BLL should only communicate with the UIL via delegate notifications. That way BLL is essentially saying, "Hey UIL, I'm finished executing my logic and here's some data arguments that you can use to manipulate the UI controls as you need to".
So UIL should never ask BLL to execute UI control logic for him. Should only ask BLL to notify him.
4 - I've seen ReactiveCocoa and heard good things about it but have never used it. So can't speak to it from personal experience. I would see how using simple delegate notification (as described in #3) works for you in your scenario. If it meets the need then great, if you're looking for something a bit more complex then maybe look into ReactiveCocoa.
Btw, this also is technically not an MVVM approach since binding and commands are not being used but that's just "ta-may-toe" | "ta-mah-toe" nitpicking IMHO. SOC principles are all the same regardless of which MV* approach you use.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With