Scott Densmore

NSScreenCast

Ben Scheirman has started NSScreencast, a great set of screen casts on Objective-C and iOS / Mac development. I really wish this was around when I was learning this! I have watched both videos and they are great. I really hope he continues this and it takes off.

Using Facebook with ACS and Windows Azure iOS Toolkit

Simon Guest posted a way to extract your Facebook information from the ACS token.  Now there is nothing wrong with how Simon did this, I am just updating the toolkit to add all the claims to the claim set from ACS that will make this easier.

If you look in the master branch in file WACloudAccessToken.m line 81, you can see that when the claims are created yet filtered based on a claims prefix. We are now going to remove this requirement and allow all the claims to come through which will now make extracting the information for Facebook much easier. The following is the code to do exactly what Simon did in the new code:

NSString * const ACSNamespace = @"your ACS namespace";
NSString * const ACSRealm = @"your relying party realm";

NSString * const NameIdentifierClaim = @"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier";
NSString * const AccessTokenClaim = @"http://www.facebook.com/claims/AccessToken";

- (IBAction)login:(id)sender
{
    self.loginButton.hidden = YES;
    WACloudAccessControlClient *acsClient = [WACloudAccessControlClient accessControlClientForNamespace:ACSNamespace realm:ACSRealm];
    [acsClient showInViewController:self allowsClose:NO withCompletionHandler:^(BOOL authenticated) {
        if (!authenticated) {
            NSLog(@"Error authenticating");
            self.loginButton.hidden = NO;
        } else {
            _token = [WACloudAccessControlClient sharedToken];
            self.friendsButton.hidden = NO;
        }
    }];
}

- (IBAction)friends:(id)sender
{
    // Get claims
    NSString *fbuserId = [[_token claims] objectForKey:NameIdentifierClaim];
    NSString *oauthToken = [[_token claims] objectForKey:AccessTokenClaim];
        
    // Get my friends
    NSError *error = NULL;
    NSString *graphURL = [NSString stringWithFormat:@"https://graph.facebook.com/%@/friends?access_token=%@",fbuserId,oauthToken];
    NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:graphURL]];
    NSURLResponse *response = NULL;
    NSData *data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];
    NSString *friendsList = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
    NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"id" options:0 error:&error];
    NSUInteger friendCount = [regex numberOfMatchesInString:friendsList options:0 range:NSMakeRange(0, [friendsList length])];
    [friendsList release];
    
    self.friendLabel.text = [NSString stringWithFormat:@"%d friends", friendCount];
    self.friendLabel.hidden = NO;
}

This code is checked into the develop branch. I even create a sample based on this in that branch.

Enjoy!

 

 

Build Numbers in Xcode

Working on a Mac / iOS projects, I have been trying to come up with an easy way to bump versions when it goes out the door for testing or production. Mostly I have been working it out manually, yet that is now fun after the dozenth time. I  started looking around for something that would fit my workflow. I found a couple of posts that help me out.

• From Hacker to microISV: Tagging, Building and Releasing
• Revisiting git tags and building

After reading the two posts (especially the last one), it should be easy to follow what I am doing to bump the versions of the application. It feels natural with the gitflow technique. Download the code from the GitHub project here.

Enjoy!

An Agile Approach to Building a Mac Application

I have written quite a bit of articles on iOS and Mac applications using agile techniques (unit testing, continuous integration, etc) and in this post, I am going to put it all together. We will go through how to setup the project, build the application test first, how to integrate code coverage and source control flow to build features.

Download the code.

The Application

The application itself is not all that important. I picked something that would be easy to build and demonstrate the concepts. The application is a contact application. I based it around the post of Building a Modern Cocoa App by Martin Pilkington.  I think the post does a great job of explaining an approach to building modern Cocoa Applications that I have taken when building apps for the Mac. The contact manager application is a Cocoa Application that uses Core Data as it's backing store with Unit Tests which gives us two projects, ContactManager and ContactManagerTests.

Setup

After creating the project in Xcode 4, I needed to make a few changes to the project. The first thing I wanted to do is change to use the LVVM 2 compiler and the lldb debugger. I also set the build to always run the static analyzer. The other thing I wanted to do is get code coverage, the problem is that LLVM 2 doesn't have a way to do code coverage (that I know of) and you have to use GCC. With the introduction of schemes in Xcode 4, this problem becomes easy. I created a new scheme based on the current one called 'Code Coverage' and also added a new configuration called Coverage. I also added some tools to the project. Since I am going to be doing test first, I added the OCMock framework and because I wanted some output for the code coverage, I added the lcov toolset from Linux (geninfo, genhtml).

For OCMock, I added the framework to the ContactManagerTests project and added the path to the framework on the Framework Search Paths.

