iOS Components and Frameworks: Understanding the Advanced Features of the iOS SDK (2014)

Chapter 14. Language Features

With the introduction of Objective-C 2.0 in 2006, continued support for Clang and LLVM compiler enhancements, and Xcode 4 in 2011, many useful new features have been added that enhance code readability and reduce the amount of code needed to meet a requirement. This chapter highlights some of the most useful new features that have been added, and some features that have been around a while that are not as well known, including the following:

Literals, which make declaring numbers, arrays, and dictionaries as easy and simple to read as string declarations.

Automatic Reference Counting (ARC), which provides an automated way to handle memory management, without many of the drawbacks of garbage collection or manual memory management. Using ARC can reduce the amount of code needed in a project and help avoid common memory management issues.

Properties, which have been enhanced to the point that declaring instance variables for a class is rarely necessary. The compiler can generate accessor methods that respect memory management, read/write, and threading settings.

Blocks, which are anonymous functions that can be passed around like parameters and can make use of variables in their local scope. These are very effective tools for simplifying code and improving code readability. Many of the iOS APIs have added support for blocks.

Fast enumeration, which provides a simple, readable approach to iterating over a collection, and performing actions on each item in a collection.

Method swizzling, which allows the developer to dynamically swap out method implementations at runtime. This can be used to enhance existing functionality when the source code is not available, and when neither subclassing nor using categories is a good option.

Literals

When Xcode 4.4 was released in July of 2012, the compiler was updated to add support for several new types of literal syntax that make declaring and using NSNumber, NSArray, and NSDictionary much simpler and much more readable. The new syntax follows the lead ofNSString literals by using the @ prefix with syntactical elements to define Objective-C objects:

NSString *aString = @"This is a string.";

Now, an @ symbol followed by numbers, brackets, curly braces, or parentheses has special meaning and represents an Objective-C object:

NSNumber *integerNumber = @45;
NSArray *workArray = @[aString, floatNumber, integerNumber];
NSDictionary *workDict = @{ @"float": floatNumber,
@"integer" : integerNumber,
@"array" : workArray };
NSNumber *radiansPerDegree = @(M_PI / 180);

In addition, new syntax has been added to make accessing elements in arrays or dictionaries simpler.

NSString *myString = workArray[0];
NSNumber *myNumber = workDict[@"float"];

NSNumber

Previously, to declare and instantiate an NSNumber, a developer had to either alloc/init or use a class method with a scalar like so:

NSNumber *floatNumber = [NSNumbernumberWithFloat:3.14159];
NSNumber *doubleNumber = [NSNumbernumberWithDouble:3.14159];

NSNumber *integerNumber = [NSNumbernumberWithInteger:45];

NSNumber *unsignedIntegerNumber =
[NSNumbernumberWithUnsignedInteger:45U];

NSNumber *longNumber = [NSNumbernumberWithLong:1234567L];

NSNumber *longLongNumber =
[NSNumbernumberWithLongLong:1234567890LL];

NSNumber *boolNumber = [NSNumbernumberWithBool:YES];
NSNumber *charNumber = [NSNumbernumberWithChar:'Q'];

With the new syntax, this is the equivalent of using the class methods on NSNumber:

NSNumber *floatNumber = @3.14159F;
NSNumber *doubleNumber = @3.14159;

NSNumber *integerNumber = @45;
NSNumber *unsignedIntegerNumber = @45U;
NSNumber *longNumber = @1234567L;
NSNumber *longLongNumber = @1234567890LL;

NSNumber *boolNumber = @YES;
NSNumber *charNumber = @'Q';

NSArray

To declare and instantiate an NSArray with a known set of elements previously, a class method or equivalent alloc/init needed to be used:

NSArray *workArray = [NSArrayarrayWithObjects: aString,
floatNumber, integerNumber, nil];

With the new syntax, declaring and instantiating an NSArray is much simpler and less verbose, and the nil terminator is no longer required.

NSArray *workArray = @[aString, floatNumber, integerNumber];

Be sure to note, however, that putting a nil object in the brackets either will cause a warning if the compiler can detect that the value will be nil at compile time, or will generate a runtime exception.

In addition to supporting a new approach to instantiating arrays, a new method of accessing and updating objects in an array is now supported. The previous approach was to call a method on NSArray to access an element.

NSString *myString = [workArray objectAtIndex:0];

Now C-style subscripting is supported to access elements in an array.

NSString *myString = workArray[0];

This type of subscripting also works for setting elements in a mutable array.

