Your First ios 7 App. Everything you need to know to build and submit your first ios app. Ash Furrow

Transcription

1

2 Your First ios 7 App Everything you need to know to build and submit your first ios app. Ash Furrow This book is for sale at This version was published on This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do Ash Furrow

3 To my wife, my greatest inspiration.

4 Contents Introduction Xcode Basic Project App Delegate Storyboard View Controller Other Files

5 Introduction Congratulations! You ve bought my book and that s a great first step toward becoming a proficient ios developer. This chapter will give you a feet-first introduction to the ins and outs of the tools used to write ios apps. We re going to begin with Xcode, then move onto basic Objective-C syntax. We ll take a look at the app delegate and create a very, very small app to poke around. I m going to assume you have some basic knowledge of object-oriented programming. If you don t, Oracle (surprisingly) has a great description of OOP¹ to get you started. We re going to be building an application called Coffee Timer to help users make coffee and tea. Before we start anything, I d like to present the Application Definition Statement. Coffee Timer helps people time coffee and tea to brew delicious beverages. We re going to start out small and augment our application in each chapter until we have something worth submitting to the App Store. Let s get started. Xcode Xcode is the Integrated Development Environment we re going to use to build our apps. Install it from the App Store² and open it up. You ll see the welcome prompt. ¹ ²

6 Introduction 2 Xcode welcome prompt Click on Create a new Xcode project to get started. This will bring up the new project dialogue window.

7 Introduction 3 Xcode new project dialogue Make sure that Application under ios is selected in the left hand pane. We re going to use the Single View Application template. Xcode is going to ask us for some values. We ll give our app a name. This is going to be what s seen under the app icon on the home screen, so it s important to pick a great name. Don t worry you can change this later if you have to. This book is going to focus on writing a timer to help people make coffee, so we ll use the name Coffee Timer for our app. The name you choose for your application will affect some directory names, some class names, as well as the copyright notices at the beginning of your files. I use my name as an Organization Name. This does not affect anything in the App Store at all. A Company Identifier is a required field and the convention is to use a reverse DNS name for your website. My website is ashfurrow.com, so my company identifier is com.ashfurrow again, you can change this later, so don t fret too long. The goal here is just to get started! Additionally, you ll need a class prefix. Objective-C doesn t have namespaces, so it uses prefixes on all the classes. The convention is to use the abbreviation of either your name or the project. Prefixes should be three letters long, since Apple reserves all two-letter prefixes for their own use. We re

8 Introduction 4 going to use CTR (standing for Coffee TimeR ) for our prefix. Finally, select iphone as the device. I ve filled in these values as shown in the next figure. Creating our first project Save the project anywhere. If you want to use git³ to keep track of changes in your project, feel free to check the Create local git repository checkbox in the save dialogue. I won t be covering how to use git in this book. After saving, you ll have a (mostly) empty project. ³

9 Introduction 5 Newly created project Basic Project Awesome! Let s build and run the app. You can either hit the Run button with the Play symbol on it, or hit command-r to run the app. This will compile the code and install the app into the device specified in the Scheme drop down menu. For now, we re not going to worry about running the app on an actual device it s a very complicated process and you re better off diving into code as soon as possible. Just make sure iphone 6.X simulator is selected from the Scheme drop down menu. The Scheme drop down menu is located in the top bar of the Xcode window, to the right of the play and stop buttons. The app is shown here.

10 Introduction 6

11 Introduction 7 This is a pretty boring app so far, but it is an app. You can hit the home button in the simulator (command-shift-home) to see the Home Screen of the simulator and there s your app. Not bad! Let s go back to Xcode to explore the parts of an app that are created for you. App Delegate Take a look at the files list on the left hand side of the Xcode window. You ll see a bunch of files. Let s go through each one, one at a time. Open the Project Navigator (command-1). Project Navigator I should mention that classes in Objective-C are represented by two files: a header and an implementation. When I say header, I mean C header, if you re familiar with C. A header specifies the public methods and properties that other classes should have access to. An implementation file specifies the private properties, as well as the code that implements the object s methods. So when you see the first two files called CTRAppDelegate.h and CTRAppDelegate.m, these two files should be treated as representing different aspects of the same class. Open up the CTRAppDelegate.h file first and take a look.

