Mark Needham

Thoughts on Software Development

Archive for the ‘Objective C’ Category

Objective C: Observations

with one comment

I’ve been playing around with Objective C over the last month or so and although my knowledge of the language is still very much limited I thought it’d be interesting to describe some of the things about the language that I think are quite interesting and others that keep catching me out.


I touched on protocols a bit in my first post but they seem like an interesting middle ground between interfaces and duck typing.

I like the fact that protocols can define optional methods so that if we’re not interested in some parts of the protocol we can just ignore those parts.

From the documentation page:

Protocols free method declarations from dependency on the class hierarchy, so they can be used in ways that classes and categories cannot. Protocols list methods that are (or may be) implemented somewhere, but the identity of the class that implements them is not of interest. What is of interest is whether or not a particular class conforms to the protocol

Smalltalkish style method names

We played with Smalltalk in a coding dojo a bit last year and the first thing that I noticed with Objective C is that the method names are very similar to those in Smalltalk.

I think this influences the way that we define the method name and its parameters as you try and define those in such a way that when you call the method it will read better.

For example I created the following method:

UILabel *aLabel	= [self createLabelFrom:project withXCoordinate:x withYCoordinate:y];

If I didn’t have to name the parameters when calling the method I doubt I would have used such descriptive names. I would have just used ‘x’ and ‘y’ as the names!

All methods are public/Defining methods in header files

As I understand it all the methods defined on an object are available to any other object to call i.e. all the methods are public

I’ve read about others using categories to simulate the idea of having non public methods but I haven’t tried anything myself yet.

Interestingly we get a compiler warning when trying to call methods on an object if those methods haven’t been defined in the appropriate header file although the code still seems to execute fine at run time.

Messages not method calls

One other thing that I sometimes forget is that we’re dealing with messages rather than method calls.

We still need to send the message to ‘self’ even if it’s a message being sent to another method on the same object.

Written by Mark Needham

August 31st, 2010 at 6:27 pm

Posted in Objective C

Tagged with

