One such change came out of their trying to adhere to their own naming conventions of methods. The second kind of late polishing is if there are new structures introduced without a matching Make macro for easy filling of said structures. I have an example for you, also in CoreLocation.

In this post I’m exploring two such changes and tell you how I dealt with them in a backwards compatible way.

A New Make Function

CoreLocation has a structure CLLocationCoordinate2D which contains latitude and longitude in decimal degrees of any coordinate on Earth. Before 4.0 was introduced I figured that it would be handy to have a CLLocationCoordinate2DMake to go with it, just like you have CGRectMake to create and fill a CGRect.

Turns out, Apple thought so too, and because I guessed the naming convention correctly they introduced this exact method in 4.0 causing my Xcode to complain like this, if I expanded the build results.

In file included from ../DTFloatingIconView.m:9:
../DTFloatingIconView.h:42: error: static declaration of 'CLLocationCoordinate2DMake' follows non-static declaration
/Developer_Stable/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.0.sdk/System/Library/Frameworks/CoreLocation.framework/Headers/CLLocation.h:125: error: previous declaration of 'CLLocationCoordinate2DMake' was here

In the code itself you could only see the first line, but the enlightening detail is found right underneath it. There’s obvious now a “previous declaration” of my helper function. It’s previous to my definition, because it’s in a header and headers precede your code always. And indeed if we have a look at CLLocation.h, there it is. Clearly marked as not available on Mac and available on iOS as of 4.0:

/*
 *  CLLocationCoordinate2DMake:
 *
 *  Discussion:
 *    Returns a new CLLocationCoordinate2D at the given latitude and longitude
 */
CLLocationCoordinate2D CLLocationCoordinate2DMake(CLLocationDegrees latitude, CLLocationDegrees longitude) __OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_4_0);

The question in this case was how I could modify my definition such that I could build with 4.0, targeting 3.0 and above and get no warnings, errors or crashes. Here’s how:

#if __IPHONE_OS_VERSION_MAX_ALLOWED < __IPHONE_4_0
// this method was introduced in SDK 4.0
static inline CLLocationCoordinate2D CLLocationCoordinate2DMake(CLLocationDegrees latitude, CLLocationDegrees longitude)
{ 
	CLLocationCoordinate2D coord;
	coord.latitude = latitude;
	coord.longitude = longitude;
	return coord;
}
#endif

By using the preprocessor macro __IPHONE_OS_VERSION_MAX_ALLOWED I can check the used SDK version and if it is below 4.0 I define it. Marking it as static inline means that this is built into the binary not as function call, but this code is actually inserted into the calling method as if it were local code.

This way I have a function to satisfy the compiler regardless whether I’m building with SDK 3.x or 4.x. The reason for doing so is that I’m using this in DTAugmentedRealityController where I don’t want to force my customers to build with a specific SDK. So that’s how I implemented it in version 1.1 of the component.

BUT, thinking about it, there’s a problem when building this code with SDK 4.0 which happily compiles it and omits the new function. But what happens if this runs on a 3.x device? A crash with an unrecognized selector. In debugger you’d get something like this:

dyld: lazy symbol binding failed: Symbol not found: _CLLocationCoordinate2DMake
  Referenced from: /var/mobile/Applications/0E8F890C-F78A-4092-99A5-9466AF298D60/test.app/test
  Expected in: /System/Library/Frameworks/CoreLocation.framework/CoreLocation

So how do we make it backwards compatible?

The easiest way I could think of is somewhat brutal, because it involves basically redirecting all calls to my own function. But looking on the bright side, by making it an inline function we actually gain a few nanoseconds by not having to have the function call overhead.

static inline CLLocationCoordinate2D CLLocationCoordinate2DInlineMake(CLLocationDegrees latitude, CLLocationDegrees longitude)
{ 
	CLLocationCoordinate2D coord;
	coord.latitude = latitude;
	coord.longitude = longitude;
	return coord;
}
 
#define CLLocationCoordinate2DMake CLLocationCoordinate2DInlineMake

This replaces all CLLocationCoordinate2DMake in your code with CLLocationCoordinate2DInlineMake which is an inline function we define regardless of the used SDK or running OS.

It’s a nasty workaround, but at least it does not cause a crash. And we can keep on using the CLLocationCoordinate2DMake function name. That’s some consolidation until we can drop 3.x support later this year.

Renamed Function

In 3.2 the method of CLLocation getDistanceFrom got renamed to distanceFromLocation. You might wonder why. Simple explanation really, Apple reserves the prefix get for methods that are using one or more of their parameters to return a value in addition to the regular return value. This is generally achieved by passing a pointer (= memory address) to the method which the method then can follow and modify the referenced piece of RAM.

Consider for example the method – (void)getValue:(void *)buffer of NSValue where the value of NSValue will be copied into the memory pointed to by “buffer”. There are very few such methods on the higher level APIs. Many more can be found on the Core Foundation level.

The naming convention seems to go that the first part of the method name tells you what is being returned, namely a distance and the last part before the first colon should tell what this parameter actually is. A name that at the same time tells it’s function. So they could have called it distanceThatWillBeCalculatedByAVeryComplicatedFormulaAndSoWeNeedASecondParameterThatIsALocation:, as long as the first and the last item in this camel-cased name. The second rule though is to non unnecessarily prolong method names if it’s possible to get by with 3 or 4 words. A distance from a location, distanceFromLocation. A sorted array by using a selector, sortedArrayUsingSelector.

There are a few such methods in the SDKs that snuck in under the radar of the Naming Convention Adherence Subcommittee at Apple HQ, so they chose to make the switch when introducing 3.2 because at this time that was the first iOS version running on the iPad and thus this change would not cause any problems there. I betcha there was somebody having sleepless nights over this until 3.2 was released in the form of the iPad. Now he can rest in peace.

But to bring balance to the force, somebody being able to rest means that somebody has extra work, we.  Because if we want to keep our code working and warning-free then we have to work around this change.

Since we will be using the latest SDK version for building the new method is valid and the old one is causing a deprecation warning. BUT because we want this code to work on previous iOS versions we cannot exclusively use the distanceFromLocation method, because this would cause an “unrecognized selector” exception (read “crash”) if somebody is running our app on iOS 3.1.x.

Usually you can work around this by using performSelector after having checked that the instance of the receiver responds to it. But in this case there’s a problem: we have a return value that we need to get hold of. I found some workarounds on the Internet that would hack and typecast around. But these methods upset my stomach, so I chose to go for the following method.

- (CLLocationDistance)distanceBetweenLocation:(CLLocation *)location1 andLocation:(CLLocation *)location2
{
	if ([location1 respondsToSelector:@selector(distanceFromLocation:)])
	{
		return [location1 distanceFromLocation:location2];
	}
 
	SEL sel = @selector(getDistanceFrom:);
	if ([location1 respondsToSelector:sel])
	{
		NSMethodSignature *mySignature = [CLLocation instanceMethodSignatureForSelector:sel];
		NSInvocation *myInvocation = [NSInvocation invocationWithMethodSignature:mySignature];
		[myInvocation setArgument:&location2 atIndex:2];
		[myInvocation setTarget:location1];
		[myInvocation setSelector:sel];
		[myInvocation invoke];
 
		CLLocationDistance distance;
		[myInvocation getReturnValue:&distance];
 
		return distance;
	}
 
	// should never get here
	return 0;
}

Of course this could have been made as a category extension, but I chose not to because I didn’t want to have to name it distanceBackwardsCompatibleWith3xFromLocation. Reason being, that if you name a category extension method the same as an existing one you overwrite it and there’s no way (similar to super) to call the original method.

Let me explain the above code.