mutableArray[0] = @"Updated Element";

These C-style subscripting methods to access array elements are supported by the compiler by translating the expressions into method calls. The objectAtIndexedSubscript: method is how the accessor subscript is implemented.

NSString *myString = [workArray objectAtIndexedSubscript:0];

The mutator subscript is implemented with the setObject:atIndexedSubscript: method.

[mutableArray setObject:@"Updated Element" atIndexedSubscript:0];

NSDictionary

To declare and instantiate an NSDictionary with a known set of keys and values previously, a class method or equivalent alloc/init needed to be used:

NSDictionary *workDict =
[NSDictionarydictionaryWithObjectsAndKeys:@"float",
floatNumber, @"integer", integerNumber, @"array",
workArray, nil];

With the new syntax, declaring and instantiating an NSDictionary is much simpler, much less verbose, and easier to read:

NSDictionary *workDict = @{ @"float": floatNumber,
@"integer" : integerNumber,
@"array" : workArray };

Be sure to note, however, that putting a nil object as either a key or a value either will cause a warning if the compiler can detect that the value will be nil at compile time, or will generate a runtime exception.

In addition to supporting a new method to instantiate dictionaries, a new method of accessing and updating objects in a dictionary is now supported. The previous approach was to call a method on NSDictionary to access an element by specifying a key.

NSNumber *myNumber = [workDict objectForKey:@"float"];

Now elements in a dictionary can be accessed using the key as a subscript.

NSNumber *myNumber = workDict[@"float"];

Elements in a mutable dictionary can also be set using a key as a subscript.

workDict[@"float"] = @3.14159F;

These subscripting methods are supported by the compiler by translating the expressions into method calls. The objectForKeyedSubscript: method is how the accessor subscript is implemented.

NSNumber *myNumber = [workArray objectForKeyedSubscript:0];

The mutator subscript is implemented with the setObject:forKeyedSubscript: method.

[mutableDict setObject:@12.345F forKeyedSubscript:@"float"];

Boxed Expressions

The compiler also supports boxed C expressions, including scalars, enums, and C string pointer types. A boxed expression will convert the result of the expression contained in parentheses into an appropriate Objective-C object.

NSNumber *radiansPerDegree = @(M_PI / 180);
NSNumber *myFavButtonType = @(UIButtonTypeInfoDark);

char *cString = "The quick brown fox...";
NSString *stringFromCString = @(cString);

Automatic Reference Counting

Automatic Reference Counting (ARC) is LLVM compiler support for automatically handling memory management for Objective-C objects. Instead of the developer calling retain, release, and autorelease methods for objects created in a project, the compiler will calculate the lifetime of each object created and automatically insert the appropriate retain, release, and autorelease calls as necessary. ARC can completely avoid the error-prone and tedious manual approach to memory management, while reducing the amount of code needed and potentially even make code perform faster. ARC code can also work seamlessly with non-ARC code; for example, if a third-party library that a project depends on is not using ARC, the project can still be updated to take advantage of ARC without updating the third-party library. ARC has matured to the point that Apple recommends using it on all new projects.

Using ARC in a New Project

In Xcode 5, ARC is the default for all new projects. For Xcode 4.6 holdouts, new projects must be enabled for ARC by selecting the option when creating it using Xcode 4.6, as shown in Figure 14.1.

Figure 14.1 Xcode 4 New Project dialog displaying checked Use Automatic Reference Counting option.

Converting an Existing Project to ARC

Existing projects written without ARC can be converted to use ARC by selecting Edit, Refactor, Convert to Objective-C ARC from the menu in Xcode, as shown in Figure 14.2.

Figure 14.2 Xcode menu, Convert to Objective-C ARC.

Xcode will ask which targets should be converted to ARC, using a dialog as shown in Figure 14.3.

Figure 14.3 Xcode Convert to Objective-C ARC, Select Targets to Convert dialog.

After you have selected the targets to be converted to ARC and clicked Check, Xcode will examine the code in the target to determine whether there will be any issues in converting to ARC. If there are problems, Xcode will present an error dialog, and any errors with the code preventing conversion to ARC will be displayed in Xcode’s Issue Navigator. Resolve any outstanding issues and rerun the check process by selecting Convert to Objective-C ARC from Xcode’s Edit, Refactor menu, and repeating the steps described. After the issues are all resolved, Xcode will display a dialog explaining the steps that will be taken to convert the project to ARC, as shown in Figure 14.4.

