Chapters
Chapters

Chapters

Hide chapters

iOS Test-Driven Development by Tutorials

First Edition · iOS 13 · Swift 5.1 · Xcode 11

Before You Begin

Section 0: 3 chapters
Show chapters Hide chapters

Section I: Hello, TDD!

Section 1: 2 chapters
Show chapters Hide chapters

Section II: Beginning TDD

Section 2: 4 chapters
Show chapters Hide chapters

Section III: TDD with Networking

Section 3: 4 chapters
Show chapters Hide chapters

Section IV: TDD in Legacy Apps

Section 4: 6 chapters
Show chapters Hide chapters

14. Modularizing Dependencies
Written by Michael Katz

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

You can unlock the rest of this book, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now

Splitting an app into modules, whether they be frameworks, static libraries or just structurally-isolated code, is an important part of clean coding. Having files with related concerns at the same level of abstraction makes your code easier to maintain and reuse across projects.

In this chapter, you’ll continue the work from the last chapter, further breaking MyBiz into modules so you can reuse the login functionality. You’ll learn how to define clean boundaries in the code to create logical units. Through the use of tests, you’ll make sure the new architecture works and the app continues to function.

Making a place for the code to go

There are several ways to modularize an app. In this tutorial, you’ll use the most common and easiest: A new dynamic framework. You can reuse a framework in many iOS projects and distribute it through tools like Cocoapods, Carthage or Swift Package Manager.

Even if you completed the challenge from the last chapter, start with this chapter’s starter project. That way, you won’t have any discrepancies with file or test names.

Let’s start by creating the new framework:

  1. From the Project editor, create a new target. Choose the Framework template to create a dynamic framework and click Next.
  2. Set the Product Name to Login.
  3. Make sure you’ve checked Include Unit Tests. This sets you up to add tests right away!

  1. Click Finish.
  2. Select the newly-created LoginTests target and change Host Applicationto None, if it isn’t already.
  3. Select Build Phases and make sure Login is the only dependency. Remove MyBiz as a dependency.

Moving files

The dependency map is free of cycles around LoginViewController, so now you can finally move some files.

Breaking up Styler’s dependencies

The first error you may notice is in Styler.swift. Styler relies on a configuration from the AppDelegate. It breaks encapsulation to refer to the app delegate in this helper framework, so you’ll need another way to set the configuration.

struct UIConfiguration: Codable {
  struct Button: Codable {
    let cornerRadius: Double
    let borderWidth: Double
  }
  let button: Button
}

var configuration: UIConfiguration?

button.layer.cornerRadius = CGFloat(configuration?.button.cornerRadius ?? 0)
button.layer.borderWidth = CGFloat(configuration?.button.borderWidth ?? 0)

Modularizing a storyboard

In the app, you create an ErrorViewController via a storyboard. You do this explicitly in UIViewController+Alert.swift through the Main storyboard. Since this storyboard lives in an app module, it’s not available to this framework.

let thisBundle = Bundle(for: ErrorViewController.self)
let storyboard = UIStoryboard(name: "UIHelpers",
                              bundle: thisBundle)
let alertController = storyboard.instantiateViewController(withIdentifier: "error")
  as! ErrorViewController

Moving tests

What about the tests? You already have some test cases that cover ErrorViewController. You can move those, too.

@testable import UIHelpers

override func setUp() {
  super.setUp()
  sut = UIStoryboard(name: "UIHelpers",
                     bundle: Bundle(for:
                              ErrorViewController.self))
    .instantiateViewController(withIdentifier: "error")
    as? ErrorViewController
}

Using the new framework with Login

Now that you have given the UI helpers their own framework, you need to tell the Login framework about it.

import UIHelpers

public init(title: String, action: @escaping () -> ()) {
  self.title = title
  self.action = action
}

Further isolating LoginViewController

Change the build scheme now to Login and build and run. You’ll still get a lot of compiler errors.

public protocol LoginAPI {
  func login(username: String,
         password: String,
         completion: @escaping (Result<String, Error>) -> ())
}

api.login(username: username, password: password) { result in
  if case .failure(let error) = result {
    self.loginFailed(error: error)
  }
}