First location1 is asked if it knows distanceFromLocation, if YES, then this is called and we’re done.
Then I’m creating a variable of type SEL to hold the signature (read “selector”) of the pre 3.2 method.
At this point I could assume that this has to be present here, but just to be safe I’m asking again.
Then I’m building an NSInvocation for this signature and setting as target location1.
I’m executing the method by calling invoke.
Then I’m creating a local variable which essentially prompts the compiler to reserve sufficient memory for it.
Finally I’m retrieving the return value of the invocation.

Do you remember what I said about methods prefixed with “get”? That’s another example: it takes a pointer (which we get by the address operator &) to point to the memory it is allowed to modify. Of course it’s your responsibility to have sufficient memory space allocated. We know that this method will return a CLLocationDistance (which is really just a double) I can take the above shown shortcut. Otherwise I’d have to inquire about the size of the return value. Possible, but unnecessary if you know the type.

Conclusion

Regardless if it’s a new convenience function/method or a renaming, as a developer you have to start thinking on several levels at the same time:

1) which methods and functions does my building SDK know about
2) which methods and functions does the executing iOS version know about

Of course you could keep ignoring deprecation warnings, or even go as far as keeping building against an outdated SDK. But your customers expect from you to offer them features that only became available in 4.0. At the same time you still want to get the money from the 3.x crowd.

It boils down to the necessity of having a 3.1 device next to your development Mac just so you can test the backwards compatibility.

So you have to create the compatibility methods, because Apple does not care about backwards compatibility. It’s in their interest that customers update as soon as possible because this decreases the possibility of jailbreaks.

Fun Fact: NSMakeRange still does not comply with Apple’s naming conventions (should be called NSRangeMake instead) and they HATE that.

Fortunately there is a great sample on the Apple Website that you might have heard it’s name mentioned in many circles: Reachability. The first version of this was difficult to use but Apple staff keeps polishing their works and so we have reached version 2.2 already, recently updated for iOS 4. The major change that 2.x gave us is the ability to get continuous updates on connection availability. This enables us to have our apps work similar to the iTunes app which displays a message to this effect when there’s no connection and has the UI return as soon as the connection is back.

So, let’s explore how to add the source for Reachability to our project and have some live checks.

First you need to download the latest version of the sample source from the developer website. Here’s the direct link. Click on the “Download Sample Code” button to retrieve the ZIP file.

If you open the sample project you might get “Base SDK missing” if you’re using the latest Xcode and SDK beta. Just switch it to one that you have, by going Project – Edit Project Settings – Base SDK. I use 4.1 at the time of this writing.

From the sample project you need Reachability.h and .m, copy them over to your project. The Reachability class actually wraps up functionality available in the SystemConfiguration.framework and so you need to add a reference to that as well.

There are two ways how you can make use of the Reachability class. The synchronous mode lets you query for the current state, the asynchronous mode sends notifications. Usually you’d want a hybrid solution, because you want a view to look correct for the current network state when it appears as well as react to subsequent changes in reachability. Every instance of Reachability is initialized with a host name that you want to be able to reach.

You can have several running at the same time if your app requires connectivity to seperate hosts. It’s up to you to decide how likely the second host will not be reachable if the first one isn’t. Reachability tests if the host name can be resolved and if there is a TCP/IP path that allows to reach the host. It does not check for the availability of certain web pages. So in all likelyhood you get by with just a single Reachability instance. That’s because not reaching one host usually means that the iPhone does not have internet connectivity.

Here’s the code to demonstrate the use within a view controller:

- (void)configureForNetworkStatus:(NetworkStatus)status
{
	// do something with status
	switch (status) 
	{
		case NotReachable:
			NSLog(@"Not Reachable");
			break;
		case ReachableViaWiFi:
			NSLog(@"Reachable via WiFi");
			break;
		case ReachableViaWWAN:
			NSLog(@"Reachable via WWAN");
			break;
		default:
			break;
	}
}
 
- (void)awakeFromNib
{
	// subscribe to notification
	[[NSNotificationCenter defaultCenter] addObserver: self 
		selector: @selector(reachabilityChanged:) 
		name: kReachabilityChangedNotification object: nil];
 
	// init one watcher, instance variable
	siteReachability = [[Reachability reachabilityWithHostName:@"www.apple.com"]
		 retain];
 
	// get first status
	NetworkStatus siteNetworkStatus = [siteReachability currentReachabilityStatus];
 
	// do something with it
	[self configureForNetworkStatus:siteNetworkStatus];
 
	// start continous updates
	[siteReachability startNotifier];
}
 
- (void)dealloc 
{
	[[NSNotificationCenter defaultCenter] removeObserver:self];
	[siteReachability release];  // also stops notifier
    [super dealloc];
}
 
- (void) reachabilityChanged: (NSNotification* )note
{
	// get Reachability instance from notification
	Reachability* curReach = [note object];
 
	// assert that we actually got Reachability instance
	NSParameterAssert([curReach isKindOfClass: [Reachability class]]);
 
	// get current status
	NetworkStatus siteNetworkStatus = [curReach currentReachabilityStatus];
 
	// do something with it
	[self configureForNetworkStatus:siteNetworkStatus];
}

In this sample I’m initializing everything in the awakeFromNib because I’m getting my view controller from a XIB file.

The code shows how to query a fresh instance for the current status. Then it starts the notifier which will send an NSNotification as soon as the connectivity state changes. As you can see there are three different values to NetworkStatus: no connection at all, site reachable via WiFi, site reachable via WWAN (= cellular data). So you could react differently if you know a big pipe is available as opposed to cellular where people might have limited bandwidth or volume.

Checking for reachability of a specific host is the most practical use case of Reachability. In much rarer cases you might want to check for availability of local WiFi or the internet in general (if you don’t need to access a specific host). Specialized initializers are available for these cases, check the header if you need these.

Enabling your apps for reachability checking is easier than ever. The most difficult part now is to design a nice screen, message or graphic to tell the user that he has to wait until he’s out of the tunnel.

First the “old way”. It needs to customize touch handling for the tableview cells themselves, which means you have to subclass UITableViewCell.

TouchAndHoldCell.h

#import <UIKit/UIKit.h>
 
@class TouchAndHoldCell;
 
@protocol TouchAndHoldCellDelegate <NSObject>
@optional 
- (void)didTouchAndHoldForCell:(TouchAndHoldCell *)cell;
@end
 
@interface TouchAndHoldCell : UITableViewCell 
{
	id <TouchAndHoldCellDelegate> delegate;
}
 
@property (nonatomic, assign) id <TouchAndHoldCellDelegate> delegate;
@end

TouchAndHoldCell.m

#import "TouchAndHoldCell.h"
 
 
@implementation TouchAndHoldCell
 
@synthesize delegate;
 
- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier 
{
    if (self = [super initWithStyle:style reuseIdentifier:reuseIdentifier]) {
        // Initialization code
    }
    return self;
}
 
- (void)touchAndHold:(NSDictionary *)params
{
	NSSet *touches = [params objectForKey:@"touches"];
	UIEvent *event = [params objectForKey:@"event"];
	[super touchesCancelled:touches withEvent:event];
 
	if (delegate && [delegate respondsToSelector:@selector(didTouchAndHoldForCell:)])
	{
		[delegate didTouchAndHoldForCell:self];
	}
}
 
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
	// 1 second holding triggers touchAndHOld
	[self performSelector:@selector(touchAndHold:) withObject:
		[NSDictionary dictionaryWithObjectsAndKeys:touches, @"touches", event, @"event", nil] afterDelay:0.5];
	[super touchesBegan:touches withEvent:event];
}
 
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
	[NSObject cancelPreviousPerformRequestsWithTarget:self];	
	[super touchesMoved:touches withEvent:event];
}
 
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
	[NSObject cancelPreviousPerformRequestsWithTarget:self];	
	[super touchesEnded:touches withEvent:event];
}
 
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
	[NSObject cancelPreviousPerformRequestsWithTarget:self];	
	[super touchesCancelled:touches withEvent:event];
}