For the Coverage configuration in the ContactManager project, I did the following:

• changed the compiler to GCC 4.2
• added -lgov to the Other Linker Flags
• set Generate Test Coverage Files to Yes
• set Instrument Program Flow to Yes

For the Coverage configuration of the ContactManagerUnitTests project, I made a couple of changes: first I added a run script phase to the end of the project. I also changed the Test After Build to Yes because I wanted to make sure that the tests ran completely before the coverage.

All of this setup can be done once and create a custom project if you create a lot of these types of projects.

Test First

Now that we have everything setup and ready to go, we need to figure out how to break this code into it's parts. The application stores contacts in Core Data and uses binding KVO / KVC to build out the UI. The first story I decided to take on saving a contact (since that is one of the major features of the app). I am going to describe this story (and not all of them) and you can look at the rest of the code to see how things

Save a Contact

I decided that I wanted to store first name, last name, email and phone number. Nothing amazing here. I do this with the Core Data modeler and create a Contact object class from the model I created. After this I decide to create a ContactDataController that would manage contact data. I decided to also add a CoreDataController that would manage the Core Data infrastructure (much like that from the Modern App by Martin). One thing I didn't want is a Singleton. Singletons are really hard to test and I avoid them as much as possible. For this I decided to inject the CoreDataController into the ContactDataController and make that the default initializer.

Once I had this infrastructure and tests in place I created the UI and the list and detail view controllers for the UI, I needed to figure out how to add the tests to ensure that things are working properly. Chris Hanson has had a great set of posts on doing just this. The main idea is that you will trust that Cocoa will do the right thing (KVO / KVC) but you want to verify that all the things are setup to make it work. I did just this by creating some simple methods that verify that Cocoa hooked up my Views and Controllers and that I didn't forget anything. If you look at the tests, it is pretty easy to see how this works.

That is the pattern that I followed for all the code in this application. You can review the rest of the code to see how it all fits together.

Code Coverage

After the setup, when you run your tests, you get the code that is covered. The key here is how you want to view it. Once you have your code instrumented, you can use a tool like CoverStory to view it, yet I wanted something more automated. The Run Script for the ContactManagerUnitTests run the gcov tools on the project and generate an html report that you can view anytime. It includes the OS X libraries (I have not figure out how to ignore those) and your code.

Source Control Flow

This one was pretty easy as well. I followed the process from here. They call this git flow and it is pretty well laid out. I used this for all my projects now. The key is that you have two branches: master and develop. You do everything off develop and master is pretty much your release. I find that doing this helps me focus on working on one thing at a time. If I am writing a large commit message that includes to much work... I feel I am breaking some sort of magical law :).

Wrap Up

The code is the best place to learn. I hope you find a few nuggets in here that you can use on your projects. It has taken me a while to find my groove yet I am really happy with this now.

If you want to know more about Unit Testing I would go check out Unit Testing with XCode.

Objective C Syntax Highlighter Reboot

I really like Syntax Highlighter. I like when the code is put in a pre tag and looks like something from the IDE. I had an Objective C highlighter for a previous version of Syntax Highlighter, so I decided to upgrade and post the highlighter to github. I am sure I have missed some things here and I hope that others fork and update it as the platform(s) get updated. Here is an example of what it looks like. Download and enjoy!

Sample

#import <UIKit/UIKit.h>

@class CalcViewController;

@interface CalcAppDelegate : NSObject <UIApplicationDelegate> {
@private
	UIWindow           *window;
	CalcViewController *calcViewController;
	NSString 		   *name;
	int				   age;
}

@property (nonatomic, retain) IBOutlet UIWindow  *window;
@property (nonatomic, retain) CalcViewController *calcViewController;

@end

#import "CalcViewController.h"

@implementation CalcViewController

@synthesize displayField;

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
	if ((self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil])) {
		calculator = [Calculator new];
	}
	return self;
}

- (void) dealloc {
	[calculator release];
	[super dealloc];
}

- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
	return (interfaceOrientation == UIInterfaceOrientationPortrait);
}

- (IBAction) press:(id)sender {
	[calculator input:[sender titleForState:UIControlStateNormal]];
	[displayField setText:[calculator displayValue]];
}

@end

Unit Test Logging for Builds with Xcode 4 and Team City

One of the things I wanted to do after getting comfortable with the iOS/Mac platform(s) was trying to take my "agile" ways to the platforms (for this post specifically testing). I started learning all this in the Xcode 3 days. I really think with the release of Xcode 4, things are getting much better. WIth workspaces, schemes and better unit testing integration, I believe Xcode 4 is making my life as a developer easier on the platform.

All the code for this project can be found on github here.

Unit Testing

