Week 14

Let’s start by creating a command line application where we can write and test some code. Launch Xcode, select Create a new Xcode project, choose OS X and Application on the left, and then select Command Line Tool. You can give your project any name, but here, we’ll call it CaesarTests. Be sure to select Objective-C as the language.

Notice how Xcode has automatically create a file called main.m for you. .m is the extension in Objective-C that’s equivalent to .cpp in C++ and m comes from implementation. If you compile and run the project, you’ll see a message that includes Hello, World! in the console on the bottom of Xcode’s widow:

Let’s look at the code that Xcode has given us, top to bottom.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
//
//  main.m
//  CaesarTests
//
//  Created by Maxim Aleksa on 12/20/14.
//  Copyright (c) 2014 Maxim Aleksa. All rights reserved.
//

#import <Foundation/Foundation.h>

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        NSLog(@"Hello, World!");
    }
    return 0;
}

Notice how on lines 1 through 7 comments are started with two forward slashes (//). And just like in C++, one can have multi-line comments between /* and */.

Like 9 has a #import statement. It’s similar to a #include, but smarter. It will only import a file once when the program compiles, even if multiple files reference it.

Line 11 begins the main function, which is the entry point of the program. Notice that it takes to arguments: an integer and an array of char *s (more on this later). This is a way to pass command line arguments to a program, so that it can receive input even before it enters main. You can do the same in C++, and Xcode has been giving you a main with argc and argv every time you create a new C++ project.

Line 12 reads as follows: @autoreleasepool {. Any program statements between the @autoreleasepool { and the matching closing } are executed within a context known an autorelease pool. The autorelease pool is a mechanism that allows the system to efficiently manage the memory your application uses as it creates new objects (again, more on this later). This is a fairly recent addition to the language and you might think that it’s tedius to do these few extra steps in the beginning and at the end of main, but it fact it takes care of many headaches of dynamic memory that you’d have to deal with in C++ (more on these ones in EECS 280!).

Line 14 calls NSLog(). Like cout, you can use it to print messages to the console, though its usage is more similar to C’s printf(), if familiar. It takes a string object (which begins with @" and ends in " in Objective-C) and prints (logs) it along with some other information, such as the current time.

Finally, main returns 0 on line 16, which means all went well.

Hopefully, Objective-C is making sense to you thus far. If not, step back and try to understand this small program.

To write Objective-C code you need to understand what pointers are and how they relate to computer’s memory. Let’s try to explain them in the context of C++. First, remember that code and data for your program are stored in random-access memory (RAM).

So far when you have been declaring variables (either of privitive types, e.g. ints, or objects, e.g. strings), you’ve been doing it like this:

int courseNumber = 203;
string courseTitle = "Discrete Mathematics";

And if you declared them inside of a function, they disappeared, unless you returned their copies. These variables live in the part of computer’s memory known as the stack. You can think of the memory devided in two main parts: the stack, where the local variables in functions are stored and deleted as the functions return, and the heap, where memory can be dynamically allocated to store values. The stack and the heap grow toward each other as more memory is allocated to hold variables, as illustrated by this diagram from Cornell:

You can also think of computer’s memory as a huge array of 1 byte (8 bits) blocks. Each block is associated with a hexadecimal number that represents its memory address.

Just as ints are variables that store integers and doubles are variables that store numbers with a decimal point, a pointer is a variable that stores memory addresses. On modern Macs (a 64-bit computers), a memory address is 8 bytes, so it makes sense that a pointer is also 8 bytes. Pointers thus allow you to keep references to other variables.

Let’s look at how to declare a pointer in C++:

<type> *<variable name>;

Let’s look at a few examples:

int *p0;
double *p1;
char *p2;
string *p3;

Remember that a pointer’s value is a memory address. Its type then describes the data located at that address. So in the first example, int *p0 declares a pointer to 4 bytes of memory that will contain an integer. Similarly, p1 is a pointer to (can hold the memory address of) a double, p2 is a pointer to a char and p3 is a pointer to a string.

Remember char * from earlier? It turns out that it was simply a pointer to a character. So argv (short for argument vector), the second argument of main, was simply an array of pointers to characters. An array can also be though of as a pointer, since both the variable that represents an array and a pointer refer to a memory address. So argv is just a two dimensional array of chars, or simply an array of C-style strings!

Anyway, by default, pointers will have invalid memory addresses, so we should only use them after we make them pointer to either an existing variable or to a dynamically-allocated chunk of memory on the heap. Here is how to allocate memory on the heap in C++ and make a pointer point to that memory:

int *myDynamicNumber = new int

*myDynamicNumber = 5;

int x = *myDynamicNumber;

Whenever we finish using that chunck of memory, we have to deallocate it, so that the operating system can give it to other programs and processes that might need it.

delete myDynamicNumber;

Finally, curl up with Binky for some pointer fun: http://www.cs.stanford.edu/cslibrary/PointerFunCppBig.avi. (Yes, that’s computer science at Stanford.)

Remember that since large objects can take a really long time to copy if we pass or return them by value, and since we want to be able to create objects inside of functions, Objective-C uses exclusively pointers to objects, and this is why knowing pointers is important. But don’t be discouraged if pointers don’t quite make sense to you. Just know that whenever you deal with objects in Objective-C, you’ll be dealing with pointers, so their type will be <ClassName> *.

Similarly, don’t be worried about having to deallocate memory. You might have had to a few years ago, but no more! Objective-C has introduced automatic reference counting (ARC), which keeps track of all the strong pointers and deallocates memory whenever an object on the heap loses all strong pointers to it. This is what @autoreleasepool is for.

Classes and objects are a very important part of Objective-C. They are use for mostly everything and it’s vital that you understand the principles of object-oriented programming before you begin building applications in Objective-C.

So let’s create a class to represent a message that can be encrypted or decrypted using a Caesar cipher. We’ll put it in two separate files, Message.h and Message.m. Message.h will be the header file and will hold the public interface of the class. This is the only file that the user’s of the class should know about. Message.m will hold the implementation of the class, as well as the private interface.

Once you create this class, you’ll see both Message.h and Message.m in the Navigator area on the left side of Xcode. Click on Message.h and you’ll see that Xcode has given you some code to start with.

It’s much easier to work with class files when you have the header file on the left side of the window and the implementation file on the right side of the window. Simply click on in the top-right corner to enable assistant editor and you shoud get a window that looks like this, with Message.h on the left and Message.m on the right:

In order to develop iOS applications, you need a Mac and Xcode. These notes cover iOS 8 SDK, for which you’ll need Xcode 6 and OS X 10.9.4 or later.

We’ll introduce a new concept, MVC (Model-View-Controller). MVC is a design paradigm used not only for iOS development, but also for creating many websites[1] and other software applications. More simply, it’s a way of organizing and thinking about code. Take a look at it’s representation in the diagram below:

Within the MVC design paradigm, we can divide an application into three major components: the model, the view and the controller.

From the above diagram, notice that the controller is “in charge” of the application. Only the controller is allowed to directly communicate with the model and with the view. The controller will usually get the data from the model and then display it on the view. The view can also communicate with the view (e.g. when the user taps on a button or scrolls through the list), as can the model (e.g. the database updates), but these communication are not as direct. Usually the controller decides to “listen” to the updates from the view and the model. But the view and the model are not allowed to talk to each other.

The good news is that we’ve already written our model. Message class is the brains of our application that will take care of encrypting and decrypting text. So now we need to build the view (i.e. user interface) and the controller, that will connect the view to the model.

Let’s start creating our iPhone application by creating a new Xcode Project, this time, select iOS and Application on the left and then choose Single View Application. A single-view application is one with just one screen. This is all we need for our app.

Next, name the project Caesar, since our app will ultimately encrypt and decrypt messages using a Caesar cipher, choose Objective-C as the language, select iPhone from the list of devices (so as to keep our app simple) and make sure that Core Data is not checked.

Once you create the project, you’ll see a window with lots of settings, but leave them as they are for now. Instead, turn your attention to the Project navigator on the left side.

Among the files are two that correspond to the AppDelegate class. An application delegate subclass is created for every new iOS application you create. In general, in this class are methods that control the application’s execution. This includes such things as what to do when the application starts, when it enters and leaves the background, when the system tells it it’s using too much memory, and when it terminates. We won’t make any changes to this class, so feel free to drag AppDelegate.h and AppDelegate.m into Supporting Files group. If you do take a look at Supporting Files group itself, you’ll find main.m, which contains the main function for our app. But we won’t touch it either.

Next, turn your attention to the ViewController class. This is our application’s controller. In general, apps have many models, views and controllers, but ours will be very simple, with just one model, one view and one controller.

Speaking of the model, let’s bring our Message class from the CeasarTest project we worked on earlier.

You can actually compile run the project right now by pressing the Run button. Xcode with open the iOS Simulator, but all you’ll see is a blank screen:

Now let’s work on the view. Select Main.storyboard from the Project navigator and you should see a window that looks something like this:

Building the user interface of our application will be much easier than writing the model. It mostly consists of dragging and dropping UI elements on the canvas. Literally.

This view is the representation of the device’s screen when the application runs. In the past, this would actually be a rectangle of the same dimensions as an iPhone’s screen. But know an iPhone can have four different screen sizes, so Apple has introduced Auto Layout mechanism, whereby we can add constraints to objects, so that our app looks right on any device.

Let’s begin by changing the background of our view to light gray. Click in the middle of the white square to select the view. Then click on the dropdown menue next to Background in the Attributes inspector of the Utilities area on the right side.

Our application will have these UI elements:

Let’s start with the slider. Click on in the lower part of the Utilities area to switch to the Object library. You’ll see a selection of many different UI elements. To quickly find the slider, type slider in the text field on the bottom of the Utilities area. Drag it and drop it somewhere in the middle of the view, then stretch it horizontally to match the below screenshot. Then click on the slider and set its maximum value to 26 in the Attributes inspector of the Utilities area on the right side.

Now let’s get two text views. Go back to the Object library in the lower part of the Utilities area and search for a text view. Place two text views in the view: one above the slider (for the original message) and one below the slider (for the encrypted/decrypted message). Then strech them, leaving some space between the upper text view and the slider for a segmented control and a label.

We also need a segmented control that will allow the user to switch between encryption and decryption. Search for the segmeted control in the Object library and place it above the slider toward the left. Stretch it to make it take the left half of the remaining space. Then double-click on First and type Encrypt and double-click on Second and type Decrypt.

Finally, search for a label in the Object library and place it to the right of the segmented control. Also stretch it to take the remaining space. Double-click on it and type Key: 0 to set its default value.

If we now try to run the app in the simulator, we’ll see the UI elements we’ve added, but they will most likely not be properly layed out:

So let’s add some constraints:

Notice that the constraints are now highlighted in orange, but the UI elements are still positioned the same way. Generally you want to see user interface elements where they’ll be at runtime, so you should update the canvas to reflect that.

Click on the Resolve Autolayout Issues icon on the bottom of the Xcode window that looks like and select All Views in View Controller > Update Frames.

The objects should reposition themselves and the view should look like this:

If you run the app now, it should look correct, but nothings will happen if you slide the slider or change the text in the upper text view. This is where the controller comes in.

Our application will have only one controller and it will be represented by the ViewController class. We won’t have to modify it’s public interface for now and most of the remaining code will go in ViewController.m

Will again be working with Assistant Editor, but this time we’ll have the Main.storyboard on the left and ViewController.m on the right.

Xcode has automatically given us two methods, viewDidLoad and didReceiveMemoryWarning. From their name, you can guess when they will be called, but our applications is simple enough, so we don’t need them. You can just delete their implementations from ViewController.m.

Before connecting the view, let’s connect the model. First we need to

#import "Message.h"

Then we need to add a property for the message (still remember what a property is?). Add

@property (strong, nonatomic) Message *originalMessage;

Now, remember that originalMessage is a pointer to a Message object (still remember what a pointer is?). This means that it points to some memory address on the heap. In order for originalMessage to be valid, we need to allocate memory for a Message object, initialize that object and set originalMessage to point to that object before we ever use originalMessage. But when should this be done? A very good time is when we first try to access originalMessage. Remember that when we acces properties in Objective-C, the getter method is called. Objective-C automatically generates setters and getters for us when we create properties, and the default getter just returns the instance variable. What we want the getter to do instead is allocate and initialize a Message object the first time we access it, and then always return the instance variable. By default, all pointers are set to nil in Objective-C, which just means that they do not point to anything. So let’s write our own getter for originalMessage where we do a simple check to see if originalMessage has been set. Let’s add this to the implementation of ViewController:

- (Message *)originalMessage {
    if (!_originalMessage) {
        _originalMessage = [[Message alloc] init];
    }

    return _originalMessage;
}

So this takes care of connecting the controller to the model. The controller now has originalMessage, a Message object that will store a string and will be able to encrypt and decrypt it with a key.

Now let’s connect the view to the controller. We need to add a property for each of the UI elements we’ve added (so we’ll need five more properties). These properties are known as outlets. Let’s first add an outlet for the text view that will have the original message. Connecting outlets is extremely easy (and fun!) in Xcode. Just hold the Control key and drag the text view between @interface ViewController () and @end.

@property (weak, nonatomic) IBOutlet UITextView *originalMessageView;

We now need to do the same for the rest of the UI elements that we’ve added. Connect the other text view and name the outlet resultingMessageView. Then connect the segmented control and name its outlet encryptionModeControl, then connect the slider, naming it keySlider and the label, naming it keyLabel.

Notice the circles to the right of @property for the outlets. If you hover over them with your mouse, Xcode will highlight the view to which that outlet is connected.

As a reminder, we’ve added these outlets so that our controller can talk to our view.

Let’s add a method called updateUI that we’ll call whenever we need to update the view (this can happen when the user updates the original message, changes encryption mode or slides the slider). We’ll put the implementation between @implementation ViewController and @end.

- (void)updateUI {

}

self.keyLabel.text

self.keyLabel.text = [NSString stringWithFormat:@"Key: %d",
                                                (int)self.keySlider.value];

self.originalMessage.message = self.originalMessageView.text;

Finally, we have to update the text in the resultingMessageView. We first have to check the value of the segmented control (encryptionModeControl). Segmeted control has a property called selectedSegmentIndex, whose value is the index of the selected segment. So it will be 0 if the user has selected Encrypt and 1 if the user has selected Decrypt. We then set the text of the resultingMessageView according to the sected mode. (Rember that we encypt and decrypt by calling methods on our model and that the key is the value of the slider).

if (self.encryptionModeControl.selectedSegmentIndex == 0) {
    self.resultingMessageView.text = [self.originalMessage
                                      encryptWithKey:self.keySlider.value];
} else if (self.encryptionModeControl.selectedSegmentIndex == 1) {
    self.resultingMessageView.text = [self.originalMessage
                                      decryptWithKey:self.keySlider.value];
}

The control will need to call updateUI when something changes with the view (when the user updates the original message, changes encryption mode or slides the slider). But since the view can’t talk directly to the controller, the controller has to “listen” to those changes. This is known as an action.

You can add an action just like you add an outlet, by dragging and dropping a UI element from the view to the controller, but this time it has to go between @implementation ViewController and @end.

First, let’s add an action for when the user slides the slider. Hold the Control key and drag the line between @implementation ViewController and @end.

Name the method changeKey and change type to UISlider. Notice that the event is Value Changed, which means that this method will be called when the value of the slider changes. Also note that the argument is Sender, which means that a pointer to UISlider will be passed in.

- (IBAction)changeKey:(UISlider *)sender {
}

int key = (int)sender.value;
sender.value = key;
[self updateUI];

Now we need to add action for when the user switches between encryption and decryption. Hold the Control key and drag the slider in an empty space betwen @implementation ViewController and @end. Name the method changeEncryptionMode and change type to UISegnementedControl. You’ll these lines of code added to the implementation:

- (IBAction)changeEncryptionMode:(UISegmentedControl *)sender {
}

[self updateUI];

Finally, the controller has to know when the user finishes editing text in originalMessageView so that it can update the text in resultingMesageView right away. Unfortunately, UITextView does not support the actions mechanism to communicate with the controller. Another mechanism that allows the view to talk to the controller is delegates. We can make ViewController to be the delegate of the text view that contains the original message. This means that ViewController will conform to UITextViewDelegate protocol, i.e. it will implement all of the required methods declared in that protocol and some of the optional ones. It turns out that the UITextViewDelegate protocol does not have any required methods, but an optional one includes textViewDidEndEditing:, which is called when the user finishes editing a text view. This sounds like a solution to our problem. First, switch to ViewController.h by clicking

@interface ViewController : UIViewController

@interface ViewController : UIViewController <UITextViewDelegate>

- (void)textViewDidEndEditing:(UITextView *)textView {
    [self updateUI];
}

One last touch. In order for the user to actually end editing a text view, he or she must dismiss the keyboard. Let’s add some code that dismisses it when the user taps on an area outside of the keyboard. We’ll skip the explanation of this code and assume thtat it works.

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    // dismiss keyboard on touch
    [self.view endEditing:YES];
    [super touchesBegan:touches withEvent:event];
}

As a summary, this is what your ViewController.h should look like:

1
2
3
4
5
6
#import <UIKit/UIKit.h>

@interface ViewController : UIViewController <UITextViewDelegate>


@end

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
#import "ViewController.h"
#import "Message.h"

@interface ViewController ()

@property (strong, nonatomic) Message *originalMessage;
@property (weak, nonatomic) IBOutlet UITextView *originalMessageView;
@property (weak, nonatomic) IBOutlet UITextView *resultingMessageView;
@property (weak, nonatomic) IBOutlet UISegmentedControl *encryptionModeControl;
@property (weak, nonatomic) IBOutlet UISlider *keySlider;
@property (weak, nonatomic) IBOutlet UILabel *keyLabel;

@end

@implementation ViewController

// lazy instantiation
- (Message *)originalMessage {
    if (!_originalMessage) {
        _originalMessage = [[Message alloc] init];
    }

    return _originalMessage;
}

- (void)updateUI {
    // update key label
    self.keyLabel.text = [NSString stringWithFormat:@"Key: %d",
                                                    (int)self.keySlider.value];

    // update model
    self.originalMessage.message = self.originalMessageView.text;

    // encrypt or decrypt
    if (self.encryptionModeControl.selectedSegmentIndex == 0) {
        self.resultingMessageView.text = [self.originalMessage
                                          encryptWithKey:self.keySlider.value];
    } else if (self.encryptionModeControl.selectedSegmentIndex == 1) {
        self.resultingMessageView.text = [self.originalMessage
        decryptWithKey:self.keySlider.value];
    }
}

- (IBAction)changeKey:(UISlider *)sender {
    int key = (int)sender.value;
    sender.value = key;
    [self updateUI];
}

- (IBAction)changeEncryptionMode:(UISegmentedControl *)sender {
    [self updateUI];
}

- (void)textViewDidEndEditing:(UITextView *)textView {
    [self updateUI];
}

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    // dismiss keyboard on touch
    [self.view endEditing:YES];
    [super touchesBegan:touches withEvent:event];
}

@end

Congratulations, you’ve now finised building your first iPhone application! Run it to make sure once more that it doesn’t have any bugs. Feel free to play with your new app and procrastinate.