This works by calling a selector with half a second delay. If the finger is lifted before this expires the delayed call is cancelled. If it does get to expire then we have a long press and thus the cell can tell it’s delegate (the tableview controller) that a long press (that’s how Apple calls it) transpired.

To use this you would override the cellForRowAtIndexPath method and provide a method to react to the long press.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
    static NSString *CellIdentifier = @"Cell";
 
    TouchAndHoldCell *cell = (TouchAndHoldCell *)[tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[TouchAndHoldCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
		cell.delegate = self;
    }
 
	// Configure the cell.
	cell.textLabel.text = @"Text";
    return cell;
}
 
 
#pragma mark TouchAndHoldCell Delegate
- (void)didTouchAndHoldForCell:(TouchAndHoldCell *)cell
{
	UIActionSheet *action = [[UIActionSheet alloc] initWithTitle:@"Actions" delegate:self cancelButtonTitle:@"Cancel" destructiveButtonTitle:@"Destruct" otherButtonTitles:nil];
	[action showInView:self.view];
	[action release];
}
 
- (void)actionSheet:(UIActionSheet *)actionSheet didDismissWithButtonIndex:(NSInteger)buttonIndex
{
	if (buttonIndex==0)
	{
		NSLog(@"Destruct");
	}
	else
	{
		NSLog(@"Cancel");
	}
}

That’s the historic evidence of past ingenuity. Next we’re going to examine how that’s done today. Easier, faster, more Apple if you will.

iOS and SDK 3.2 gave us one of the most ingenious things that Apple could ever invent. For two years we had to code all our touch handling ourselves which resulted in a variety of different approaches, all with a different feel to them. Gesture Recognizers changed all that, 3.2 brought them first to the iPad and they are also part of iOS 4.x. Unfortunately they are not backwards compatible.

All it takes is to create such a gesture recognizer instance and attach it to the appropriate view.

- (UITableViewCell *)tableView:(UITableView *)tableView 
            cellForRowAtIndexPath:(NSIndexPath *)indexPath 
{
    static NSString *CellIdentifier = @"Cell";
 
 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) 
	{
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault 
		reuseIdentifier:CellIdentifier] autorelease];
 
		UILongPressGestureRecognizer *longPressGesture = 
			[[[UILongPressGestureRecognizer alloc] 
			  initWithTarget:self action:@selector(longPress:)] autorelease];
		[cell addGestureRecognizer:longPressGesture];
    }
 
	// Configure the cell.
	cell.textLabel.text = @"Text";
    return cell;
}
 
- (void)longPress:(UILongPressGestureRecognizer *)gesture
{
	// only when gesture was recognized, not when ended
	if (gesture.state == UIGestureRecognizerStateBegan)
	{
		// get affected cell
		UITableViewCell *cell = (UITableViewCell *)[gesture view];
 
		// get indexPath of cell
		NSIndexPath *indexPath = [self.tableView indexPathForCell:cell];
 
		// do something with this action
		NSLog(@"Long-pressed cell at row %d", indexPath);
	}
}

Gesture Recognizers employ the same methodology as we have seen before for adding target/actions to UIControls, for example UIButtons. The target is the instance of a class to receive the message, the action is the selector. And the parameter that’s being passed is the sender of the message. For UIControl events that’s the sending view, for UIGestureRecognizer events it’s the instance of the gesture recognizer you have set up.

In the above example we simply create a UILongPressGestureRecognizer (which has the appropriate expiration time interval already built in) and attach it to each cell we create. If the tableview is long enough so that we get to recycle cells it would still work, because we don’t care which cell a recognizer is attached to, as long as there is one for each cell you can tap on, recycled or new.

In the longPress: method we can query the tableView for the “line” we tapped on. For a while I was setting the cell’s tag value to the number of the row, but I found that this ceases to work if you allow for deletion of rows, because then the indexes you put into the tags have incorrect values. Better to ask the tableView itself at time of the pushing via the conveneient indexPathForCell method.

Also note that this method is being called twice, namely when the gesture is recognized (when the finger was on the cell long enough) and when it’s ended (when you lift the finger). Usually you’ll want to only react when it’s started.

You see, that gesture recognizers really reduce the amount of code we need to write to achieve some advanced touch handling.

So it pays to know about all the nifty utilities that Apple provides for you to make your life easier.

Creating Rectangles

For most structures that you will encounter in Apple’s SDKs you will also find a corresponding macro to create such a structure on the fly and in the same line fill it with values. Usually those macros are set up for you as a preprocessor define and are named like the structure they are creating plus suffice Make.

// create a rectangle
CGRect newRectangle = CGRectMake(0, 0, 100, 200);

Actually CGRect consists of two sub-structures, a CGPoint for the (usually) upper left origin as well as a CGSize for the width and height. But CGRectMake takes care of filling these accordingly, the first two parameters go into the origin (x,y) and the latter two parameters end up in size (width, weight). Even though it looks like a C-function it’s actually not. Due to being configured as preprocessor macro there is no C-function generated at compile time, but actually the commands to fill the structure are copied into your code so you don’t incur an overhead for pushing the parameters onto the stack and function calling.

Shrinking, Expanding, Edge Insetting

If you need to shrink a CGRect by a certain value horizontally and vertically you could do so by modifying the structure members themselves. But way more elegant is to use the provided convenient macro CGRectInset. Positive values will decrease the size evenly for the new rectangle to be centered in the old one. Negative values by the same token will increase it.

CGRect aRectangle = CGRectMake(0,0, 100, 200);
CGRect smallerRectangle = CGRectInset(aRectangle, 10, 20);
// result origin (10, 20) and size (80, 160)

This method is fine for 80% of use cases, but sometimes you want to apply different insets for each edge. Imagine, if you will that you want, to have a property contentInsets that would specify the distance a view content should have from each border. The structure of choice for this is UIEdgeInsets(top, left, bottom, right), and of course, there is also a matching Make macro available.

Once you have both you can easily apply the insets to your rect to receive the finally content rectangle. The macro for this purpose is UIEdgeInsetsInsetRect, would you have guessed?

CGRect rect = CGRectMake(0, 0, 100, 200);
UIEdgeInsets contentInsets = UIEdgeInsetsMake(10, 20, 30, 40);
 
CGRect result = UIEdgeInsetsInsetRect(rect, contentInsets);
NSLog(@"x: %f, y: %f, width: %f, height: %f", 
		result.origin.x, result.origin.y, 
		result.size.width, result.size.height);
// x: 20.000000, y: 10.000000, width: 40.000000, height: 160.000000

Actually the above NSLog is how I have been inspecting CGRect for the past 2 years. Right after I published the first version of this blog post I was pointed out to me that there is an even more elegant method: NSStringFromCGRect. Wow, a third as much key strokes.

NSLog(@"%@", NSStringFromCGRect(result)); 
// {{20, 10}, {40, 160}}

