Design Then Code - Building Ios Apps From Scratch

Transcript

Building iOS Apps From Scratch by Mike Rundle Before taking a crack at any Design Then Code project Code project tutorials you'll need some knowledge of Xcode, Objective‑C, Cocoa and UIKit. My goal is for this guide to help bridge the gap between having no knowledge of iOS development and having enough to start tackling more interesting projects. Tools Apple provides a number of tools to enable developers to build Mac and iOS apps. To download them, head to the Mac App Store and search for "Xcode". This $4.99 download will give you access to Xcode (the IDE that Mac/iPhone developers use), Interface Builder, the Cocoa Frameworks, tools for testing your apps, and a lot more. To register as an official iOS developer and developer and publish apps to the App Store (not to mention testing your apps on a real device!) it costs $99 per year. Here's a quick overview of the tools Apple provides.  Xcode Xcode is an IDE (Integrated Development Environment) used by Mac and iOS developers to build applications. It's not just a code editor: it has a variety of additional goodies baked in like great autocomplete support, static code analysis (it finds bugs in your code before you compile, including memory leaks) and a variety of debugging and performance tools. You could use could  use TextMate TextMate or BBEdit and then use command line tools to do the final compilation, but most developers choose to do it all within Xcode. I use Xcode for all app development. Interface Builder Interface Builder is an application that lets you build your interfaces visually. Built‑in objects like buttons, tab bars, sliders and labels can easily be dragged onto your app's interface and then configured by tweaking the palettes and panels. You can also use Interface Builder to connect targets and actions (what happens when an interface element is acted on by a user, and what object handles the action) as well as manipulate controllers and object bindings. In my particular development workflow, I prefer not to use Interface Builder, mostly because I work on custom interface components and those still take a lot of code to get exactly right. I recommend that new Mac and iPhone developers get acquainted with Interface Builder, but at the same time still learn the UIKit code that it is generating for you. I've seen many developers start using Interface Builder and never leave it, so they never actually learn how to code interfaces from scratch. All Design Then Code tutorials Code tutorials forego Interface Builder and explain how to write all UI code by hand. Frameworks And the most important piece of the puzzle: frameworks. Without frameworks frameworks and APIs developers wouldn't easily be able to create applications that run on Mac OS X or iOS. Apple provides dozens of frameworks that enable developers to do things like create user interfaces, write networking code, encrypt important information, draw graphics to the screen, play audio and video, save data and passwords, take pictures, display webpages and much more. The frameworks that Apple provides let you start off with a rich set of commands and tools upon which to build your applications. Without the various frameworks that Apple provides, every developer would be reinventing the wheel over and over again. There are lots of goodies given to you in the various Cocoa frameworks frameworks so, many times, an incredibly complex thing can be accomplished in only a few lines of code. An example of  this is automatically fetching a file on the Internet by its URL, parsing this file, then stuffing it into a data structure that you can manipulate instantly is just a one‑liner!. one‑liner! . These are just the main tools that Apple provides but there are many, many more to explore and use. Go pick up Xcode from the Mac App Store and start poking around within your new /Developer directory. Introduction To Programming? Are you totally new to computer programming? Have never even written any JavaScript? This tutorial might be tough to swallow. Take a look at the following list of terms and examples: 15; ; Variable — var x = 15 getName(); Function — var name = John.getName(); Loop — for (var x = 0; x < 10 10; ; x  x++) ++) 20) ) Conditional — if (x == 20  array( ("dog" "dog", , "cat" "cat"); ); Array — var things = array If any of these are confusing to you, I'd suggest heading to the JavaScript the JavaScript tutorial at w3schools.com and w3schools.com  and working through the first few sets of chapters to get a quick feel for general computer programming constructs. If you're coming from a language that does not look like C (Lisp, Ruby, etc.) or if you have no C programming knowledge knowledge (what's a header file? what's a struct?), I'd recommend taking a quick read of Scott Stevenson's excellent C language tutorial and tutorial  and then coming back after your brain is thoroughly soaked with knowledge. Now let's talk about Objective‑C. Introduction To Objective-C Objective‑C is the language that most Mac and iOS developers use to write native applications. There are alternative ways to write Mac and iOS apps (pure C or C++, MacRuby, PyObjC, MonoTouch, etc.) but we won't be exploring those avenues here. Apart from these programming languages, it's also possible to build "apps" that aren't natively compiled for the platform but are instead websites made to look like a native app but loaded in a web browser. Those apps can be written using a variety of frameworks but they're primarily built using web technologies including JavaScript, HTML and CSS. If you're looking to build mobile websites or web apps then you don't need to learn Objective‑C or Cocoa and probably don't need to go any farther in this tutorial. If you're looking to learn a new programming language and build native apps for the Mac and iOS, then this is the place for you! Objective‑C is an object‑oriented programming language that is essentially a thin layer on top of C. It adds Smalltalk‑style messaging, runtime reflection, inheritance and many other things to the C programming language. Its syntax is very unique and may be confusing at first to seasoned developers used to languages like Ruby or Java. Because Objective‑C is a superset of C, developers can "drop down into" C at any point in their code if they wish. Many parts of a Mac or iOS application will utilize native C function calls and primitive C data types right next Objective‑C methods and data types. Classes, Objects & Methods In case your object‑oriented programming programming fu is rusty (or totally nonexistent) we should first define what classes, objects and methods are and how they relate to each other in Objective‑C. A class is a blueprint that describes the state and behavior of a particular set of objects. It typically models a concept or a thing from the real world, for example, an Animal. An Animal class would probably define some variables like the number of legs it has, its height and weight, and also behaviors, like running, eating and sleeping. An object of a given class is called an instance of the class. Each new instance you create can have its own values for the data. You could create 100 instances of the Animal class and set each one's variables to something different. Methods are behaviors a class possesses, and in Objective‑C, you can call a method directly on the class itself or on an instance of it. These two types of methods are called class methods and instance methods. When you want to create a new instance of a class, you have to first allocate and initialize a block of memory for it on the heap. The heap is memory set aside for dynamic allocation and in Objective‑C all objects live on the heap. All Obj‑C objects are pointers to this block of memory and an asterisk (*) denotes that a variable is a pointer type. Here's an example of creating an instance of our Animal class.  Animal  myAnimal  myAnimal = [[ Animal alloc] *  alloc] init];  init]; Let's break this down piece by piece. The first thing you'll probably notice are the square brackets. They're everywhere in Objective‑C and they encapsulate method calls. On the left side of  the line we're creating a new Animal* variable named myAnimal, then, on the right side, we're doing 2 different method calls (one nested within the other) and assigning what they return to myAnimal. To understand what's going on we need to look at the method calls from the inside‑out. First, we're  alloc] ] which means we're calling [Animal alloc When working with variables that have an explicit, set size at compile time, they're stored on the stack. The stack stores local information and you can access its data without pointers. Primitive data types (int, char, float, etc.) have a defined, maximum size so they're sto red on the stack. In Obj‑C, objects don't have a maximum size (they can grow as much as you need t hem to) so their memory must be dynamically allocated on the heap and referenced with pointers. A pointer is an address in memory, and to access what's actually stored in that memory position, you dereference  the  the pointer to get at its contents. calling the class method +alloc directly on the Animal class. Class methods are preceded with a plus sign. This method returns a generic object type of id. Then, we call the instance method -init which initializes the memory, allowing us to actually use this new object. Instance methods start with a minus sign. Objects in Objective‑C aren't fully ready to be used unless these two steps are taken. An important concept to understand when working with objects is that if you allocated memory for it, you're also responsible for letting the runtime know when you're done using the object so that its memory can be released. An object can be in use in different parts of an app at once, so Objective‑C uses a reference counting system counting system to keep track of  all this usage. When an object is first created, the number of  references on the object is one one.. When an object is no longer being used, a -release message must Starting in Xcode 4.2, there's a new feature that Cocoa developers can use called Automatic Reference Counting (ARC) Counting (ARC) which takes all the be sent to it, and this decreases the number of  effort out of manual memory management. It's references on the object by one one.. When the overall a compiler feature which will automatically  add  add in calls to -release for you so you don't ever number of references on an object drops to zero zero,, the object's memory is freed. If objects that are no have to manually release or autorelease any longer being used stay around and occupy objects. It's still important t o understand what's happening to your memory behind the scenes, memory some bad things could happen, one of  which is your iOS app is forced to quit because it's using too many resources. For Mac apps, if an app takes up more and more memory, it could make but now ARC can make your development times faster. Read an overview of ARC at Apple's website or a full explanation at the Clang website or LLVM site. the whole system sluggish. Have you ever left Photoshop or Safari open for a few days and everything gets bogged down? It's because the apps are continually using more memory — potentially due to a memory leak — and there are fewer resources for other running apps. Memory is a precious resource when developing software so it's important to use it  judiciously. For an in‑depth in‑depth look at Cocoa memory memory management rules, rules, read Apple's Memory Management Programming Guide. Guide . Now that we know how to create a fully‑formed, fully‑functional fully‑functional instance of a class, let's create a new Airplane object and call some methods on it.  Airplane *  myAirplane  myAirplane = [[ Airplane alloc]  alloc] init];  init]; [  myAirplane  myAirplane fly]; fly]; [  myAirplane flyTo:@  myAirplane flyTo:@"Austin, "Austin, TX"]; TX"]; [  myAirplane flyTo:@  myAirplane flyTo:@"Dulles "Dulles Airport" landAtTerminal Airport" landAtTerminal: :3]; Calling methods on objects in Objective‑C has a fairly unique syntax compared to other languages you may be familiar with, so let's recreate the same calls in Java.  Airplane myAirplane = new   Airplan  Airplane e();  myAirplane.  myAirplane.fly(); fly();  myAirplane.  myAirplane.flyTo( flyTo("Austin, TX"); TX");  myAirplane.  myAirplane.flyToAndLandAtTerminal flyToAndLandAtTerminal( ("Dulles Airport", Airport", 3); Here we're initializing a new Airplane object and then calling 3 different methods on it. flyTo: : takes in one argument. The The first, -fly takes in no arguments. The second, -flyTo flyTo: :landAtTerminal: landAtTerminal: takes in two arguments. The full names of Objective‑C third, -flyTo methods include the names of the arguments. Colons in a method name indicate that it takes an argument, one colon for each argument that it takes. These are instance methods so a minus sign is included at the beginning of the method name. Objects don't just have behaviors, they can store data as well. Let's imagine a Car object and the types of data attributes it could possess: Model year Name of manufacturer Color Will it turn on? Let's look at these attributes. First, we have model year. This could be represented by a numerical year, like 2008. What kind of data is 2008? It's a number, and in Objective‑C that number could be represented in a few different ways: As a primitive int As a Foundation framework data type NSInteger As an instance of the NSNumber class Choices, choices! Let's talk about what each of these mean. The variable type int comes from C and is a primitive data type that holds a number with a certain maximum value. An NSInteger is a special primitive data type from Apple's Foundation framework that is automatically sized correctly for the current architecture. The third way is an instance of  the NSNumber class that is also defined in Foundation Foundation framework.  framework. We'll learn more about Foundation and other Apple frameworks in a bit. Neither an int nor an NSInteger are objects which means you don't have to worry about dynamically allocating memory for them since they have a pre‑defined size. They get created on the stack, not the heap, so no pointer is needed to access their contents. Things like an int, NSInteger, CGFloat, CGPoint, CGRect (and a whole slew of other things defined in the Foundation Data Types Reference) Reference) aren't objects, so no pointer (asterisk) is needed. Now let's look at the third example of how we could store the number 2008: as an NSNumber object. We can initialize a new NSNumber object like this: NSNumber *year = [NSNumber  numberWithInt:  numberWithInt:2008 2008]; ]; If this is an instance of the NSNumber class, where's +alloc? Where's -init? Well, it turns out, some objects have convenient class methods that return an object with memory that you don't have to manage yourself. Since you didn't manually create the memory using +alloc and -init, you don't have to worry about sending it a -release message when you're done. Many frequently‑used objects defined in Apple's Foundation framework have these nice constructors. Of course if you want (or need) to manually manage their memory, we could have also done this: NSNumber *year = [[NSNumber  alloc]  alloc] initWithInt:  initWithInt:2008 2008]; ]; So now we have an instance of the NSNumber class that is wrapped around a regular int of  2008. Why go through the trouble of using an NSNumber object when we could have more easily used an int or NSInteger? Because some Cocoa classes only make use of other objects, they simply don't work with primitive types, for example, NSArray. An NSArray is an object that manages the ordered collection of other objects. If we wanted to use an NSArray to hold a series of numbers, we'd have to use NSNumber objects because it doesn't work with primitive data types like int or NSInteger. We could use ints and NSIntegers in a regular C array, but then we wouldn't get all the great, built‑in behaviors that are defined in the NSArray class. To initialize our Car object and access its instance variables, we do this: Car  myCar  myCar = [[Car alloc] *  alloc] init];  init];  myCar.  myCar.  modelYear  modelYear = [NSNumber  numberWithInt:  numberWithInt:2008 2008]; ]; In this example, modelYear is a @property of the Car class which enables us to use the dot syntax to access it. We'll get into the specifics of properties and instance variables a bit later. Now that we know how to initialize new objects, call methods, and access its instance variables, let's dive into defining new classes. Defining An Objective-C Class To define a new class in Objective‑C you must define two things: the class's interface and its implementation. A class interface tells the compiler about the class's instance variables and methods so it know what to expect. Like a preview of upcoming attractions. A class implementation is the actual code and functionality for each method. By convention, a class interface goes into a .h file and the implementation is in a .m file. For a Car class, the two files would be Car.h and Car.m. Here's our Car interface file: @interface Car : NSObject {  modelYear;  modelYear; NSNumber *  manufacturerName;  manufacturerName; NSString * UIColor *color; color; BOOL willTurnOn;  willTurnOn; } @property (nonatomic, nonatomic, retain)  retain) NSNumber  modelYear;  modelYear; * @property (nonatomic, nonatomic, copy)  copy) NSString *  manufacturerName;  manufacturerName; @property (nonatomic, nonatomic, retain)  retain) UIColor *color; color; @property (nonatomic, nonatomic, assign)  assign) BOOL willTurnOn;  willTurnOn; - (void)drive; drive; - (void)turnRadioToStation turnRadioToStation:( :(NSString *) *)station station; ; - (void)setRadioVolume:( setRadioVolume:(NSNumber *) *)volume volume; ; - (BOOL)hasNavigation; hasNavigation; @end Let's go over the Car class interface line by line. @interface Car : NSObject At the top of our interface file we declare Car to be a subclass of NSObject which is the root class for class for most of the Cocoa classes you'll encounter. I like to think about subclassing as creating a more specialized version of an object. A generic class in Cocoa should be an NSObject subclass. If you're making a specialized version of a button you might make a UIButton subclass. Specialized version of a text label? It'd be a UILabel subclass. What if  we wanted to make a specialized version of a Car, say, a convertible? Well, we'd probably declare a Convertible class which would be a subclass of our Car class, which, as I just explained, is itself an NSObject subclass. A subclass gives you the functionality of its parent class and all the other parent classes up the chain. A Ferrari object is a also a Convertible object which is also a Car object. If you declare all Car objects as having GPS then the Ferrari will as well. Right? Sure, but when you create a subclass in Objective‑C you can c an choose to add or re‑implement functionality of the parent classes as you see fit. For example, all UIButtons look a certain way, but if you want to make a totally custom button for your iOS app, you can subclass UIButton and draw the button's graphics yourself. Your custom code will override the default behavior in the parent UIButton class. Next up, the class's instance variables. @interface Car : NSObject {  modelYear;  modelYear; NSNumber *  manufacturerName;  manufacturerName; NSString * color; UIColor *color;  willTurnOn; BOOL willTurnOn; } Inside the curly braces, right after the class declaration, you'll find the object's instance variables. Instance variables are attributes for a specific instance of an object. If you create 3 different Car objects they would each have their own values for these instance variables. Not all cars have the same color, and not all instances of our Car class will have the same color instance variable value. Instance variables are declared with the variable type and the variable's name. Three of these instance variables are objects (see the asterisks?) and the fourth is a primitive boolean type that can only be either YES or NO. After the instance variables you'll find a series of @property declarations. @property (nonatomic, nonatomic, retain)  retain) NSNumber  modelYear;  modelYear; * @property (nonatomic, nonatomic, copy)  copy) NSString *  manufacturerName;  manufacturerName; @property (nonatomic, nonatomic, retain)  retain) UIColor *color; color; @property (nonatomic, nonatomic, assign)  assign) BOOL willTurnOn;  willTurnOn; Properties are Properties  are an Objective‑C 2.0 feature that allow you quicker, more effortless access to your instance variables. What these actually do is Another great thing about properties is that if  you want to keep things really simple, you don't configure the getter and setter methods to methods  to have to declare them as instance variables at all, you can let the runtime environment access and update these instance variables. For automatically create  the  the instance variables as each instance variable you want to access and car. .color, update using dot syntax (car car. car .willTurnOn, etc.), you have to declare it as a @property as well. Before Obj‑C properties came along, you'd have to write two methods for each instance variable to "get" and "set" its value, but they're needed. So with that in mind, you could skip all instance variable declarations in the Car class and have the first l ine be simply @interface Car : NSObject and skip ahead to your @property declarations. This really saves a lot of time, and lets you not repeat yourself in the code. now you can use properties to configure them automatically, allowing us to use the nifty dot syntax described previously. There are various ways to configure @properties and rather than go into depth here, you'll find Apple has a guide just guide just for them. them. And finally you'll see the method signatures for the behaviors implemented in the .m file. - (void)drive; drive; - (void)turnRadioToStation turnRadioToStation:( :(NSString *) *)station station; ; - (void)setRadioVolume:( setRadioVolume:(NSNumber *) *)volume volume; ; - (BOOL)hasNavigation; hasNavigation; These method declarations describe the type of data returned by a method, the method name and its arguments. These are all instance methods because of the ‑ preceding each one. These must match their corresponding implementation (the code that actually runs when the method is called) in the .m file exactly. Now for the implementation of our Car class which will exist in a file called Car.m. @implementation Car @synthesize modelYear @synthesize  modelYear, , manufacturerName  manufacturerName, , color,  color, willTurnOn;  willTurnOn; - (void)drive { // Code to make the car drive would go here! } - (void)turnRadioToStation turnRadioToStation:( :(NSString *) *)station station { // Turn on the radio adjust the station! } - (void)setRadioVolume:( setRadioVolume:(NSNumber *) *)volume volume { // This one goes to 11! } - (BOOL)hasNavigation { // Does this car have it? } @end Again, let's go over each line. @implementation Car At the top is a compiler directive of @implementation which signifies the start of our implementation file for this class. @synthesize modelYear @synthesize  modelYear, , manufacturerName  manufacturerName, , color,  color, willTurnOn;  willTurnOn; Next is the @synthesize statement which is the counterpart to @property in the class interface. In our interface we declared our object's properties, and now, in the implementation file, we use @synthesize to automatically generate the getters and setters based on our declared configurations for them. Don't forget to have both @property and @synthesize declarations for each property you want to use. - (void)drive { // Code to make the car drive would go here! } - (void)turnRadioToStation turnRadioToStation:( :(NSString *) *)station station { // Turn on the radio adjust the station! } - (void)setRadioVolume:( setRadioVolume:(NSNumber *) *)volume volume { // This one goes to 11! } - (BOOL)hasNavigation { // Does this car have it? } After we've synthesized our properties, we will write the code for each of the methods declared in the interface. The method signature is the same as in the interface file, but the functionality for each method follows directly after within a pair of curly braces. And that's it! Our Car class is now fully defined. Let's initialize a new Car object and work with it a bit.  myCar = [[Car alloc] *  alloc] init];  init]; Car  myCar // Set some of its properties  myCar.  myCar.color = [UIColor  redColor];  redColor];  myCar.  myCar.  modelYear  modelYear = [NSNumber  numberWithInt:  numberWithInt:1995 1995]; ]; // Call some of its methods [  myCar turnRadioToStation:@  myCar turnRadioToStation:@"Hot "Hot 97"]; 97"]; [  myCar  myCar drive]; drive]; // Tell the Objective-C runtime that we're done with this Car object [  myCar  myCar release]; release]; After creating a fresh instance of a Car object we can start using it. First, we can set some of its properties like its color or modelYear. The dot notation "object.property" works because we declared certain instance variables to be able to be retrieved or set in this manner. It doesn't happen automatically, but if you use @property and @synthesize then you're golden. It may seem pretty simple, but Objective‑C is doing some legwork in the background to make sure that memory is allocated and deallocated properly when you directly access an object's properties. turnRadioToStation: : and We can also call a Car object's instance methods like -turnRadioToStation drive. Notice in the first method call, we're passing in a string as an argument since that is expected from the method definition. The second method, -drive, takes in no arguments. When we're done using our instance of a Car class, we send it a -release message to decrease If you're developing in Xcode 4.2 or later and have Automatic Reference Counting turned Counting turned its reference count by one. As the only place using on, you would skip the -release message as this object, the reference count would drop to it's not needed. zero and zero  and its memory would be automatically deallocated. To be more specific, the runtime automatically calls the -dealloc method on our Car object. Typically we would implement -dealloc in this class and do some cleanup/maintenance work before the memory is deallocated and the object vanishes. This is just scratching the surface of Objective‑C, but it's enough to propel you in the right direction if you want to start understanding and building Mac and iOS apps. Now onto the interesting stuff. Introduction To Cocoa (and Cocoa Touch) The phrases "Objective‑C development" and "Cocoa development" are thrown around interchangeably, and usually if you say either one, people know that you're talking about building Mac and iOS apps. Cocoa is a set of frameworks that Apple built for developers to use when building Mac and iOS apps. The Cocoa frameworks are written in Objective‑C and Objective‑C is the preferred language used to access the Cocoa frameworks when developing Mac and iOS applications. Apple used to provide support for using Java to access the Cocoa frameworks, but it has fallen out of use in recent years. There are other ways to access Cocoa APIs, including bindings for Python, Perl, Ruby, and C#, but for the most part those aren't sanctioned by Apple. The frameworks that make up what's known as "Cocoa" include Foundation and Application Kit The NS‑prefix comes from NeXTSTEP, the (AppKit) for Mac OS X, and when developing iOS object‑oriented operating system developed by NeXT Computer. Apple purchased NeXT in apps, Foundation and UIKit. Foundation 1997 and Mac OS X is a descendant of it s framework provides framework  provides a base layer of classes for operating system. string and number manipulation, date objects, It's important to remember that not everything with an NS‑prefix is an object, for example, NSRectMake() is a C function that returns an collections, networking and more. Some objects include NSString, NSArray, NSURLConnection, AppKit classes  classes are NSDictionary and NSNumber. AppKit used to build the interface for Mac applications NSRect (a type of struct), and NSInteger is a primitive data type. including windows, controls and menus. Example Depending on which framework you're working with, objects and functions may have a CG‑ AppKit objects include NSWindow, NSView, prefix (for Core Graphics), a CF‑prefix (for Core NSButton, NSImageView and NSScrollView. Foundation), an MK‑prefix (for the iOS mapping framework MapKit), a UI‑prefix (for the When developing iOS apps you'll still use the interface framework UIKit in iOS), or various others. same, more generic classes available in the Foundation framework but instead of using AppKit to build user interfaces, UIKit UIKit is  is used instead. Some objects from UIKit that you'll be using all the time are UIWindow, UIView, UIButton, UIViewController, UILabel, UITableView, UITextView and UIWebView. You might notice that for many objects, the UIKit version has the same name as the AppKit original, but with a UI‑ prefix instead of  NS‑. A full list of classes available within UIKit is shown here at here at Apple's Developer site. To be honest, you'll probably never use Car or Airplane objects unless you're building an app for a car dealership or airport. The objects that you'll typically be using and subclassing are ones that Apple provides as part of the Cocoa frameworks, like NSArray to manage collections of objects, UIViewController to manage a screenful of content, UITableViewCell for a custom row in a table, UILabel for displaying small bits of text, UIImageView to display an image on the screen and many, many more. Apple provides many interesting and incredibly useful classes for you to use as you construct Mac and iOS apps, and typically they are descendants of a number of other classes, adding more functionality and specialization specialization the further down the inheritance chain you look. For example, let's take a look at UIButton's full inheritance chain: UIButton inherits from UIControl UIControl inherits from UIView UIView inherits from UIResponder UIResponder inherits from the root class NSObject NSObject is the root class for most Cocoa objects and handles memory allocation, initialization, message passing and other lower‑level tasks. UIResponder handles interaction events like tapping the screen with your finger. UIView defines a rectangular area on the screen and provides the functionality to place or draw content within that rectangle. UIControl is the base class for user interface widgets and manages the state (selected? highlighted? disabled?) as well as what actions occur when the user interacts with it. And finally we get down to UIButton, a specialized control that takes care of a button's text label, all the styling of the button, and what it looks like when it's selected or highlighted. It's important to remember that when using a UIButton you don't just have access to the functionality of that  class,  class, but of all  the  the classes that UIButton inherits from all the way up to NSObject. I can't tell you how many times I missed something that was available in an object's parent class because I was only looking in the documentation for the immediate class I was using. Common Objects & Functions Regardless of what your app looks like there are some objects, functions and data structures that you'll use over and over so it's important to become familiar with them. NSString A string is a sequence of characters, and in Objective‑C, a string is an NSString object with a lot of built‑in functionality. functionality. The shorthand way of referring to a string @"looks like this" with an @ sign in front of a double‑quoted run of characters. NSString objects can be compared to one another, converted to other encoding formats, used to hold the contents of a file or URL, changed to C‑style strings, used in regular expression matches or turned into numbers. Once you create a string it cannot be modified. This may sound odd if you're coming from PHP or JavaScript, but if you want to modify a string after it has been created, you should use NSMutableString instead, a mutable (modifiable) subclass of NSString. Here's an example of how you might construct an NSURL object by using a string: NSURL *url = [NSURL URLWithString :@ :@"http://google.com/" "http://google.com/"]; ]; And here's an example of using a mutable string: NSMutableString  myString  myString = [NSMutableString  stringWithString *  stringWithString:@ :@"Reading "Reading [  myString replaceOccurrencesOfString  myString replaceOccurrenc esOfString:@ :@"Read" "Read" withString  withString:@ :@"Writ" "Writ"   options: options:NSLiteralSearch  range:  range:NSMakeRange (0,  myString  myString length])]; [ length])]; That's a gigantic method that we're calling! The NSMutableString instance method - replaceOccurrencesOfString: replaceOccurrencesOfString : withString: withString:options: options:range range: : finds a string within a string, then replaces it with something else. Notice the call to the NSMakeRange NSMakeRange() () function, part of the Foundation framework. It returns an NSRange struct data type which has two members: location and length. NSArray An array is an ordered collection of things and if  you're using NSArray, those "things" all have to be objects. Just like with an NSString, once it's created it cannot be modified unless you use NSMutableArray instead. Here's an example of  A struct is a special C data type that encapsulates other pieces of data into a single cohesive unit. Like an object, but built into C. Many Cocoa objects use structs. Each component of a struct is called a member. Some common structs you'll need to be familiar with include NSRange (has 2 NSUInteger members: location and length), CGPoint (has 2 CGFloat members: an X coordinate and a Y coordinate), CGSize (has 2 CGFloat members: width and height) and CGRect (has one CGPoint member and one CGSize member). To access the value of a member within a struct, dot notation is used. For example, if  myPoint is an CGPoint, you can access the X coordinate member of it with myPoint myPoint. .x. making an array: NSArray  myArray  myArray = [NSArray  arrayWithObjects *  arrayWithObjects:@ :@"Fish" "Fish", , @"Dogs" "Dogs", , nil]; arrayWithObjects: class method, the list of  When creating an NSArray using the +arrayWithObjects: objects needs to be nil‑terminated or it won't compile. It's not very intuitive at first, but it's important to remember to add it at the end of your list of objects or your code will crash and burn. Organizing objects into an array is useless if you never do anything with your new collection. Here are some examples of what you can do with a filled array. id myObject =  myArray  myArray objectAtIndex: [ objectAtIndex:3]; [  myArray makeObjectsPerformSelector  myArray makeObjectsPerfor mSelector: :@selector @selector( (runTowardsTheMoon runTowardsTheMoon)]; )]; NSUInteger  howMany = [  myArray  myArray count]; count]; The -objectAtIndex: objectAtIndex: instance method returns an id, a generic object in Cocoa. Since you can hold any type of object you want in an NSArray, when you access an object it gives you back a generic object type. It doesn't know what types of objects are being stored. Also, in the second example, what's a @selector? A @selector in Objective‑C is basically a method signature. In this example, we're telling each object in the array to call their -runTowardsTheMoon instance method. In the third example the method returns an NSUInteger, a Foundation framework primitive type that's an unsigned integer, that is, an integer that's greater than zero. NSDictionary Almost all languages have the concept of a data structure that holds key‑value pairs. Perl and Ruby have hashes, Python has dictionaries, PHP has associative arrays and Objective‑C has the NSDictionary class. The Foundation framework provides us with NSDictionary (and its mutable brother NSMutableDictionary) to hold key‑value pairs where all keys and values have to be objects. Let's define some dictionaries:  myDict  myDict = [NSDictionary NSDictionary *   dictionaryWithObjectsAndKeys:@ dictionaryWithObjectsAndKeys:@"aObj" "aObj", , @"aKey" "aKey", , @"bObj" "bObj", , @"bKey" "bKey", , nil]  arrayWithObjects:@ :@"One" "One", , @"Two" "Two", , @"Three" "Three", , nil NSArray *objs = [NSArray  arrayWithObjects  arrayWithObjects:@ :@"Blue" "Blue", , @"Green" "Green", , @"Yellow" "Yellow", , NSArray *keys = [NSArray  arrayWithObjects NSDictionary *anotherDict = [NSDictionary   dictionaryWithObjects: dictionaryWithObjects:objs forKeys: forKeys:keys]; keys]; dictionaryWithObjectsAndKeys: : In the first example we're calling the class method +dictionaryWithObjectsAndKeys which has to be nil‑terminated just like with some NSArray methods. In our object listing at the end we alternate object, key, object, key until we're done with all the pairs. In the second example we're creating two different NSArray objects — one to hold the keys and another to hold the objects — and then we pass these two arrays into the dictionaryWithObjects: :forKeys forKeys: : to build our NSDictionary class method +dictionaryWithObjects dictionary. Again, notice that we're not using +alloc or -init to manually allocate memory for these dictionaries. This means we don't have to worry about their memory or calling -release when we're done using them. A common use of NSDictionary is within an array: each element in the array is an NSDictionary object. For example, if you're building a Twitter app, the information for each tweet could sit in an NSDictionary, then each of these dictionaries is kept in order within an NSArray. // First, find the dictionary in the 4th position in the array. // Then, access the object paired with the key "tweet_text" NSString *status = [[  myArray objectAtIndex:  myArray objectAtIndex:4] objectForKey:@  objectForKey:@"tweet_text "tweet_text Organizing NSDictionarys within an NSArray is a simple way to store some structured data. NSNumber If you want to store a primitive number in an NSArray or NSDictionary you'll have to package it up into an NSNumber object first. NSNumber has a number (ha!) of convenient class methods so you'll rarely need to manage the memory yourself. NSNumber *  myNumber  myNumber = [NSNumber  numberWithInt:  numberWithInt:326 326]; ]; int myInt =  myNumber  myNumber intValue]; [ intValue]; You can get the primitive value of an NSNumber object just as easily as you can store it. NSLog() NSLog () NSLog() is a C function to send output to the console, useful when debugging your application. NSArray  myArray  myArray = [NSArray  arrayWithObjects *  arrayWithObjects:@ :@"Yo" "Yo", , @"Hey" "Hey", , nil]; NSLog( @"My array: %@", %@", myArray ); int myInt = 2011 2011; ; int anotherInt = 2012 2012; ; NSLog( @"My int: %d and another int: %d", %d", myInt,  myInt, anotherInt ); Writing static text out to your log isn't that useful, so NSLog() lets you output variables as well. To include a variable in your output, you need to know what type of variable it is because NSLog() has different format specifiers based on the variable type. For example, an array is an object so you'd use %@. The specifier for a plain int is %d. These format specifiers are "stand‑ins" for the actual value of the variable listed at the end of the function call. Apple provides the full list of list of string format specifiers to be used in NSLog() so make sure to always use the right one. Building Cocoa Applications We've talked about Objective‑C syntax and what objects are. We've also discussed some common Foundation frameworks objects and how Objective‑C classes are defined. Now it's time to start using some more complex Cocoa objects and putting all the pieces together to build a Cocoa app. Models, Views and Controllers, Oh My! A common design pattern in software development is called Model‑View‑Controller , or MVC for short. It's a methodology that separates the behavior and data of the application from the user interface. By keeping parts of the application separated into different classes your application can be developed more quickly and easily. By their design, the Cocoa frameworks practically force developers to use solid MVC principles, especially when building iOS apps. Each object in your application is assigned one of three roles: model, view or controller. These roles describe that object's behavior and responsibilities. Let's talk about what each part of MVC means as it pertains to building iOS apps. Model The model layer manages the data of your application. Model objects encapsulate data and also hold the behaviors that will update or process this data. If you're building a Twitter app you might create model objects to represent an individual account, tweet, direct message or follower profile. If you were writing an invoice‑sending app you'd probably have model objects for a company, person, invoice and more. A retro photography app? Perhaps only one model object representing a photo. You can think of model objects as being the nouns in a sentence that describes what your app does. If you were building an app that persistently stores its data across launches, you'd build behavior into your models so that they could save their own data to a file on the user's iPhone, or perhaps send it to a server somewhere. Here's some code showing how you'd initialize and use a model object. Client  myClient  myClient = [[Client alloc] *  alloc] init];  init];  myClient.  myClient.firstName = @"John" "John"; ;  myClient.  myClient.lastName = @"Smith" "Smith"; ;  myClient.  myClient.phoneNumber = @"212-555-1212" "212-555-1212"; ; [  myClient saveDataToFile];  myClient saveDataToFile]; In your apps you may use many model objects or you may use none, it all depends on what kind of app you're building. Model objects are typically just subclasses of the Cocoa root object, NSObject. A benefit of using model objects is that they can be reused. Say you've built an iOS app and then you choose to port it to the Mac. If you've built your model objects with reusability in mind (not using iOS‑specific APIs) it's fairly easy to port them to another Cocoa platform like OS X. Your model objects should not be concerned or tied to the user interface at all, thus making reusability possible. View Views are the objects used to build your user interface. For most of this guide the objects we've discussed represented abstract concepts, things or types of data, but view objects are different because they're actually seen by the user on the screen. Text labels, buttons, input fields, table views, scrollable panes and tabs are all view objects with defined behaviors and attributes. Views in iOS apps are all descendants of UIView, the root object used to build user interface components defined in the UIKit framework. Here's a list of  list of  all the classes available to you in UIKit. Views have the ability to draw themselves (with colors, patterns, images, borders, shadows, corner radii, transparency, etc.) and also respond to user input. Apple provides a number of built‑in view classes for use in your applications. You can use these as‑is, customize some of their attributes, or go completely custom and write your own totally unique view objects to build custom user interfaces and new methods for user interaction. Here's an example of initializing and customizing a UILabel, a built‑in view object that draws a simple run of text on the screen. CGRect  textRect = CGRectMake (0,0,200 200, ,50 50); ); UILabel  myLabel  myLabel = [[UILabel  alloc] *  alloc] initWithFrame:  initWithFrame:textRect]; textRect];  myLabel.  myLabel.text = @"Photos" "Photos"; ;  myLabel.  myLabel.backgroundColor = [UIColor  clearColor];  clearColor];  myLabel.  myLabel.font = [UIFont  boldSystemFontOfSize  boldSystemFontOfSize: :24 24]; ];  myLabel.  myLabel.textColor = [UIColor  blackColor];  blackColor];  myLabel.  myLabel.shadowColor = [UIColor  whiteColor];  whiteColor]; That's a lot of properties! You'll find that most Apple‑built view objects come loaded with ways for them to be configured, mostly by setting their properties. Many properties on UILabel look similar to CSS styles like color, background color, text shadow, font and more. An important thing to remember is that initializing a view object does not put it on the screen, it simply creates the object in memory. To put it on the screen, you must add the view as a subview on an existing user interface object. The main UIWindow for your application is the top‑level view object for your application. All views that you create and use in your app are subviews of the window, or of each other, creating an overall view hierarchy. Let's take a look at another view object example where we add it to the screen. CGRect imageViewRect = CGRectMake (0,0,150 150, ,150 150); ); UIImageView  *logoView = [[UIImageView  alloc]  alloc] initWithFrame:  initWithFrame:imageViewRec logoView. logoView.image = [UIImage imageNamed:@  imageNamed:@"logo.png" "logo.png"]; ]; [self.  window addSubview:  window addSubview:logoView]; logoView]; [logoView release]; release]; // Skip this if you're using ARC  When you initialize a view object you typically don't just call -init on it, you call a different initialization method -initWithFrame which not only initializes the view object but also sets its frame property. What's a frame? A frame is the rectangular region on the screen that the view is drawn into. It's a CGRect struct with four members: X position, Y position, width and height. The X and Y coordinates make up a CGPoint struct named origin, and the width and height are part of an CGSize struct named size. In web design, when you absolutely position a