Don’t forget the tests

Next, you’ll want to add tests to your protocol to verify the changes you’ve just made.

@testable import MyBiz

@testable import Login

Fixing MyBiz

Now that you have two new frameworks that contain previously-available code, you’ll need to fix up the dependencies their usage project. Switch back to the MyBiz scheme and you’ll start seeing all sorts of build errors.

import UIHelpers

let ui: UI

let ui: UIConfiguration

import Login

import Login

func login(
  username: String,
  password: String,
  completion: @escaping (Result<String, Error>) -> ()) {

  let eventsEndpoint = server + "api/users/login"
  let eventsURL = URL(string: eventsEndpoint)!
  var urlRequest = URLRequest(url: eventsURL)
  urlRequest.httpMethod = "POST"
  let data = "\(username):\(password)".data(using: .utf8)!
  let basic = "Basic \(data.base64EncodedString())"
  urlRequest.addValue(basic,
                    forHTTPHeaderField: "Authorization")
  let task = session.dataTask(with: urlRequest)
  { data, _, error in
    guard let data = data else {
      if error != nil {
        DispatchQueue.main.async {
          completion(.failure(error!))
        }
      }
      return
    }
    let decoder: JSONDecoder = JSONDecoder()
    if let token = try? decoder.decode(Token.self,
                                       from: data) {
      self.handleToken(token: token, completion: completion)
    } else {
      do {
        let error = try decoder.decode(APIError.self,
                                       from: data)
        DispatchQueue.main.async {
          completion(.failure(error))
        }
      } catch {
        DispatchQueue.main.async {
          completion(.failure(error))
        }
      }
    }
  }
  task.resume()
}

func handleToken(token: Token,
                 completion: @escaping (Result<String, Error>) -> ()) {
  self.token = token
  Logger.logDebug("user \(token.userID)")
  DispatchQueue.main.async {
    let note = Notification(name: UserLoggedInNotification,
                            object: self,
                            userInfo: [UserNotificationKey.userId:
                                        token.userID.uuidString])
    NotificationCenter.default.post(note)
    completion(.success(token.userID.uuidString))
  }
}

class API: LoginAPI

Fixing the storyboard

Even though the app builds, it does not yet run or pass the tests. The next stop on this refactor train is to work on the storyboard.

Fixing the tests

There are a few build issues to fix in the tests.

override func login(
  username: String,
  password: String,
  completion: @escaping (Result<String, Error>) -> ()) {

  let token = Token(token: username, userID: UUID())
  handleToken(token: token, completion: completion)
}

override func login(
  username: String,
  password: String,
  completion: @escaping (Result<String, Error>) -> ()) {

  loginCalled = true
  super.login(username: username,
              password: password,
              completion: completion)
}

sut.login(username: "test", password: "test") { _ in }

@testable import Login
@testable import UIHelpers

@testable import UIHelpers

override func setUp() {
  super.setUp()
  sut = UIStoryboard(
    name: "UIHelpers",
    bundle: Bundle(for: ErrorViewController.self))
    .instantiateViewController(withIdentifier: "error")
    as? ErrorViewController
}

Wrap up

Pat yourself on the back. Login is now in its own framework and ready to be re-used in another project. You’ll have to distribute both the Login framework and the UIHelpers frameworks, but it’s normal for frameworks to have their own dependencies.

Challenges

This chapter walked you through the minimum amount of work to cleanly pull the Login functionality into its own framework. However, there’s (a lot of!) room for improvement. Fix up the project by completing any of the following:

Key points

  • Frameworks help organize code and keep the separation of dependencies clean.
  • Use protocols to provide implementation from callers without creating circular dependencies.
  • Write tests before, during and after a large refactor.

Where to go from here?

Gosh, that was a lot of work, but you really cleaned up the code. There are a few areas that are worth investigating in the future to improve your architectural hygiene. Some of these were suggested in the Challenge, but you can achieve even more improvement with a dedicated user state manager, and by using a pattern like Router or FlowController to handle showing the error and login screens, rather than relying upon AppDelegate.

13. Breaking Up Dependencies
15. Adding Features to Existing Classes
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now