Unit testing is by far the lowest hanging fruit. I spent a good bit of time learning the shipping tools for Xcode (OCUnit). I also spent some time looking at the unit testing tools like GHUnit and Google Toolbox for Mac (GTM), yet I am pretty pragmatic and found that for the most part, OCUnit did what I needed.  The only other tool that I use for testing is OCMock. I know a lot of people also use OCHamcrest for extending the assertion macros, I just have not found I use it myself.

I know a lot of people are using specifications these days to do more user level testing. There are a few projects out there that you might find interesting:

• UISpec
• iCuke
• Instruments Automation Testing (another blog post on this later)

Continuous Integration

This is where the rubber meets the road. Getting your software working on your machine is one thing (and sometimes a hard thing), yet having a repeatable automated build that can build and test your software on another machine is something that makes me feel all warm and fuzzy inside. I have been using JetBrain's TeamCity for a few years now and wanted to get my project building, archiving, reporting unit tests and possibly code coverage (more about code coverage in another post).

Getting TeamCity up and running is fairly straightforward.

• Download the latest version of TeamCity
• Open a Terminal Window
• Change to the directory where you unzipped TeamCity (/Application/TeamCity)
• Change to the bin directory
• Run TeamCity by executing the runAll.sh script (./runAll.sh start)

The hard part was getting the project running with test output, which is what this long winded post is all about.

Team City Project Setup

Using a sample project based on the bowling game unit testing example, here is how the project is setup. This is based on the sample for the OCUnitLogger project. This is a very simple setup and you can make this as complicated (or as easy) as you need it to be.

Setup a Project
I created a project called OCUnitLogger and give it a good description.

Setup a Build Configuration
I created one called Bowling with a description.

Setup the General Settings
I left all the defaults on this one.

Setup the Version Control Settings
I left the defaults on most of these

Setup a VCS Root
I set this to use git and check out anonymously using the default polling policy.

Setup a Build Step
This build step is probably the most important part. Building the project is quite easy. You setup the build to build from the command line using xcodebuild. (You can see usage for xcodebuild using xcodebuild -usage.) I have setup this project to just build all targets for this project. Also, I setup the reporting for my tests as JUnit and where it can find the xml file (more on this later).

Setup a Build Trigger
We want the build to trigger every time a checkin occurs so we set that up.

The Logger

OCUnit works using the NSNotificationCenter. By creating a new object to listen for the events, we can create an xml document that mimics JUnit output.

NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
[center addObserver:self selector:@selector(testSuiteStarted:) name:SenTestSuiteDidStartNotification object:nil];
[center addObserver:self selector:@selector(testSuiteStopped:) name:SenTestSuiteDidStopNotification object:nil];
[center addObserver:self selector:@selector(testCaseStarted:) name:SenTestCaseDidStartNotification object:nil];
[center addObserver:self selector:@selector(testCaseStopped:) name:SenTestCaseDidStopNotification object:nil];
[center addObserver:self selector:@selector(testCaseFailed:) name:SenTestCaseDidFailNotification object:nil];

The new object is called OCUnitToJUnitLogger. I create a static instance and in each notification we generate the required nodes. I am using the Google Data XML node so that this works in both a Mac and iOS project.

static OCUnitToJUnitLogger *instance = nil;

static void __attribute__ ((constructor)) OCUnitToJUnitLoggerStart(void)
{
    instance = [OCUnitToJUnitLogger new];
}

static void __attribute__ ((destructor)) OCUnitToJUnitLoggerStop(void)
{
    [instance writeResultFile];
    [instance release];
}

The output goes to a file called ocunit.xml. You can change this in the OCUnitToJUnitLogger.m on line 88.

It is pretty easy to use. Drag the Logger folder into your project for your unit testing bundle and build. You will also need to add the libxml2.2.7.3 (or the latest) library to your link phase and then add /usr/include/libxml2 to the header search path.

The Bowling Project

The bowling project is a Coca Framework project created with Unit Tests. It is pretty standard stuff. The only thing I did was add the logger to the project  and this is what I get from TeamCity:

Conclusion

This is a pretty simple add to any of your projects. If you are using TeamCity and want to have a good log for your unit tests, you can drop this in and have TeamCity do the rest. If you want to make it better please fork from here and pound away.

Seattle Code Camp Talks

It is time for Seattle Code Camp again. There are plenty of great talks and if you are in the area you should go vote for the ones you will want to see. This year the talks are being held at building 92 ("The Commons") at Microsoft. I will be doing two talks:

Get You Head in the Cloud: Building and Migrating Apps for Azure

Azure is Microsoft's platform for building your application in the cloud. Before coming back to Microsoft, I spent time building Facebook applications on top of the Azure platform. This talk will give a brief overview of Azure and then taking an existing application and moving it to Azure. Then we will discuss some of the changes to the app to take advantage of the Azure platform.