Wway more elegant, I’m sure you’ll agree? (Thanks Matt and Thomas But that’s the point of making these write ups. You learn a bit from writing them and you learn a bit more when other pros tell you the mistakes you made.

Interesting Intersecting

Another thing that you might want to do often with as little code as possible is to check whether a point is inside a rectangle or whether two rectangle are intersecting each other. Did you hit the rectangle? Did your avatar rectangle intersect with the mine rectangle? Boom!

// enemy hit?
CGRect enemyRect = CGRectMake(0, 0, 100, 200);
CGPoint hitPoint = CGPointMake(50, 50);
 
if (CGRectContainsPoint(enemyRect, hitPoint))
{
	// YES!
}
 
// landmine touched?
CGRect playerRect = CCRectMake(200, 300, 10, 10);
CGRect mineRect = CGRectMake(10, 10, 20, 20);
 
if (CGRectIntersectsRect(playerRect, mineRect))
{
	// OUCH!
}

Doing it like this as opposed to complicated if statements makes your game engine code read almost like plain English. Further similar macros are defined in CGGeometry.h which you can easily look at by CMD+Doubleclicking on such a CGRect macro.

On the WWDC videos I remember seeing the use of for the 4 macros to get the maximum and/or minimum values for the coordinates. CGRectGetMaxX, CGRectGetMinX, CGRectGetMaxY, CGRectMinY can save you from writing more code than is necessary.

Dictionary Representation

Often you might have to store a CGRect in a plist on disk, but you don’t have to create the dictionary in a difficult fashion. CGRect, being at the same level as Core Foundation has a function to create a CFDictionary for it’s current contents.

CFDictionaryRef frameDictRef = CGRectCreateDictionaryRepresentation(self.view.frame);
NSDictionary *frameDict = [NSDictionary dictionaryWithDictionary:
							   (NSDictionary *)frameDictRef]; // autoreleased
CFRelease(frameDictRef);
 
NSLog(@"%@", frameDict);

You can directly treat the CFDictionary you get back as NSDictionary, but I recommend that you create a new autoreleased instance instead and properly release the CFDictionaryRef. CoreFoundation objects don’t have an autorelease, that’s why we have to do it this way to not have a leak.

 {
    Height = 1004;
    Width = 768;
    X = 0;
    Y = 20;
}

The reverse is way easier because we don’t have to create something to release afterwards. Just define a CGRect to take up the decoded values and provide the address to it to a function.

CGRect rect;
CGRectMakeWithDictionaryRepresentation((CFDictionaryRef)frameDict, &rect);

The same works also for CGPoint and CGSize by the way, but then you naturally get X+Y or Width+Height into your dictionary.

Storing it in Obj-C Storage Classes

One more thing I had forgotten about mentioning which comes into play if you are already thinking like an object oriented pro. CGRect are structures, not objects. So you would naturally be out of luck if you wanted to save them in storage classes like NSArray, NSSet or NSDictionary.

How very nice of Apple to provide some class methods in UIGeometry.h that let us wrap all those structures into handy NSObjects.

NSMutableArray *tmpArray = [NSMutableArray array];
[tmpArray addObject:[NSValue valueWithCGRect:rect]];
[tmpArray addObject:[NSValue valueWithCGRect:result]];
 
NSLog(@"%@", tmpArray);

Similar methods are available for points, sizes, transforms and edge insets.

Conclusion

You see that a great deal if thinking went into all these convenience methods on our behalf. So that we won’t have to. This makes working with and manipulating structures that you encounter in your daily Cocoa life a breeze and they should be second nature. So don’t just store them in your tool chest, but use them sub-consciously. The amount of code you save will take your breath away.

The Old Way

Consider the following snipped just to get a similar nausea so that you can appreciate what I am going to show you afterwards. That’s from a random switch in cellForRowAtIndexPath.

NSString *CellIdentifier = @"ServerSectionSwitch";
 
SwitchCell *cell = (SwitchCell *)[tableView dequeueReusableCellWithIdentifier:
		CellIdentifier];
if (cell == nil) 
{
	cell = [[[SwitchCell alloc] initWithFrame:CGRectZero reuseIdentifier:
		CellIdentifier] autorelease];
}
 
cell.titleLabel.text = @"Enable on WLAN";
ASiSTAppDelegate *appDelegate = (ASiSTAppDelegate *)[[UIApplication sharedApplication] 
		delegate];
 
cell.switchCtl.on = appDelegate.serverIsRunning;
[cell.switchCtl addTarget:appDelegate action:@selector(startStopServer:) 
			forControlEvents:UIControlEventValueChanged];
return cell;

So obviously I had created a custom tableview cell, so let’s glance at that as well.

SwitchCell.h

#import <UIKit/UIKit.h>
 
 
@interface SwitchCell : UITableViewCell {
	UISwitch *switchCtl;
	UILabel *titleLabel;
 
}
 
@property (nonatomic, retain) UILabel *titleLabel;
@property (nonatomic, retain) UISwitch *switchCtl;
 
@end

SwitchCell.m

#import <UIKit/UIKit.h>
 
 
@interface SwitchCell : UITableViewCell {
	UISwitch *switchCtl;
	UILabel *titleLabel;
 
}
 
@property (nonatomic, retain) UILabel *titleLabel;
@property (nonatomic, retain) UISwitch *switchCtl;
 
@end
 
#import "SwitchCell.h"
 
#define MAIN_FONT_SIZE 16.0
#define LEFT_COLUMN_OFFSET 10.0
 
@implementation SwitchCell
 
@synthesize switchCtl, titleLabel;
 
- (id)initWithFrame:(CGRect)frame reuseIdentifier:(NSString *)reuseIdentifier {
    if (self = TABLEVIEWCELL_PLAIN_INIT) {
        // Initialization code
		self.selectionStyle = UITableViewCellSelectionStyleNone;
 
		// layoutSubViews will decide the final frame
		titleLabel = [[UILabel alloc] initWithFrame:CGRectZero];	
		titleLabel.baselineAdjustment = UIBaselineAdjustmentAlignCenters;
		titleLabel.font = [UIFont boldSystemFontOfSize:MAIN_FONT_SIZE];
		[self.contentView addSubview:titleLabel];
 
		switchCtl = [[UISwitch alloc] initWithFrame:CGRectZero];
		[self.contentView addSubview:switchCtl];
    }
    return self;
}
 
 
- (void)setSelected:(BOOL)selected animated:(BOOL)animated {
 
    [super setSelected:selected animated:animated];
 
    // Configure the view for the selected state
}
 
- (void)layoutSubviews
{
	[super layoutSubviews];
    CGRect contentRect = [self.contentView bounds];
 
	NSString *text = titleLabel.text;
	CGSize sizeNecessary = [text sizeWithFont:[UIFont systemFontOfSize:
		MAIN_FONT_SIZE]];
 
    CGRect frame = CGRectMake(contentRect.origin.x + LEFT_COLUMN_OFFSET , 
		contentRect.origin.y,  sizeNecessary.width+20.0,  contentRect.size.height);
	titleLabel.frame = frame;
 
	frame = CGRectMake(contentRect.origin.x + contentRect.size.width - 91.0 -
		 LEFT_COLUMN_OFFSET,contentRect.origin.y+
				(contentRect.size.height-27.0)/2.0, 
					   94.0, 27.0);
	switchCtl.frame = frame;
}
 
- (void)dealloc 
{
	[titleLabel release];
	[switchCtl release];
    [super dealloc];
}
 
@end

Ok, you feel my sickness over this code? Let me explain, these are the reasons why this is crappy coding.

• It’s completely unnecessary to make a subclass for UITableViewCell just to add a subview, in this case a UISwitch. This adds so much extra code that it’s ridiculous. Unmaintainable. Manual. Laughable.
• You’ll laugh out loud (LOL) when you see how I am doing it today and how much less code is necessary. this code completely ignores the cell’s accessoryView and instead builds it’s own view hierarchy.
• Wasn’t it SDK 2.1 when we sitched from initWithFrame to initWithStyle?
• Obviously I did not know about NSUserDefaults back then, because why else would I save user settings in a “global” variable in my app delegate?
• Apart from that, I’m calling an action in a different class, makes it harder to understand for other programmers

But hey, as I said this code is from about 2 years ago. Thankfully I know now better and here I’m going to share my wisdom. Buckle up!

The Warp-Speed Way

First and foremost I don’t need this extra class any more, because we’re going to do it using a method that takes care of sizing and positioning of the switch for us automatically.

NSString *CellIdentifier = @"ReportSection3";   UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier]; UISwitch *switcher; if (cell == nil) { cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease]; switcher = [[[UISwitch alloc] initWithFrame:CGRectZero] autorelease]; [switcher addTarget:self action:@selector(toggleSumOnOverview:) forControlEvents:UIControlEventValueChanged]; cell.accessoryView = switcher; } else { switcher = (UISwitch *)cell.accessoryView; }   // make it multiline cell.textLabel.text = @"Fetch royalty sum and\nshow it on overview (slow)"; cell.textLabel.numberOfLines = 0; cell.textLabel.font = [UIFont boldSystemFontOfSize:13]; cell.textLabel.adjustsFontSizeToFitWidth = YES;   // set from user defaults switcher.on = [[NSUserDefaults standardUserDefaults] boolForKey: @"RoyaltyTotalsOnOverView"]; return cell;

