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 →