Before we proceed full speed in developing our app, we need to establish a software architectural pattern.
What is a software architectural pattern?
A software architectural pattern is a way of architecting or organizing, the code. That includes the way of creating folders, files or groups of files, file components, and techniques used to make those components function as a whole; in short, a complete application.
Choosing an architectural patterns
There are a number of design patterns available to developer to utilize. The popular ones are:
MVC - Model View Controller
MVP - Model View Presenter
MVVM - Model View ViewModel
They all have pros and cons and choosing one over another is determined by the specifics of each project. All of those are reasonably popular, however MVC is still dominant for native iOS development.
Part of this domination is the reinforcement of this pattern by Apple. This is how Apple organizes its code and suggests the structure for developers by how it presents the development kit and the default code generated by Xcode.
Understanding the Model-View-Controller (MVC)
Let’s identify each component:
Model is the data and the logic of the specifics of our application.
View is represented by all the visual components that are presented to the user.
Controller is a linking element that manages both the model and the view.
The controller is responsible for communicating independently with the view AND with the model.
And what’s critically important is that the model AND the view NEVER INTERACT! We can even say they don’t know of each other’s existence!
Why is this so important?
This is a key requirement that allows us to implement flexible and abstract code that is easy to develop, test, and maintain.
For example, say, we have an app and are happy with its functionality but would like to refresh its visual appearance (the look and animations) or perhaps introduce some fancy interactions. The primary component we need to adjust will be the view. And, perhaps, some of the controller, but not the model.
Let’s see how the MVC model applies to our project.
MVC for iOS
As you may guess, the way we have our project restructured by Xcode, implements the MVC architecture. Let's review it deeper.
Our model will include all the logic specific to the app. This is a very custom element that is not created by Xcode by default. The structure and contents of every file is unique to the app and it would be unreasonable to attempt to create a single template for it.
At the moment we don't have any files to include in this category, but this will change shortly!
The view is represented by all the visual elements of the application. And, since we've already got started on this, we know that we'll be implementing our visual interface in a storyboard. Specially, we'll be using Main.storyboard file. It's empty for the moment, but we can already observe the initial template of file:
The controller will include the managing code that will coordinate the view - all the elements on our main storyboard and the model - the custom files we'll create to implement the logic of our app.
We haven't written any code yet, however, like for the view, we have a file that was generate for us with some default code in it - ViewController.swift:
Is this a perfect architecture?
There are many arguments against Apple's choice of MVC architecture, however, the Apple's implementation. In part, it gets misinterpreted and abused, resulting into less efficient code.
The main misuse of this patterns is placing ALL the 'controller' code within ViewController files. This typically results into gigantic inefficient view controller files.
In fact, file name - ViewController - actually suggests that mostly the view controlling elements needs to go there as well as usage of OTHER controllers.
In more complex applications, say, we have a payment system. We may implement a separate PaymentController instead of placing payments management code within a specific ViewConctroller.
Or, if we have a sophisticated camera functionality, there round be a CameraController.
For simpler applications, however, it's typical and acceptable to place most of the controlling code into the ViewController files.
And what is the rest of the files?
The rest of the files we can call supporting files. Some were included by us - like the custom font file. And others regenerated by Xcode. You are already familiar with all of them to come degree except for AppDelegate.swift.
AppDelegate.swift is the main code file that operating system executes when the app is launches. The time needed to launch the app is managed in this code, the more it needs to execute, the longer the app will take to launch.
Grouping project source files
Let's organize the source files of our project according to what we learned, so that it's easier to navigate the code.
There are two ways to organize files:
By creating groups that will have physical folders and placing files in them. You can also observe the same file structure in Finder.
By creating virtual groups and only referencing the files organized in different physical file structure.
For that we'll create 3 groups with folders - one for each MVC component.
The first we'll create is for Model. We don't have any files that will belong to it yet. To create an empty group, right click on 'FrameIT' folder and select 'New Group' and name the new folder 'Model':
Next let's create a group for the view. Select the Main.storyboard file and right click on it. This time select 'New Group from Selection' option and name the folder 'View'.
Repeat the same for the controller by selecting the ViewController.swift file and creating a folder 'Controller' for it.
And finally, let's select the rest of the files in the Navigator and create a virtual group for them. Right-click on 'FrameIT' like you did for the model and this time select 'New Group without Folder' and name it 'Supporting files'.
As a result your should have following project structure in the Xcode Navigator and Finder:
A couple things to highlight here:
Our storyboards are hidden further within project folder Base. When we decided to create a View folder that included the main storyboard, Xcode created another warping Base for it and moved it to our Model folder. And the launch screen storyboard remained within the original Base folder in our root FrameIT folder.
The Controller folders' contents are as expected - containing our ViewController.swift file.
Removing files from the project
Another useful file manipulation to learn is removing files from a projects. We have 2 options:
Remove the reference. This will make the project ignore the file, however the file will physically remain in it's original folder. The file may later be re-added. Or moved manually to a different folder of a project and them re-added.
Removing the file completely. This will delete the file completely.
When do we get to chose one of the options?
When we try to delete a file or a group/folder, we are presented a dialog. Let's try to delete our ViewController.swift file:
Make a copy of your current project and spend a few moments experimenting with creating groups and folders in your project and removing/adding and moving files around. Observe how your manipulations affect the physical file structure in finder. This understanding will help you be able to troubleshoot if your file manipulations cause any issue in your project.
We are all set to continue the implementation!
The MVC architectural pattern means Model View Controller. It implies code organization of three parts:
Model contains the logic of the application.
View implements the interface of the application.
Controller is a linker between the model and the view.
The model and the view NEVER communicate.