At the top you see the usual dequeueReusableCellWithIdentifier. Because it’s special cell with the switch being an addition we give it a new identifier. In case there isn’t already such a cell we make a new one, create an autoreleased UISwitch and set it as the cell’s accessoryView.

On the other hand if we got back a cell from the dequeue we set our switcher variable to the accessoryView which has to be a UISwitch, because we put it there. Then I did some adjusting of the text label to fit the long text. Finally the current switch status of the switch is equal to a value in our user defaults.

In short we are getting or creating a switch-enabled cell and set the value of the switch. What’s great about this approach is that we don’t have to do anything to position the switch or even find out it’s correct size. All of this is done automatically. UISwitches know their ideal size (sizeThatFits:) and cells know how to position their accessoryView based on it’s size. Actually I am convinced that this is the same method Apple uses for whenever you see a switch or any other accessory for that matter in a tableview cell. Another effect you get for free is that if the cell is put into edit mode any textLabel and detailTextLabel will get resized automatically.

The second step, because we no longer call complicated functions to store a user setting somewhere in the app delegate, just reacts to whenever the switch’s value changes. The user defaults mechanism automatically takes care of persisting the changed value and as I have shown recently you can also easily specify default values for the defaults.

- (void)toggleSumOnOverview:(UISwitch *)switcher { [[NSUserDefaults standardUserDefaults] setBool:switcher.on forKey:@"RoyaltyTotalsOnOverView"]; }

Too simple for you? Well, we still need to react to a change of this user setting. So, in the init of the affected viewController all I need to add is:

// if defaults setting changes [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(reloadTableView:) name:NSUserDefaultsDidChangeNotification object:nil];

This calls a method to reload the contents of its table view whenever any value of the user defaults changes. Of course there needs to be a removeObserver in dealloc as well, but you can imagine this.

Advanced Tactics

I love the way Apple lets the cell monitor the size of the accessoryView and take care of all necessary resizing automatically. One scenario where this is especially useful is if you have a purchase button like DTPurchaseButton that enlarges to the left if you push it. Say, in neutral state, the button is labeled $0.99 and if you push it once this changes to BUY NOW. I said it before and I’ll say it again: the resizing of the textLabel in a tableview cell is done automatically for you!

Take a look at the screenshot below. This has a purchase button as accessoryView in a transparent tableview cell. See how the textLabel automatically decreases its size when the button becomes larger?



This is from a famous Twitter client for which I quite recently implemented In-App Purchasing with my DTShop+DTPurchaseButton killer combo. I will randomly select a winner for a free copy of DTPurchaseButton+DTShop, the easiest way to add IAP to your apps. To enter in the draw, just twitter me the correct answer @dr_touch plus a link to this article before end of July 31st.

]]> http://www.drobnik.com/touch/2010/07/cells-with-switch/feed/ 0 http://www.drobnik.com/touch/2010/07/defaults-for-the-defaults/ http://www.drobnik.com/touch/2010/07/defaults-for-the-defaults/#comments Thu, 15 Jul 2010 10:03:05 +0000 drops http://www.drobnik.com/touch/?p=2841 I previously explained how to use NSUserDefaults to your advantage, basically being the OSX equivalent to the Windows registry. User Defaults are the way how you can persist small amounts of data in a convenient way. They are basically dictionaries that the system takes care of for you with the added benefit of being cached in memory.

Today we’ll up it one notch. Session 124 of the WWDC 2010 videos brought to my attention the fact that there’s also a mechanism to provide default values for the defaults. Up until now I would have retrieved an object from the defaults, checked if it’s nil and then set the value. Consider the following code snipped from SpeakerClock:

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; NSNumber *countdownNum = [defaults objectForKey:@"Countdown"];   if (countdownNum) { countdown = [countdownNum doubleValue]; } else { countdown = self.currentPreset.startDuration; }

This works, but it’s not elegant. Wouldn’t it be great if we could pre-register those values so that a simple retrieval always has a result?

It turns out that there is not just one set of defaults that you can write to and read from. There are multiple sets, Apple calls them “domains”. The one we’ve been using so far is called the Application Domain and it’s written to the Library/Preferences folder in you app sandbox. It’s named like your app bundle identifier with a plist extension. It’s really just a property list dictionary on disk.

Other domains available can be either persistant or volatile. Persistant means that they are saved somewhere whereas volatile means that they are only present in memory during the execution of your app. These are all standard domains and they are searched in this order:

1. NSArgumentDomain (volatile)
2. Application – Identified by the application’s identifier (persistent)
3. NSGlobalDomain (persistent)
4. Languages (Identified by the language names) volatile
5. NSRegistrationDomain volatile

So, we already know the application domain. Languages is set by the system and from these you can get the current UI language. On iPhone all apps are sandboxed, so the global domain is of no use to us. This leaves two potentially useful other domains to explore: the argument domain and the registration domain.

What’s great about this structure is that we don’t have to care about accessing these domains specifically. The applicable value is always searched for us. If it’s not in the application domain, then it’s taken from the registration domain, if present.

Using NSRegistrationDomain

This domain is not written do disk, so you need to fill it with your defaults value every time your app launches. The documentation recommends using the initialize class method which get’s called only once and before a class is accessed the first time. So let’s have those in our application delegate.

