This is an old revision of the document!
This is the first section of the iOS crash course. These three lectures will cover the basics of the development process. By the end of the third you should have a solid foundation to begin iOS development yourself. However, this is only a brief primer! In the rest of the iOS lectures we will be diving into more difficult and complex topics in a more comprehensive way. For theses three lectures, the whole picture will not be clear; follow along closely and try to understand each step.
Lecture 1 will cover:
In these three lectures you will be making a sample application called “UWMadInstagram.” This app will use UW Madison's Instagram feed, providing users with an interface to view images and comments. This app will be pretty unimpressive in its functionality, but it will show you how to complete a lot of basic tasks.
Xcode is the IDE used for all iOS development. Although 3rd party IDE's exist, you should learn and appreciate Xcode, its fast, slick, and optimized for iOS. Because Apple has vertical control over their products (i.e. they have control over their products from hardware to operating system to application) Xcode can make a lot of menial tasks very easy and integrates well into the development cycle.
Xcode's main view may seem a little overwhelming right now, but a lot of the options are not needed at this point. The two circles on the image below show everything you need to pay attention to now. On the top left you'll see a play button. This runs your application in the Simulator. Top right contains six buttons. The three on the left represent panes currently open in Xcode. The three buttons on the right allow you to change editor types. Don't worry too much about them now!
InterfaceBuilder (commonly abbreviated as IB) is Xcode's integrated view-building tool. It is a WYSIWYG (what-you-see-is-what-you-get) editor that allows you to drag and drop UIViews onto the screen easily. One of the nicest features of Xcode, InterfaceBuilder allows you to deal with the View creation process without ever having to write a single line of code.
IB can look a little complicated, but there are only a two broad kinds of items that appear on the screen.
You learned that Controllers were objects responsible for managing views and models in the MVC sections, but we didn't discuss what a ViewController really was. In iOS, ViewControllers are objects that are tasked with managing one “scene” in an application (“scene” is in quotes because the deliniation between ViewControllers is not always distinct.) Each ViewController typically gets the whole screen and a task; a SettingsViewController may be responsible for the settings page while a LoginViewController may authenticate the user. ViewControllers do not inherently have any knowledge of the structure of the app– they don't know which ViewControllers came before them or started the application. To make managing many ViewControllers simpler, we use a custom ViewController called a UINavigationController. Navigation Controllers implement a stack for keeping track of ViewControllers. As a developer, you can push and pop Controllers onto the Nav Stack. The first ViewController in the Navigation Controller's stack is reffered to as the root view controller.
Its useful to do a quick Hello, World starter just to get your feet wet. We will code two variations to get an idea how InterfaceBuilder works.
Click on the ViewController.m file on the project navigator. Type the following line before the closing brace in the viewDidLoad method.
Run your program by clicking the play button in the top left corner. Check the console for your message!
Ok, that was pretty basic. NSLog is a library function call that logs the message within the quotes to the console. The @ sign before the quotes means string literal. Don't worry about it now, just understand that whatever is in between the quotes gets pushed to the console.
In this next step, we're going to make a Hello, World button and label on the main interface.
At this point you can run your app again and see the views laid out on the root view. Unfortunately, since the views are not connected to code, they don't do anything terribly interesting.
What does this mean? One of the ways in which iOS is structured is called MVC, which stands for Model, View, Controller. This is just a way of thinking of different objects in code and keeping them separate. Essentially, each type of object's source code never mixes with other types of object's source code. Views don't merge into controllers and vis versa. You have already seen Views (the label and the button) and Controllers (the rectangle in the middle of the screen, and the file you wrote “Hello, World!” in.) Controllers are the masters of the program, so to make Views do anything interesting we have to connect the two. We will discuss MVC in more detail in the next lectures.
We connect Views to Controllers using a simple drag and drop. There are two kinds of connections you can make:
IB stands for InterfaceBuilder. It is an established convention in iOS to prefix your objects with 2 letters that tell the programmer from what library they come from.
When the user presses the button, we want to change the text of the label to “Welcome to UW Madison Instagram!” In order to do this, we need access to the label through an IBOutlet, and we need to know when the button is pressed through an IBAction. In order to make connections, we have to use the Assistant Editor to see the storyboard and the code.
@interface ViewController : UIViewController
Anything inside of the braces is private to our class.
Ok. That was a lot of unexplained steps in quick succession. If this seems painful, don't worry. Its really quite simple, and at this point you've performed all the steps you'll ever need to build almost any iOS interface! If you can't quite understand what just happened, don't worry. You can just repeat the previous steps over and over to build your interfaces, and eventually things will click. We will discuss a little more of the theory of InterfaceBuilder in later classes.
There's one more step left in our greeting. If you click on the ViewController.m file in the project navigator, you'll see a new method was added that matches the name of the action you just created. Every time the button is pressed, this method will get called (and thats why its called a callback.)
When the button is pressed, we want to change the text of the label. The method used to do this is called setText: Don't worry about the syntax right now.
[labelHello setText:@"UW Madison Instagram"];
Run your program and check the button and greeting. If the text is being cut off, your label isn't wide enough.
This app will serve a few, fairly limited functions. Users will be able to connect to UW Madison's Instagram feed over the internet and display all of the images and comments listed there.
In this lecture you will begin creating the interface of the application though InterfaceBuilder. First, each scene of the app will get a ViewController. Then, you will drag Views onto their corresponding ViewControllers.
We won't be coding ViewControllers in this lecture, but you have to know what they are in order to understand the structure of iOS applications. All of the types of views avaliable to you are presented in the Object Library highlighted above
The view objects that you drag onto ViewControllers in InterfaceBuilder make up the “scene” for each view controller. When that ViewController is loaded in your app it loads all of the views you dragged onto it in InterfaceBuilder.
Now we're going to populate the views of the app. The process for dragging and dropping views onto controllers is simple, the only thing that changes is the type of view. After you're finished, do not connect IBActions or IBOutlets.
You should size the views as shown in the picture, and change the names of the two buttons on the first controller and the label (tagged with a 2 in the image) to match. Note: the names under the ViewControllers do not match what yours will look like, and the original view controller does not have the greetings button listed.)
Congratulations, you've just built an interface. There is one small thing missing, the ability to transition between view controllers. The switch between view controllers is called a segue (pronounced seg-way.)
The Images button should connect to the view controller where you put the Table View. The Settings button should connect to the controller that has the Text View and the “Images per Page” label.
Now, if you test the app again, pushing the Images and Settings buttons should switch you to a new view controller. There's no way to get back, unfortunately, which brings us to the most commonly used tool for organizing Controllers, the Navigation Controller.
A UINavigationController is a meta-controller (it controls other controllers) and you will use it all the time to keep your controllers in order. Its function is very simple: it maintains a stack of view controllers, which creates a controller hierarchy. All this means is there are controllers below the active controller, and new controllers can be pushed onto the active controller. When this push happens, a new controller becomes the active controller.
The navigation controller automatically adds a back button after a segue happens to show that there is another controller below the active one. When this back button is pressed, it informs the navigation controller that a pop happens, which removes the active view controller from the screen and exposes the one below it.
There's one small change we still have to make to let the app know that we want the Navigation Controller to be the root view controller. The arrow that doesn't have a left end denotes the root view controller, you need to drag it from the original view controller to the navigation controller.
Test your app. You should be able to move back and forth between the three view controllers (the menu, the table, and the settings.)
If this seemed a little slow, don't worry. The fun is just starting. Covering iOS development is a little weird for most people at first, because they have to deal with a new language, IDE, and set of conventions like MVC. In the next lecture you'll learn the basics of the Objective-C language and start making custom View Controllers to give your app some functionality.
This first set of lectures is introductory. Its meant to get your feet wet and hopefully give you a sense of what the process of creating an app entails. It will not train you to be a successful developer! If you choose to stay with iOS we'll dive into the theory, giving all of the new terms learned here a place in the big picture. Don't worry if it seems like you're following steps here without understanding, doing is one of the best ways of learning!