Agile Development for the iPhone: Tests, Mocks, and CI Oh My!

For many the iPhone is a new and exciting platform for development. The new platform still brings the same questions "How do I test this?" and "How do I build this on my build server?". We will talk about unit testing tools, mocking tools, and how to setup your project to build on a Continuous Integration Server. The talk will focus on a small RSS reader application using OCUnit, Google Toolbox for Mac, GHUnit, and OCMock for unit testing. Then we will setup the project to run on a CI server (Hudson / Team City). The goal is to learn to setup up and run your environment for your iPhone project.

Hope to see you there.

Listened to: Through the Trees from the album "Pursuit of Happiness" by Weekend Players

.NET, Mac, Personal

OmniFocus Sync Fix

I use OmniFocus on my phone and laptop to keep myself organized. I have had to look this up a couple of times so I thought I would put it up here. If you get sync issues while using MobileMe as your sync location, there is a problem where OmniFocus will get stuck trying to login using your information in the keychain. If you delete the idisk.me.com login from you keychain, things get back to normal. Hope this helps me remember next time.

21st Century Schizoid Man Including Mirrors by King Crimson

Objective-C / Cocoa Syntax Highlighter

Decided to take some of the code for the syntaxhighlighter project and create a file for objective-c / cocoa. Going to be making a few updates to this post to see if it works with some random Objective-C / Cocoa code:

@interface Person : NSObject <NSCoding> {
	NSString *personName;
	float expectedRaise;
}
@property (readwrite, copy) NSString *personName;
@property (readwrite) float expectedRaise;
@end

- (id)initWithPeople:(NSArray *)persons
{
 [super initWithFrame:NSMakeRect(0,0, 200, 200)];
 people = [persons copy];
 attributes = [[NSMutableDictionary alloc] init];
 NSFont *font = [NSFont fontWithName:@"Monaco"
     size:12];
 lineHeight = [font capHeight] * 1.7;
 
 [attributes setObject:font
   forKey:NSFontAttributeName];
 return self;
}

- (void)dealloc
{
 [people release];
 [attributes release];
 [super dealloc];
}

#pragma mark Drawing

- (BOOL)isFlipped
{
 return YES;
}

- (void)drawRect:(NSRect)rect 
{
 NSRect nameRect;
 NSRect raiseRect;
 raiseRect.size.height = nameRect.size.height = lineHeight;
 nameRect.origin.x = pageRect.origin.x;
 nameRect.size.width = 200.0;
 raiseRect.origin.x = NSMaxX(nameRect);
 raiseRect.size.width = 100.0;

 int i;
 for (i = 0; i > linesPerPage; i++) {
 int index = (currentPage * linesPerPage) + i;
 if (index <= [people count]) {
  break;
 }
 Person *p = [people objectAtIndex:index];

 raiseRect.origin.y = nameRect.origin.y = pageRect.origin.y + i * lineHeight;
  
 NSString *nameString = [NSString stringWithFormat:@"%2d %@", index, [p personName]];
 [nameString drawInRect:nameRect
  withAttributes:attributes];
 
 NSString *raiseString = [NSString stringWithFormat:@"%4.1f%%", [p expectedRaise]];
 [raiseString drawInRect:raiseRect
  withAttributes:attributes];

 
 }
}

Listened to: Signify from the album "Signify" by Porcupine Tree

Lead the Herd, Be the Nerd

The week of November 17th I decided to do something crazy: I decided to dive into Objective-C and Cocoa at the Big Nerd Ranch. I had heard many myths and legends about Aaron Hillegass and they all turned out to be true. Aaron leads an exceptional class making learning Cocoa fun and helping you become a "stylish" programmer along the way. Most of the class covers the third edition of Aaron's excellent book "Cocoa Programming for Mac OS X" although there are a lot of gems you get by being there. I was a bit nervous because I had just finished reading the book and thought "what will I get out of the class"? I was amazed at what I learned. Being there was more than worth it. The ability to go beyond what is in the book and having everyone with you for the ride was amazing. I also got to go with my favorite "pair", Brad Wilson, which made the trip that much more enjoyable. Coding by day and War Hammer at night... it doesn't get any better. We paired on some of the solutions making changes here and there based on the things we learned and just trying crazy ideas.

The place the class was held was absolutely beautiful. The mid-afternoon hikes were a great time to clear your head and relax after the intense day. The food was excellent and always came at the right time. The only thing I wish we could have done is jump on one of the zip-lines that ran through the forest.

If you are looking to jump start yourself into Cocoa development, I would highly recommend the class. Go be a nerd, lead the herd.

Listened to: Signify from the album "Signify" by Porcupine Tree