Objective C: Expected ‘(‘ before ‘Project’

with one comment

A mistake I’ve made more than a few times while declaring headers in Objective C is forgetting to explicitly import the classes used in the interface definition.

I’ve been refactoring some of the code I wrote earlier in the week and wanted to create a ‘LabelFactory’. I had the following code:


#import <UIKit/UIKit.h>
@interface LabelFactory : NSObject {
+ (UILabel*)createLabelFrom:(Project *)project withXCoordinate:(NSInteger)x withYCoordinate:(NSInteger)y;

Which gives this error on compilation:

/Users/mneedham/SandBox/iPad/CIMon/LabelFactory.h:9:0 /Users/mneedham/SandBox/iPad/CIMon/LabelFactory.h:9: error: expected ')' before 'Project'

I’ve been wondering what that error message actually means for a while and more by accident than design I re-read the section of Apple’s documentation on ‘referring to other classes

An interface file declares a class and, by importing its superclass, implicitly contains declarations for all inherited classes, from NSObject on down through its superclass. If the interface mentions classes not in this hierarchy, it must import them explicitly or declare them with the @class directive:

Declaring ‘Project’ with the ‘@class’ directive just above ‘@interface’ helps fix that problem:

@class Project;
@interface LabelFactory : NSObject {

The original error message I was getting is still slightly mystifying to me…

Written by Mark Needham

August 14th, 2010 at 10:33 am

Posted in Objective C

Tagged with

Objective C: Back to being a novice

with one comment

As I mentioned in my previous post about parsing an XML file in Objective C I’m a novice on the Dreyfus Model when it comes to this type of development and I’ve found it interesting that I’ve dropped back into habits from my PHP days when I was first learning how to program.

The big picture

My first instinct after I’d created a project in XCode was to try and understand how an iPad application fits together.

While this approach has worked fairly well for me in languages that I’m familiar with I found that I ended up shaving multiple yaks all at once.

I know too little about all of the individual components such that when I start reading how they all work together I end up veering off track and reading about how each of the components work on their own.

For the moment I’ve put the big picture to one side and I’m just trying to understand the ins and outs of the language by hacking bits of code together.


Talking about hacking code, I’ve found myself copying and pasting example code that people have posted and then tweaking it bit by bit, re-running the code each time to check I haven’t broken anything.

Eventually I’ll need to learn how to write the code from scratch but at the moment I make way too many mistakes that the copy/paste approach gives me quicker feedback about how the language works.

When the code stops working I find myself commenting out code until I get it back into a working state because I’m not yet able to intuitively narrow in on where the problem might be.

Limit the hours a day

Perhaps due to the frustration of everything being a struggle I find that I’m quite mentally fatigued after coding for a few hours.

On the days when things work more frequently than not I find that I can code for longer but at the moment I’m finding it more beneficial to stop coding when I’m getting too frustrated and then pick it up later.

Quite frequently I’ll work out how to do something that I was really struggling with after leaving it for a while.


Despite being a big fan of Test Driven Development I haven’t written a single test in Objective C yet.

While that will probably be the most effective way to develop code, as I’ve previously suggested, I don’t necessarily think it’s the most effective way to learn a new language.

The feedback loop is slowed down as you first try and setup a testing framework and because you don’t know the syntax that well it’ll probably be a bit of a struggle to get a test setup.

Writing a bit of code and then compiling and running it provides a feedback loop which is working fine for me at the moment although I’m sure at some stage I’ll drift back towards my TDD roots.

Written by Mark Needham

August 6th, 2010 at 3:59 am

Posted in Objective C

Tagged with

Objective C: Parsing an XML file

with 12 comments

I’ve been wanting to try out some iPad development for a while and as a hello worldish exercise for myself I thought I’d try and work out how to parse the cctray.xml file from Sam Newman’s bigvisiblewall.

Realising that I’m a novice on the Dreyfus Model when it comes to Objective C I started out by following a tutorial from iPhone SDK Articles which explained how to do this.

The first thing I learnt is that the built in library follows an event driven approach to handling XML.

As I understand it we create a parser which steps through the XML document and then raises various events based on what it finds in the document. e.g. an event will be raised when we reach the end of an element.

Those events will then be handled by a delegate that we setup on the parser.


I included the ‘cctray.xml’ file in the ‘Resources’ folder of my XCode project just to simplify things and this is the code that we would need to setup the parser to read the file:

	NSString* path = [[NSBundle mainBundle] pathForResource:@"cctray" ofType:@"xml"];	
	NSURL *url = [NSURL fileURLWithPath:path];
	NSXMLParser *xmlParser = [[NSXMLParser alloc] initWithContentsOfURL:url];
	XMLParser *theDelegate = [[XMLParser alloc] initXMLParser];
	[xmlParser setDelegate:theDelegate];
	[xmlParser parse];

‘theDelegate’ needs to be an instance of an object which conforms to the NSXMLParserDelegate protocol.

All the methods on this protocol are optional so that seems to mean that any object we passed to ‘setDelegate’ would be fine.

The cctray XML looks like this:

  <Project name="Project 1 :: Fast" activity="Sleeping" lastBuildStatus="Success" lastBuildLabel="3.0.754" lastBuildTime="2009-07-27T14:17:19" webUrl="http://localhost:8153/cruise/tab/stage/detail/enterprisecorp-3/3.0.754/build/1" />

Since we’re mostly interested in getting the attributes of each ‘Project’ element we want to provide an implementation for the ‘parser:didStartElement:namespaceURI:qualifiedName:attributes:’ method on our ‘XMLParser’ object.

The ‘attributes’ part of this method is what we’re interested in and we can extract the data we’re interested in with the following code:

@implementation XMLParser
- (XMLParser *) initXMLParser {	
	[super init];
	return self;
- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName 
  namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qualifiedName 
	attributes:(NSDictionary *)attributeDict {
	if([elementName isEqualToString:@"Project"]) {		
		NSString *name = [attributeDict objectForKey:@"name"];
		NSString *lastBuildStatus = [attributeDict objectForKey:@"lastBuildStatus"];

If we were interested in getting the actual body of any of the elements then we’d need to implement the ‘parser:foundCharacters:’ method but in this case what I want to do is much simpler so that’s unnecessary.

I found the event driven approach to parsing XML quite interesting and it reminds me a bit of node.js and its approach to dealing with web requests by raising various events. Perhaps it’s just that I’ve started to notice it but the event driven approach seems to be more prevalent these days.

Written by Mark Needham

August 4th, 2010 at 5:00 am

Posted in Objective C

Tagged with