Sundeep Gupta

As an iOS engineer I have spent my professional life reading, producing, and sifting through a lot of code. I’ve been tasked with finding the tiniest details that can make or break a product experience and fixing old issues with new solutions. But recently I’ve noticed a pattern in the problems I’ve faced—context changes everything.

On the most recent project I worked on, I was building for a large-scale iOS platform with about 120,000 lines of code, made up of 20 frameworks, and has seen over 80 different developers work on it. A project at such scale will inevitably have bugs and require on-the-spot quick fixes. The problem is that once a phase of the project is handed over to someone else, the nuanced understanding of a person’s decision making is lost. And then lost even more when it’s handed over again in the future.

This loss is something my team has come to call context erosion. It’s a problem that’s easiest understood if we forget about code for a moment.

The Walter White Problem

This year for Halloween, I decided to dress up as Walter White from the TV show, Breaking Bad. I woke up early and my partner used makeup to give me a black eye and put some bruises on my face—as well as adding a “bloodied” bandage to my nose. When my kids woke up and saw me they were scared and worried. They didn’t know why someone had beaten me up! I tried to explain to them that it’s my Halloween costume. But my kids didn’t know the character and were visibly upset that I’d been hurt.

The reality was that they only saw the end result, they didn’t have the context of why I looked the way I did. They’d never seen the show, so it was only natural that they would assume that I was hurt.

And that’s what context erosion is: It’s when the end result moves further and further away from the original “why” of why something is the way it is, forcing you to risk making a critical mistake or spend time trying to find the root of the original problem.

For my kids this meant I had to to assure them that I wasn’t hurt and I was doing an impression—a simple, but teary solve.

But for us engineers, context erosion can be a massive drain on resources, morale, and quality of work.

It’s something I’ve seen first hand.

Back to Coding

A teammate of mine on a recent project was telling me about how the payment flow in the app has a problem because it uses an SFSafariViewController to let the user pay via a website. But, the SFSafarViewController also allows the user to bounce out to the Safari app by tapping on the Safari icon in the tab bar. And if the user does this, the payment doesn’t work.

My colleague also told me that the app used to use a WKWebView instead but at some point they swapped it out for the SFSafariViewController. So I asked why? His answer: I don’t know. The Git history didn’t say why, and neither did the ticket. And unfortunately, the person who did the swap no longer worked at our client’s company.

The context around this SFSafariViewController decision had completely eroded. My coworker ended up wasting a lot of time going back to the WKWebView trying to figure out why it was problematic. He ended up keeping it, but he wonders if there’s something he overlooked that might break the app.

Solving for Context Erosion

Put context into the tickets – The ticket is a great place to explain the context and reasoning behind the work to be done. It also provides the opportunity to link to other contextual artifacts like designs, other tickets, etc. Not only will this provide foundational context, it also helps the developer do their work.

Leverage source control – Source control is fantastic at recording code changes. Why not let it record context. Leave explanations in your code, commit descriptions, PRs, and code review comments.

Go beyond just replying to code review questions – If someone asks a question while reviewing code, don’t just reply to the comment, because in the future someone else reading that code will have to dig up the review and go through the comments to find that piece of important context. Add that context to the code itself or to the commit description.

Disable squashing and fast forward pull request merges – Squashing diffs and commit messages/descriptions are a bit like downscaling 4K video to 480p—information is lost and finding specific information becomes harder. Fast forward (or rebased) merges for pull requests isn’t as good as forcing a merge commit because the merge commit will automatically get some helpful context—the PR number and a link to it.

Background

Some time ago, while digging through the RxSwift source code, I first encountered Never. At the time, I filed it away in my brain under the “weird — look into that” compartment. It wasn’t until recently that I had a chance to revisit it. It’s a neat little concept, but more importantly, useful! We’re now using it in production code. This article will help you understand Swift’s Never type and it’s usefulness via two real-world examples.

What is Never?

The quick and dirty: Never expresses impossibility via the type system. There are two main uses

Express when code cannot be run or called

Express when a function cannot return

This article will dive into the first point — which is what I refer to as impossible code. I’ve found the second point regarding non-returning functions to be less practical and not as interesting to discuss here and will instead defer to Swift’s fatalError as an example.

Impossible code

What makes Never interesting is that it’s an uninhabited type — it cannot be instantiated. Just look at it’s implementation:

enum Never {}

It’s an enum with no cases. There’s no way to instantiate it — but the type exists and it’s available for use. In fact, we can easily create our own uninhabited type in the same way. This becomes valuable as the Swift compiler takes advantage of this fact to help us be more expressive within the type system.

Void and NSNull

