The Clean Architecture: An Introduction

In the last post, I talked about various architectures used as alternatives to MVC, in a attempt to solve MVCs problems, such as Massive View Controller.

In this post, I would like to introduce you to another architecture, which seems to me to be the best starting point for your app’s architecture: the Clean Architecture.

Continue reading

Moving Towards The Clean Architecture for Apple Development

In the last post, I talked about MVC, its problems, and how it could be done right. Various architectures have emerged to try to address the deficiencies of MVC. Before I talk about the Clean architecture, I like to talk about some of them.

Alternative Architectures to MVC

Up front, I don’t have a lot of experience with these, but I have studied them and I believe they are a step in the right direction. They all introduce another object to take over some of the responsibilities from the controller, but I don’t think they go far enough because the new object typically has too many responsibilities as well and tends to grow just as the controller in MVC does. They do spread the load though, reducing the issues with MVC and increasing testability. 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

5 Ways to Avoid Force Unwrapping

Someone on the reddit iOS Programming group asked “What are the mistakes generally done by iOS developers while coding in Swift?”A lot of comments were about using force unwrapping on optionals. Comments such as:

  • Force unwrapping everything
  • Using pyramids of if-let as opposed to guard statements
  • var firstName: String! ugh
  • Overuse of force unwrapped optionals. I cringe when I see that especially when a simple one-liner guard statement would make the code a ton safer.

So, I thought I would address this concerns and list 5 ways you can avoid force unwrapping.

Continue reading

Do You Find The Whole Planning Process Painful?

A thread in the AskPrograming forum on reddit started with this question and I thought I would share my thoughts on planning and up-front design.

Basically, the originator of the thread is expressing his dislike of planning before coding, but thinks it’s a good idea because they’ve either been told that or seen others do it. They also expresses dislike for planning tools and wonders if there’s a better way. Basically, they wants to know how do you plan and how do you break up a project into tasks that you need to do. 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