iOS 5: KEY TOOLS AND TECHNOLOGIES RICHARD WARREN CHAPTER 1 Automatic Reference Counting (ARC) In the past, memory management has been one of the most challenging parts of iOS development. ARC helps simplify memory management, by analyzing your code and automatically inserting the necessary retain, release, and autorelease method calls. Memory Management Basics •Local variables are created on the stack. They are automatically deleted once the current function returns. •To store a value beyond the current function, you must allocate memory on the heap. That value will then remain until we release them. •All Objective-C objects are created on the heap. In Objective-C, when we talk about memory management, we are typically talking about managing objects on the heap. •There are two main memory management errors: •Forgetting to release memory on the heap creates a memory leak. •Releasing memory too early, then trying to access it again creates a dangling pointer. •In the most simple examples, memory management seems easy. However, in any real-world application, it is often difficult to determine who should be responsible for allocating and releasing the required memory. 2 Retain and Release We manage the lifecycle of Objective-C objects using their retain count. •All Objects start with a retain count of 1. •Calling retain on an object, increases its retain count by 1. •Calling release, decreases its retain count. •Calling autorelease reduces the object’s retain count by 1 at some point in the future (usually at the end of the current run loop). •When the retain count hits 0, the object is deallocated. •If you create an object using a method whose name begins with alloc, new, copy, or mutableCopy, you own the object. You must release it when you are done. •If you receive an object using any other method, you must retain the object if you wish to keep it past the current method call. •You can get more information on manual memory management in Apple’s Advanced Memory Management Programming Guide. 3 Problems with Manual Memory Management Manual retain and release (MRR) has served Objective-C well for over 3 decades. It’s a solid system and has been used to create hundreds of thousands of high-quality applications. However, MRR still has a few problems. •Inserting the correct retain, release and autorelease calls is tedious. •The developer must constantly think about where their objects are coming from. Do they own the objects, or will the objects be autoreleased. •The manual memory management must be correct 100% of the time. Even one mistake can cause a memory leak or dangling pointer. •The developer’s energy and attention could be better spent solving interesting problems, not managing memory. •You can also create retain cycles. If two objects retain each other, they will never be released. •Apple has provided a number of tools, like Instruments, to track memory usage and help eliminate memory bugs. •Still, memory-related bugs are the #1 reason why iOS applications crash. 4 Garbage Collection To address these problems, Apple introduced garbage collection with Mac OS X 10.5, Leopard. •A garbage collector runs on a low-priority background thread. •It monitors all references to Objective-C objects. •When it determines that an object is no longer being used by the application, it deallocates the object. •This greatly simplified developing applications for the Mac, but it has some problems. •Developers have very little control over when and how the garbage collector runs. •If objects are rapidly created and released, memory usage can spike, causing the application to use too much memory, before the garbage collector can catch up. •Alternatively, the garbage collector may unexpectedly run, slowing down the application at a critical moment. •Most importantly, garbage collection is not available for iOS. 5 Introducing ARC ARC is a compiler feature that provides automated memory management for Objective-C objects. Conceptually, ARC follows the retain and release memory management conventions. As your project compiles, ARC analyzes the code and automatically adds the necessary retain, release, and autorelease method calls. •ARC largely frees developers from worrying about memory management. •Memory management is handled at compile-time. •There are no unexpected slowdowns during the application’s execution. •The developer maintains control over when and how objects are deleted from memory. •Apple has also optimized memory management under ARC. Basic retain and release calls are 2.5 times faster than MRR, and auto release pools can be up to 6x faster. •There are some additional rules that we must follow--however the compiler enforces these. •Unfortunately, ARC does not protect us from creating retain cycles. 6 Zeroing Weak References The objects in our application can be seen as a directional graph, starting with the UIApplication instance, and moving down through our custom data. Whenever we create a reference to an object (e.g. an object @property in one of our classes), we need to consider whether it refers to a new object, or if it refers back to an object further up in our graph. •If we are referring to a new object, we should use a strong reference. This tells ARC to retain the object for us. •If we are referring back up the graph, we need to use a weak reference. This tells ARC to use a zeroing weak reference. •ARC will not retain the object. It must be retained somewhere else (using a strong reference), or it will not remain in memory. •If the object is ever deallocated, the zeroing weak reference will automatically be set to nil. This eliminates any chance of having dangling pointers. •Objects should always use weak references to their delegates. 7 ARC Rules of the Road •Don’t use objects in C structs. •Don’t create a property with a name that begins with “new.” •Don’t call dealloc, retain, release, retainCount, or autorelease. •Don’t override the retain, release, retainCount, or autorelease methods. •You can override dealloc, but it’s often not necessary. •When implementing dealloc, don’t call [super dealloc]. •Don’t use NSAutoreleasePool objects. Use the new @autoreleasepool{} blocks instead. •Use __bridge __bridge_retain or __bridge_transfer when casting between objects and void*. •Don’t use NSAllocateObject or NSDeallocateObject. •Don’t use memory zones or NSZone. 8 Demo 9 CHAPTER 2 Storyboards Interface Builder (now part of Xcode) has long allowed developers to graphically design their application’s user interface. Even letting developers draw connections between control events and methods in their code. Now, Storyboards takes this one step further. We can not only create an individual scene--we can graphically lay out the relationships and segues between scenes. Interface Builder and Nibs •Unlike many visual tools, Interface Builder does not generate code to create your user interface. Instead, it constructs the interface from live objects, then archives them. •Traditionally, the interface archive is a binary .nib file. When you load a nib, you are loading all the objects that make up the user interface. •Recent versions of Xcode allow saving the interface as XML to better support source control and diff tools. •Modern projects save the files as .xib files, then compile the .xib to a .nib file in the final product. •The terms nib and xib are generally used interchangeably. •Each nib file has a file’s owner. You can draw connections from the owner to objects created by the nib. •IBOutlet allows you to connect instance variables to objects in the nib. •IBAction allows you to connect methods to UIController events in the nib. 11 Nib Demo Storyboards Storyboards extends Interface Builder’s power. While nibs let us define a screenful of information, Storyboards let us graphically lay out the relationships and transitions between screens. •A storyboard has the following features: •One or more scenes. Each scene represents a significant chunk of information on the screen. •Relationships between containers (navigation view controller, tab view controller, etc.) and their content. •Segues between scenes. •At compile time, the storyboard is converted into nib files. •Each scene roughly translates to its own nib file. •There isn’t a strict 1:1 relationship between scenes and nibs. 13 Using Storyboards •Storyboards are only supported by iOS 5 and later. If you want to support earlier versions, you cannot use Storyboards. •You can freely mix Storyboards and nibs inside a single project. However, you must load each new Storyboard or nib in code. A storyboard cannot load a nib or another Storyboard. •One nib can refer to another nib; however, this is not supported in Storyboards. This means we can do some things in nibs that we cannot yet replicate with Storyboards. •You cannot draw connections between the objects of one scene and another. All connections must be drawn within a single scene, with only segues and relationships leading out to other scenes. •Storyboards are most useful when first creating a project: •You can quickly sketch out the framework and workflow for the entire application. •This can save a lot of time when initially setting up the application. 14 Passing Data Across Segues •Before the application segues from one scene to the next, the originating scene’s view controller’s prepareForSegue:sender: method is called. •We should override prepareForSegue:sender: and pass the data we need to the destination’s view controller. •Note: the destination view may not exist yet. We should store the data in the view controller, then pass it to the view in its viewWillAppear: method. •To get data back from the destination, we should make the sending view controller a delegate of the destination. •We must define the delegate protocol ourselves. •We assign the sender as the destination’s delegate in prepareForSegue:sender:.