The Clean Architecture: An Example

Today, I’d like to take an example iOS app written with an MVC architecture and show you what the example would be with a Clean Swift architecture. The example I’ve chosen to use is the Quiz app from chapter 1 of the 3rd edition of iOS Programming: The Big Nerd Ranch Guide.

The Quiz is a simple app that is like flash cards. It looks like this:

The Show Answer button will reveal the answer to the question and tapping on the Next Question button will display the next question.

The MVC Example

Click here to download the source code for the MVC version from Big Nerd Ranch’s site. The code is actually from the 6th edition.

Let’s look at the relevant code. Here’s the code for the view controller, ViewController.swift: Continue reading →

Model View Controller: Problems and Solutions

Model View Controller or MVC is the application architecture used by default for applications on all Apple platforms. Most of the tools, frameworks, and docs from Apple all talk about it and support it.

In MVC, objects are assigned 1 of 3 roles:

  • Model – objects that encapsulate and manage the data the application works with (this includes persistence). The data typically represents things in the real world like an employee, hardware part, or a picture that is being drawn. More abstract things can also be part of a model such as a hiring process. When data in the model changes it notifies a controller object, typically via delegation or notifications. Model objects should have no knowledge of the user interface and be reusable in other applications in similar problem domains or on other devices.
  • View – user interface objects that displays the model’s data and respond to user interface events such as taps, swipes, mouse clicks, etc. The view has no knowledge of the model. It simply display what a controller tells it to. Events are likewise just relayed to the controller.
  • Controller – The object that coordinates the model and the view. It handles user interface events and translates them into actions on the model. When the model changes it tells the view to update itself with new data it obtained from the model.

Here’s a nice picture from Apple’s documentation that nicely depicts the above description:

Model View Controller Diagram

Model View Controller Diagram

For a more detailed description of MVC, I highly recommend you read Apple’s documentation on MVC.

Problems with MVC

Continue reading →

Part 4: What Are the Downsides to Putting the Core Data MOC in the App Delegate

In part 3, I talked about why putting the MOC in the app delegate makes any code that uses the MOC will be dependent on the app delegate and why that’s not a good thing.

In part 2, I talked about why putting the MOC in the app delegate is a violation of the Single Responsibility Principle.

In part 1, I talked about why putting the MOC in your app delegate makes you dependent on Core Data for your application’s persistence.

Today, I Iike to address the 4th and final reason I gave in part 1. Here the 4th reason again:

Any tests you write will be dependent on the App Delegate and Core Data and will be hard to test and slow as a result.

Continue reading →

Part 3: What Are The Downsides to Putting the Core Data MOC in the App Delegate

In part 2, I talked about why putting the MOC in the app delegate is a violation of the Single Responsibility Principle.

In part 1, I talked about why putting the MOC in your app delegate makes you dependent on Core Data for your application’s persistence.

Today I like to talk about the 3rd reason I gave in part 1, which is:

  • Any code you write that uses myManagedObjectContext will be dependent on the App Delegate.

Continue reading →

Part 2: What Are The Downsides to Putting the Core Data MOC in the App Delegate

In my previous post, I gave some reasons why putting the Core Data MOC in your app delegate was a bad idea. Those reasons were:

  1. The app delegate is managing the Core Data stack. Classes should only have one responsibility. The app delegate is already responsible for managing application lifecycle. It shouldn’t be managing the Core Data stack as well.
  2. You are completely dependent on Core Data and using it as your persistence method for your app. What if you decide to switch to Realm or something?
  3. Any code you write that uses myManagedObjectContext will be dependent on the App Delegate.
  4. Any tests you write will be dependent on the App Delegate and Core Data and will be hard to test and slow as a result.

In the previous post, we talked about how putting the Core Data MOC in your app delegate makes your app dependent on Core Data as your persistence mechanism and makes it hard to use something else.

Continue reading →

3 Ways To Fix Your iOS Testing Woes

Lots of companies have constant problems testing their iOS apps. Here are some ways to fix or ease them.

1. Don’t Make Developers Run or Write UI Tests

UI tests are black box tests and test the app from the perspective of the user. Your developers are the worst choice to test the app from this viewpoint and you need a fresh set of eyes for those tests. The QA engineer’s job is to test the app from the user’s viewpoint. Your QA Engineers should write these tests.

Plus, UI tests run entirely too slow for your developers to run them all the time and are much too failure prone. Don’t waste their time by making them write and run these tests.

Continue reading →

What are the Downsides to Putting the Core Data MOC in the App Delegate?

I saw this question on the iOSProgramming topic in reddit:

I’ve seen a number of different ways to access the NSManagedObjectContext when working with Core Data, but I was wondering if there are any downsides to the way I’ve been doing it. Basically, I stick a computed variable in the AppDelegate, and grab it when I need it…

Please let me know if you see any flaws… If not, feel free to use it!

The writer then shows the following code which is the computed variable:

There are a number of downsides to this:

  1. The app delegate is managing the Core Data stack. Classes should only have one responsibility. The app delegate is already responsible for managing application lifecycle. It shouldn’t be managing the Core Data stack as well.
  2. You are completely dependent on Core Data and using it as your persistence method for your app. What if you decide to switch to Realm or something?
  3. Any code you write that uses myManagedObjectContext will be dependent on the App Delegate.
  4. Any tests you write will be dependent on the App Delegate and Core Data and will be hard to test and slow as a result.

This is basically the lazy developer’s way of doing things. Granted the Xcode templates generate the Core Data code in the app delegate and doing this makes it easy to get the MOC, but Apple’s example code and the Xcode templates are not always the best way to do things. They are frequently the opposite.

In this post, let’s just focus on the 2nd issue, that of being dependent on Core Data and using it as your persistence method. Perhaps I will cover the other issues in future posts.

Continue reading →