+ (void) initialize { // called once before this class is used the first time NSDictionary *defaultsDict = [NSDictionary dictionaryWithObject:@"Touch" forKey:@"Doctor"]; NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; [defaults registerDefaults:defaultsDict]; }   - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];   NSString *readValue = [defaults objectForKey:@"Doctor"]; NSLog(@"default for key 'Doctor' is '%@'", readValue);   // Override point for customization after app launch [window addSubview:viewController.view]; [window makeKeyAndVisible];   return YES; }

Put all default values for your defaults into the dictionary you pass to the registerDefaults. This enables the mechanism to always find a value and you no longer have to use tricks like I did above to check if a value is actually set.

It makes sense to put all your default values into a dictionary plist that you add to your app bundle. Then instead of creating the dictionary in code to pass to registerDefaults you can read your prepared dictionary from disk and use this. This way you can also easily modify the defaults without having to change your code.

Arguments

Something that you probably have less use for on iPhone is the arguments domain because iPhone apps will usually not be called with command line arguments. However if you find yourself leveraging your iPhone app knowledge to create a command line tool in Foundation than that’s the most convenient method to retrieve parameter values.

For testing you can supply program arguments in Xcode via the Executables section. It also works for iPhone apps, and such arguments override registration or application domain settings. So it’s great for debugging a setting there.



The exact same code above now outputs ‘Alban’ which was the specified argument. So you override a default setting just to test something without having to add additional code to your project.

For command line tools this replaces the handling of argc and argv in main and gives saves you from having to parse these. As somebody who’s written a couple of tools let me tell you that this is a big convenience.

Conclusion

Actually all of that is explained in the Introduction to User Defaults document but for me somebody had to find out which parts actually apply to the iPhone platform. I tend to read over parts that sound too technical and make me think that they probably don’t work on iPhone.

Knowing about what I wrote here goes a long way to simplifying how your provide default values in your app, how you can quickly override them for testing and how to get arguments from the command line if you chose to write a tool.

]]> http://www.drobnik.com/touch/2010/07/defaults-for-the-defaults/feed/ 0 http://www.drobnik.com/touch/2010/07/understanding-ios-4-backgrounding-and-delegate-messaging/ http://www.drobnik.com/touch/2010/07/understanding-ios-4-backgrounding-and-delegate-messaging/#comments Sun, 04 Jul 2010 22:05:50 +0000 drops http://www.drobnik.com/touch/?p=2787 UPDATE: Added handleOpenURL to the flow charts. Added UIApplicationExitsOnSuspend. Untangled some lines.

Now that we all are moving our source code gradually to iOS 4 I had to pause and think a bit about where to move which code. A problem that I’m facing frequently when updating a project is that the didFinishLaunching is only called if the app really launches.

That poses a bit of a challenge if you are used to doing things like refreshing images or other files off the internet. An app that is resumed from standby does no longer go through this delegate method. So an app that would always show fresh content upon launch before 4.0 multitasking would no longer load any new content as soon as you build it for 4.0. That’s actually one of the main reasons why I have not yet had time to update MyAppSales to 4.0.

To gain the possibility for “fast app switching” you actually don’t need to do anything. All apps automatically support it because they no longer get terminated if the user pushes the Home button. They get put into a sleep mode while the iPhone still has enough memory for everything else. It’s only if RAM runs out that the OS starts killing apps. There is begins with the ones that have the most memory reserved.

I grabbed the free trial of Omnigraffle and the Non-techie Process Flowchart Stencils by gfraser. Then I researched when all these various delegate methods of UIApplication are being called and drew charts to illustrate the flow.

By inhaling first how it was before multitasking and then upgrading your mental process to backgrounding we can begin to fully appreciate how it all fits together.

The World Before Multitasking

The first thing that I learned from this is that applicationDidBecomeActive: is being called right after application:didFinishLaunchingWithOptions:. So even before 4.0 it would have been smart to put there any kind of code that you want executed whenever the app becomes active, be it after app start or upon rejecting a phone call.



Not shown on this diagram is the situation that your app is eating up all the system memory and ignores both the level 1 and level 2 memory warnings. In that case the OS will also terminate your app without totally unscrupulous.

The mechanism with WillResignActive and DidBecomeActive is sort of the Backgrounding Lite that has always been there. This occurs whenever some other thing is displayed in front of your app. This could be the UI to accept a phone call or something as benign as the synching screen.

Multitasking ON

Adding multitasking to this flow chart makes it about twice as complex. I probably spent an hour trying to fit it all together with no crossing lines. Another thing that I noticed while doing this is that applicationWillResignActive: is the only delegate method that I could not optimize into a single box, because one use is to show that the app has been interrupted, the other is to the path into the background.



An app built with 3.2 will still go through a short background stage where applicationDidEnterBackground: is called. but then it will be terminated as usual. If the same app is built against a 4.x SDK then it will not go straight from background to being terminated. Instead it will stick around and so will be the debugger. As soon as you tap the app icon again or choose it from the app switcher it is first informed that applicationWillEnterForeground and then applicationDidBecomeActive.

An app that is suspended but still in RAM might be terminated by the OS if memory runs low. But after entering the background there is no longer any delegate method being called, instead the app will receive a KILL signal. This occurs also if the user long-presses the app icon in app switcher and then removes the app from there with the removal button.

Accepting a phone call no longer terminates your app but will send it into the appropriate background mode. Within the background box you see two purple states that the app can be in. All apps are suspended in RAM per default. You might want to slim down your memory footprint to make your app a less likely target for killing if the system runs low on memory.

Only apps that actually require background processing continue to be executing. This requirement is either set in info.plist or by telling the OS that you have a task to complete, like for example a file upload.

The following kinds of activities get to run in true multi tasking behind the foreground app with lesser CPU priority.

• playing music: “App plays audio”
• geo location: “App registers for location updates”
• VOIP: “App provides Voice over IP services”

If your app does one of these things then adding the key to info.plist is all it takes. But be aware that as soon as your app stops doing what it stated it would be doing the OS again will send it to sleep, only to be awakend by another gentle tap by the user.

In background mode you’re advised to stop updating the UI. Especially with OpenGL Apple is really strict. If you app as much as touches OpenGL while in background the app gets killed right away.

There are only two scenarios left where your app’s applicationWillTerminate: will actually be called: if it’s build with an SDK of less than version 4.0 or if you chose to opt out of backgrounding by adding the UIApplicationExitsOnSuspend key to your info.plist.

So, let’s ask the question we’ve been doing all this fuss for: Where should you now put your code to initialize, update or save changes? applicationWillTerminate not being called in the majority of cases makes it a rather bad candidate to save user defaults or data.

Looking at the chart I see applicationDidEnterBackground as the ideal candidate delegate method for saving state. This is also the last method to be called before a regular 4.0 app gets put to sleep and before a possible kill.

For updating data from the web the case is not as clear. You would not want to reload every time the user comes back to your app. Possible applicationDidBecomeActive: is a good place, provided that you only reload data if sufficient time has passed to be able to assume that something new is available.

Only the first loading of data can stay in application:didFinishLaunchingWithOptions: since every call  applicationDidBecomeActive: most likely has the data already loaded previously.

Conclusion

Adding fast app switching and multitasking support is quite easy since for the most part you don’t need to do anything. But you WILL have to review the contents of your app delegate methods to see which code has to be moved into one of the other delegate methods now. Clean out applicationWillTerminate: and have a close look at application:didFinishLaunchingWithOptions: to check if you have something in there that needs to be done every time the app becomes active.

These charts come from some experimentation that I did and what I remembered from the WWDC 2010 session videos on multitasking. Potentially there are mistakes or more surprises hidden in there. Please let me know if you find any.

Here’s the chart in PDF format in case you want to print it out and frame it.

]]> http://www.drobnik.com/touch/2010/07/understanding-ios-4-backgrounding-and-delegate-messaging/feed/ 20 http://www.drobnik.com/touch/2010/07/the-3-2-hurdle-of-mpmovieplayercontroller/ http://www.drobnik.com/touch/2010/07/the-3-2-hurdle-of-mpmovieplayercontroller/#comments Sun, 04 Jul 2010 14:20:05 +0000 drops http://www.drobnik.com/touch/?p=2783 Prior to iOS 3.2 your only option for playing videos on iPhone was to use MPMoviePlayerController and only in full screen mode. It made sense because who really wants to look at stamp sized videos on his mobile phone.

The iPad changed all that and brought along several changes in how you can place videos. All those changes also made it into the iPhone SDKs. Here’s a pitfall that you might not have seen if you didn’t upgrade the SDK on one of your iPhone projects.



I had an app that played videos like this:

movieController = [[MPMoviePlayerController alloc] initWithContentURL:movieURL]; [movieController play];

The variable movieController is an instance variable. This is necessary because MPMoviePlayerController could not be released before it’s done playing without cutting off the video. So I used the notification that it sends upon ending playback to release the object and reclaim the memory.

