DEV Community: Tom Pearson

MVVM and Coordinators is the Industry Standard Architecture

Tom Pearson — Thu, 08 Aug 2019 09:23:05 +0000

I had a lot of phone calls as interview first stages when I was recently applying for iOS Developer jobs. At some point we would always start talking about what architectural patterns I use or am comfortable with. Each time I would say that I used MVVM with Coordinators and more often than not it seemed to be like magic words were spouting from my mouth - I was normally greeted with "oh, we use that too" and definitely got me an upper hand. This was in London but I wouldn't be surprised if this translates to most other countries/tech hubs as well.

So it seems that companies have widely adopted it rather than MVC/MVP/VIPER or anything else. My thoughts on why:

Closely related to MVC so easy for the whole team and newcomers to adopt
Allows reactive programming (RxSwift/Combine) to be easily slotted in as there are designated places for where the bindings should occur, and it seems like reactive programming will be the future
Provides guidelines for where to place certain pieces of code which better helps organise things than MVC but is more flexible and pragmatic than VIPER

What a coordinator looks like

I'm only going to describe coordinators because I think view models are covered widely elsewhere.

There isn't a set rule for what is or isn't a coordinator. I arrived at something like the following that suited most of my needs:

protocol Coordinator {
    var parentViewController: UIViewController { get }
    func start()
}

It's fairly simple but encapsulates everything a coordinator needs, something to present the new view controller that will be created, and a function to kick everything off.

Then we would create a new coordinator for each distinct workflow. For example, a logging in coordinator would look something like:

class LoginCoordinator: Coordinator {
    let parentViewController: UIViewController

    init(parentViewController: UIViewController) {
        self.parentViewController = parentViewController
    }

    func start() {
        let loginViewController = LoginViewController()
        parentViewController.present(loginViewController, animated: true)
    }
}

This is a simple example. Coordinators can be taken further if you want to restrict them to only be presented by other coordinators, so that they don't know about what ViewController is the root of which coordinator. In this case you would make a 'main' coordinator, and the coordinator protocol would have an array of child coordinators so they hold reference to the coordinators that they are presenting.

As the requirements of the workflow get more complex it's easy for the coordinator to get bloated. Also this example didn't use a view model but if we had used one the coordinator would be responsible for instantiating it and passing it into the view controller, so I'm sure you can appreciate things can get out of hand quickly.

Other skills in demand

TDD, but also just testing in general
Reactive programming - RxSwift/Combine

Namespaces in Swift

Tom Pearson — Tue, 06 Aug 2019 14:58:33 +0000

Namespaces in their simplest form are a way to group related areas of code. They make one of the hardest problems in programming, naming things, easier. They exist in a lot of other languages but not natively in Swift.

Microsoft's C++ documentation says:

Namespaces are used to organize code into logical groups and to prevent name collisions that can occur especially when your code base includes multiple libraries.

The Problem

If you're working on a large codebase then you probably name classes specifically enough so you won't get them confused with other areas of the codebase. Unfortunately to achieve this we have to make the trade off of longer class names to get this specificity. Also as we add more and more classes the global namespace gets more polluted, meaning that you end up with an information overload when trying to use autocomplete.

For example you'd probably make classes like LoginViewController or ContactsDataSource. This can be taken to more of an extreme as you get into very specific workflows in a large codebase.

The Solution

A nice, swifty way to solve this is to use an empty enum to create a gateway into the specific workflow and implement all specific classes inside extensions on that enum. You can then access these classes using the dot syntax. So instead of the examples above you would have Login.ViewController and Contacts.DataSource.

This also helps you organise code into logical groups - you know all the code related to the login flow will be under the Login namespace.

Implementation in Code

Making the namespace is just making an empty enum:

enum Login {}

Then the classes are implemented as extensions to that enum in a new file, in this case probably called Login+ViewController.swift:

extension Login {
    class ViewController: UIViewController { ... }
}

We use an enum instead of a struct because you can't instantiate an empty enum, so it can purely be used for accessing other classes without confusion of what its purpose is.

References

Microsoft Namespace Documentation

Some speaker at a Meetup who said that he did this

What is Agile?

Tom Pearson — Thu, 16 May 2019 21:53:24 +0000

When I first started software development I had no idea what Agile was. Two years in I still had no idea what it was but I kept on hearing the word pop up in talks and the importance of it was always emphasised in job descriptions. Indeed, I practiced it at my company, according to the description on our website, but no one had ever explained how what I was doing was Agile. So I decided to do some research and figure out what everyone was talking about.

The history of Agile can be directly traced back to 2001 when some software developers got together and proposed a new way of working on software projects. The problem was that initial commercial software projects were treated the same as a normal engineering project - a big plan made by 'smart' people was designed and then the 'dumb' workers would follow the plan (obviously this is a horrible way to look at it). An example of this is an architect designing a blueprint for a building and then labourers following the plan to build it. This project management practice is known as Waterfall.

Software didn't adapt well to this. Software projects, and their requirements, tend to change shape a lot more than buildings - and so our agile founding fathers drew up some principles for more suitable practices based around flexibility, feedback and adapting to changing requirements. These are enshrined in the Manifesto for Agile Software Development

Rather annoyingly for us software engineers a lot of these principles were left intentionally vague. Perhaps so they would stand the test of time or to have them apply to as broad a range of situations as possible.

The principles

A large part of the Agile manifesto's principles champion direct feedback between business people and developers. It prioritises the individuals and teams over organisations. And places working software with technical excellence as one of its goals.

So basically an Agile project is the antithesis of a bureaucratic, cumbersome project run by a committee of managers who don't listen to any feedback from customers or workers. This helps us know what agile isn't but still doesn't help us know what it is. Feedback is good but how much is too much before you get bogged down in meetings? Should you have standups? How many people before it gets too big? Should managers always consult with their teams before making any decisions? How do you actually decide what working software is? Should it matter what you think at all if the only purpose of the project is to satisfy the customer?

We still don't really have a good answer to the question of what Agile is, mainly because there isn't a good answer. Agile varies company to company, team to team. It is just some guidelines of how development can happen.

The reason Agile is so confusing is because it has been hijacked by people who have realised that they can sell the concept of Agile to companies who are looking to improve their development practices, even build careers (SCRUM Master) around it. This is a very cynical way to look at it but it also makes a lot of sense in explaining how it's used now compared to how it was intended to be used.

Perhaps there is so much confusion around Agile because people are constantly trying to change it in order to sell it to you - Are you doing Agile? That's not Agile. Let me show you how to do it in my new book.

Or maybe it's because we want to be told exactly what Agile is, and to have the gap left by the writers of the manifesto filled in. Maybe we don't want to have to struggle with the questions that it presents but would rather have someone rigorously define it for us so we don't have to think, and the problem is we can't decide who's interpretation is the most valid or we get bored of one and jump to another.

As Dave Thomas, one of the founding fathers, says we shouldn't really use the word Agile as we do. It's been turned into a noun. It was intended to be used as the verb - as in practices that are agile. As he points out, it's interesting that we now use it with a capital A, the same way we refer to God.

The sad reality

So sadly Agile has lost its intrinsic meaning over time and has become not much more than a buzzword slapped on job descriptions and websites. My advice is not to try to understand it because you'll never be able to keep up with it, or convince others of what it truly is (or more importantly isn't) because they have already formed and latched onto their own idea of it. Put that you practice it on your resume and forget about it.