Considerations in implementing MVVM in iOS with Swift

I’ve been researching iOS design patterns searching for new techniques for writing correct, fault-tolerant, and maintainable code as quickly as possible, and I’ve realized a terminological inexactitude has led to some confusion in design discussions I’ve had in the past. I think most people may be talking about implementing a layer of abstraction between the view controller and the model, delegating querying the model for information. This has it’s uses, but what I’ll be covering here is placing a layer of abstraction between the view and controller and calling that a view model.

One popular approach to application architecture in iOS is known as MVVM, or Model-View-ViewModel, developed by Microsoft around 2005. What I thought a view model was about was a “model” of a UIView’s desired input. Roughly, the “view model” of a UILabel would be a String, because you can set and get the string of the label. So imagine you had a custom UIView that looks something like this:

class ProfileView: UIView {
 @IBOutlet weak var userImageView: UIImageView!
 @IBOutlet weak var nameLabel: UILabel!
 @IBOutlet weak var biographyTextView: UITextView!
}

Instead of exposing the image view, label, and text view to the user of this class, which is desirable because the implementation of label or text view or that might very well change in the future, you “model” this view with a lightweight structure that looks something like this:

struct Model {
 let userImage: UIImage?
 let fullName: String?
 let biography: String?
}

Which enables you label the subviews of profile view as private and to write a derived property on your profile view that looks like this:

var model: Model? {
 get {
  return Model(userImage: userImageView.image,
  fullName: nameLabel.text,
  biography: biographyTextView.text)
 }
 set {
  userImageView.image = model?.userImage
  nameLabel.text = model?.fullName
  biographyTextView.text = model?.biography
 }
}

This allows you to hide the implementation of the view to users of it, define how you want the input of a view to be structured (“full name” or “first name” and “last name”, for instance), and you can then write extensions on your actual model layer to get the input you want. Like this, for instance:

class User {
 var image: UIImage?
 var firstName: String?
 var lastName: String?
 var biography: String?
}

extension User {
 var profileViewModel: ProfileView.Model {
   return ProfileView.Model(userImage: image,
                            fullName: "\(firstName) \(lastName)",
                            biography: biography)
 }
}

Another way of implementing this pattern that might have some benefits if you’re interested in testing is with protocols. You won’t be able to add the model as a nested class of your view, which can make organizing code easier. Instead of having the view model generated in an extension, you could make the view model a protocol:

protocol ProfileViewModelProtocol {
 var userImage: UIImage? { get }
 var fullName: String? { get }
 var biography: String? { get }
}

And then instead of making the view model a derived property on the user, you add conformance to this protocol in an extension on your model:

extension User: ProfileViewModelProtocol {
 var userImage: UIImage? {
   return image
 }
 var fullName: String? {
   return "\(firstName ?? "") \(lastName ?? "")"
 }
 var biography: String? {
   return bio
 }
}

And then the property of the profile view becomes something like this:

 var model: ProfileViewModelProtocol? {
  didSet {
    userImageView.image = model?.userImage
    nameLabel.text = model?.fullName
    biographyTextView.text = model?.biography
   }
 }

But this only defines communication one way. Models change. So how does this approach to MVVM tackle that? Let’s say the user can modify the biography in this profile. We’ll need to implement UITextViewDelegate on ProfileView and define a ProfileViewDelegate:

protocol ProfileViewDelegate: NSObjectProtocol {
 func biographyDidChange(_ biography: String)
}

class ProfileView: UIView, UITextViewDelegate {
  /* ... */
 weak var delegate: ProfileViewDelegate?
 
 func textViewDidChange(_ textView: UITextView) {
   delegate?.biographyDidChange(textView.text)
 }
}

And the pattern all comes together in our hypothetical ProfileViewController:

class ProfileViewController: UIViewController, ProfileViewDelegate {
 @IBOutlet fileprivate weak var profileView: ProfileView!
 var user: User?
 override func viewDidLoad() {
   super.viewDidLoad()
   profileView.model = user
 }
 
 func biographyDidChange(_ biography: String) {
   user?.bio = biography
   // inform API
 }
}

To make this version clear, here’s a nice graphic I made for you:

This graphic makes the benefits clear in that there’s a level of abstraction in-between the view and the controller which is responsible for translating between the model layer and the view layer. If I find a good example of the other variety of MVVM, I’ll investigate and write up a post about it. Here’s a playground with all the code from this post.

Getting Laravel to use the Bootstrap 4 Alpha

I’m developing a Markdown-based notes taking platform with Laravel, and I want it to use all the latest and greatest CSS framework: the Boostrap 4 Alpha. To get this set up, I had to learn how web applications and Laravel maintains dependancies and packages code. The default site that Laravel generates has some links on the default page, and if you add the built-in authentication with PHP Artisan, those pages are served with an older version of Bootstrap. So how do you change this?

First, you need to add Bootstrap 4 Alpha as a dependency in the NPM dependency file “package.json” like, as well as Laravel’s version of Gulp called “Elixir” and it’s version of “Webpack”, another JS tool, like so:

"laravel-elixir": "^3.0.0",
"bootstrap-v4-dev": "^4.0.0-alpha.6",
"laravel-elixir-webpack": "^1.0.1"

You should then run NPM’s install to get the latest files. Now, navigate to the SCSS file in your Resources/Assets/SASS directory from your root Laravel directory. In app.scss, remove any unneeded lines, and make it look like this:

@import "node_modules/bootstrap-v4-dev/scss/bootstrap.scss";

This imports the new version of Bootstrap instead of whatever version your project came with. When we run Gulp, this will compile the latest Bootstrap SCSS files for your Laravel application, but we’ll also need to update the JavaScript file. Navigation to the Bootstrap JS file in Resources/Assets/JS, and make replace any mention of the Bootstrap JS (probably “bootstrap-sass”) file with this line:

require('bootstrap-v4-dev');

With your dependancies installed and your assets pointing towards Bootrap 4, it’s time to set up Gulp so that you can compile these into your web application. Create a “gulpfile.js” in your root directory and add these lines:

var elixir = require('laravel-elixir');
var elixir = require('laravel-elixir');
require("laravel-elixir-webpack");

elixir(function(mix) {
   mix.sass('app.scss').webpack('app.js');
});

Now, when you run “gulp” in your root directory, you should find that your CSS and JavaScript have been updated to Bootstrap 4.

How I picked Laravel Homestead as my first backend development platform

As an experienced iOS developer, I interface all the time with backend services, and JSON RESTful APIs in particular. It’s a fairly common story for iOS developers to begrudge their work being blocked by backend holdups or bugs, and so, I thought I might as well try to try my hand at backend development to see if I could fix these problems myself.

Working on Apple platforms is simple. Language? Swift. OS? MacOS. IDE? Xcode. On and on, many questions have one answer. So you can imagine my uneasiness when asking the same questions on my first steps into backend development. Language? Uh, Ruby or PHP or Javascript or Java or … OS? Well, you can develop on whatever you want and you can run software on whatever you want, but probably something UNIXIDE? Well, what OS did you pick? And what language? And why aren’t you using Vim you filthy casual? (Emacs get out.)

Okay. I had some choices to make. I’ve heard from a few sources that backend should be old, boring, and crucially, reliable. I could think of no better candidate than PHP, and given that a few of the projects I’ve worked on have successfully deployed with PHP and I have some previous experience with it, it seemed like a reasonable first choice.

But I don’t want to fall into the trap of writing bad code, which I understand is easy to do in PHP, and I also don’t want to write code that has been written better by people that came before me. So I did some digging for PHP frameworks, and I found Symphony, CodeIgniter, and Laravel. The way that I picked one of these was the very scientific approach of picking the one with the most starts on GitHub, for better or worse, which at time of writing is Laravel.

I now set out to get a development environment up and running for Laravel, and to do that, here’s what you do. You’ll need to download Vagrant, which is a manager for virtual machines, VirtualBox, which is a virtualization engine, and Homestead, which is a nicely configured Laravel virtual machine. Homestead uses Vagrant which runs on VirtualBox.

To get this up and running, I found these tutorials very useful:

It took a while, but I now have it working, and I’m ready to start developing my Laravel app.