// subscribed to MPMoviePlayerPlaybackDidFinishNotification - (void) movieFinished:(NSNotification *)notification { [movieController release]; movieController = nil; }

I want to continue targeting devices with 3.0 and later, but my Xcode only has the 3.2 and 4.0 SDKs. You can build against 4.0 and set deployment target to 3.0. If you use the code above it still builds but confusingly you don’t get any picture any more, at least not in simulator.

The reason being that MPMoviePlayerController has been modified to output it’s playback into a UIView. This view is a property you can then incorporate into your own view hierarchy with any dimensions you like. In order to still get the full screen playback you had before you would be required to resort to view adding and controlling and other trickery. But way easier is to instead use the new MPMoviePlayerViewController.

Look again at the class name in case you don’t see the difference. The “View” is new between “Player” and “Controller”. Note that the name now contains ViewController, so you can present and dismiss it modally like you are used to. MPMoviePlayerViewController takes care of it’s own MPMoviePlayerController which you can access via a property. The notification still get’s called if you subscribed to it. So that’s still a good place to have some actions to execute as soon as video playback finishes.

Now the interesting part: how can you use the new view controller but still have your code working on iPhones which still run 3.x? You have to check if the new class is available and use it only if it can be resolved. If not we need to continue using the old method.

if (NSClassFromString(@"MPMoviePlayerViewController")) { MPMoviePlayerViewController *player = [[MPMoviePlayerViewController alloc] initWithContentURL:movieURL]; player.modalTransitionStyle = UIModalTransitionStyleCrossDissolve; videoOverviewViewController.modalTransitionStyle = UIModalTransitionStyleCrossDissolve; [videoOverviewViewController presentModalViewController:player animated:YES]; [player release]; } else { movieController = [[MPMoviePlayerController alloc] initWithContentURL:movieURL]; [movieController play]; }

Here are two interesting things: you can use NSClassFromString to check for runtime availability of classes. Of course the class is available if I build against 4.0 SDK, but when a user legally executes the app on 3.x (due to the lower deployment target) this code detects that the new class is not there. Non-existing classes return nil for NSClassFromString.

Also note that since the modal presenting causes the view controller to be retained we no longer need a special IVAR to keep track of it and can release it locally right after presenting it.

With this small modification I can build my code against the brand new 4.0 SDK but still have it run on iDevices that have not yet been upgraded from 3.x.

Or so I thought. For some reason that I still cannot explain the above code worked fine to play in my iPhone 4, but showed only a black screen on iPhones running 3.1.x. So I called upon Apple Developer Technical Support for a solution, which came a couple of days later. It still had a slight error for using a notification that never got sent, but I fixed that to arrive at the following solution which is now tested and working on 3.1.x, 3.2 and 4.0

In the header:

// IVARS MPMoviePlayerViewController *mViewPlayer; MPMoviePlayerController *mMPPlayer;

In the implementation:

-(void)playVideo:(NSURL *)url { videoOverviewViewController.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;   if ([NSClassFromString(@"MPMoviePlayerController") instancesRespondToSelector:@selector(view)]) { // running iOS 3.2 or better mViewPlayer = [[MPMoviePlayerViewController alloc] initWithContentURL:url]; mViewPlayer.modalTransitionStyle = UIModalTransitionStyleCrossDissolve; videoOverviewViewController.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;   [videoOverviewViewController presentModalViewController:mViewPlayer animated:YES];   [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(movieDidExitFullscreen:) name:MPMoviePlayerPlaybackDidFinishNotification object:[mViewPlayer moviePlayer]]; } else { mMPPlayer = [[MPMoviePlayerController alloc] initWithContentURL:url]; [mMPPlayer play];   [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(moviePlayerDidFinish:) name:MPMoviePlayerPlaybackDidFinishNotification object:mMPPlayer]; } }   - (void) movieDidExitFullscreen:(NSNotification*) aNotification { MPMoviePlayerController *player = [aNotification object]; [[NSNotificationCenter defaultCenter] removeObserver:self name:MPMoviePlayerPlaybackDidFinishNotification object:player]; [player pause]; [player stop];   [videoOverviewViewController dismissModalViewControllerAnimated:YES];   [mViewPlayer.view removeFromSuperview]; [mViewPlayer release];   mViewPlayer = nil; }   - (void) moviePlayerDidFinish:(NSNotification*) aNotification { MPMoviePlayerController *player = [aNotification object]; [[NSNotificationCenter defaultCenter] removeObserver:self name:MPMoviePlayerPlaybackDidFinishNotification object:player]; [player pause]; [player stop]; [player release];   mMPPlayer = nil; }

So there you have it, finally an officially recommended way to get full screen video playback working that’s both backwards compatible with 3.x but gives you the new video features present on 4.0, e.g. portrait playback.

John Muchow also explains how he solved this problem on his blog. His approach is slightly different but also quite interesting.

]]> http://www.drobnik.com/touch/2010/07/the-3-2-hurdle-of-mpmovieplayercontroller/feed/ 2 http://www.drobnik.com/touch/2010/06/hacking-uiscrollview-gesture-recognizers/ http://www.drobnik.com/touch/2010/06/hacking-uiscrollview-gesture-recognizers/#comments Sat, 26 Jun 2010 09:25:30 +0000 drops http://www.drobnik.com/touch/?p=2755 As of SDK 3.2 most of the touch handling code in stock controls has been taken out and replaced with this amazing new technology called Gesture Recognizers. This means besides of using them yourself and creating your own you can also fiddle with behaviors of standard controls if they interfere with your own gestures.

I’m currently working quite a bit on something based on UIScrollView and there I found several things that I needed to tweak.

Disabling Pinch

The first modification I did was to get around a bug in UIScrollView.  I did not actually want user zooming in my scroll view, but just use the setting of the zoomLevel to scale images without having to redraw them. And you can only set the zoomLevel to values between min and max.

So, during autorotation, I reduced the min zoom scale, set the new zoom level and then set min and max both to the new zoom. But the problem with this, as of SDK 3.2., is that if you change the min or max zoomLevel property the scroll silently adds a UIPinchGestureRecognizer to itself via the addGestureRecognizer method that now all views have.



Now that in of itself might not be a problem if it did not do anything. But as soon as you pinch the fingers together or apart then there is a bug setting the scrollview’s contentOffset to (0,0) causing my scrollview to the left and top. So I overrode the addGestureRecognizer to specifically disable the pinch detector.

If you prevent the addition instead of disabling it, you get a crash. Subclass UIScrollView and add this code to the implementation.

