There are four fundamental stages or processes that you will go through during the implementation of an application:
Regardless of whether it is an Objective-C or an iOS application, each and every application will follow these same basic implementation steps and in this post we’re going to take a closer look at each step in turn.
This is the process in which you create and modify Objective-C source code. Source code is the name given to the programming instructions or statements that you write to tell your computer what you want it to do. Objective-C is a particular language for writing those instructions and the resulting source code is stored in files called source files.
There’s nothing special about source files, they’re just plain old text files with no extra formatting and in Objective-C they usually have a .m extension to indicate their contents. It is in the formatting information that there is a gotcha.
You really need to be careful with the editor that you use to create your source code and you really really want to avoid word processors (note the different in name) such as Microsoft Word or Pages. Both of those tools (and many other word processors for that matter), add extra formatting information when they create a file and it is that formatting information that doesn’t mix well with source code. To avoid these problems, my recommendation is therefore to use Xcode as your editor.
Xcode is a tool provided by Apple and is what we call an integrated development environment (IDE). This means that not only does it allow you to edit your source code (without adding any of that nasty formatting information) it also supports you through the subsequent phases of this process by allowing you to compile, link and execute your source code as well. I’ll mention this again later.
The process of converting your source code into a language that can be understood by your computer is called compilation (the act of which is called compiling) and is performed by a tool called a compiler.
First the compiler takes the output of your editing activities, source code in one or more source files, and performs a series of checks to make sure it all makes sense and doesn’t contain any mistakes.
As you might expect these checks are extensive. They can be anywhere from checking that you’ve used valid Objective-C statements (the instructions we talked about in the editing phase) right through to identifying whether you have structural problems with your source code. Think of it as proof reading for your source code. If there are mistakes, you’ll need to go back and edit your code and fix them before you can move on. If there aren’t, and the compiler is happy, it will convert your source code into something that your computer can understand. The result of this conversion is something called object-code and the compiler stores this object-code in one or more object files.
For each source file you supply, the compiler will generate a corresponding object file with the same file name as the source file it was created from but instead of the .m extension as we saw with source files it will give the file a .o or a .obj extension to indicate it contains object code.
Once your program grows to any significant size, it is likely that it will consist of more than one source file. Collectively the source files that make up your application are grouped together in something called a project where the project name and your program name are usually synonymous.
Splitting your source code across multiple files does introduce some overhead (in that you need to manage all the files that make up your project) but Xcode helps you with this and there are a number of benefits in doing so:
- Having multiple source files allows you to focus and work on individual sections of your application one part at a time. This can be extremely beneficial, especially if you have thousands of lines of code and can save on some serious scrolling action.
- Each individual source file can be incrementally developed to add features and functionality.
- As we saw in the previous phase, by storing your source code in individual files you can also compile each of them separately allowing you to individually eliminate typographic errors at an early stage.
Now, by splitting your program into multiple source files, you also gain the benefits of something else, something that probably out-weighs all of the points above. You gain the benefits of using source code libraries.
Source Code Libraries, or libraries for short, are sets of source code, just like the source code that you write, that are provided along with the Objective-C programming language. They are not part of the language itself but instead extend it to provide additional features and functionality that are not built into the language itself.
When you are editing your source code you can make use these libraries, re-using the functionality within them within your own programs and eliminating the need for you to write that functionality yourself. You wouldn’t believe how powerful this is. It can save hours, days or even months of editing time and really allows you to focus on the specifics of what makes your program unique.
The question is though, how do you combine your source code files and the libraries that you have made use of, and combine them into a program? This is where another process and another tool comes in; say hello to linking and the linker.
Linking is the process of taking all the object files that the compiler generated in the previous phase along with the libraries that were referenced within your source code and combining them all into a single executable program. This process is performed by a tool called a linker and the first thing it does is to check that it can find all the bits that make up your program. This means making sure that all the object files are available, and that it can find all the libraries that you want to make use of. As with compilation, any errors at this stage mean back to the editing phase to fix them, but if all the necessary parts of your application are present and correct, the linker will take them all and combine them all into a single executable program.
Now there is one thing to note. As I mentioned earlier, Xcode is an IDE and allows you to both build and link your application from within its interface but you won’t see specific menu items or buttons relating to these individual activities. Instead, Xcode simplifies things by combining the compiling and linking phases we’ve just talked about into a single super-phase which it calls building. It’s really just there for simplicity. There aren’t really that many times when you want to just compile or just link so it’s simplified things by providing you with a way of doing both in one easy step. So don’t get confused. If you see Build in the Xcode interface, it is really compiling and linking under the hood.
The final stage in our implementation sequence is executing. This is the stage where you actually run your program (the output of the linking phase) and can only be done if you have successfully completed the previous three phases in the implementation process.
As with the other phases though, the execution phase can also result in errors. Whether it be your users using your application in an unexpected fashion or even entering incorrect data, sometimes you will see your application unexpectedly quit or simply not respond. These are what we call runtime errors in that they occurred at the point you were running your application and as with all of the other implementation phases, errors at this point mean going all the way back to the editing phase to fix them.
So in a nutshell that’s it. Four phases. From your fingers typing it in on the keyboard to a running application these phases are common for each and every application your going to write in Objective-C and iOS. In this post I hope I’ve given you a basic understanding of these phases. I hope I’ve established some terminology. The basics of a vocabulary that will build as our journey moves forward. If I haven’t, or you need more help, please feel free reach out. I’m here to help.
Image source: https://commons.wikimedia.org/wiki/File:Compiling.jpg