Figure 14.4 Xcode Convert to Automatic Reference Counting dialog.

After you click Next, Xcode will preview the changes that need to be made to convert the project to ARC, as shown in Figure 14.5. Xcode will display each file that will require changes, and each specific change that will be needed. This preview highlights how the amount of code in the project will be reduced.

Figure 14.5 Xcode Source Comparison View.

Clicking Save will make the recommended changes to the project.

A project can be set to use ARC manually by specifying a build setting, as shown in Figure 14.6. After this setting is changed, the compiler will issue errors for any non-ARC issues found in the project, and it is up to the developer to address those manually.

Figure 14.6 Xcode Build Settings for Objective-C Automatic Reference Counting.

Basic ARC Usage

There are new coding rules and guidelines to follow for projects using ARC. The compiler will enforce the ARC-specific rules, and generate warnings or errors as appropriate:

Create instances of variables and properties as normal, using alloc/init, new, copy, or class methods.

Using retain, release, and autorelease is not allowed. The compiler will automatically insert retain, release, and autorelease for objects allocated in project code at compile time. Note that the inserted statements are not visible.

Use qualifiers for properties (described in more detail in the “Properties” section later in the chapter) or variables to specify ownership and lifecycle. ARC qualifiers, described in the next subsection, tell the compiler when a retain is needed to indicate ownership, or when an object is owned somewhere else and a retain is not needed. The qualifiers help ARC understand the intended life cycle of an object so that the compiler can properly release and/or nil an object pointer when it is no longer needed.

Avoid dealloc. The compiler will create dealloc methods automatically as needed, and dealloc must not be called directly by code. Custom dealloc methods can be created to handle special situations or objects not handled directly by ARC; however,[super dealloc]cannot be called from those custom dealloc methods.

Use @autorelease blocks instead of NSAutoreleasePool. Blocks are described in more detail later in the chapter.

When using or interacting with Core Foundation objects, use the new qualifiers __bridge, __bridge_retain, __bridge_transfer to indicate ownership intent.

ARC Qualifiers

There are four ARC qualifiers for object ownership that tell the compiler how to handle each object. The qualifiers are specified either implicitly (__strong is the default) or explicitly when declaring an object.

__autoreleasing: autoreleasing is not the same as autorelease; rather, it is used for passing an object by reference, as in this example:

__autoreleasing NSError *error = nil;

self.listArray = [moc executeFetchRequest:fetchReq
error:&error];

__strong: strong is the default, and it indicates that the object should be retained for the lifetime of its current scope. The object will be set to nil before it is destroyed.

__weak: weak indicates that the object should not be retained. The compiler will automatically set the object to nil before it is destroyed.

__unsafe_unretained: Same as weak, but the object is not set to nil before it is destroyed.

Declaring properties have different qualifiers, which each imply one of the four ARC qualifiers as described in the “Properties” section later in the chapter.

Blocks

Blocks are a new C language feature, made available in Objective-C and in iOS starting with version 4.0. Since then, Apple has added support for blocks in significant portions of the iOS SDK. Blocks are anonymous functions, which can accept parameters and return a value, and are able to capture the state of the runtime when they are executed. In addition, blocks are actually Objective-C objects, so they can be passed around as parameters; can be stored in Foundation arrays, dictionaries, and sets; and can take advantage of manual memory management or ARC. Last but not least, blocks can modify objects in the same lexical scope. All that adds up to the capability for blocks to make previously cumbersome programming patterns simple and readable.

In practice, blocks are widely used to replace delegates and completion handlers. Rather than setting up a property for a delegate, adding a protocol definition, implementing delegate methods, and devising methods to pass state variables to the delegate methods, you can implement delegate logic in a block.

Declaring and Using Blocks

One method of using blocks is to create a block variable, which can be assigned a block and then executed inline in code. A block variable declaration can have a name, can declare parameter types, and can optionally declare a return type (the compiler can infer the return type, but it is good coding form to declare it).

NSString* (^repeatString) (int, NSString*);

In this case, NSString* at the left of the line of code declares the return type. In parentheses, after the caret symbol (^), repeatString is the name of the declared block. The second set of parentheses declares that two parameters are required for the block, first an int and second anNSString*. After these are declared, the block can be assigned using a block literal, indicated by the caret symbol.

repeatString = ^NSString* (int numTimes, NSString *repeat)
{
NSMutableString *retString = [[NSMutableString alloc] init];

for (int i=0; i<numTimes; i++)
{
[retString appendString:repeat];
}
return [NSString stringWithString:retString];
};