12 Introduction 8 1 // 2 // CTRAppDelegate.h 3 // Coffee Timer 4 // 5 // Created by Ash Furrow on // Copyright (c) 2013 Ash Furrow. All rights reserved. 7 // 8 9 #import <UIKit/UIKit.h> 10 CTRAppDelegate : UIResponder <UIApplicationDelegate> 12 (strong, nonatomic) UIWindow *window; 14 The group of lines at the top, the comment, is a standard copyright notice Xcode inserts into each file you create. The next line is an #import statement. This imports other header files so we can reference the classes specified in them. This is a lot like #include in C, except you can #import a file more than once without any bad consequences. In this case, we ve imported UIKit/UIKit.h. UIKit is the framework for displaying user interfaces in ios apps. The <angle brackets> around the file mean that it s a library. We need this #import so we can access UIResponder, UIApplicationDelegate, and UIWindow later on. Next, we see the CTRAppDelegate : UIResponder <UIApplicationDelegate>. There are a lot of things going on here, so let s break it down a means that we re declaring the interface for a class. Doing so in a header file means that it s the public interface. The class name is what immediately follows; in our case, the class name is CTRAppDelegate. Next, there s a colon followed by UIResponder. UIResponder is the super class which CTRAppDelegate extends. I m not going to go into the specifics of what UIResponder is right now; just know that the app delegate extends UIResponder. Finally, in the angle brackets, you have UIApplicationDelegate. This is probably the most important part of the line. Inside the angle brackets specify which protocols the class conforms to. Protocols are like interfaces in other languages: they are a guarantee that this object will implement certain methods. Other classes using CTRAppDelegate can expect that it has certain methods. That s actually only mostly true. Protocols may specify optional methods, which is the case with UIApplicationDelegate. I ll discuss protocols in a later chapter and I ll describe what an application delegate is momentarily. First, let s take a look at the rest of the header file. The next line (strong, nonatomic) UIWindow *window;. This means that there is a property called window of a type UIWindow. strong means that it is owned by this class (we ll get into strong and weak keywords in Chapter 7. nonatomic has to do with concurrency. Since

13 Introduction 9 our application won t really be taking advantage of concurrency, using atomic properties would incur a slight overhead. All you need to know is that 99% of the time, when you declare a property referencing another object, it looks like this: (nonatomic, strong) ClassType *propertyname; Finally, there is line. This corresponds to at the beginning of the class. That s it you ve just examined your first Objective-C class! We now know that this is a class named CTRAppDelegate that extends UIResponder and conforms to the UIApplicationDelegate protocol, and that it has one public property called window. But what on Earth is an application delegate? An application delegate, or app delegate, is a special class used by the app. All apps have exactly one app delegate. The app delegate is responsible for being notified about certain important application events, like finishing launching or quitting. It s the job of the app delegate to let the rest of the app know when something important happens. Let s open up the implementation file, CTRAppDelegate.m, so you can see what I mean. These are the existing contents of CTRAppDelegate.m. 1 #import "CTRAppDelegate.h" 2 CTRAppDelegate (BOOL)application:(UIApplication *)application 6 didfinishlaunchingwithoptions:(nsdictionary *)launchoptions 7 { 8 // Override point for customization after application launch. 9 return YES; 10 } (I m omitting the copyright header for the rest of this book.) The first line #imports the header for the implementation file. This is standard for all implementation files. Next, we CTRAppDelegate. This starts the implementation for our object. Next, we have a list of empty methods that Xcode has stubbed out for us. Let s look at what a method looks like. 1 - (BOOL)application:(UIApplication *)application 2 didfinishlaunchingwithoptions:(nsdictionary *)launchoptions The dash means that the method belongs to an instance of the class and not that class itself (class methods have plus signs instead of dashes). In other languages, we d call this an instance method

14 Introduction 10 versus a static method. The value BOOL in between the (parentheses) specifies the return type of the method. The next part gets a little complicated. Objective-C methods mix the method name with the parameters, so you get sort of a named parameter effect. There are two colons in the method name, so there are two parameters. The names of the parameters are application and launchoptions, and their types are UIApplication and NSDictionary respectively. The method name is referenced to as application: didfinishlaunchingwithoptions:. It s a little complicated, but don t get too hung up on it. Later on, when we start to write our own methods and call them, it ll start to make sense. For now, take a look at the list of method names in the implementation file. application: didfinishlaunchingwithoptions: applicationwillresignactive: applicationdidenterbackground: applicationwillenterforeground: applicationdidbecomeactive: applicationwillterminate: Xcode will also have filled these in with descriptions of what each stub does. Application state is a little complicated. Once launched, an app is in the foreground until the user opens another app or returns to the Home Screen. Then it enters the background. From there, it stops executing until opened again, but it s still in memory. In the background, an application will either be returned to the foreground and become the active application again, or it will be terminated. These methods should all be fairly strait forward, except for maybe applicationwillresignactive:. This is called when an application is still in the foreground, but isn t actively being used by the user. The best example is when someone double-taps their Home Button to make the multitasking tray appear or when you recieve a phone call. The application is still in the foreground, but not actively responding to user events. Why would you care? Well, games and videos should pause and OpenGL should throttle down its frame rate. Other than that, it s not terribly important. So that s what an app delegate does out of the box: it responds to application events. For now, it won t matter much, but the app delegate is a central component of any application and deserves a good overview. Let s throw some logging information into the app and re-run it. Add the following logging information to your methods.

15 Introduction (BOOL)application:(UIApplication *)application 2 didfinishlaunchingwithoptions:(nsdictionary *)launchoptions 3 { 4 NSLog(@"Application has launched."); 5 6 return YES; 7 } (void)applicationwillresignactive:(uiapplication *)application 10 { 11 NSLog(@"Application has resigned active."); 12 } (void)applicationdidenterbackground:(uiapplication *)application 15 { 16 NSLog(@"Application has entered background."); 17 } (void)applicationwillenterforeground:(uiapplication *)application 20 { 21 NSLog(@"Application has entered foreground."); 22 } Re-run the app and play with it. Click the Home Button (command-shift-h). Double-click it. See how the application moves from foreground to background. Logging information will be displayed in the console, which will be opened for you when something is printed there.