One of my initial questions was, “How is this different from Void and [NSNull](https://developer.apple.com/documentation/foundation/nsnull?” It goes back to the ability to instantiate things. Void and NSNull can be instantiated as:

let void = () let null = NSNull()

Void and NSNull instances can represent the absence of a value. And the absence of a value is possible, it’s a real thing. It can be essentially thought of as representing an occurrence or something happening — an event. For instance, I’d like to know when the rain stops but I don’t care about how much rain fell. Void would work well for this.

Never, on the other hand, can’t do this because it can’t be instantiated. When it’s used to define a function or variable, or more practically, to name a generic type, it can make code impossible to run. But why would anyone write code that would never run? It might seem strange at first, but it comes up when working with generics and it can help us avoid resorting to fatalError or developer comments like // No need to do this.

Let’s look at some examples of impossible code.

Networking with Never

This example will use Never in a networking implementation that uses generics. We’ll start with Swift’s Result and build on that in the subsequent networking code.

Impossible Results

Swift’s Result (now built into Swift 5) is a generic enum that can help showcase some impossible code. It is defined as:

enum Result<success failure> where Failure: Error { case success(Success) case failure(Failure) }

Here it is being used for a name fetching routine:

func fetchName(for number: Int) -> Result<string error> { guard number >= 0 else { return .failure(ExampleError.error) } // (Fetch the name...) return .success("Maya") } let nameResult = fetchName(for: 33) switch nameResult { case .success(let name): print(name) case .failure(let error): print(error) }

What would an instance of Result<never error> mean? It would mean it must have failed. Since it is impossible to create an instance of Never, it would be impossible to create the .success case here. Here’s a slightly different example:

let mrPerfect = Result<never error>.success("I never fail") switch mrPerfect { case .success(let text): print(text) }

*In case you’re wondering, in Swift 5, Never already conforms to Error.

The .failure case in the switch isn’t required as the compiler knows it’s impossible to create it. Thus, there is no need to use fatalError or an instructive // This should never happen comment. In fact, it would be helpful for the compiler to issue an “Impossible to execute” warning if the .failure case was ever written.

Handling Impossible Responses

Using the previous example as a building block, let’s describe networking requests using an abstract and generic Request type:

protocol Request { associatedtype Response func send(completion: (Result<response error>) -> ()) }

Request has a generic associatedtype, Response, which is used to describe the type of object that will eventually be provided back to the caller. When the network call finishes, completion is called with a Result<response error>.

Suppose we want to implement a user analytics network call. For this call we don’t care about knowing when it succeeds however, when it fails, we’d like to log it so that we can fix it later.

TrackScreen1 implements this without Never:

struct TrackScreen1: Request { let name: String func send(completion: (Result<void error>) -> ()) { // (Send the request...) let networkError: Error? = nil if let error = networkError { completion(.failure(error)) } // No need to call `completion` for success. } } TrackScreen1(name: "Home").send() { result in switch result { case .success: break // This should never happen. case .failure(let error): print(error) } }

Did you notice how comments are required to help others understand the requirement and protect against developer error? This is because the code alone doesn’t express the requirement of not caring about the success case.

With Never, we can directly encode the requirement as shown here in the improved TrackScreen2:

struct TrackScreen2: Request { let name: String func send(completion: (Result<never error>) -> ()) { // (Send the request...) let networkError: Error? = nil if let error = networkError { completion(.failure(error)) } } } TrackScreen2(name: "Home").send() { result in switch result { case .failure(let error): print(error) } }

Here, in send, there’s no need to worry about developers calling completion because it’s impossible to create the .success case. Further, when the caller handles the result, the .success case can be omitted from the switch.

Never has provided a type-safe way to express the requirement. It gives some flexibility to describe other scenarios like fire-and-forget calls — calls that don’t need any completion handling whatsoever. Not to mention, it facilitates cleaner code.

Coordinators with Never

If you’ve ever used a “coordinator” pattern for describing navigation flows in an iOS app, this example might hit home a bit more. Here’s a quick overview of how we’ll interpret the pattern.

A coordinator can be thought of as being responsible for a particular user flow. For example, there might be a SettingsCoordinator which shows the user’s settings. In that particular flow, tapping the “Add Payment” button might start a child flow, AddPaymentCoordinator, to add a payment method.

Parent coordinators generally need to know when a child finishes so it can react accordingly. The child might also need to pass data back to its parent when it finishes. Given these requirements, here is the coordinator protocol:

protocol Coordinator { associatedtype Completion func start(completion: (Completion) -> ()) }

The settings and payment example described above might look like:

class SettingsCoordinator: Coordinator { func start(completion: (()) -> ()) { // (Show the flow...) // (When user taps "Add Payment".) AddPaymentCoordinator().start() { paymentID in // (Show button to "Pay now" with new payment...) } } } class AddPaymentCoordinator: Coordinator { func start(completion: (String) -> ()) { // (Show the flow...) let paymentID = "CreditCard123" completion(paymentID) } }

Forever Coordinators

It turns out that some coordinators never finish. The best example of this is the very first, or root, coordinator. It introduces the app and spawns child coordinators, but it’s impossible for the user to “finish” it.

Let’s look at how this AppCoordinator1 looks like without using Never:

class AppCoordinator1: Coordinator { func start(completion: (()) -> ()) { // (Start the app's UI...) // No need to call completion. } } class AppDelegate { let appCoordinator1 = AppCoordinator1() func applicationDidFinishLaunching() { appCoordinator1.start { _ in // This should never happen. } } }

Just like our earlier networking example, helper comments are required to express the requirement of this coordinator never finishing.

Here is the improved AppCoordinator2 using Never:

class AppCoordinator2: Coordinator { func start(completion: (Never) -> ()) { // (Start the app's UI...) } } class AppDelegate { let appCoordinator2 = AppCoordinator2() func applicationDidFinishLaunching() { appCoordinator2.start { _ in } } }

The implementation is cleaner without the helper comments while still being expressive. Even though it’s impossible to execute the completion closure, it’s still required when calling start. Ideally, the compiler would warn us if code was ever written inside the closure.

Summary

This post explores Swift’s Never via two real-world examples. It illustrates how we can write impossible to execute code — expressed via types. This reduces our need to use fatalError, and // This should never happen comments. Writing expressive, clean code is important for building quality products that are maintainable. Moreover — it feels good!

Acknowledgements

My team and I recently discovered a bug in one of our projects, and the culprit turned out to be the FlatMap operator—or rather, our misuse of it. I don’t know why, but FlatMap was a recurring source of confusion. (And the official Rx docs didn’t really shed much light on the subject.) Fortunately for us, we eventually gained clarity around the FlatMap operator using a real-life analogy that I thought would be worth sharing:

FlatMap is like the combining or flattening of commits pushed by a growing team of developers on a project.

Think of a team of developers on a project that uses a Continuous Integration (CI) service to build each pushed commit. The CI is interested in all of the commits pushed by all of the developers, including newly added ones, on the project.

FlatMap Analogy. Animation by Deyu Wang

We can dig into this more with code—in this case, Swift (and RxSwift). First, let’s define the objects we’ll need.

class Project { private let developerSubject = PublishSubject<developer>() var developerStream: Observable<developer> { return developerSubject.asObservable() } func addDeveloper(_ developer: Developer) { developerSubject.onNext(developer) } func stop() { developerSubject.onCompleted() } } class Developer { private let commitSubject = PublishSubject<commit>() let name: String init(_ name: String) { self.name = name } func startCoding() -> Observable<commit> { return commitSubject.asObservable() } func stopCoding() { commitSubject.onCompleted() } // Helper to externally simulate coding activity. func pushCommit(_ hash: String) { commitSubject.onNext(Commit(author: name, hash: hash)) } } struct Commit { let author: String let hash: String } class CI: ObserverType { func on(_ event: Event<commit>) { switch event { case .next(let commit): print("CI is building \(commit).") case .completed: print("CI stopped.") case .error(let error): print("CI errored: \(error).") } } }

Type Declarations

Now let’s instantiate things and hook it all up.

let project = Project() let jim = Developer("Jim") let anna = Developer("Anna") let bob = Developer("Bob") let ci = CI() project.developerStream .flatMap { developer -> Observable<commit> in print("\(developer.name) started coding...") return developer.startCoding() } .subscribe(ci)

Setup Objects

We flatMap the developerStream onto each developer’s commits. The resulting stream is subscribed to by the CI.

Looking closer, in the flatMap closure, for each developer emitted on developerStream, we return the developer’s stream of commits via the startCoding() function. This allows the flatMap to observe the commits emitted by all developers and then flatten them into a single output stream. The CI subscribes to this output stream so it can build each commit.

Let’s play with this to see what happens when we start adding developers and pushing commits. The trailing comments are the output from the print()s.

project.addDeveloper(jim) // Jim started coding... jim.pushCommit("1") // CI is building Commit(author: "Jim", hash: "1"). project.addDeveloper(anna) // Anna started coding... jim.pushCommit("2") // CI is building Commit(author: "Jim", hash: "2"). anna.pushCommit("3") // CI is building Commit(author: "Anna", hash: "3"). jim.pushCommit("4") // CI is building Commit(author: "Jim", hash: "4").

Normal Operation

Notice how even after Anna is added to the project, Jim remains “active” and the CI continues to see Jim’s additional commits. Jim’s commit stream returned from startCoding() doesn’t get replaced by Anna’s. Further, the order in which each developer is added doesn’t matter. The CI only sees the commits in the sequence they are pushed. The CI doesn’t care about the developers themselves, it only cares about their commits.

Taking a closer look, our flatMap subscribes to the commits from each developer received from developerStream. Even when new developers are received, those subscriptions continue to live on. This enables the commits from both Jim and Anna to be combined and flattened into a single output stream.

Wait — how is this different from **Merge?**

Instead of FlatMap, we could of course use the Merge operator to combine commits from multiple developers into a single stream. If the project’s developers are known and fixed, this would be fine, as Merge takes a static list of observables.

Observable.merge([jim.startCoding(), anna.startCoding()]).subscribe(ci)

However, if Bob came along to join the project at a later point, we’d have to handle that somehow. With FlatMap, since we subscribe to new developers being added, it’s handled for us already. Bob’s commits would automatically be taken into account and added to the flatMap’s output stream. Thus, we could say that Merge is for a static list of observables, while FlatMap is for a dynamic list of observables.

So, that’s most of it. But let’s get a more complete (Rx joke) understanding of how FlatMap works by exploring complete and error events.

Completions

It’s easy to start things, hard to complete them.

This saying is very true for FlatMap. In a nutshell, the CI will receive the completed event once all “active” observables in the chain have completed.

Let’s look at an example where, after some normal operation, only the project stops. Will the CI stop?

project.addDeveloper(jim) // Jim started coding... project.stop() project.addDeveloper(bob) bob.pushCommit("1") jim.pushCommit("2") // CI is building Commit(author: "Jim", hash: "2").

Completing the Project (Parent Observable)

No, the CI doesn’t stop. After the project stops, adding Bob has no effect because developerStream has already completed so he’s never “activated” in the flatMap. Thus, when Bob pushes a commit, the CI doesn’t see it. However, existing project members like Jim are free to continue pounding away and pushing commits which do get built by the CI.

Now let’s examine when, instead of the project stopping, every developer on the project stops. Will the CI stop?

project.addDeveloper(jim) // Jim started coding... project.addDeveloper(anna) // Anna started coding... jim.stopCoding() anna.stopCoding() jim.pushCommit("1") project.addDeveloper(bob) // Bob started coding... bob.pushCommit("2") // CI is building Commit(author: "Bob", hash: "2").

Completing the Developers (Child Observables)

No, the CI doesn’t stop. As shown, when all the project’s developers stop, it affects neither the CI nor the project. Bob is still able to join the project afterwards and push commits which the CI builds.

The only way to stop the CI’s subscription is to stop the project and all existing developers:

project.addDeveloper(jim) // Jim started coding... project.addDeveloper(anna) // Anna started coding... project.stop() jim.stopCoding() anna.stopCoding() // CI stopped. project.addDeveloper(bob) bob.pushCommit("1") jim.pushCommit("2")

Completing the CI’s Subscription

It’s worth noting here that if no developers are ever added to the project, calling project.stop() would also stop the CI.

Errors

error events work as expected. When either the project or any added developer errors, the CI will receive the error event and the whole chain stops working.

Conclusion

Now that we know how FlatMap actually behaves, we’re able to use it with more confidence and in the right places.

The easiest way to play with this code (or any RxSwift code) on your own is to use the RxSwift repo’s playground. To get a closer look at things, including when the isDisposed event is being emitted, you may want to add this code to the playground along with some debug operators.

Acknowledgements

Preface: Swift 4 has the awesome new Codable type, so some of this code may not apply if you're using Swift 4.

Motivation

Sometimes we're unable to use third party code, or it may not make sense for you. Networking is probably an area where I find using something like Alamofire acceptable given it's immense community support. But still, it's pretty darn big. How much of it do you actually need? If you ever decide to write your own, here's an approach that might work for you.

The code

The complete code is in this GitHub Gist.

After watching this objc.io Networking video. Actually using it wasn't working out. In fact, a big mess was made. It was a classic case of over-engineering. It was all thrown out and code continued to be written the way it should be at first: simple, and with duplication. After all the kinks were worked out, refactoring reduced it to the correct abstractions. It was practice of one of the most valuable programming lessons I learned (and lucky me, in person) from the amazing Sandi Metz - which is

Don't abstract too early. - Not a direct quote, but a message from Sandi Metz.

When done, some of the abstractions started to look like ones from the video :).

Major components

WebService

The highest level abstraction which provides the public API. It's a domain descriptive API consuming and providing domain objects. It creates Actions and sends them to the ActionManager for processing.

public struct WebService { let actionManager: ActionManager

// As public API, optimize for simplicity by only providing a Result and not throwing. func getProfile(id: String, completion: @escaping (Result<profile>) -> Void) { let action = Action<nsnull profile>(urlString: "api.com/profile", method: "GET", body: NSNull()) perform(action, completion: completion) } func createProfile(_ profile: Profile, completion: @escaping (Result<nsnull>) -> Void) { let action = Action<profile nsnull>(urlString: "api.com/profile", method: "POST", body: profile) perform(action, completion: completion) } private func perform<req res>(_ action: Action<req res>, completion: @escaping (Result<res>) -> Void) { do { try actionManager.perform(action) { completion($0) } } catch { completion(Result.failure(error)) } }

}

Since this is the public interface, we want to keep it as simple as possible by not throwing and only providing a Result. A Result is widely implemented Swift Enum:

public enum Result<value> { case success(Value) case failure(Error) }

The other thing to note here is the creation of Action objects, which is the crux of how all of this works.

Action

This encapsulates the behaviour and data for a round trip network call. Domain object -> Network -> Domain object.

internal struct Action<requestbody: encodable responsebody: decodable> { let urlString: String let method: String let body: RequestBody let decode = ResponseBody.decode // Anything else you may need like tokens, headers, etc. func request() throws -> URLRequest { guard let url = URL(string: urlString) else { throw WebServiceError.invalidURL(urlString) } var request = URLRequest(url: url) request.httpMethod = method request.httpBody = try body.encode() return request } }

This type requires specialized generic types for the request body, and the response body. I actually don't like these names much, but haven't thought of better ones yet. RequestBody and ResponseBody would be generally domain types which conform to Encodable and Decodable which serialize domain objects to JSON and vice versa:

public protocol Encodable { func encode() throws -> Data } public protocol Decodable { static func decode(data: Data) throws -> Self }

Here it is impelemented on our Profile domain object:

public struct Profile: Encodable, Decodable { let name: String let age: Int public static func decode(data: Data) throws -> Profile { guard let object = try JSONSerialization.jsonObject(with: data) as? [String: Any], let name = object["name"] as? String, let age = object["age"] as? Int else { throw WebServiceError.invalidJSON(data) } return self.init(name: name, age: age) } public func encode() throws -> Data { let object: [String: Any] = ["name": name, "age": age] return try JSONSerialization.data(withJSONObject: object) } }

We also implement these protocols on NSNull because we want to be able to send and receive empty bodies. So we can make use of the Null Object Pattern to achieve "same" code and less code paths. At first, creating a new null type was considered, but why when we have good ol' Foundation's NSNull sitting around!

extension NSNull: Encodable, Decodable { public static func decode(data: Data) throws -> Self { return self.init() } public func encode() throws -> Data { return Data() } }

Further, Action produces a native URLRequest that is used with NSURLSession later on to make the actual network call.

ActionManager

This performs Actions and knows how to talk to the lower level HTTPManager. It creates URLRequests and deserializes responses.

internal struct ActionManager { let httpManager: HTTPManager func perform<req res>(_ action: Action<req res>, completion: @escaping (Result<res>) -> Void) throws { let request = try action.request() httpManager.performRequest(request) { result in switch result { case .success(let data): do { completion(Result.success(try action.decode(data))) } catch { completion(Result.failure(error)) } case .failure(let error): completion(Result.failure(error)) } } } }

We can see perform is generic on the same types as the Action it accepts and calls back with a Result with Res value, which would be a domain type.

HTTPManager

The lowest level abstraction that implements URLSession.

internal struct HTTPManager { let urlSession: URLSession func perform(_ request: URLRequest, completion: @escaping (Result<data>) -> Void) { urlSession.dataTask(with: request) { data, response, error in if error != nil { return completion(Result.failure(error!)) } let response = response as! HTTPURLResponse // Trusting the docs for this example! // Could pass in an object that deals with status codes, which would be part of the Action. guard response.statusCode == 200 else { return completion(Result.failure(WebServiceError.invalidStatusCode(response.statusCode))) } completion(Result.success(data ?? Data())) }.resume() } }

It does the network call work and verifies an expected response status code. Notice, it calls back with empty Data when the response doesn't have one - instead of (optional) Data?. This works because when we expect an empty response, our ResponseBody type would be, NSNull. And it can handle decoding empty Data. Thus, we can avoid the complexity of passing through an optional here.

Conclusion

Again, the complete code is in this GitHub Gist. If you're considering writing your own network code, I hope this approach can help and I welcome any feedback you may have!

Optional way :(

Take this function for example:

func request(for urlString: String) -> URLRequest? { guard let url = URL(string: urlString) else { return nil } return URLRequest(url: url) }

This function returns an Optional. This is not good practice. Why? That's just it - "Why?". Every developer asks this question hundreds of times every day. "Why is this an optional? Why would it be nil?". The way this function is right now does not help answer that question. If you take this concept further, it's like the end user experiencing an error, and showing the user a generic "Sorry, error" message. Actually, it's worse. It's semantically wrong. Because this function doesn't even tell you if an error had even occured. It's providing a valid value back of type Optional. Its up to the consumer to determine if nil is actually an error value or not. There should never be this type of guessing.

Throwing way :)

The function should be written like this:

enum NetworkError: Error { case invalidURL(String) } func request(for urlString: String) throws -> URLRequest { guard let url = URL(string: urlString) else { throw NetworkError.invalidURL(urlString) } return URLRequest(url: url) }

This throwing version is now semantically correct. The consumer doesn't need to make any guesses about the return value because it's not an optional. And when something does go wrong, we throw a meaningful, expressive error. Along with some helpful data. Beautiful. Now you might be saying this isn't ideal because the consumer needs to use do/try/catch mechanism, which isn't as "clean". I argue the benefits far out weight the costs and we can revert to using try? if we don't need to do/try/catch.

Flexibility

We've created a lot of expressive flexibility in our code as we can consume this code in four different ways:

Pass the error up

func profileRequest(for id: Int) throws -> URLRequest { return request(for: "https://api.com/user/\(id)") }

Transform the error

func profileRequest(for id: Int) throws -> URLRequest { do { return try request(for: "https://api.com/user/\(id)") } catch { throw NetworkError.invalidProfileRequest(id: id, original: error) } }

Handle the error

func profileRequest(for id: Int) -> URLRequest { do { return try request(for: "https://api.com/user/\(id)") } catch { // Perhaps show some error UI. } }

Ignore the error

func profileRequest(for id: Int) -> URLRequest? { return try? request(for: "https://api.com/user/\(id)") }

Conclusion

Note: Code examples are in an Xcode playground hosted on GitHub.

PODI Overview

Recently, there have been several articles published on the subject of Dependency Injection (DI) in Swift. They all utilize a protocol oriented approach and more specifically, protocol extensions, to achieve what typical DI frameworks achieve. I thought "PODI" would be a nice name for it, which stands for "Protocol Oriented Dependency Injection".

I'll focus on a subtle, but important safety issue we found in our implementation. I won't go into depth on PODI itself, as the articles do a nice job of it. But here's a quick and dirty illustration:

Traditional (Constructor) DI

We can supply our dependencies at the time of initialization.

protocol MascotType { func dance() } struct Mascot: MascotType { func dance() { print("Do the Macarena") } } struct MockMascot: MascotType { func dance() { print("Do nothing") } } struct Team { let mascot: MascotType } let mascot = Mascot() let team = Team(mascot: mascot) team.mascot.dance() // Do the Macarena let mockMascot = MockMascot() let testTeam = Team(mascot: mockMascot) testTeam.mascot.dance() // Do nothing

PODI

struct MascotProvider { static var mascot: MascotType = Mascot() } protocol HasMascot {} extension HasMascot { var mascot: MascotType { return MascotProvider.mascot } } struct Team: HasMascot {} let team = Team() team.mascot.dance() // Do the Macarena MascotProvider.mascot = MockMascot() let testTeam = Team() testTeam.mascot.dance() // Do nothing

We leverage protocol extensions to do the injection for us. To change the dependency, we modify the MascotProvider.mascot property.

One key benefit is that we can instantiate our Teams in a simple, clean way. It's nice for retro fitting DI into a codebase which doesn't inject anything. The drawback is the instantiating code hides the injection, so more implicit knowledge is needed. The developer would need to inspect the Team struct's declaration to know MascotType is being injected.

Swift DI articles recently published:

A Swifty Approach to Dependency Injection

Dependency Injection with the Cake Pattern in Swift

Pure Swift Dependency Injection

Using Protocol Composition For Dependency Injection

Problem

Background

Recently, I joined a project and have been retro fitting DI into an existing codebase to enable unit testing. PODI seemed great for this. In our particular case it's a necessity because the app depends on an external dependency which hardcodes CoreBluetooth's CBCentralManager initialization which crashes the simulator during a unit test.

After implementing PODI for this dependency, and supplying a mock, the tests were still crashing for the same reason!

Side tip: How to mock a type you don't own

Unintuitive Swift static properties

Here is an example of why the test was crashing while injecting a mock using PODI. It's the same as above except to show things more clearly, I removed the previous funcs and implement init on the MascotTypes.

protocol MascotType {} struct Mascot: MascotType { init() { print("Init real mascot") } } struct MockMascot: MascotType { init() { print("Init mock mascot") } } struct MascotProvider { static var mascot: MascotType = Mascot() } protocol HasMascot {} extension HasMascot { var mascot: MascotType { return MascotProvider.mascot } } MascotProvider.mascot = MockMascot() // Output: // Init real mascot // Init mock mascot

Notice the output. Setting MascotProvider.mascot is causing Mascot to initialize. It turns out this is known behaviour and apparently by design. I think it's unintuitive and as such, should be considered a bug and fixed. Others seem to agree as shown by this bug report.

Solution

Resolve static property issue

To overcome this issue, we create a backing optional variable on the Provider which starts out as nil so nothing gets instantiated when something is set:

struct MascotProvider { private static var _mascot: MascotType? static var mascot: MascotType { get { if _mascot == nil { _mascot = Mascot() } return _mascot! } set { _mascot = newValue } } } MascotProvider.mascot = MockMascot() // Output: // Init mock mascot

All good right? This certainly fixes the above problem. However, our application is heavily asynchronous using background threads to help achieve concurrency. And this code is not thread-safe.

Thread-safety

Due to the nil check, if two threads call the getter when _mascot is nil, two instances of Mascot will be instantiated. This can be shown by running this code:

DispatchQueue.concurrentPerform(iterations: 10) { _ in _ = MascotProvider.mascot }

On my machine, I see Mascot initialized four times. Further, when _mascot is nil, if the getter is called and immediately after, the setter is called with a MockMascot instance, we can run into a unexpected memory issues.

The technique we use to achieve thread-safety is to use a queue. We ensure all unsafe operations go through a GCD DispatchQueue.

struct MascotProvider { private static let queue = DispatchQueue(label: String(describing: MascotProvider.self)) private static var _mascot: MascotType? static var mascot: MascotType { get { if _mascot != nil { return _mascot! } queue.sync { if _mascot != nil { return } _mascot = Mascot() } return _mascot! } set { queue.sync { _mascot = newValue } } } }

Note that MascotProvider.mascot's getter doesn't put everything into the queue. This is a safe performance optimization because if _mascot is already initialized and set, there is no risk of multiple threads accessing it. All threads will receive the same instance. Thus, the queue is only used when _mascot is nil.

Wrap-up

Due to this design choice (or bug) by the Swift team, PODI implementation is more complex with more boilerplate. Ideally, this could be abstracted away and perhaps packaged into a small library - which I will call "Podium" :).

Summary

We describe the application of the Chain of Responsibility pattern to help with handling web requests inside of an iOS web view. We start with some background and context around the problem, then move to implement the technique to resolve it. The example is done in the Swift language.

Background

Our iOS native app contains a web view to allow users to interact with a complex web app. In this simplified example, we will have a view controller, WebViewController, which has the UIWebView property called webView. We assign webView's WKNavigationDelegate to WebViewController. WKNavigationDelegate is used to handle any HTTP requests webView makes.

import UIKit import WebKit class WebViewController: UIViewController, WKNavigationDelegate { var webView: WKWebView! override func viewDidLoad() { super.viewDidLoad() self.setupWebView() } func logout() { // code to log out } func showAboutView() { // code to show the About view } func webView(webView: WKWebView, decidePolicyForNavigationAction navigationAction: WKNavigationAction, decisionHandler: (WKNavigationActionPolicy) -> Void) { let path = navigationAction.request.URL!.path if path == "sign_out" { // code to handle logging out decisionHandler(.Cancel) return } else if path == "about" { // code to show a native About view decisionHandler(.Cancel) return } decisionHandler(.Allow) } private func setupWebView() { self.webView = WKWebView(frame: self.view.frame) self.webView.navigationDelegate = self self.view.addSubview(webView) } }

You can see in the delegate method webView:decidePolicyForNavigationAction:decisionHandler, there is some conditional code to handle the request and we either allow the web view to continue processing it, or we stop it.

Problem

Handling requests in this way poses a problem when there are more then just a couple. As development continues and more cases arise, it's clear we'll need to solve this in a better way. It sounds like the perfect case for the object oriented Chain of Responsibility design pattern.

Chain of Responsibility pattern

Quickly, the Chain of Responsibility pattern lets a request pass through multiple "links" of a chain. If a link handles the request, we're done and we bail. Otherwise, the request is passed to the next link in the chain.

Implementation

In our example, we want to process each HTTP request by sending it through a chain of potential handlers. And once a handler handles the request (like showing the native About view) we clearly don't want or need the other handlers to do anything. We handled it, so stop processing the request. Lets start backwards by figuring out what we want our delegate method to look like:

Client code

func webView(webView: WKWebView, decidePolicyForNavigationAction navigationAction: WKNavigationAction, decisionHandler: (WKNavigationActionPolicy) -> Void) { let handled = self.requestChain.handle(request: navigationAction.request, controller: self) if handled { decisionHandler(.Cancel) } else { decisionHandler(.Allow) } }

A couple of things to note here. We've introduced the chain object, requestChain, which has the handle method. We'll get into this object in a bit, but for now, notice we simply check to see if the chain handled the request or not. More precisely, if any of the handlers (links), that make up the chain, handled the request. If so, stop webView from handling the request.

Chain code

To implement the chain, we need three components: 1. The link protocol (also known as an interface in other languages, like Java). 2. The concrete link classes. 3. The chain class, which holds the links.

Links

protocol RequestHandler { func handle(request request: NSURLRequest, controller: WebViewController) -> Bool }

Each handler in our chain will take a request, and possibly handle it. And it returns a Bool to indicate if it handled it or not. If you're wondering why we're passing the controller argument, it's because in this contrived example, we'll call methods on controller to handle requests. In general, you may want to pass in different objects, or a closure instead.

Lets look at an example of a concrete class:

class logoutHandler: RequestHandler { func handle(request request: NSURLRequest, controller: WebViewController) -> Bool { if request.URL!.path == "logout" { controller.logout() return true } return false } }

The class implements the protocol's handle method, by inspecting the request and conditionally handling it. All concrete RequestHandler classes would behave in this similar way. Here's another:

class AboutHandler: RequestHandler { func handle(request request: NSURLRequest, controller: WebViewController) -> Bool { if request.URL!.path == "about" { controller.showAboutView() return true } return false } } ##### Chain

Now that we know what our links look like, lets put them together in our chain class, RequestChain.

class RequestChain { var handlers: [RequestHandler]! init(handlers: [RequestHandler]) { self.handlers = handlers } func handle(request request: NSURLRequest, controller: WebViewController) -> Bool { for handler in self.handlers { let handled = handler.handle(request: request, controller: controller) if handled { return true } } return false } }

We initialize our RequestChain with an array of RequestHandlers so we can loop over them when we want to process a request. Obviously, this is a very basic implementation and we could make this more sophisticated with guards, ability to add and remove handlers, etc. Also, you may notice that the handle method signature, is exactly the same as the RequestHandler protocol's. This is a natural thing to do, but it doesn't have to be this way, depending on your preference and scenario. In the handle method, we traverse chain of links and return once one of them handles the request.

Client code revised

Now that we have our chain setup, we simply need to instantiate and hook everything up. Here's the final version of our WebViewController:

class WebViewController: UIViewController, WKNavigationDelegate { var webView: WKWebView! var requestChain: RequestChain! override func viewDidLoad() { super.viewDidLoad() self.setupWebView() self.setupRequestChain() } func webView(webView: WKWebView, decidePolicyForNavigationAction navigationAction: WKNavigationAction, decisionHandler: (WKNavigationActionPolicy) -> Void) { let handled = self.requestChain.handle(request: navigationAction.request, controller: self) if handled { decisionHandler(.Cancel) } else { decisionHandler(.Allow) } } func logout() { // code to log out } func showAboutView() { // code to show the About view } private func setupWebView() { self.webView = WKWebView(frame: self.view.frame) self.webView.navigationDelegate = self self.view.addSubview(webView) } private func setupRequestChain() { let handlers: [RequestHandler] = [LogoutHandler(), AboutHandler()] self.requestChain = RequestChain(handlers: handlers) } }

Conclusion

Intro

Showers are a mysterious place where for some reason, insights appear. I made a mini break through with the practice of Functional Programming (FP) in the shower. In hindsight, it's not groundbreaking, but I think it's worth discussing, especially if you're struggling to grasp how FP can be used in practice.

A while back, a functional approach nicely solved a problem I was having, where I was going to implement some type of interface with a set of concrete classes, but then realized a function would be easier and cleaner. So, I'm calling this out as a technique.

FP can be used in place of the common Object Oriented practice of programming to interfaces, not implementations.

I don't know yet if this is true in general, but it's certainly true for the Strategy Pattern. I'll use my previous post, Dependency injection example in Swift to illustrate this.

Code

The Swift Playground for this post can be found in this repo if you'd like to download it.

Object Oriented example

First, let's review the OO example. This was inspired by a Sandi Metz Ruby exercise I experienced a while back, and ported to Swift to illustrate what exactly Dependency Injection is and how it can be useful. The technique described in the post is more precisely known as the Strategy Pattern.

Quickly, the Song class has a recite() method to sing a short song consisting of an array of phrases. Using the Strategy Pattern, we can instantiate and recite the song, but remixed in a certain way, at runtime. To do this, we to pass in an object that conforms to the Remixer protocol (in other OO languages, like Java, a protocol is called an interface). In the example, we implement Repeater and Reverser to recite the song with repeated phrases and reversed phrases, respectively.

class Song { private let lineStart = "This is " private let lineEnd = "." private var phrases = [ "the house that Jack built", "the malt that lay in", "the rat that ate" ] init(remixer: Remixer?) { if remixer != nil { self.phrases = remixer!.result(self.phrases) } } func line(number: Int) -> String { let linePhrases = self.phrases[0...number-1].reverse() let line = linePhrases.joinWithSeparator(" ") return self.lineStart + line + self.lineEnd } func recite() -> String { var lines = [String]() for i in 1...self.phrases.count { lines.append(self.line(i)) } return lines.joinWithSeparator("\n") } } protocol Remixer { func result(list: [String]) -> [String] } class Repeater: Remixer { func result(list: [String]) -> [String] { return list.map { return $0 + " " + $0 } } } class Reverser: Remixer { func result(list: [String]) -> [String] { return list.reverse() } } Song(remixer: nil).recite() Song(remixer: Repeater()).recite() Song(remixer: Reverser()).recite()

Functional example

In the OO example, above, Song uses the Remixer protocol defined method result() on the object being passed in. Now, instead of passing in an object, which conforms to the Remixer protocol, which implements result(), in a sense, we'll pass in the result() function directly. Easy, right? Let's look at the code.

class Song { private let lineStart = "This is " private let lineEnd = "." private var phrases = [ "the house that Jack built", "the malt that lay in", "the rat that ate" ] init(remixer: Remixer?) { guard let r = remixer else { return } self.phrases = r(phrases) } func line(number: Int) -> String { let linePhrases = self.phrases[0...number-1].reverse() let line = linePhrases.joinWithSeparator(" ") return self.lineStart + line + self.lineEnd } func recite() -> String { var lines = [String]() for i in 1...self.phrases.count { lines.append(self.line(i)) } return lines.joinWithSeparator("\n") } } typealias Remixer = [String] -> [String] let repeater: Remixer = { lines in return lines.map { return $0 + " " + $0 } } let reverser: Remixer = { lines in return lines.reverse() } Song(remixer: nil).recite() Song(remixer: repeater).recite() Song(remixer: reverser).recite()

Song looks identical to the OO version except for inside init(). init() still takes a parameter of type Remixer?, but now, Remixer's type is a function, not a protocol. In place of our concrete classes which implemented the dynamic behaviour in result(), we define constants of type Remixer, our function type.

If you have dynamic behaviour in your OO code and you're looking to introduce FP into your practice, this is one approach that can help you get into the swing of it.

tl;dr

Skip to the Solution section for the implementation which includes all the code examples.

Problem

On a recent project, I had an issue with choppy scrolling in a couple of collection views which held a grid of images. It wasn't horrible, but noticeable enough, especially on slower phones.

Original implementation

The app has a domain object called a "cue". Each cue had an image associated with it and we wanted to render cues in the "library". Because the cues were static, they were placed in the asset catalog.

// CCLibraryViewController - (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath { CCCueCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:NSStringFromClass([CCCueCell class]) forIndexPath:indexPath]; CCCue *cue = self.cues[indexPath.item]; [cell configureWithImage:[UIImage imageNamed:cue.name]]; return cell; } // CCCueCell - (void)configureWithImage:(UIImage *)image { self.imageView.image = image; [CCHelper tintImageView:self.imageView withColor:kGreyColor]; } // CCHelper + (void)tintImageView:(UIImageView *)imageView withColor:(UIColor *)color { UIImage *tintableImage = [imageView.image imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate]; imageView.image = tintableImage; imageView.tintColor = color; }

As you can see, everything is pretty straightforward here.

Sidebar:

I've learned since, that you can actually set your images' rendering mode directly in the asset catalog GUI:

Diagnosis

It turns out there were 3 implementation details that contributed to the performance issue.

Tinting

UIImage imageNamed:

Asset Catalog

So, basically the entire implementation :)

Tinting

I won't get into why tinting was required, but there was a work around by providing natively sets of natively tinted images. It certainly helped, but there was still a bit of scroll lag.

UIImage imageNamed:

If you do a search for UIImage imageNamed performance, you'll get a lot of hits discussing problems with how Apple implements this. The key thing for our particular problem was that when an image instantiated this way is rendered by setting on a UIImageView, and because this must be done on the main (UI) queue, it causes a performance lag. It does this because the image must be decompressed at render time.

Asset Catalog

Based on the issues with UIImage imageNamed:, using the Asset Catalog was no longer an option. This wasn't really causing anything actually, but I prefer to use the Asset Catalog when I can.

Solution

The goal was to get perfectly liquid smooth scrolling every time, even on the first scroll. To achieve this, I implemented a caching strategy that I pieced together from my research on the issue. In a nutshell:

Place the images in the bundle, not the Asset Catalog.

When the app loads, start caching asynchronously.

Instantiate images using UIImage imageWithContentsOfFile: decompressing them and tint it as needed.

Wrap them in NSPurgeableData instances.

Use the images from the cache if available, otherwise create them and and cache them.

Let's go through all of this with actual code examples.

The cache

I used a simple NSCache object to provide automatic memory managed caching. Much preferred over NSDictionary. You can read more about NSCache here.

- (void)cacheSystemCueImages { dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{ for (CCSystemCue *cue in self.systemCues) { NSString *key = [cue thumbnailCacheKey]; if ([self.systemCueImageCache objectForKey:key]) { continue; } CCDiscardableImage *discardable = [CCHelper decompressedImageForPath:[cue imagePath] size:[cue thumbnailSize] tintable:[cue tintable]]; [self.systemCueImageCache setObject:discardable forKey:key]; } }); }

Here you can see the caching done on a background queue so it doesn't block the UI. Each image is stored along with a unique key, used to retrieve it later. I'll get into what a CCDiscardableImage in a bit.

Instantiating the images

We need to use UIImage imageWithContentsOfFile: to avoid the pitfalls of UIImage imageNamed:. Namely, don't let the OS do the caching for us. We want to fully control how we cache our images, specifically, already decompressed and tinted, so when we're on the main queue, it's only a matter of rendering a pre-processed image.

+ (CCDiscardableImage *)decompressedImageForPath:(NSString *)path size:(CGSize)size tintable:(BOOL)tintable { UIImage *image = [UIImage imageWithContentsOfFile:path]; return [self decompressedImage:image forSize:[self screenScaledSize:size] tintable:tintable]; } + (CGSize)screenScaledSize:(CGSize)size { CGFloat scale = [UIScreen mainScreen].scale; return CGSizeMake(size.width*scale, size.height*scale); } + (CCDiscardableImage *)decompressedImage:(UIImage *)image forSize:(CGSize)size tintable:(BOOL)tintable { UIGraphicsBeginImageContext(size); [image drawInRect:CGRectMake(0, 0, size.width, size.height)]; image = UIGraphicsGetImageFromCurrentImageContext(); UIGraphicsEndImageContext(); if (tintable) { image = [image imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate]; } return [[CCDiscardableImage alloc] initWithImage:image]; }

For us to store a fully decompressed image in the cache, which is what will help our performance, we need to provide the size at which it will be rendered at which is done by rendering it to a UIGraphicsImageContext and snapping an image from that.

CCDiscardableImage: NSPurgeableData

NSPurgeableData from the horse's mouth:

You should use the NSPurgeableData class when you have objects with bytes that can be discarded when no longer needed.

You might be wondering why we'd need to do this since NSCache already manages itself. Well, it does, but in my testing, it doesn't behave optimally. If we used NSCache directly with UIImages, the cache would fill up. But if I backgrounded the app, and then foregrounded it again, the cache would be empty and have fill up again. To avoid this, I wrapped the images in NSPurgeableData:

#import <UIKit/UIKit.h> @interface CCDiscardableImage : NSPurgeableData @property (readonly, strong, nonatomic) UIImage *image; - (instancetype)initWithImage:(UIImage *)image; @end #import "CCDiscardableImage.h" @interface CCDiscardableImage() @property (strong, nonatomic) UIImage *image; @end @implementation CCDiscardableImage - (instancetype)initWithImage:(UIImage *)image { if (self = [super init]) { _image = image; } return self; } @end

Using the image

I try to get the image from the cache first. If it's not there, I go through the same process as before to create it.

- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath { NSString *reuseIdentifier = NSStringFromClass([CCCueCell class]); CCCueCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:reuseIdentifier forIndexPath:indexPath]; CCSystemCue *cue = self.cues[indexPath.item]; NSString *key = [cue thumbnailCacheKey]; BOOL isSelected = [self isSelectedIndexPath:indexPath]; CCDiscardableImage *cachedDiscardable = [self.cueImageCache objectForKey:key]; if (cachedDiscardable) { [cell configureWithImage:cachedDiscardable.image isSelected:isSelected]; return cell; } dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{ CCDiscardableImage *newDiscardable = [CCHelper decompressedImageForPath:[cue imagePath] size:[cue thumbnailSize] tintable:[cue tintable]]; [self.cueImageCache setObject:newDiscardable forKey:key]; dispatch_async(dispatch_get_main_queue(), ^{ if ([self isVisibleIndexPath:indexPath]) { [cell configureWithImage:newDiscardable.image isSelected:isSelected]; } }); }); return cell; } - (void)configureWithImage:(UIImage *)image isSelected:(BOOL)isSelected { self.imageView.image = image; isSelected ? [self addBorder] : [self removeBorder]; }

If we need to create the image, we do that in the background again to not lock up the UI. But remember, we need to actually render the image on the main queue, otherwise, the rendering will be delayed. Also, the we really only need to render the image if the cell is still visible on the screen. If the user is scrolling super fast, the cell might be hidden at this point in time, in which case, no need to render it. A simple additional optimization.

Conclusion

The resulting implementation worked out well. There was zero scroll lag because all the heavy lifting was now done in the background. And this was because we were able to cache fully decompressed images by not using UIImage imageNamed:. The worse case scenario was if the user was very speedy by opening the library view and immediately scrolling down fast. This would result in some cells appearing blank for a fraction of a second. But the scrolling would remain liquid smooth. I hope this post or perhaps one bit of it was helpful for you.

Being present for 10 minutes is better than being just there for 60.

This was the advice a career coach once gave me when I was figuring out how to spend more time with my family.

Ever since practicing being present, it has improved my life as developer and as a person. If you do a search for "being present", you'll find many articles from fields like psychology, social science and spiritualism. There are clearly many benefits but I'm going to discuss this from my own experiences and how it has helped me.

Meaning of "present"

It means to live in the moment and in the place. It means to have your mind fully engaged with the people your with and the activity at hand. If I'm with my wife talking about weekend plans, I'm thinking about that, not the email I need to write before bed. If I'm writing code, it means thinking and writing code, not looking at my messages.

Why be present?

Being present in your interactions has several benefits:

Connect more deeply with others

When you're present, something magical is happening, at least for me it feels like this. Your minds are symbiotically working together, simultaneously communicating. Sure, only one person can speak at a time, but when the other person is present, they are communicating with body, their sounds and perhaps their touch. This deeper experience leaves people feeling more connected.

Boost creativity

When you're present amongst others, say in a meeting, you're more creative. Creativity can be thought of as ideas feeding off of other ideas. If you're not fully engaged, then you're not receiving or processing other people's ideas as well as you could, so your ideas won't be as good, or they might be stale or repeated. Have you ever heard someone say something great, but it was said 5 too late? That person obviously was not present. (I've totally done that!)

Boost productivity

If you're fully engaged with people or your task at hand, you're more effective and productive.

Boost memory

As you'll be processing things more deeply, you'll remember more of it.

All in all, it's a better experience for you and those around you. And when working independently, you'll get more done in less time and that feels great.

How can you be more present?

Make a conscious effort, that's pretty much it. But a lot of times it's not easy. It takes discipline, forethought and energy. Sometimes it's easy. Ever listen to an amazing speaker? You're totally in the moment, right? What about a bad speaker? You need to put in mental energy to be present. Also, as humans, we're wired to be distracted. So, in a nutshell, to be more present: eliminate distractions, and actively engage. Here are some practical things I do:

Eliminate distractions

Turn off your phone. Otherwise, use airplane mode and/or turn off notifications.* If you go into a meeting, don't bring anything with you. If you really need to, only pen and paper for notes. Or if you prefer, a laptop or tablet. Keep in mind though, depending on who's there, electronic devices can carry negative stigma compared to pen and paper.* When working on your device, make sure only the apps you need for the task at hand are open and quit all others. Use "distraction free" or full screen mode wherever possible to avoid temptation of opening email or another app. And turn your notifications off.

Actively engage

Listen to others, and avoid the temptation to speak until they're finished speaking. If you're worried you'll forget something you'd like to say while they're still talking, you shouldn't be because if it's important enough, you'll remember. If you're still worried, jot it down.* Look at the person, and make eye contact. This will keep you engaged with the person, and your ears will follow.* Ask clarifying questions and rephrase things they tell you. This will help you fully understand the other person's point, and signal to them you're actively listening.

When you're speaking, make eye contact, to help others engage with you.* Avoid ad-hoc interactions in favour of scheduled ones. Ad-hoc interactions interrupt you which breaks you being present on whatever you're doing. And second, it's hard to focus because your head still might be engaged with what you were just doing. If you're a developer, you know how much energy and time context switching takes.

Being present is better

Learning and practicing presence in my interactions isn't easy, it takes some effort. But it has easily been worth it for me, both personally and professionally. I hope my experiences can help you too.

Pair programming was brought into the mainstream by the Extreme Programming movement and is steadily gaining popularity in production environments. In my two years of pair programming and leading other pairs, I've noticed that sometimes pair programming is fantastic and once, can be even magical. And sometimes, it really sucked. I wanted to explore the reasons behind this and have identified a few patterns that might shed some insight into what it takes for pair programming to work well.

My pairing experience

I believe its important for you to know what kind of experience I have so you can evaluate this post within better context. I’ve been pair programming almost every day for about two years with two different companies. One was a consulting company where we developed applications for clients. The other was a high growth startup developing a large SaaS product. Through out this time, I paired with over 20 developers all with different backgrounds, personalities, skill, experience and cultures.

Side note: Just realizing how much of a benefit that is when you pair program. I've met so many wonderful people and have become friends with many of them.

Is pair programming worth it?

I wrote a bunch of stuff here on this topic in my draft but deleted it because I don't want to confuse the point of this post. There are many other research papers, opinions, stats, that say one thing or another. I don't think this question matters much in a general context. There are far too many variables.

In the writing below, you will see that I do believe there is good and bad pair programming. So my answer to this question is the most popular answer in our industry - "It depends." :)

And while I may have your attention on this topic, I will mention that I've noticed that pair programming will help the business if it also helps the programmers. (This may deserve a future post.)

Characteristics of effective pairs

When I think about all of my good and bad pairing experiences, many things that go through my head. Instead of repeating all of that, I summed everything up into this fancy, MBA, consulting style two-by-two matrix.

Pair programming success matrix

Definitions

(Mind the) effectiveness gap

In my observations, the most relevant, distinguishing factor between pairs was the gap in effectiveness between the two individuals. Many things go into how effective a programmer might be - their previous experience, domain knowledge, language knowledge, etc. If we combine all of those things together, we'll get "effectiveness". Perhaps another way to think about "effectiveness" is the potential strength of their output, including speed and quality. For the purposes of this discussion, I'm going to refer to high and low effective programmers as "seniors" and "juniors".

Benefit

When pairing, the hope is that the business (and the individuals) will benefit more than if the two worked independently.

Pairs with small effectiveness gaps

In my experience, these generally worked out better than pairs with large gaps. Perhaps the reason is because the developers have more in common, which equates to instant "free" empathy which helps improve their interactions. I believe the points outlined in the matrix are clear. Essentially, strong pairs with small effectiveness gaps have a good chemistry. They understand and respect each other, communicate often, and help each other learn. It results in a very satisfying and mutually beneficial interaction. It's usually a lot of fun too.

If we dig a level deeper, there are different characteristics between senior and junior pairs.

Junior pairs

It is my observation that junior pairs provide more benefit than senior pairs. Why? Probably because junior developers have weak opinions, their egos are smaller, and they care more about learning as opposed to being "right".

I also believe there's the "new kids in school" effect happening. Imagine you're a kid and your family moves to a new town in the middle of the school year. If there was another kid in your class who also joined around the same time as you, you'd probably become friends rather easily since you're both in the same situation. It's the same with pairing. If you're both new to the app/technology/language/whatever, you'll instantly have more empathy for one another. You'll want to explore similar things, get excited about solving the same type of problems and generally collaborate well.

When two juniors pair, the primary goal should be to learn.

Senior pairs

When both developers are seniors, it's harder to get a good match for the same reasons. Every programmer is different, and has different opinions. The more experience you have, the stronger those opinions are. Also, when you know a lot, it is possible for it inflate your ego. When one person has a large ego, the pair may yield poor decisions due to being insecure or the there person "tiptoeing" around to ensure they don't dent their pair's ego.

Even worse is when both pairs have large egos. In this case they argue (not debate) a lot and it can become tense with animosity. The worse I've seen is when the navigator would physically walk away from the workstation for extended periods of time. The pair wasn't even communicating at this point and obviously in negative benefit territory.

Good senior pairs have a lot of respect for each other. They talk a lot. They debate, discuss and plan. They work at a professional level, not personal. It is a thing of beauty. And the business benefits greatly with strong output.

When two seniors pair, the primary goal should be to produce.

Pairing juniors with seniors

Putting together a senior and junior requires a different approach. This pairing arrangement tends to happen when new developers join the company or switch into a new development context. The new, "junior" might be paired with a "senior" with the expectation for the junior to ramp up quickly. If the senior is not the right person, or has the wrong expectations, this will turn out badly. and risk hurting the junior's morale.

Expectation

Leadership must understand this arrangement is about ramping up the junior as fast as possible. But that must be understood by everyone who has a stake in this pair - the other developers, designers, QA, etc., and, especially the senior. The pair should not have any pressure to deliver, because once they do, it will ruin the pairing dynamic. It will turn into frustration on both sides because the senior will be slowed down by, or will run ahead of the junior.

Output will be slow while mentoring takes place.

Mentoring

Once the senior understands that their role is to mentor, and not to pump out stories, only then can the pair start to engage in beneficial work. But there's more to consider.

Good mentors listen, answer questions, observe and ask leading questions.

This is really hard to do because as human beings, we tend to do the opposite. So here's a reminder:

Do NOT tell them what to type, or tell them what to do or take over and show them. Stop yourself. Let them make the mistake you see coming. Let them feel some of the consequences. Let them think about why that was bad. Let them correct it. Let them ask you questions along the way. Try to answer with questions. If they get stuck, lead them out with questions.

I remember I was really under the gun to get stuff done while I was pairing with a brand new co-op student. I knowingly steamrolled my pair and continuously apologizing, which probably didn't make him feel any better. Looking back, I should have changed the pairing arrangement or found a way to take the pressure off.

It takes a ton of patience, self-confidence and empathy to be a good mentor. We want build the junior up, not show them what you know. From what I've seen, good programming mentors are lacking in our industry. Everyone is too busy trying to get stuff done or they just don't have the human skills to do it well. Some questions that may help determine if someone is a good mentor are:

Do they share knowledge and help juniors often? Do they get defensive about their skills or opinions? Are they comfortable with sacrificing for the good of the team?

When pairing a senior and junior together, the primary goal should be mentoring and learning.

Leadership's role

Culture

In any situation, good things happen when there is understanding between people. Pair programming is no different. Understanding comes from empathy, communication and self-confidence. Business and technical leaders can set the example so it can propagate down through the rest of the team. Culture comes from the top. And it's not what they say it is, it's how they act that defines culture.

Expectations

As I've identified above, each pairing scenario is different. It's important to recognize them as different, understand what will make it beneficial, and communicate that to everyone who needs to know so that expectations are clear and in alignment with the pairing dynamic.

Conclusion

This particular subject reinforced for me that programming is as much about people as it is about technology. We are people, writing software for people, in collaboration with other people. The technical skills are obviously required, but being a great programmer goes hand in hand with being a great person.

What is dependency injection?

Complicated explanation

Wikipedia provides a definition with perhaps more fancy terms along with a very general example, which I don't find very helpful.

Over simplistic explanation

This StackOverflow post has several answers, including one that quotes James Shore:

Dependency Injection" is a 25-dollar term for a 5-cent concept. [...] Dependency injection means giving an object its instance variables. […].

Although in his blog post he goes into more detail, this statement is misleading. Its more complicated than just providing instance variables.

My explanation

Having a good understanding of what problem dependency injection can solve might be a good place to start. If you can think of a time where you have existing, working code and then you're given the task of adding behaviour you didn't originally anticipate. Dependency injection can help with this sort of thing, so that the new behaviour is easy to add.

Here's my attempt at explaining it:

Dependency injection is recognizing the various changes your object needs to make. Instead of having your object make those changes, you move the changes out into their own "changer" objects (dependencies), and then pass (inject) them into your object for it to use. What gives dependency injection its power and usefullness is creating an abstraction from these dependencies to provide a unified interface. This way you your object has to care about this abstracted interface and not the actual dependency it recieves (which helps acheive loose coupling).

Examples are usually more helpful, so lets get to it.

Dependency injection example in Swift

This example is inspired by an example Sandi Metz did in a workshop I attended which helped clarify things for me. The following example shows the evolution of the Song class which recites the cumulative song, The House That Jack Built. For conciseness, I only use the first three lines of the song:

This is the house that Jack built.

This is the malt that lay in the house that Jack built.

This is the rat that ate the malt that lay in the house that Jack built.

We'll start with a single requirement, then add requirements that help reveal the need for dependency injection. I've created playground files located in this Github repository or you can directly download them. At the bottom of each playground file, there are "tests" to make sure our code is working.

Start - normal case

The initial requirements are to recite the song, or a specified line. This is in the file 0-Plain.playground.

class Song { private let lineStart = "This is " private let lineEnd = "." private let phrases = [ "the house that Jack built", "the malt that lay in", "the rat that ate" ] func line(number: Int) -> String { let linePhrases = self.phrases[0...number-1].reverse() let line = " ".join(linePhrases) return self.lineStart + line + self.lineEnd } func recite() -> String { var lines = [String]() for i in 1...self.phrases.count { lines.append(self.line(i)) } return "\n".join(lines) } }

Add first requirement - repeat each phrase

This requirement means we want each phrase in each line to repeat. For example, the second line would be:

This is the malt that lay in the malt that lay in the house that Jack built the house that Jack built.

There are several options to add this requirement and it doesn’t matter which one we choose as they'll converge to the same fundamental issue. I choose to do the following which can be seen in 1-Repeat.playground.

Make the phrases property mutable.* Create a custom init that takes a repeat boolean.

Conditionally modify phrases based on repeat.

class Song { // ... private var phrases = [ "the house that Jack built", "the malt that lay in", "the rat that ate" ] init(repeat: Bool) { if repeat { self.phrases = self.phrases.map { phrase -> String in return phrase + " " + phrase } } } // ... }

Here, we have a new dependency that the phrases array needs to be changed to accomodate the new requirement. Notice Song handles the dependency internally, it's not being injected in.

Add second requirement - reverse the song

Now we want the ability to recite the song and each lines backwards. For example, line two would be:

This is the malt that lay in the rat that ate.

To add this, I simply follow the pattern already established. The changes made in 2-Reverse.playground are:

Instead of a boolean now, pass in a songType to indicate how the song should be sung.

Add the code to reverse phrases.

class Song { // ... init(songType: String) { if songType == "repeat" { self.phrases = self.phrases.map { phrase -> String in return phrase + " " + phrase } } else if songType == "reverse" { self.phrases = self.phrases.reverse() } } // ... }

Now we have two dependencies that Song internally handles. This code is a bit wierd as we still have to pass in a string for the normal case. We could solve this in a few ways, but that's not the focus so lets leave it for now.

What if we are to add a third requirement now? You're probably feeling the urge to look for a better way than to just add a third songType. The code we have now isn't "open" for change, in that, to add new new behaviour, we need to modify our code. We want to be able to only add new code.

Move dependencies out

First, lets move the dependent code their own classes and modify our init accordingly to use them in 3-Classes.playground:

class Repeater { func result(list: Array<string>) -> Array<string> { return list.map { item -> String in return item + " " + item } } } class Reverser { func result(list: Array<string>) -> Array<string> { return list.reverse() } } class Song { // ... init(songType: String) { if songType == "repeat" { self.phrases = Repeater().result(self.phrases) } else if songType == "reverse" { self.phrases = Reverser().result(self.phrases) } } // ... }

Now that our dependencies live outside of Song, the code is a little bit nicer, but it's still not open for change. We still have the conditional in our init and our Song still must know about both Repeater and Reverser dependencies. To solve this problem, we need the ability to inject these dependencies into Song. But how? By creating an abstraction of and so we can provide a unified interface to them. There are three ways to do this in Swift: inheritance, protocols, and closures. For this example, I choose to use a protocol.

Note: If we were doing this in a dynamically typed language like Ruby, we wouldn't need this step since we've already given our dependencies the same interface, result().

Inject dependencies

We create our protocol Remixer and have our dependencies conform to it. Now we can inject any class conforming to Remixer into Song's init as seen in 4-Injectction.playground.

protocol Remixer { func result(list: Array<string>) -> Array<string> } class Repeater : Remixer { // ... } class Reverser : Remixer { // ... } class Song { // ... init(remixer: Remixer?) { if remixer != nil { self.phrases = remixer!.result(self.phrases) } } // ... }

That's it! That is dependency injection.

You might be wondering about why init takes an optional Remixer value. That was a choice I made. We could have also created another Remixer called Keeper that does returns the list without modification, and inject a Keeper into init. Or also set a Keeper as the default paramater value.

Add third requirement - randomize the song

This requirement means to play the song in a random order. And now that Song is open to change via dependency injection, this requirement is trivial to add. We simply add a new Remixer called Shufflerand inject it in as shown in 5-Shuffle.playground.

Problem

Recently, for an iOS project I was working on, I needed to speed up the modal animation and alter its duration curve to match a different custom animation somewhere else in the app. Unfortunately, the built-in modal segue or presentViewController:animated:completion: doesn't provide any opportunity to modify the animation.

My first thought was to get my custom animation to match Apple's built-in modal animation behaviour. But how? It's not published anywhere. I could brute force match it by trial and error, but then app would have a dependency on Apple. If Apple were to change their stock animation in the future, I'd run into the same problem.

Solution

It was clear that I needed to build my own modal animation so I could have full control without any dependencies. The solution uses the iOS 7+ custom animation protocols: UIViewControllerAnimatedTransitioning and UIViewControllerAnimatedTransitioningDelegate. There's plenty of literature about how they work. If you're interested in digging in, here is a good point: objc.io - View Controller Transitions. At the bottom of that article, there are more links, including reference to the WWDC video.

Example

From a birds eye, here is how things work:

From the presenting view controller, initialize and configure the animator.

Configure the modal and present/dismiss it with animation set to YES. If you don't turn the animation on, the animator will not be used.* Provide the animator to the UIViewControllerTransitioningDelegate delegate methods.

In the animator, configure and animate your views.

Code

Here is some code that illustrates how to do this. Note that I've left out the unrelated bits.

Presenting View Controller

// PresentingViewController.m #import "ModalAnimator.h" @interface PresentingViewController () <UIViewControllerTransitioningDelegate> @property (strong, nonatomic) ModalAnimator *modalAnimator; @end @implementation PresentingViewController - (void)viewDidLoad { [super viewDidLoad]; self.modalAnimator = [ModalAnimator new]; } // Storyboard "Present Modally" seque with "Animates" turned on. - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { UIViewController *viewController = segue.destinationViewController; viewController.modalPresentationStyle = UIModalPresentationCustom; viewController.transitioningDelegate = self; } #pragma mark - UIViewControllerTransitioningDelegate methods - (id<UIViewControllerAnimatedTransitioning>)animationControllerForPresentedController:(UIViewController *)presented presentingController:(UIViewController *)presenting sourceController:(UIViewController *)source { [self.modalAnimator shouldPresent]; return self.modalAnimator; } - (id<UIViewControllerAnimatedTransitioning>)animationControllerForDismissedController:(UIViewController *)dismissed { [self.modalAnimator shouldDismiss]; return self.modalAnimator; } @end

Here you can see the general flow. In this example, a storyboard segue is used to present the modal. Here is how the segue is configured in the storyboard:

Alternatively, it could have been presented in code like so:

viewController.modalPresentationStyle = UIModalPresentationCustom; viewController.transitioningDelegate = self; [self presentViewController:viewController animated:YES completion:nil];

Custom Animator

// ModalAnimator.h @interface ModalAnimator : NSObject <UIViewControllerAnimatedTransitioning> - (void)shouldPresent; - (void)shouldDismiss; @end

The public interface is very simple. Only a couple of configuration setters to let the animator know if we should be using the present or the dismiss animation. As seen above in the PresentingViewController.m code, these get called in the UIViewControllerTransitioningDelegate methods.

// ModalAnimator.m @interface ModalAnimator () @property (nonatomic) BOOL isPresenting; @end @implementation ModalAnimator - (instancetype)init { self = [super init]; if (self) { self.isPresenting = YES; } return self; } - (void)shouldPresent { self.isPresenting = YES; } - (void)shouldDismiss { self.isPresenting = NO; } #pragma mark - UIViewControllerAnimatedTransitioning methods - (NSTimeInterval)transitionDuration:(id<UIViewControllerContextTransitioning>)transitionContext { return 0.2; } - (void)animateTransition:(id<UIViewControllerContextTransitioning>)transitionContext { UIViewController *fromVc = [transitionContext viewControllerForKey:UITransitionContextFromViewControllerKey]; UIViewController *toVc = [transitionContext viewControllerForKey:UITransitionContextToViewControllerKey]; UIView *fromView = fromVc.view; UIView *toView = toVc.view; UIView *containerView = transitionContext.containerView; NSTimeInterval duration = [self transitionDuration:transitionContext]; if (self.isPresenting) { UIViewController *topFromVc = [self topViewControllerForViewController:fromVc]; [topFromVc viewWillDisappear:YES]; fromView.userInteractionEnabled = NO; [containerView addSubview:toView]; // Setup animating the view from the bottom of the screen. CGRect originalFrame = toView.frame; CGRect hiddenFrame = CGRectMake(originalFrame.origin.x, originalFrame.size.height, originalFrame.size.width, originalFrame.size.height); toView.frame = hiddenFrame; [UIView animateWithDuration:duration animations: ^{ toView.frame = originalFrame; } completion: ^(BOOL finished) { [transitionContext completeTransition:![transitionContext transitionWasCancelled]]; [topFromVc viewDidDisappear:YES]; }]; } else { UIViewController *topToVc = [self topViewControllerForViewController:toVc]; [topToVc viewWillAppear:YES]; CGRect hiddenFrame = CGRectMake(fromView.frame.origin.x, fromView.frame.size.height, fromView.frame.size.width, fromView.frame.size.height); [UIView animateWithDuration:duration animations: ^{ fromView.frame = hiddenFrame; } completion: ^(BOOL finished) { [fromView removeFromSuperview]; toView.userInteractionEnabled = YES; [transitionContext completeTransition:![transitionContext transitionWasCancelled]]; [topToVc viewDidAppear:YES]; }]; } } #pragma mark - Private methods - (UIViewController *)topViewControllerForViewController:(UIViewController *)viewController { if ([viewController isKindOfClass:[UINavigationController class]]) { UINavigationController *navigationController = (UINavigationController *)viewController; return navigationController.topViewController; } else { return viewController; } } @end

The animator essentially implements two delegate methods which describe the animation and its duration. A couple of things to take note of:

To preserve the way the default modal presentation works, manually call view lifecycle methods.

The private method topViewControllerForViewController: is here to ensure that the view life cycle methods are called on the correct view controller.

Wrap-Up

I ended up using this modal animator in a few places in my app, and now it looks and feels consistent. If this has helped you or have different or better ways to speed up modal animations in iOS, feel free to comment.

Presenting the Modal

Modal viewDidLoad

Presenter viewWillDisappear:animated:

Modal viewWillAppear:animated:

Modal viewDidAppear:animated:

Presenter viewDidDisappear:animated:

Dismissing the Modal

Modal viewWillDisappear:animated:

Presenter viewWillAppear:animated:

Presenter viewDidAppear:animated:

Setup

Create a new app extension target by going go File, New, Target in the Xcode menu, then in the left panel select Application Extension and select Share in the right pane. Next, you'll need to name it, and then make sure it belongs to your correct project and embedded in your main target. Remember, app extensions must be distributed with your main app.

Now run the app in Xcode, open a website in Safari and tap the Share icon on the bottom. The Action Sheet should appear and your app should be amongst the sharing options. If you tap on your app, a native share dialog should appear. If you have that working, then we're good to move on.

Xcode creates a target and a folder of files which you'll see in the Project Navigator. If you inspect that folder you should see three files:

ShareViewController.swift

MainInterface.storyboard

Supporting Files/Info.plist

In this example, we'll ignore the MainInterface.storyboard file as we're more interested in simply getting the url from Safari to share.

Info.plist

First thing's first, lets get our extension configured to share URLs by opening up the Info.plist file and making a few changes. If you right click on it in the Project Navigator, and select Open As, Source Code, we can it in its XML form. We need to change NSExtensionActivationRule to a dictionary and add NSExtensionActivationSupportsWebURLWithMaxCount as a Number with the value 1. This lets the OS know that we'll be looking for a web url in our controller. The final result of the NSExtensionKey node in the file should look like this:

<key>NSExtension</key><dict><key>NSExtensionAttributes</key><dict><key>NSExtensionActivationRule</key><dict><key>NSExtensionActivationSupportsWebURLWithMaxCount</key><integer>1</integer></dict><key>NSExtensionPointName</key><string>com.apple.share-services</string><key>NSExtensionPointVersion</key><string>1.0</string></dict><key>NSExtensionPointIdentifier</key><string>com.apple.share-services</string><key>NSExtensionMainStoryboard</key><string>MainInterface</string></dict>

Code

Now that we're configured, lets get into the code and open up ShareViewController.swift. You'll see Xcode stubs out a few methods for us, but to keep this example focused, the only method I'll work in for this example is didSelectPost. This is a delegate method that gets called when the user taps the "Post" button in the share dialog. In here, we'll add the code needed to extract the url and user entered text for our share.

override func didSelectPost() { //get the itemProvider which wraps the url we need var item : NSExtensionItem = self.extensionContext.inputItems[0] as NSExtensionItem var itemProvider : NSItemProvider = item.attachments[0] as NSItemProvider //pull the URL out if (itemProvider.hasItemConformingToTypeIdentifier("public.url")) { itemProvider.loadItemForTypeIdentifier("public.url", options: nil, completionHandler: { (urlItem, error) in var urlString = urlItem.absoluteString //do what you need to do now, such as send a request to your server with this url }) } //default stubbed out code which can pass data back to the host app. self.extensionContext.completeRequestReturningItems(nil, completionHandler: nil) }

Notice in the completion handler closure, there are no typed arguments. This is because Swift will automatically infer the argument type. If we try to type urlItem to NSURL, we'll get compile errors, because that argument is inherently NSSecureEncoding!.

This post assumes you're already familiar with the basics of Kiwi testing. For more information about Kiwi, you can look at the Kiwi documentation or read Test Driving iOS Development with Kiwi.

Private Methods/Properties

Before learning about this, we were exposing private methods and properties in order to test them. And felt dirty in the process. To avoid this, use is a class extension. In your test file, create an interface to the class that has the private stuff you need to test. Then simply declare any private methods/properties and voila!

#import "Kiwi.h" #import "SGStopWatch.h" @interface SGStopWatch (StopWatchTesting) @property (nonatomic, strong) UILabel *clockLabel; - (void)resetClockLabel; @end SPEC_BEGIN(StopWatchSpec)

Block Variables

As everything in Kiwi is done via blocks, if you like to reset the state by instantiating (or replacing) your variable inside of a block, you need to preface your variable declaration with __block. This is especially useful for any beforeEach blocks you create.

describe(@"Stopwatch", ^{ context(@"when stopped", ^{ __block SGStopWatch *stopWatch; beforeEach(^{ stopWatch = [SGStopWatch new]; }); }); });

Shortcut Tests

A quick and dirty tip, but worth mentioning. You can test for nil using shorthand like this: [stopWatch shouldBeNil] or [stopWatch shouldNotBeNil]

Pending Tests

If you like stubbing out tests, and then coming back to them later, you can mark your tests "pending" by starting them with pending instead of it. Pending tests are not actually tested, so it won't affect your overall test result. What I like about using pending is that it produces a yellow compiler warning so you won't forget about it.