The block literal requires restating the return type after the caret symbol, and then naming the parameters that must match the declaration. The block code is specified between brackets, and a semicolon after the final bracket indicates that the assignment of the block variable is complete. After the block variable is assigned, it can be used in code just like a function.

NSString *repeatTest = repeatString(5,@"Test ");

NSLog(@"The result is: %@",repeatTest);

This will log the following result:

The result is: Test Test Test Test Test

Block definitions can also be established using a typedef for simplicity and clarity:

typedefvoid (^MyCompletionBlock)(id result, NSError *error);

After a block has a type definition, it can be used to create a block variable or in method declarations.

Capturing State with Blocks

When assigning a block literal, variables from the current lexical scope can be used in the block. An important characteristic of this use is that, by default, the value of those variables is “captured” or locked to the value at the time when the block is assigned. Even if the value of that variable is changed before the block is executed, the value at the time of assignment is what is used in the block execution. This example modifies the previous example to use an NSString* from the enclosing scope in the block, rather than a parameter.

NSString *blockTestString = @"Block Test ";

NSString *(^repeatString) (int);

repeatString = ^NSString* (int numTimes)
{
NSMutableString *retString = [[NSMutableStringalloc] init];

for (int i=0; i<numTimes; i++)
{
[retString appendString:blockTestString];
}
return retString;
};

blockTestString = @"Block Test Change";

NSString *repeatTest = repeatString(5);

NSLog(@"The result is: %@",repeatTest);

This approach will log the following:

The result is: Block Test Block Test Block Test Block Test Block Test

If the block needs to be able to use the updated value of the variable, or needs to update the variable directly, that variable can be declared with the __block modifier to indicate that blocks should access the variable directly rather than capturing its value at the time of block assignment. To modify the previous example to demonstrate the block using the current value of a variable from the enclosing scope, and the block updating that variable, first the variable is declared with the __block modifier.

__block NSString *blockTestString = @"Block Test ";

Then the block is modified to be return type void, and the block literal is changed to update the variable directly rather than return a value.

void (^repeatString) (int);

repeatString = ^ (int numTimes)
{
NSMutableString *retString = [[NSMutableString alloc] init];

for (int i=0; i<numTimes; i++)
{
[retString appendString:blockTestString];
}
blockTestString = retString;
};

After the block is defined and assigned, the blockTestString variable is changed, and then the block is executed.

blockTestString = @"Block Test Change ";

repeatString(5);

NSLog(@"The result is: %@",blockTestString);

This logs the following result, indicating that the blockTestString variable was used with the most recent value before the block was executed, and that the blockTestString string was changed by the block:

The result is: Block Test Change Block Test Change Block Test Change
Block Test Change Block Test Change

Having both approaches available gives the developer a great deal of flexibility in using blocks to achieve desired results.

Using Blocks as Method Parameters

Another method of using blocks is to use them as method parameters. A common use case for this is a completion handler for a long-running or asynchronous task. To use a block as a completion handler, first a method must be declared with a completion block as a parameter.

- (void)longRunningTaskWithCompletionHandler:
(void(^)(void))completionBlock
{
...
if (completionBlock) {
completionBlock();
}
}

The syntax might look a bit awkward, but the method declares that it should receive a block with no parameters and no return type as a parameter. When the method has completed, it will execute the passed-in completion block. This allows the caller to avoid having to set up separate delegate methods to handle the completion logic, and thus the caller can specify the starting and completion logic all in one place, making it easy to read and check.

[self.submitButton setEnabled:NO];
[self.progressIndicator setHidden:NO];
[self.progressIndicator startAnimating];

ICFViewController* __weak weakSelf = self;

[selflongRunningTaskWithCompletionHandler:^{
[weakSelf.submitButton setEnabled:YES];
[weakSelf.progressIndicator stopAnimating];
[weakSelf.progressIndicator setHidden:YES];
}];

In this example, a UIButton called submitButton and a UIActivityIndicatorView called progressIndicator have been set up as properties (described in the next section) in the class. When the Submit button is tapped, a method will disable the button to prevent additional submissions while the long-running task is running. The method will display the progressIndicator and start animation, and then call the long-running task. The completion handler block is assigned directly in the method call to the long-running task as a parameter, so all the completion logic is visible right where the long-running task method call is made. The completion logic will reenable the submitButton and hide the progressIndicator. Although this example is trivial, it should be evident that this pattern can be very useful in common situations, especially when handling error conditions locally.