- (void)addGestureRecognizer:(UIGestureRecognizer *)gestureRecognizer { // workaround for bug: pinch recognizer gets added during rotation, // causes contentOffset to be set to (0,0) on pinch if ([gestureRecognizer isKindOfClass:[UIPinchGestureRecognizer class]]) { gestureRecognizer.enabled = NO; }   [super addGestureRecognizer:gestureRecognizer]; }

This way effectively disables the pinching without risking any other adverse effects.

Perpendicular Swipe Detection

The second example of fiddling with the scrollview gesture recognizers came from me wanting to use vertical swipes to trigger an action while retaining the horizontal swiping for the scroll view paging.

In my view controller I had this code to add the swipe handling:

- (void)viewDidLoad { [super viewDidLoad];   // other init stuff   // add vertical swipe detector UISwipeGestureRecognizer *swipeRecognizer = [[UISwipeGestureRecognizer alloc] initWithTarget:self action:@selector(verticalSwiped:)]; [self.view addGestureRecognizer:swipeRecognizer]; swipeRecognizer.direction = UISwipeGestureRecognizerDirectionUp | UISwipeGestureRecognizerDirectionDown; swipeRecognizer.delegate = self; [swipeRecognizer release]; }

With the scrollview behind it it still gets to detect all kinds of swiping also if you swipe diagonally downwards. There’s an easy way to see what kinds of gestures are currently attached to a view:

for (UIGestureRecognizer *gesture in _scrollView.gestureRecognizers) { [gesture requireGestureRecognizerToFail:swipeRecognizer]; NSLog(@"%@", gesture); }

All gesture recognizers have a good description and a paging scrollview gets these:

• UIScrollViewDelayedTouchesBeganGestureRecognizer
• UIPanGestureRecognizer, must-fail = UIScrollViewPagingSwipeGestureRecognizer
• UIScrollViewPagingSwipeGestureRecognizer, must-fail-for = UIPanGestureRecognizer

The pan gesture is the stock one which we also could use, but the two others are custom recognizers that Apple made by subclassing UIGestureRecognizer and added specific detection logic. Now we wouldn’t want to mess with these, let alone even mention UIScrollViewDelayedTouchesBeganGestureRecognizer or UIScrollViewPagingSwipeGestureRecognizer in our code, because those are private API classes and would cause our app to be rejected.

But again there’s a simple fix to the dilemma.Note the dependencies must-fail and must-fail-for. In the log you see that for the pan gesture to work, the paging swipe gesture must fail first. This mechanism lets you make gestures dependent on the failure of others or themselves cause others to fail.

We can employ the same mechanism and permit the detection of the paging swipe only if our own vertical swipe gesture failed.

for (UIGestureRecognizer *gesture in _scrollView.gestureRecognizers) { // don't want to mention any Apple TM'ed class names ;-) NSString *className = NSStringFromClass([gesture class]); if ([className rangeOfString:@"Swipe"].location!=NSNotFound) { [gesture requireGestureRecognizerToFail:swipeRecognizer]; } }

I didn’t want to mess with the two other recognizers because a) I don’t know what the delayed touches one is for and b) making the pan dependent on the failing of the vertical swipe might introduce a bit of lag for the panning to be detected. So I just got the class name from the instances and made apples paging swipe dependent on my vertical swipe detector failing.

So you see, Gesture Recognizers are not only greatly simplifying touch handling for your apps, but if you dare look at how Apple is using them you can also tweak them a bit if necessary.

]]> http://www.drobnik.com/touch/2010/06/hacking-uiscrollview-gesture-recognizers/feed/ 0 http://www.drobnik.com/touch/2010/06/rendering-pdf-is-easier-than-you-thought/ http://www.drobnik.com/touch/2010/06/rendering-pdf-is-easier-than-you-thought/#comments Thu, 17 Jun 2010 07:54:01 +0000 drops http://www.drobnik.com/touch/?p=2718 We all know by now that Adobe is almost as evil as …, well let’s say they pioneered a couple of functionalities that where great for the longest time. One being the PDF format which is actually totally built into OSX everywhere. On OSX you’re able to print into a PDF without having to install extra software. Also iOS comes with PDF support and today we’ll look at how we can draw a PDF in a view.

How UIWebView sees it

The first idea you might have is to use UIWebView to display PDFs which is not difficult, just get the URL, make a NSURLRequest and pass this to a web view.

_webView = [[UIWebView alloc] initWithFrame:frame]; _webView.delegate = self; _webView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;   // we don't want interaction, full size _webView.scalesPageToFit = YES; _webView.userInteractionEnabled = NO; _webView.backgroundColor = [UIColor whiteColor];   //fileURL is an NSURL to a PDF file [_webView loadRequest:[NSURLRequest requestWithURL:fileURL]];

But there is one drawback: you cannot really control how it will arrive on screen. For one thing, UIWebView draws a fat gray border and shadow which might somewhat mess up your UI design.

Wouldn’t it be great if you could draw the PDF somehow into a view? Yes, we can!



Drawing PDF Pages

Apple provides in CoreGraphics a whole set of functions prefixed CGPDF to deal with PDFs. The easiest method for drawing the first page of a PDF file I pieced together from the documentation like this. This is a regular view where I replaced the drawRect as follows:

- (void)drawRect:(CGRect)rect { CGContextRef ctx = UIGraphicsGetCurrentContext();   // PDF might be transparent, assume white paper [[UIColor whiteColor] set]; CGContextFillRect(ctx, rect);   // Flip coordinates CGContextGetCTM(ctx); CGContextScaleCTM(ctx, 1, -1); CGContextTranslateCTM(ctx, 0, -rect.size.height);   // url is a file URL CGPDFDocumentRef pdf = CGPDFDocumentCreateWithURL((CFURLRef)url); CGPDFPageRef page1 = CGPDFDocumentGetPage(pdf, 1);   // get the rectangle of the cropped inside CGRect mediaRect = CGPDFPageGetBoxRect(page1, kCGPDFCropBox); CGContextScaleCTM(ctx, rect.size.width / mediaRect.size.width, rect.size.height / mediaRect.size.height); CGContextTranslateCTM(ctx, -mediaRect.origin.x, -mediaRect.origin.y);   // draw it CGContextDrawPDFPage(ctx, page1); CGPDFDocumentRelease(pdf); }

The part about the mediaRect is necessary because PDF pages are typically larger than what you really see on screen. There are usually some printing, color and crop marks outside of the content area. I managed to eliminate those by changing the transformation matrix of the CGContext.

The official method in the documentation is to use CGPDFPageGetDrawingTransform, but this has a catch: it won’t scale the image to be larger than 100% and instead center it on screen. So we build our own transform, ignoring the aspect ratio because we want to fill the view with that.

If the PDF is small enough to keep in memory you could also load it into an NSData object and access individual pages from it super fast. To read from data as opposed to providing an NSURL you change the code like this:

// data is an NSData object we filled with the PDF data from file before CGDataProviderRef dataProvider = CGDataProviderCreateWithCFData((CFDataRef)data]); CGPDFDocumentRef pdf = CGPDFDocumentCreateWithProvider(dataProvider); CGDataProviderRelease(dataProvider);

We’re using “toll-free bridging” to simply use our NSData instance where the function is expecting a CFDataRef, and of course if we have a method called SomethingCreate then we also have to have a SomethingRelease.

Conclusion

Having this ability to render PDF pages int any resolution gives you a great deal of flexibility. A great tool to have in your toolchest! You might even go as far as using PDFs as your main graphics container because it can contain both vector and bitmap graphics. In fact it’s the closest you can get to vector graphics on iOS.

Now please don’t go and make yet another PDF reader with this. With iBooks 1.1 soon supporting native PDF viewing that would make no sense.

Here are a couple other ideas:

• An app that lets you keep your musical note sheets on your iPad. You could mark sections and specify their order and then choose between classical mode (one sheet per screen) or 1-pass mode, where the sections are flattened such that you don’t have to go back to repeats, but always play from left to right. Couple that with some fancy notes OCR to have the iPad play a bar before you. Maybe use audio clues on when to know to turn the page.
• An app that lets you EDIT PDFs on the iPad, with cut/copy/paste support so that you can paste things on the iPad into a PDF-based scrapbook.
• Make a presentation app similar to Prezi. You would load a PDF as basis and then you would record zoom levels, viewed rectangle and rotations along a user-defined path. Give presentation to external display.
• Use a similar technique to render rich-text documents into reports that you can e-mail from your app.
• Make an electronic version of a magazine similar to Wired, no need for Adobe’s weird Illustrator-to-App converter that makes half a GB apps.

If you’re interesting in partnering or co-developing these ideas please e-mail me.

]]> http://www.drobnik.com/touch/2010/06/rendering-pdf-is-easier-than-you-thought/feed/ 5