Mocking a UIKit Delegate Protocol with Kiwi

I'm experimenting with mock objects in Kiwi and decided to try and mock the UIAlertViewDelegate. I ran into two issues. 1. Order is important when creating the mock delegate object. It needs to be setup with all the delegate method receive calls before you use the object associated with the delegate protocol.

2.  The delegate protocol methods need to be mocked in the order they are invoked, or you'll receive a test failure. This can be trial and error, if you don't know how the delegate protocol works.

a. For each mock delegate test, I just kept running until I was able to get the mock delegate calls passing.

b. I also discovered that the didDismissWithButtonIndex and  clickedButtonAtIndex were not invoked after using the dismissWithClickedButtonIndex method call.

[objc] #import "Kiwi.h" #import "PSMessages.h" #import "PSMessageConstants.h"


describe(@"Create an alertview", ^{ __block PSMessages *messages = nil; beforeEach(^{ messages = [[PSMessages alloc] init]; });

NSDictionary *urlMessage = @{ @"type" : @"url", @"url" : @"", @"message" : @"Create a collage for the next holiday.", @"title" : @"Design Collages", @"buttons" : @[@"Yes", @"No"] };

context(@"with a url message", ^{ __block UIAlertView *alert = nil; beforeEach(^{ alert = [messages alertForMessage:urlMessage]; }); it(@"the cancel button is pressed", ^{ id delegateMock = [KWMock mockForProtocol:@protocol(UIAlertViewDelegate)]; alert.delegate = delegateMock;

int buttonIndex = alert.cancelButtonIndex;

[[[delegateMock shouldEventually] receive] alertViewShouldEnableFirstOtherButton:alert]; [[[delegateMock shouldEventually] receive] didPresentAlertView:alert]; [[[delegateMock shouldEventually] receive] willPresentAlertView:alert]; [[[delegateMock shouldEventually] receive] alertView:alert willDismissWithButtonIndex:buttonIndex]; [[[delegateMock shouldEventually] receive] alertView:alert willDismissWithButtonIndex:buttonIndex];

// Note: delegate methods not called for programatic UIAlertView dismiss [[[delegateMock shouldEventually] receive] alertView:alert didDismissWithButtonIndex:buttonIndex]; [[[delegateMock shouldEventually] receive] alertView:alert clickedButtonAtIndex:buttonIndex];

// Invoke methods after the delegateMock object is setup [alert show]; [alert dismissWithClickedButtonIndex:buttonIndex animated:NO];


it(@"the ok button is pressed", ^{ id delegateMock = [KWMock mockForProtocol:@protocol(UIAlertViewDelegate)]; alert.delegate = delegateMock;

int buttonIndex = alert.firstOtherButtonIndex;

[[[delegateMock shouldEventually] receive] alertViewShouldEnableFirstOtherButton:alert]; [[[delegateMock shouldEventually] receive] didPresentAlertView:alert]; [[[delegateMock shouldEventually] receive] willPresentAlertView:alert]; [[[delegateMock shouldEventually] receive] alertView:alert willDismissWithButtonIndex:buttonIndex]; [[[delegateMock shouldEventually] receive] alertView:alert willDismissWithButtonIndex:buttonIndex];

// Invoke methods after the delegateMock object is setup [alert show]; [alert dismissWithClickedButtonIndex:buttonIndex animated:NO];

}); });

}); SPEC_END [/objc]

Unit Testing Static Libraries with Kiwi for iOS Development

I've been playing with Kiwi and I'm trying some BDD (Behavior Driven Development) for a new static library component I wanted to build. I began with a new Xcode project using the Static Library template, but ran into issues with the difference between "logic tests" and "application tests". In short, all my non-UIKit code worked great, until I started to test my UIKit related functions.

The code crashed and makes it frustrating to write unit tests. If you've never experienced it before, it'll make your unit test experience unproductive. To solve the issue you'll need to create a new target (empty iOS application) and include unit tests. Xcode will automagically setup the unit tests to be "Application Tests" instead of "logic tests."


#0 0x00a40881 in __HALT () #1 0x0097a971 in _CFRuntimeCreateInstance () #2 0x01337cc1 in GSFontCreateWithName () #3 0x05c32281 in UINewFont () #4 0x05c323ec in +[UIFont systemFontOfSize:traits:] () #5 0x05c32438 in +[UIFont systemFontOfSize:] () #6 0x05be24ee in +[UILabel defaultFont] () #7 0x05be32e5 in -[UILabel _commonInit] () #8 0x05be3424 in -[UILabel initWithFrame:] () #9 0x05e7cc67 in -[UIAlertView(Private) _createTitleLabelIfNeeded] () #10 0x05e8b4b9 in -[UIAlertView setTitle:] () #11 0x05e8bb37 in -[UIAlertView initWithTitle:message:delegate:cancelButtonTitle:otherButtonTitles:] () #12 0x02605831 in __block_global_23 at /Users/paulsolt/dev/Photo-Slide-Show/PSMessages/PSMessagesTests/PSMessagesTest.m:165 #13 0x0261b584 in __25-[KWExample visitItNode:]_block_invoke_0 at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWExample.m:220 #14 0x0261a11e in __42-[KWContextNode performExample:withBlock:]_block_invoke_0 at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWContextNode.m:116 #15 0x0261a11e in __42-[KWContextNode performExample:withBlock:]_block_invoke_0 at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWContextNode.m:116 #16 0x0261a11e in __42-[KWContextNode performExample:withBlock:]_block_invoke_0 at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWContextNode.m:116 #17 0x0261a03e in -[KWContextNode performExample:withBlock:] at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWContextNode.m:132 #18 0x0261a05d in -[KWContextNode performExample:withBlock:] at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWContextNode.m:135 #19 0x0261a05d in -[KWContextNode performExample:withBlock:] at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWContextNode.m:135 #20 0x0261b539 in -[KWExample visitItNode:] at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWExample.m:216 #21 0x0261a553 in -[KWItNode acceptExampleNodeVisitor:] at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWItNode.m:41 #22 0x0261ae22 in -[KWExample runWithDelegate:] at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWExample.m:113 #23 0x02618c95 in -[KWSpec invokeTest] at /Users/paulsolt/dev/Photo-Slide-Show/Frameworks/Kiwi/Kiwi/KWSpec.m:105 #24 0x2010405b in -[SenTestCase performTest:] () #25 0x201037bf in -[SenTest run] () #26 0x2010792b in -[SenTestSuite performTest:] () #27 0x201037bf in -[SenTest run] () #28 0x2010792b in -[SenTestSuite performTest:] () #29 0x201037bf in -[SenTest run] () #30 0x201063ec in +[SenTestProbe runTests:] () #31 0x0072f5c8 in +[NSObject performSelector:withObject:] () #32 0x00002342 in ___lldb_unnamed_function11$$otest () #33 0x000025ef in ___lldb_unnamed_function13$$otest () #34 0x0000268c in ___lldb_unnamed_function14$$otest () #35 0x00002001 in ___lldb_unnamed_function4$$otest () #36 0x00001f71 in ___lldb_unnamed_function1$$otest ()


1. Add a new target with it's own unit tests. Creating unit tests with a "static library" template gives you "logic tests", while creating unit tests with a "iPhone application" gives you "application tests." The difference is that you can't use UIKit classes in logic tests, but you can in application tests.


2. In an application test, the runloop of the iPhone app starts, which means all the UIKit goodies are setup. The bad news is that it loads all the default state from your previous app runs. You might need to write some methods to cleanup or reset state. (GHUnit is nice because it's more sandboxed)

3. If you're using Kiwi you'll have to setup the Kiwi environment (library/header paths) again for the application tests.


UICollectionView Custom Actions and UIMenuController

The UICollectionView can provide a special UIMenuController with cut, copy, and paste actions. To add UICollectionView custom actions you need to implement a few extra methods for the shared UIMenuController object. The view controller's parent window needs to be the key window and you'll need to respond to UIResponder method canBecomeFirstResponder. In your UICollectionViewController class do the following:

[objc] // ViewController.h @interface ViewController : UICollectionViewController

// ViewController.m -(void)viewDidLoad { [super viewDidLoad]; self.collectionView.delegate = self;

UIMenuItem *menuItem = [[UIMenuItem alloc] initWithTitle:@"Custom Action" action:@selector(customAction:)]; [[UIMenuController sharedMenuController] setMenuItems:[NSArray arrayWithObject:menuItem]];


#pragma mark - UICollectionViewDelegate methods - (BOOL)collectionView:(UICollectionView *)collectionView canPerformAction:(SEL)action forItemAtIndexPath:(NSIndexPath *)indexPath withSender:(id)sender { return YES; // YES for the Cut, copy, paste actions }

- (BOOL)collectionView:(UICollectionView *)collectionView shouldShowMenuForItemAtIndexPath:(NSIndexPath *)indexPath { return YES; }

- (void)collectionView:(UICollectionView *)collectionView performAction:(SEL)action forItemAtIndexPath:(NSIndexPath *)indexPath withSender:(id)sender { NSLog(@"performAction"); }

#pragma mark - UIMenuController required methods - (BOOL)canBecomeFirstResponder { // NOTE: This menu item will not show if this is not YES! return YES; }

- (BOOL)canPerformAction:(SEL)action withSender:(id)sender { NSLog(@"canPerformAction"); // The selector(s) should match your UIMenuItem selector if (action == @selector(customAction:)) { return YES; } return NO; }

#pragma mark - Custom Action(s) - (void)customAction:(id)sender { NSLog(@"custom action! %@", sender); } [/objc]

Here's what it looks like:

UIMenuController Custom UICollectionView

Linking to a Facebook Page from an iOS App

The Facebook app broke the old way of creating an iOS facebook page link. If the app isn't installed the old facebook link works, but when it is installed it just opens the Facebook app to the default page. Fix your app links to Facebook using this url format:

Old iOS Facebook Page Link:

New iOS Facebook Page Link:

The only downside is that the user would have to login via the mobile website in order to "like" your Facebook page. It's certainly better than just seeing the "default" screen in the app. I'm not sure if the new Facebook SDK 3.1 fixes any of these issues, but I haven't seen a solution on


iPhone Link to Facebook Page fails with App

Linking to a facebook page doesn't work from iOS if the new Facebook app is installed.

iPhone Link to Facebook Page Works

Linking to the mobile Facebook page with the ?_rdr flag fixes the issue.

Duplicate Code Signing on Xcode with Any iOS SDK

Working with Xcode code signing is a pain. You may have encountered a situation where there are more than two code signing identity's in Xcode. This means that you potentially have to change four different code signing settings to update your app, rather than just two. I think this is cruft from upgrading to the newest Xcode version or something. Here's what it looks like and here's how to fix it. It's very annoying when developing and testing with adhoc and app store builds.


Code signing in Xcode 4


The issue is visible with the "Any iOS SDK" seen as a subitem to the Debug and the Release builds. Things won't work correctly if the two don't match in my experience. So I end up having to change two at a time.


You can close Xcode or keep it open. It seems to work either way before you start the next steps.

1.Open your project folder in finder. (Right click project in Xcode and choose "Show in Finder")

Show in finder

2. Right click on the Xcode project file in Finder -> "Show Package Contents"

Xcode project Show package contents

3. Right click on the project.pbxproj and choose "Open With" -> "TextEdit"

Xcode project in Textedit

4. Search for "Sign" and delete any lines that look like the following. Xcode will regenerate, so don't worry about deleting them. I believe the first two are the root of the problem.

"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer";

"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer";

CODE_SIGN_IDENTITY = "iPhone Developer";

Textedit code sign identity

5. Open the project settings in Xcode and see the duplicate "Any iOS SDK" are removed and Xcode regenerated the default Code Sign Identities.

Fixed code sign duplicates

6. Update with your credentials for Debug/Release.

Update code sign


Using the social.framework on iOS 6.0

Using the social.framework is real simple on iOS 6.0. Apple only refers to their reference, so I decided to show the code snippet example. To change between twitter and  Sina Weibo, just use the types: SLServiceTypeSinaWeibo SLServiceTypeTwitter. It just takes 10 lines of code. If you used the Twitter.framework, you can remove it and replace your Twitter code with the following code. The Social.framework will manage all social networks moving forward.

if([SLComposeViewController isAvailableForServiceType:SLServiceTypeFacebook]) {

SLComposeViewController *socialSheet = [SLComposeViewController composeViewControllerForServiceType:SLServiceTypeFacebook];

[socialSheet setInitialText:@"posted from @PhotoTable"];

[socialSheet addImage:image];

[socialSheet setCompletionHandler:^(SLComposeViewControllerResult result) {

NSLog(@"Result: %d", result);


[self presentViewController:socialSheet animated:YES completion:^ {



App Rochester - iPhone Programming Presentation

In followup from my iPhone programming presentation I have uploaded the presentation and sample Xcode project (Xcode 4.3.2) The sample converts between temperatures in celsius and fahrenheit. The sample shows how to setup the gestures in Xcode's interface builder, rather than in Objective-C code. Using the UIPanGestureRecognizer we can allow sliding input for the temperature conversion. The only code we need to implement is the action to take in response to a detected gesture.

Download the slides and sample code:


iPhone Unit Testing Explained - Part II

Xcode 4 has drastically improved iPhone unit testing and Mac unit testing from my previous post, iPhone Unit Testing Explained - Part I Creating the unit testing target is easy and you can start writing test code in under 5 minutes.

The biggest hassle in testing is setting up the project correctly, and Xcode 4 makes it simple. If you read Part I, I pushed for GHUnit because of the GUI interface, but now Xcode's built in testing is enough to get you started. If you need a GUI, add GHUnit later, but start writing your tests today, since they're compatible with GHUnit when you decide to integrate with it.

Testing is important to start from the beginning or you will never have the motivation to write the tests unless your boss demand

Getting Started

To start writing unit tests you have two options, either create a new project with unit tests or add unit tests to an existing project.

New Project with Unit Tests

Create a new project and make sure the checkbox is enabled for unit tests.


New Xcode 4 Project with Unit Tests

Add Unit Tests Target to Existing Projects

Add a unit test target to your project by clicking on your Project (top left) -> Add Target (bottom middle) -> iOS -> Other -> Unit Testing Bundle.


Add Unit Tests to Existing Xcode Project

(Optional) Share the Target and Testing Scheme

If you add a unit test target, you'll most likely want to share your testing scheme with your team over version control (git, svn, etc.) Otherwise you're teammates will have to setup for themselves.

Goto Editor -> Manage Schemes -> Click Shared next to the Unit Test


Share Xcode Schemes with Teammates

Adding Resources

When you want to test code or import resources like images or data files you'll need to tell the testing target about the resources. There are two ways, you can do it when you first add the resource to the project or you can do it by editing the Build Phases for the unit test target.


Adding New Resources to the Unit Test Target

Click on File -> Add Files to "TestProject" -> Click on the checkbox on unit test target and Copy items


Copy Items and add to Unit Test Target in Xcode 4

Adding Existing Resources to the Unit Test Target

Click on your project "TestProject" -> Build Phases -> Expand one of three (Compile Sources, Link Binary With Libraries, or Copy Bundle Resources)


Build Phases for unit test in Xcode 4

Resource Paths are Different!

Many assumptions that your bundle is the main bundle will cause problems when testing. (Especially when adding tests to existing code) Look at the difference in bundles, the main bundle isn't what you'd expect in a unit test.

NSString *mainBundlePath = [[NSBundle mainBundle] resourcePath];

NSString *directBundlePath = [[NSBundle bundleForClass:[self class]] resourcePath];

NSLog(@"Main Bundle Path: %@", mainBundlePath);

NSLog(@"Direct Path: %@", directBundlePath);

NSString *mainBundleResourcePath = [[NSBundle mainBundlepathForResource:@"Frame.png" ofType:nil];

NSString *directBundleResourcePath = [[NSBundle bundleForClass:[self class]] pathForResource:@"Frame.png" ofType:nil];

NSLog(@"Main Bundle Path: %@", mainBundleResourcePath);

NSLog(@"Direct Path: %@", directBundleResourcePath);


Main Bundle Path: /Applications/

Direct Path: /Users/paulsolt/Library/Developer/Xcode/DerivedData/PhotoTable-dqueeqsjkjdthcbkrdzcvwifesvl/Build/Products/Debug-iphonesimulator/Unit Tests.octest

Main Bundle Path: (null)

Direct Path: /Users/paulsolt/Library/Developer/Xcode/DerivedData/PhotoTable-dqueeqsjkjdthcbkrdzcvwifesvl/Build/Products/Debug-iphonesimulator/Unit Tests.octest/Frame.png

Problem: My Unit test has a nil image, data file, etc. Why?

The unit test doesn't use the same bundle for resources that you're accustomed to when running an app. Therefore, the resource we're trying to load cannot be found.  You'll need to make changes to the code to support testing external resources (images, data files, etc). For example the following code

- (UIImage *)resizeFrameForImage:(NSString *)theImageName {
UIImage *image = [UIImage imageNamed:theImageName];
// ... do magical resize and return
return image;

Solution 1: Change the function parameters

Functions like these are semi-black boxes that aren't ideal for testing. You want access to all your inputs/outputs, especially if we're working with any kind of file resource. To fix it, just pass in the resource from the unit test, rather than having the function load it from a NSString object.

- (UIImage *)resizeFrameForImage:(UIImage *)theImage {
// ... do magical resize and return
return theImage;

Solution 2: Change the resource loading inside the function

If you need to load the resource in the function, you can alternatively change the way it is loaded. You need to stop using UIImage's imageNamed: method and switch to imageWithContentsOfFile: This way you can pass in the resource with the correct path, however it'll change logic elsewhere in your app.

- (UIImage *)resizeFrameForImage:(NSString *)theImagePath {
UIImage *image = [UIImage imageWithContentsOfFile:theImagePath];
// ... do magical resize and return
return image;

Solution 3: Load resources using the bundle for the current class

- (UIImage *)resizeFrameForImage:(NSString *)theImageName {
// Note: There are several ways you can write it, but make sure you include
//  the extension or you'll have trouble finding the resource
// 1. NSString *imagePath = [[NSBundle bundleForClass:[self class]] pathForResource:@"Image.png" ofType:nil];
// 2. NSString *imagePath = [[NSBundle bundleForClass:[self class]] pathForResource:@"Image" ofType:@"png"];
NSString *imagePath = [[NSBundle bundleForClass:[self class]] pathForResource:theImageName ofType:nil];
UIImage *image = [UIImage imageWithContentsOfFile:imagePath];
// ... do magical resize and return
return image;

My First Test

Code completion in Xcode will make writing tests easy. To test different things you'll use the following macros:

  • STAssertNotNil(Object, Description);
  • STAssertEquals(Value1, Value2, Description);
  • STAssertEqualObjects(Object1, Object2, Description);

Example: MyTest.m

@implementation TestImagePrintHelper
- (void)setUp
[super setUp];
// Set-up code here.
- (void)tearDown
// Tear-down code here.
[super tearDown];
- (void)testName {
NSString *testFirstName = @"Paul";
STAssertEqualObjects([person firstName], testFirstName, @"The name does not match");

The STAssertEqualObjects macro will invoke the object's isEqual method, make sure you write one. See the section below. If you used the STAssertEquals it will test for primitive/pointer equality, not object equality.

Testable Code

Writing testable code requires that you add some additional functions that might feel optional before you decided to start testing.

1. Create a isEqual method for your class.

Most of the time you'll want to compare if the object is the correct object. This always requires that you write an isEqual method, otherwise you'll be using the NSObject isEqual test and it'll compare address pointers for the objects.

Example: Person.m

- (BOOL)isEqual:(id)other {
if (other == self) { // self equality, compare address pointers
return YES;
if (!other || ![other isKindOfClass:[self class]]) { 
// test not nil and is same type of class
return NO;
return [self isEqualToPerson: other]; // call our isEqual method for Person objects
- (BOOL)isEqualToPerson:(Person *) other {
BOOL value = NO;
if (self == other) { // test for self equality
value = YES;
 } elseif([[selffirstName] isEqualToString:[other firstName]] &&
[self age] == [other age]) {
// Add any other tests for instance variables (ivars) that need to be compared
value = YES;
return value;

2. Create a description method for your class.

This is what will output on the command line, rather than the objects memory address. It can be also called when you decide to print the value in a tests

Example: Person.m

- (NSString *)description {
return [NSStringstringWithFormat:@"Person Name: %@ Age: %d", [self firstName], [self age]];

Example: Test using the description method, and we'll see the first name and age printed like it was formatted in our description method.

STAssertEqualObjects([personfirstName], testFirstName, @"The name does not match %@", person);

Further reading in Apple's Unit Testing Guide is available. Now you have the basics for unit testing. The next part will provide an example project using resources and providing unit tests.

(Part III: Coming Soon)

Learn iPhone Programming via Skill Share in Rochester, NY

I'm teaching a small hands-on course for iPhone development in Rochester, NY on April 21st 10am-12pm.


Space is limited:

About this Class

Learn how to get started with iPhone/iPad development and start making iPhone/iPad apps today. Install the tools and create an app without prior experience.

Lecture: 30-45 minute lecture on getting started

  • Xcode - Code editor
  • Objective-C - Computer language
  • Setting up developer credentials

Workshop: 1:30 hours

  • Learn how to start programming
  • Build your first app - hands on learning

Recommended Reading

About Paul Solt

  • Computer science graduate student at RIT
  • Worked at Apple Inc. and Microsoft.
  • 4 years as a computer science student instructor at RIT
  • 5 apps on App Store
  • 12 years of programming experience


  • Mac computer (Macbook Pro, Macbook Air, iMac)
  • Install Xcode 4.3+ from the Mac App Store.
  • (Optional) Bring iPhone/iPad with usb cables
  • (Optional) Register as a iOS Developer $99/year:

The Potential of Siri

I've been working on iPhone development for several years and I have been very excited to see how the iPhone SDK has progressed. See my original article on how I envisioned the iPad revolutionizing the computing experience. Siri takes the iPhone platform to an entirely new level.  Feature article by MD

If you're curious as to how the potential of Siri will impact iOS App development, then look no further than the video Apple used to demonstrate the technology, despite its somewhat heavy-on-the-awesome slant. The fact of the matter is, this is voice recognition technology that's approaching the level of sophistication you saw in Startrek Voyager as a kid, and it could do wonders for 3rd party App developers.

"Load Angry Birds. New game, please. Aim 45 degrees off the starboard. Lower 3 degrees. Fire. Raise 3 degrees. Fire. Down with the piggies! Fire."

It sounds far fetched, but is it? Voice control to do anything from text messaging to calling, and it's not difficult to imagine it controlling things that are not traditionally based around natural voice input. It'd also be a great idea to work in some camera/augmented reality games, as playing "I Spy" with Siri could only make the device even more intuitive, when you're not ringing your husband, friend or O2 without even touching your handset.

An open API to Siri will help push developers in a new direction building innovative software for the iPhone 4S, given that Siri pushes the boundaries in a way that encourages people to try something new. Google Goggles was a great example of this - it took what QR codes were doing and pushed it farther than anyone had expected it to go - I certainly didn't expect to be able to use my voice to dictate a text message, make two calls and send an email to my boss, did you?

The best thing about it is the potential it awards developers working with voice and hardware interaction, as unless you're paranoid about SkyNet and HAL-9000 becoming a reality, it certainly puts a friendlier face on an already friendly looking phone. All that's left is for us to enjoy the adventures many app programmers are embarking on with Siri, in addition to the talented invidiual who's just ported it to the iPhone 4. Good times to come, ahead.

Idea to App Store - How to make, market, and sell your iPhone App

I've posted my presentation from the Computer Science Community at RIT on making iPhone/iPad apps from February 2011. The video is in two parts and I discuss the initial sales, analytics, marketing when releasing an iPhone app.

Update: 8/31/11 Idea to App Store Slides (PDF)

Part 1:


Part 2:


Transparent UITableView with Custom Background UIView and Tap Gestures

In order to create a custom background for a transparent UITableView you'll need to do a few things. I've got the basic code below after a lot of tinkering. I've also included how to make it so you can hide the UITableView when you tap in the transparent areas below the rows using a UITapGestureRecognizer. In the images below you can see the custom view in action.

UITableView with custom backgroundView
UITableView with Custom Background

[caption id="attachment_1101" align="aligncenter" width="159" caption="Hidden UITableView Showing Custom Background"]Hidden UITableView with Custom Background[/caption]

Key Points:

  • Don't subclass UITableView, instead use it as a instance variable in your own custom UIViewController subclass.
  • Create a custom UIView subclass to use as the background view, this will be visible when the UITableView is hidden or has a transparent background view.
  • On iPad make sure you clear the UITableView's backgroundView and set it to nil in addition to setting the background color to[UIColor clearColor]
  • Register a UITapGestureRecognizer with the viewController's view and then set the attribute cancelsTouches to NO so that the touches from the gesture propagate to both the UITableView and the custom background view.
  • In the -(void)handleTapGesture: method you'll want to send taps that don't touch a row to toggle the UI so that the UITableView hides or unhides.


  • I show a UINavigationBar, so my UITableView frame needs to take into account the size of the navigation bar.
  • Set the UILabel's or custom views backgroundColor in the table's cells to have [UIColor clearColor] so that they animate and fade correctly.

See the sample code below:

Limiting UIPinchGestureRecognizer Zoom Levels

Here is how to use a UIPinchGestureRecognizer and how to limit it's zoom levels on your custom views and content. My use case was for resizing images on a custom view. I wanted to prevent very large images and to prevent very small images. Very large images have a ton of pixilation and artifacts. While very small images are hard to touch and a user cannot do anything useful with them.

Basic Math

1. We know: currentSize * scaleFactor = newSize

2. Clamp the maximum scale factor using the proportion maxScale / currentScale

3. Clamp the minimum scale factor using the proportion minScale / currentScale

The code below assumes there is an instance variable CGFloat lastScale and that a view has been set for the UIPinchGestureRecognizer.

Sample Code

#import <QuartzCore/QuartzCore.h>   // required for working with the view's layers


- (void)handlePinchGesture:(UIPinchGestureRecognizer *)gestureRecognizer {

if([gestureRecognizer state] == UIGestureRecognizerStateBegan) {
// Reset the last scale, necessary if there are multiple objects with different scales
lastScale = [gestureRecognizer scale];

if ([gestureRecognizer state] == UIGestureRecognizerStateBegan ||
[gestureRecognizer state] == UIGestureRecognizerStateChanged) {

CGFloat currentScale = [[[gestureRecognizer view].layer valueForKeyPath:@"transform.scale"] floatValue];

// Constants to adjust the max/min values of zoom
const CGFloat kMaxScale = 2.0;
const CGFloat kMinScale = 1.0;

CGFloat newScale = 1 -  (lastScale - [gestureRecognizer scale]); // new scale is in the range (0-1)
newScale = MIN(newScale, kMaxScale / currentScale);
newScale = MAX(newScale, kMinScale / currentScale);
CGAffineTransform transform = CGAffineTransformScale([[gestureRecognizer view] transform], newScale, newScale);
[gestureRecognizer view].transform = transform;

lastScale = [gestureRecognizer scale];  // Store the previous scale factor for the next pinch gesture call

Artwork Evolution on App Store

Artwork Evolution - Paul Solt Artwork Evolution, my first iOS App is now available on the App Store for iPhone, iPod Touch, and iPad. It allows you to create complex abstract art with the touch of a finger. You can breed images together to create new images.

[caption id="attachment_1038" align="aligncenter" width="396" caption="Artwork Evolution on iPhone 4"][/caption]

Tutorial Video


Objective-C/C++ iPhone Build Failures

If you're working with Objective-C/C++ (i.e. mixing both languages) in an iPhone/Mac application you may come across some strange errors in the build process due to a configuration issue.

error: bits/c++config.h: No such file or directory

[caption id="attachment_1005" align="aligncenter" width="457" caption="Too many build failures"][/caption]

One of my projects, Texture Evolution was a Mac application that referenced a C++ Mac library. About 6 months ago I ran into an issue where my build would fail. It may have been related to an update to Xcode, but I'm not entirely sure. After a lot of time, frustration, Google'ing, and project configuration changes I came across a solution.

Today I ran into the same problem and couldn't quite remember how to fix it for my Doxygen Xcode documentation Target that references the C++ Mac library. I wasted more time trying to figure it out again, so here's the breakdown.

The Problem:

Using iostream.h or other STL from C++ and compiling with the Base SDK set to 10.4 and GCC 4.0.

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.1.sdk/usr/include/c++/4.0.0/iostream:43:0 /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.1.sdk/usr/include/c++/4.0.0/iostream:43:28: error: bits/c++config.h: No such file or directory

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.1.sdk/usr/include/c++/4.0.0/iosfwd:45:0 /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.1.sdk/usr/include/c++/4.0.0/iosfwd:45:29: error: bits/c++locale.h: No such file or directory

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.1.sdk/usr/include/c++/4.0.0/iosfwd:46:0 /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.1.sdk/usr/include/c++/4.0.0/iosfwd:46:25: error: bits/c++io.h: No such file or directory

(11,000+ other errors)

The Solution:

Set the Base SDK to Mac OS X 10.5 and GCC to 4.2. You'll need to make changes to project using the library as well as the libraries Target/Project settings. When you make changes make sure the Target properties displays "All Configurations" (i.e. Debug/Release/Release Adhoc/Release AppStore) so that you fix it for all of your build types. Double check and make sure that your static libraries and your project Targets have matching configurations.

[caption id="attachment_1000" align="aligncenter" width="461" caption="Using Base SDK: Mac OS X 10.5 and GCC 4.2"][/caption]


It may be a simple configuration issue, but I'm not really sure. For some reason when I use GCC 4.0 it builds against arm and uses the iPhone SDK, but when I use GCC 4.2 it uses the Mac SDK. The library is explicitly targeting Mac OS X 10.4, but it doesn't seem to work when it's targeting GCC 4.0. Here's the comparison build output:

Base SDK Mac OS X 10.4, GCC 4.0

CompileC /Users/paulsolt/dev/xcode_build_output/ /Users/paulsolt/dev/xcode_build_output/ ../../source/Canvas.cpp normal armv6 c++
cd /Users/paulsolt/dev/ArtworkEvolution/Xcode/ArtworkEvolution
setenv LANG en_US.US-ASCII
setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.0 -x c++ -arch armv6 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wunused-variable -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.1.sdk -mfix-and-continue -gdwarf-2 -mthumb -miphoneos-version-min=3.2 -iquote /Users/paulsolt/dev/xcode_build_output/ -I/Users/paulsolt/dev/xcode_build_output/ -I/Users/paulsolt/dev/xcode_build_output/ -iquote /Users/paulsolt/dev/xcode_build_output/ -F/Users/paulsolt/dev/xcode_build_output/Debug-iphoneos -I/Users/paulsolt/dev/xcode_build_output/Debug-iphoneos/include -I/Users/paulsolt/dev/xcode_build_output/ -I/Users/paulsolt/dev/xcode_build_output/ -fvisibility=hidden -c /Users/paulsolt/dev/ArtworkEvolution/Xcode/ArtworkEvolution/../../source/Canvas.cpp -o /Users/paulsolt/dev/xcode_build_output/

Base SDK Mac OS X 10.5, GCC 4.2

CompileC /Users/paulsolt/dev/xcode_build_output/ /Users/paulsolt/dev/ArtworkEvolution/Xcode/ArtworkEvolution/../../source/Canvas.cpp normal x86_64 c++
cd /Users/paulsolt/dev/ArtworkEvolution/Xcode/ArtworkEvolution
setenv LANG en_US.US-ASCII
/Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/paulsolt/dev/xcode_build_output/ -I/Users/paulsolt/dev/xcode_build_output/ -I/Users/paulsolt/dev/xcode_build_output/ -iquote /Users/paulsolt/dev/xcode_build_output/ -F/Users/paulsolt/dev/xcode_build_output/Debug -I/Users/paulsolt/dev/xcode_build_output/Debug/include -I/Users/paulsolt/dev/xcode_build_output/ -I/Users/paulsolt/dev/xcode_build_output/ -fvisibility=hidden -c /Users/paulsolt/dev/ArtworkEvolution/Xcode/ArtworkEvolution/../../source/Canvas.cpp -o /Users/paulsolt/dev/xcode_build_output/


GCC 4.2 is required for 10.5, if you try and use the Base SDK of 10.4 and GCC 4.2 you'll get this error.

GCC 4.2 is not compatible with the Mac OS X 10.4 SDK

iPhone Unit Testing Explained - Part 1


Here's the first part of a multi-part iPhone Unit Testing Series. (Updated 3/31/12 with Xcode 4 testing)

For the second part of iPhone Unit Testing Explain - Part II

How comfortable are you on a bike without a helmet? Writing code without tests is like riding a bike without a helmet. You might feel free and indestructible for now, but one day you'll fall and it's going to hurt.

I can't start a new project without source control, it's one of my requirements. Personally, I feel very uncomfortable and exposed without something to track my code changes. In reality, I hardly need to revert changes, but the knowledge that I can go back to something else enables me to make bigger and more confident changes.

Testing should also be a requirement and it doesn't get enough attention in the classroom or on code projects. Part of the problem is that there is a lack of information and the high learning curve. Most tutorials provide the bare minimum and don't provide real world examples. There are two major hurdles that you'll need to overcome.

1. How do I use this testing framework?

Getting started with some new technology is always a daunting task. The only way you're going to learn is if you teach yourself. Make sure to free yourself from distractions and get a cup of coffee so you can think clearly. When there are lots of unit testing frameworks and you need to evaluate what your requirements are going to be. For beginners it's not always clear and you're going to have to sample the available options.

[ad#Link Banner]

2. How do I write testable code?

Most computer science courses don't explain how to write testable code, they focus on the output matching. Students assume that if my code displays X and I'm trying to display X, then the code must be correct. Testable code can be hard to master, but it's worth the effort. There's two important aspects of unit testing that I've discovered.

a. A unit test, or a set of unit tests, validates that the function you just wrote works like you think it works. It takes microseconds for the computer to tell you if something works or not, and it takes you seconds or minutes to validate if it works. Your time is valuable, let computers do the grunt work of testing and you'll have more time to write code.

b. Unit tests force design testing. High-level designs don't translate into direct code without usability issues. As you write and test code you will find that a function should take X parameters instead of Y parameters, or that the function name doesn't match the functionality it provides. Take the time to fix your design and you'll have code that's easier to use and better documented. The sooner you fix design issues, the more time you'll have to work on features.

I still haven't answered how to write testable code. Getting started is a matter of baby steps; take two steps at a time, and soon you'll be walking.

a. Isolate the basic functions that have clear input and output. Write a test that provides a function with good input and bad input. Think about what additional functions you'll need to prove that the function you're testing works as expected. For example, in order to test a setter function, you'll need a getter function. As you write more tests, refactor common tasks into helper functions, so that you can spend more time testing functionality instead of writing boilerplate test code.

b. Make sure you document each function as you test it, if you don't write comments now, it's never going to happen. Documentation is best when the details of the function are fresh in your mind and you can explain the edge cases.

Not everything is easy to test, but don't be discouraged, since the tests you write will begin to validate that your code works as documented. You're making progress and it's going to get easier as you write more tests. Another benefit is that you'll have higher quality code that you can rely on into the future.

[ad#Large Box]

iPhone Testing

Over the past weekend I set out to integrate a unit test framework into my current project. I ended up testing three different frameworks: OCUnit, Google Toolbox for Mac (GTM) iPhone Unit Testing, and GHUnit. I will provide a brief overview and pros and cons to each framework and my final conclusion.

OCUnit (SenTesting)

Pros:  Xcode integration (super easy), acceptance testing during builds, test debugging in Xcode 4 (Updated 3/31/12 for Xcode 4 improvements)
  • Xcode 4+ has built in support for unit testing using the OCUnit testing (SenTesting) framework. It's easy to create a new test case, since there are Xcode test/target templates.
  • Xcode can display test failures like syntax errors with the code bubbles during the build/run stages, which can facilitate acceptance testing. These errors will link to the file and unit test that is failing, which is very helpful in terms of usability.

[caption id="attachment_854" align="aligncenter" width="555"] OCTest Unit Test Failure Code Bubble[/caption]

Cons:  logic tests vs. application tests, device/simulator test limitations
  • There are far too many steps required to create the unit tests in Xcode 3.2.4. I'm not sure why more of the process isn't automated, maybe in Xcode 4? To provide test coverage I needed to create 3 additional test targets each with specific settings
  • Writing a test for something basic (addition) is trivial using OCUnit, but testing code (memory management) that may crash isn't. You need to follow a special set of instructions to get unit testing debugging work, otherwise you'll be scratching your head. (Link 1) (Link 2) (Link 3)
  • Apple created their own categories of tests: logic tests and application tests, but the distinction isn't clear. Logic tests are meant to test code that doesn't use any UI code, while Application testsare designed for testing UI related code. This sounds fine, but when you try to create unit tests, the code you're testing becomes very tightly coupled to the tests you can write.
    • For example, logic tests are not run in an application, so code that would provide a documents or bundle directory for saving/loading may not work without refactoring the code.
  • The biggest limitation is that logic tests only run using the iPhone Simulator and application tests only run on the device. Logic tests are not run when you build for the actual device, so you have to constantly switch between simulator/device to get acceptance test coverage. Running application tests only on the device is very slow, compared to running it in the iPhone Simulator.

[caption id="attachment_856" align="aligncenter" width="528"] OCTest Application Testing on the Device[/caption]

Google Toolbox for Mac (GTM):  iPhone Unit Testing

Pros:  Xcode integration, acceptance testing during builds, easy setup
  • GTM iPhone unit testing provides code bubbles with test failures, like OCUnit, when building the target for the iPhone Simulator. The failure indicators are better than OCUnit, since it includes the error icon on the line of failure in GTM. However, the code bubbles do not appear when building for the device. The code bubbles can be clicked on to take you to the unit test that is failing. You can perform acceptance testing when building for the iPhone Simulator.

[caption id="attachment_850" align="aligncenter" width="540"] GTM iPhone Unit Testing Test Failure Code Bubbles[/caption]

  • Compared to OCTest, GTM iPhone Unit Testing is a breeze to setup. You can write unit tests that target the UI and logic of your code within the same class.

[ad#Link Banner]

Cons:  Documentation, output
  • GTM iPhone unit testing was straightforward to setup using the google code guide. The documentation is a little sparse, but it provides enough to get going. I think pictures would help explain the process and help break up all the text. I found the following visual tutorial semi-helpful, but there's no definitive source.
  • When building a test and running the script during the build phase there is a lot of extraneous output that can be overwhelming. Some of the output is visible in the previous code bubble screenshot and the screenshot below. The output is not formatted as nicely as the OCTest output.

[caption id="attachment_852" align="aligncenter" width="542"] GTM iPhone Unit Testing Log Output from a Test Run[/caption]


Pros:  Device/simulator testing, easy debugging, easy setup, iPhone Test Result GUI, command line interface
  • GHUnit has the easiest setup process of the three unit testing frameworks. It's based on GTM and it is capable of running OCUnit, GTM, and GHUnit test cases. The documentation is pretty good and there is a nice visual setup guide.
  • GHUnit is easy to debug any test case without any additional setup. Place a breakpoint and run the test application in the simulator or on the device.
  • GHUnit provides a way to run tests on the command line, if you want to integrate with continuous integration tools. (Hudson)
  • The major selling point is that it provides a graphics user interface to display the results of each test, including test duration, if performance is important. The interface allows the user to switch between all tests and failed tests in a unit test application. Additionally, it drill into a test failure to display the unit test failure message and the stack trace. After using GHUnit, GTM Unit Testing leaves a lot to be desired beyond log output for visual feedback.
    • The GUI enables a pleasant workflow where you can set breakpoints and re-run tests to try and isolate bugs in the test code. The workflow replaces the need to perform acceptance testing during the build process, because it is so much more interactive.
    • On iPhone 4 it will resume on the All/Failed tests tab that you were last running/debugging. Note:  There is a minor issue described below in the cons section.

[caption id="attachment_857" align="aligncenter" width="248"] GHUnit Testing All Test Cases on the Device[/caption]

[caption id="attachment_858" align="aligncenter" width="248"] GHUnit Test Case Failures[/caption]

[caption id="attachment_859" align="aligncenter" width="248"] GHUnit Test Case Failure Message[/caption]

Cons:  No acceptance testing, Documentation, minor GUI issues, Setup Time
  • There is no way to run tests as part of the build process using GHUnit. It's a paradigm shift from the OCUnit and other similar unit testing frameworks that enable testing during the build process. However, you can use a continuous integration framework to run unit testing as you check in code to a central repository.

[ad#Link Banner]

  • Documentation is good, but it could be better. The behaviors of the GUI are not clearly defined. Finding the GHUnitIOS.Framework was not clear in the documentation. I updated an article on github that addressed the documentation issue.
  • There are some minor GUI issues, if you use the GUNIT_AUTORUN environment variable. If you switch to the Failed tests tab on the GUI, it will only run the failed tests. Running the subset is good when you're fixing an issue, but it can be confusing if you're adding a new test. The new test won't run until you switch back to the Alltests tab. Setting a breakpoint on the new test, will also do nothing, since it doesn't run.
    • I'd like to see an additional button on the Failed tests tab that says "Run All Tests" and on the All tests tab a "Run Failed Tests" button. I think the additional buttons would make it clear that run doesn't always do the same thing.

[caption id="attachment_861" align="aligncenter" width="248"] Only the Test Failures are Rerun on the Failed Tests Tab[/caption]


Update: 3/31/12 With Xcode 4, creating and debugging unit tests in Xcode is so easy, it's not worth the initial effort to integrate GHUnit, unless you need visual feedback on the device.

I would recommend using the built in Xcode 4 unit testing bundles and then add GHUnit after the fact, when you need visual feedback. GHUnit is compatible with the default testing available in Xcode 4.

The testing interface in GHUnit is the easiest to see test results and it doesn't require as much log output digging. I like the workflow I have when using GHUnit.

  1. Switch to the GHUnit Test Target
  2. Write unit test for new function
  3. Test new function (Command-R) and see it fails (Optional)
  4. Stub and implement new function
  5. Test implementation (Command-R). Repeat 4 until the test passes
  6. Repeat for next function
  7. Switch back to the Application Test Target

Updated: (3/31/12) With the release of Xcode 4 and more integrated testing, using OCUnit/SenTest is a lot easier to get started. I will be providing a walk through on setting up Xcode 4 and working with bundle resources in the next part.

(Part II - working with unit tests in Xcode 4)

[ad#Large Box]