16 Introduction 12 Logging console Storyboard Next comes the fun part: the Storyboard. The Storyboard visually lays out everything the user is going to see and interact with inside of your app. For now, the storyboard looks a little boring.

17 Introduction 13 Main Storyboard Your main storyboard is named MainStoryboard.storyboard in Xcode. Click it once to open it. The first thing I want you to do, and this is very important, is to open the File Inspector in the right hand pane (comand-alt-1) and find the checkbox labelled Use Autolayout to uncheck it. Autolayout is this hot new technology from Apple that s pretty complicated to use in practice, so we re going to stick with the older way of doing things for now. You ll thank me later. Feel free to explore around the Storyboard. Notice the buttons to zoom in and out. These will be handy once the Storyboard becomes larger. Notice the hierarchy of the Storyboard on the left hand side. You can hide it with the arrow on the left useful for developing on smaller screens. The View Controller is the parent of the View, as you might expect. Click on view controller in the hierarchy, then open the Identity inspector (command-alt-3). The Identity Inspect can also be shown by opening the View menu, then selecting Utilities and clicking Identity Inspector. What s that? The Custom Class is set as CTRViewController. Interesting that s the name of the other class Xcode created for us.

18 Introduction 14 View Controller In fact, when ios unpacks your Storyboard, it uses the value in the Custom Class to know which class to instantiate. Let s explore the view controller files, then we ll come back to how it interacts with the Storyboard. The CTRViewController.h file is pretty boring. CTRViewController : UIViewController 2 It has no public properties or methods. All it specifies is the superclass of our view controller, UIViewController. Let s take a look at the implementation file. CTRViewController () 2 4 CTRViewController (void)viewdidload 8 { 9 [super viewdidload]; 10 // Do any additional setup after loading the view, typically from a nib. 11 } (void)didreceivememorywarning 14 { 15 [super didreceivememorywarning]; 16 // Dispose of any resources that can be recreated. 17 } 18 Very interesting! We ve got a re-declaration of our interface. Since this is in the implementation file, this is where we ll put any private property declarations. We don t need to declare our private methods, a practice that s sometimes held over from the days of C. block in the implementation file is only for private properties. The implementation itself contains two method stubs: viewdidload and didreceivememorywarning. We ll ignore the latter and focus on the former. When the Storyboard wakes up to be shown to the user, it needs to load a view controller. The class it uses for that view controller is set by the Custom Class property in the Storyboard, like we saw

19 Introduction 15 earlier. Once the view controller loads the view, it calls viewdidload on the controller. This is the developer s opportunity to customize the view before it s first displayed to the user. Let me show you what I mean. Replace the viewdidload implementation with this one: 1 - (void)viewdidload 2 { 3 [super viewdidload]; 4 5 NSLog(@"View is loaded."); 6 7 self.view.backgroundcolor = [UIColor orangecolor]; 8 } This will add some logging and change the background colour of the view controller s view. Indeed, our console output looks like the following: 1 Coffee Timer[10054:c07] Application has launched. 2 Coffee Timer[10054:c07] View is loaded. And indeed, the background colour of the view is now orange.

20 Introduction 16

21 Introduction 17 Other Files Those are the main files that you ll work with 99% of the time in Xcode. However, you can open the Supporting Files folder in the Files pane to see some behind the scenes action. The Coffee Timer-Info.plist is the file that specifies a lot of the metadata about our app. These are values like our version number, which interface orientations we support, and the default language. You don t change these very often. We also have InfoPlist.strings. We ll talk more about this in Chapter 9, but it basically allows your app to have a different name in different languages. Next is super-interesting: main.m. If you re familiar with C, this is the main.c equivalent. 1 #import <UIKit/UIKit.h> 2 3 #import "CTRAppDelegate.h" 4 5 int main(int argc, char *argv[]) 6 { { 8 return UIApplicationMain(argc, argv, nil, 9 NSStringFromClass([CTRAppDelegate class])); 10 } 11 } You don t need to understand what s going on, but the gist is that the call to UIApplicationMain() starts your app and does not return until the application terminates. Next we have Coffee Timer-Prefix.pch. This is the precompiled header. It s basically a header file that s automatically #imported in every file. That means global C macros can be defined here. Finally, We have Default.png, Default@2x.png, and Default-568h@2x.png. These are the default, retina default, and tall screen retina default files, respectively. These are the launch images for the app and are black by default. That s it! You ve created your first Xcode project and explored every nook and cranny of it. It s not important to understand every piece we re going to do more in-depth exploring in the next chapter. What s important is that you re familiar with the over-arching concepts: what the app delegate is and what it s for, that views are laid out in the Storyboard, and that code to modify views goes in the view controller.