Swish Movement

Update: Lion sleep woes solved

2011-08-22T21:16:00.011+01:00

In my previous post I was complaining how my MacBook would no longer sleep. The sleep function worked well after installing Lion but then stopped working unexpectedly.
It turns out that this is not an uncommon problem with many people complaining of the same issue. Advice on how to fix it varies wildly with solutions including (but not limited to): SMC reset, PRAM reset, turn off preference X, delete folder Y - there are even 3rd party application to force your Mac to sleep.

However the advice that worked for me was actually fairly logical:

1. Use pmset to view the power management settings:

localhost:work teabot$ pmset -g

    ...

    disksleep	10

    sleep		0 (imposed by 46)

    hibernatemode	3

    ...

The interesting thing in the output is the line that states 'sleep 0' - presumably indicating that sleep mode is disabled. Further along this line we find 'imposed by 46'. This is actually telling us the id of the process (PID) that is blocking sleep mode.

2. List the process with the matching PID:

localhost:work teabot$ ps -ef | grep 46

    0  46  1 0 9:05pm ??  0:00.16 /usr/sbin/cupsd -l

    0 107 46 0 9:05pm ??  0:00.59 ipp://nano.local.:631/printers/HP_Photosmart_C4100_series 7...

    ...

So we can see that a queued print job is inhibiting sleep mode and in this case I resolved the issue by clearing my print queue at which point my MacBook was happy to sleep once more.

It's pretty bizarre that a queued print job should disable sleep mode. The action of me closing the MacBook lid should make clear my intention of wanting the computer to sleep. If the print job is so important - perhaps a warning dialog should be issued so that I might have some idea why sleep mode will not be activated?

I assume that other types of process may inhibit sleep mode. Thankfully the pmset command includes some unexpectedly useful output to help us figure out which process is responsible. I can't imagine how long it would've taken me to find the errant print job without it.

More OSX Lion woes

2011-08-22T08:22:00.007+01:00

I having more small yet significant problems with OSX Lion. I'm running the latest version - 10.7.1 - on both my MacPro and MacBook.

My MacPro:
I find that I frequently lose the ability to resolve DNS names. This is only resolved by restarting the machine. Some Googling suggests that this issue may be due to a failing mDNSResponser process. I use this machine as a media server, so in practice I get up in the morning and try to tune some Internet radio only to find that I need to reboot my media server before I can do so. I'm going to try killing the process so that I don't have to restart the machine each time.

My MacBook:
Sometimes my MacBook just won't sleep. Closing the lid, Cmd-Alt-Eject, and the Apple menu option have no effect. It's really frustrating. Some people report that this can happen if Internet Sharing is enabled - it's not in my case. Apple's 'sleep' implementation used to be its crowning jewel. Coupled with OSX's stability I could: go months without rebooting my laptop, have a working system within seconds of opening the lid, happily sling my MacBook into a bag just moments after shutting the lid. I can't anymore...

When I wake this machine from sleep - when I can actually get it to sleep that is, I often find that the wireless card is in an unknown state. This makes it impossible to connect to a wireless network or switch the wireless off. The machine seems to sort itself out after a few minutes but it's quite annoying - especially if I'm trying to look something up in a hurry.

Summary: With this extremely poor OSX Lion release Apple has reminded us what it was like to run Windows XP on a cheap laptop in 2002.

Inheriting Maven profiles

2011-08-10T15:46:00.006+01:00

I'm in the process of moving a number of projects from Ant/Ivy to Maven. Many of our projects use Thrift and we use a Maven Thrift plugin to conveniently compile our Thrift IDL. Given that all of our Thrift projects have the same setup, the plugin is declared in a our parent POM.
The plugin is declared in a profile that is only activated when a thrift source directory is present:

  <profile>

    <id>uses-thrift</id>

    <activation>

      <file>

        <exists>${basedir}/src/main/thrift</exists>

      </file>

    </activation>

    <build>

      <plugins>

        <plugin>

          <groupId>org.apache.thrift.tools</groupId>

          <artifactId>maven-thrift-plugin</artifactId>

          ...

I actually have a number of plugins defined in such profiles so that they become active only when relevant source artefacts are present in the sub-project.

This all looks good, but in practice I found that the profiles were never activated in sub-modules that were being built from a parent project. It was as if the activation state was determined at the parent level, not on a per module basis.

It seems that profile inheritance does function as I expected in Maven 2. It does however work perfectly with Maven 3.

AFP failing between OSX Lion machines

2011-07-22T08:40:00.006+01:00

I recently upgraded both my MacPro and MacBook to Lion. The upgrades went fine, but I now find that I cannot open a non-guest AFP connection between the two machines. On the client I see 'Connection Failed...' and in the server console I find:


22/07/2011 08:39:20.350 AppleFileServer: _Assert: /SourceCache/afpserver/afpserver-581/afpserver/AFPRequest.cpp, 2005
22/07/2011 08:39:20.354 AppleFileServer: _Assert: /SourceCache/afpserver/afpserver-581/afpserver/AFPRequest.cpp, 2005
22/07/2011 08:39:20.400 AppleFileServer: Calling ReadLock on lock < 0x2a833128 > while holding WriteLock
22/07/2011 08:39:20.524 ReportCrash: DebugSymbols was unable to start a spotlight query: spotlight is not responding or disabled.
22/07/2011 08:39:20.965 com.apple.launchd: (com.apple.AppleFileServer[424]) Job appears to have crashed: Illegal instruction: 4
22/07/2011 08:39:21.062 ReportCrash: Saved crash report for AppleFileServer[424] version ??? (???) to /Library/Logs/DiagnosticReports/AppleFileServer_2011-07-22-083921_localhost.crash
22/07/2011 08:39:22.389 com.apple.launchd: (com.apple.AppleFileServer) Throttling respawn: Will start in 8 seconds

I also have a crash report.

This is fairly annoying as my MacPro acts as the Time Machine backup for my MacBook. Has anyone experienced anything similar and are there any workarounds?

Update: I found a work around: I removed all folders from 'System Preferences/Sharing/File Sharing/Shared folders' and I can now connect. The unfortunate side effect of this workaround is that now the whole file system on the server is shared - subject to the authenticated user's privileges.

An ordered builder pattern

2011-05-24T18:19:00.055+01:00

I was recently implementing the builder pattern for some immutable objects and was taking the approach described by Joshua Bloch in his excellent book 'Effective Java'. I particularly like the readability that the pattern provides when constructing complex objects and I think this arises because each property value is contextualized by the preceding method name:

Person.Builder builder = new Person.Builder();

Person person = builder.id(10).name("Jim").age(21)

.pets("cat", "dog").build();

I also like working with builders in an IDE because the auto-complete process can nicely lead you through the object's construction with a few taps of Ctrl+Space. However, there are a few things that could be improved with the pattern:

Handling of mandatory state

There are two obvious ways we can enforce mandatory properties with the pattern. Firstly we could pass mandatory property values in the builder constructor. This gives us a compile-time enforcement of mandatory properties. However, for many mandatory properties it can suffer from the problem that the pattern was meant to avoid - telescoping constructors. Imagine that the id and name are mandatory:

Person.Builder builder = new Person.Builder(1, "Jim");

Person person = builder.age(21).pets("cat", "dog").build();

The second way we can enforce mandatory properties is by checking the builder state in the build() method. This preserves the readablility API but relegates the mandatory property checking to run-time - quite a penalty.

Redundant invocation paths

Normally a property setter method on a builder just returns the builder instance:

public Builder id(int id) {

this.id = id;

return this;

}

This means that on the returned value we can call any other builder method, including the one that we just invoked. We could - if we wanted to - chain many redundant calls that overwrite the builder state:

Person person = builder.id(10).id(11).id(12).id(13).build();

While this isn't a likely to occur, it shows that the path we take through the building of the object isn't incredibly directed - it would be nice if we couldn't set the id more than once. We could do this at run-time but it would be far better if we were prevented from even writing such code! This lack of order also degrades our IDE auto-complete experience a little - imagine a builder with 20 properties - every time we see the auto-complete suggestions we have to mentally parse a list of 20 property setters - including those we've already set.

Adding order to the builder pattern

I had a go at addressing these (minor) short comings of the pattern and with some simple additions was able to create a builder that can lead you through the building process and enforce mandatory properties at compile-time in a nice contextualized way. The trick is to create a number of subordinate builder classes.

Consider an immutable value class:

  public class Person {

    private final int id;    // MANDATORY

    private final String name; // MANDATORY

    private final int age;  // OPTIONAL

    private final Set pets; // OPTIONAL

...

Now let's deal with the mandatory fields. It makes sense that you must first set the id property before doing anything else. Therefore the only possible method invocation from our builder class will be id(int id) - but what should this return? The next step in our builder sequence is to set the mandatory name, therefore we should return a builder class on which you can only invoke the name(String name) method, so we defined a subordinate builder class NameRequiredFieldBuilder, that only allows the name to be set and return this from the invocation of id(int id):

  public static class Builder {
    ...
    public NameRequiredFieldBuilder id(int id) {
      this.id = id;
      return requiredName;
    }

...

    public static class NameRequiredFieldBuilder {
      private final Builder builder;

      private NameRequiredFieldBuilder(Builder builder) {
        this.builder = builder;
      }

      public ? name(String name) {
        builder.name = name;

        return ?

}

So we can now change the builder invocations like so: builder.id(10).name("Jim") - in fact we no option but to call these methods, in this order. Let's deal with providing the builder with the the optional fields. At this point we'd like to be able to call age(int age), pets(String... pets), or build(). and we'd like to do this using the object returned by name(String name). To achieve this we define a subordinate builder class for the optional fields and the build() method:

  public static class OptionalFieldsBuilder {
    private final Builder builder;

    private OptionalFieldsBuilder(Builder builder) {
      this.builder = builder;
    }

    public OptionalFieldsBuilder age(int age) {
      builder.age = age;
      return builder.optionalFields;
    }

    public OptionalFieldsBuilder pets(String... pets) {
      for (String pet : pets) {
        builder.pets.add(pet);
      }
      return builder.optionalFields;
    }

    public Person build() {
      return new Person(builder);
    }

  }

An instance of OptionalFieldsBuilder is then returned by NameRequiredFieldBuilder.name(String name):

  public OptionalFieldsBuilder name(String name) {
    builder.name = name;

    return optionalFields;

}

So now we can call the builder property setters for the optional fields and then finally call the method to build an object instance. Full source code for this example.

Some observations

Breaking the builder into a number of subordinate builder classes allows us to introduce order into the build process. We can lead users of our API through the construction process, having them specify mandatory fields values first, only once, and potentially in order of importance. The modified pattern ensures that all mandatory fields are supplied at compile-time as it's not possible to invoke build() otherwise. The modified pattern does away with constructor supplied parameters and potential telescoping issues. Furthermore the subordinate builder classes limit method choices in our IDE's auto-complete mechanism to only the pertinent properties.

We could introduce additional structure to the invocations of the setters of the optional properties, however this might lead to a proliferation of subordinate builder classes. I feel that there is no need to dictate the order in which optional properties are set, and indeed how many times they are set.

From an implementation perspective, the overhead of creating subordinate builder classes for a few mandatory properties is small. A more scalable approach would be to use an annotation processor to generate the builder classes at compile time as had been done with Jan-Kees van Andel's make-builder tool.

Change of tack

2011-05-24T18:08:00.004+01:00

It's been a while since I've developed anything for IOS and I'm not back working with Java again at Last.fm. I have been dabbling with C/C++ on some Arduino projects at the London Hackspace - but other than that I'm pretty much a full-time Java developer. However, I really enjoyed writing about my programming experiences and have missed jotting my thoughts down on a this blog. Rather than start a new blog for general programming posts I've decided to repurpose this one given that it already contains some possibly useful programming content.

Hopefully my (3) followers won't be too put out by this :-) I have updated the strap-line and description of this blog to reflect this new direction.

For the record, the most successful Swish Movement post was that relating to private methods in Objective-C - I still get comments on that post!

Accessing SSHFS within finder

2009-09-09T10:22:00.003+01:00

I usually need to access remote systems using SSHFS and SFTP from my Mac. Unfortunately OSX Finder does not support this by default. To make my life a little easier I used MacFUSE and created a shell script to mount the relevant file system:

#!/bin/sh
sshfs user@myhost.com:/aPath/ ~/Desktop/myhost.com.mount-point \

-oauto_cache,reconnect,volname=myhost

However, this can be a little frustrating so I was very happy when a friend introduced me to MacFusion - a GUI based client for mounting SSHFS volumes. Try it!

Dependency Injection with the iPhone SDK

2009-06-22T23:30:00.005+01:00

Like many Enterpise Java developers - my first exposure to the Inversion of Control principle (IOC) was when applying the then radical Spring Framework some years ago. I believe that there was an IOC/DI micro container project being incubated at Apache Jakarta prior to Spring but it certainly didn't enjoy the same adoption rate.

We now find that we rely heavily on the Dependency Injection provided by our containers and frameworks. They take the responsibility for the monotinous, repetative, and tedious creational and configuration concerns of our classes leaving with much cleaner code. With some small amount of configuration they create our objects, configure them with appropriate values, and wire then up - injecting references into dependent objects. As developers this makes out lives much easier - we're no longer writing lots of boiler plate code - knowing that the frameworks will take care of it for us. Indeed we find the IOC principal in the latest releases of the EJB specification and in popular frameworks such as Spring, Seam and Guice.

But what does this have todo with iPhone development? Since starting work on a large iPhone project I have mostly concentrated my efforts on improving the data access and business logic layers of our application. However, over time I began to move towards the view tier - refactoring some of our UIViewContollers. More often than not the existing view controllers where monolithic classes servicing quite complex views. The views themselves could be broken down into logical units so I worked hard to move the various responsibilities of the view controllers into seperate classes that then became composite members of a parent controller - for example:

MyViewController

Became:

MyParentViewController
MyListViewController
MyToolbarController
MyDetailViewController

While this neatly divided and encapsualted responsibility - it created many dependencies that needed to be satisfied. For example, the MyViewController would have to construct it's sub-controllers and pass in references to UI components such as UIButtons etc. so that they could then be managed by the sub-controller object. To do of this I would have to write a lot of boring, error-prone code - passing view components in to object via init method arguments or properties. As well as being a little tedious this also prevents the code being as clean as it could be.

Fortunately I was missing an iPhone SDK Inversion of Control trick. The Interface Builder application is commonly used to create views using a hierarchical view component model - a concept that I assume most are familiar with - you might draw a rectangular view, add a few buttons and arrange them etc. The magic begins when you specify which UIViewController class should act as controller; Once the class has be set you can begin drawing connecting lines between the actual view components and the member variable names in that class - you describe you object dependencies using a visual metaphor - very cool!

This object dependency configuration is stored in the view's XIB (nib) file and is used by the iPhone frameworks to instantiate and wire up your objects at runtime.

While this is fairly intuitive for situations where we have views mapping to single monlithic controllers, it takes a little more work when we have composite controllers. In this scenario subsets of our view components might be managed by a class that is not and does not need to be a fully fledged UIViewController. However, this sub-contoller class will be a member of a parent composite UIViewController that pulls together multiple sub-controllers - each with their own distinct responsibilities for various view components within the larger view. Clearly, we would like to use Interface Builder to direct the instantiation of these sub-controllers and satisfy the referential dependencies between them, the parent controller, and the view components.

We can do this in Interface Builder by using the 'Object' component from the component library. We create a new object for the NIB by dragging the Object component from the library. We can then specify the class of the object we wish to instantiate using the Inspector.

However, this new object - created when the NIB is loaded - will be orphaned as it's not currently associated with any other objects. Lets assume that the parent controller may need to communicate with the sub-controller. In this event we need to create an IBOutlet in the MyParentViewController class:

@interface MyParentViewController : UIViewController {

@private

IBOutlet MySubController* subController;

...

In addition to this lets assume that the responsibility of the MySubController includes something button related and hence must have a reference to a UIButton in the view. In the MySubController class we need to create another IBOutlet - this time for the button:

@interface MySubController : NSObject {

@private

IBOutlet UIButton* button;

...

Notice that MySubController does not extend UIViewController - it doesn't need to as it's responsibilities are small and may be focused purely on a subset of view components. We can now wire these objects up in Interface Builder:

Now when the NIB is loaded the sub-controller object will be instantiated and a reference injected into the parent controller - all without any code or additional effort. With this approach we can begin to break-up those monolithic view controllers into classes that adhere to the Single Responsibility Principle so that our view controllers aren't doing 'too much'. In addition to this we can keep our classes nice and clean as we don't have to litter them with extra properties and init method arguments to pass references to dependent objects. We can rely on the platform to satisfy these dependencies by injection according to the relationships we defined previously in Interface Builder.

Clearly the above example does not live in the real world. However, I have found that for complex views an controllers the approach works extremely well.

SQLite optimization on the iPhone

2009-05-28T21:26:00.003+01:00

Our current iPhone application makes quite heavy use of SQLite. We persist the model in the database using a Data Access Object pattern built on top of my own JDBC like SQLite layer and it is all still quite lightweight. CoreData whould have been prefereable but we have to be compatible with iPhone SDK versions prior to 3.0. We also use the database to rank trends using indexed and weighted keywords and some additional temporal factors. Thankfully the text data we search through on the device is pre-indexed so we don't have to worry too much about getting suitable data into the tables. However we do need the database to run queries against this data and we spotted early on that optimization would be beneficial here.

I had some ideas of where we could improve and with a little Googling I found a sparse but useful SQLite optimization FAQ compiled by Jim Lyon. I quickly put together a hit list of optimizations that I'd try.

Use a between construct instead of LIKE

The FAQ explains that a LIKE cannot use an index and thus where possible it should be replaced with the > and < operators. For example:

word LIKE 'dog%'

Can be replaced with the more efficient:

word > 'dog' AND word < 'doh'

It's not a trivial replacement. Firstly the strings you are comparing must be of one case only. I also ran into trouble with international characters which of course don't fit nicely into the byte ranges. Furthermore you must write a little logic to generate the last character(s) of the 'upper limit term' (in this case 'dog'). Incrementing the last character is all well and good - but what about when you want to perform:

LIKE 'oz%'

I simply appended a low value character to the string to obtain the 'upper limit term' and ended up with something like: 'oz!' Thankfully I could work within these limitations for our use-cases and performance was much improved.

Move members of IN clauses into temporary tables

Many of our queries used variable length IN clauses. This made it unfeasible to prepare and cache the resultant statements and they would be prepared fresh each time. This sucked up and incredible amount of time - we might spend a second just preparing the statement. A typical clause is shown here:

AND id IN (32, 45, 67, 68, 80)

I decided that if I moved these values into a temporary table I could use a sub-select within the IN clause and hence end up with a static statement that I could prepare once and cache:

AND id IN (SELECT id FROM temporary_ids)

In addition to this I hoped to use a PRAGMA directive described in the FAQ to move the temporary tables off of the flash disk and into memory:

PRAGMA temp_store MEMORY

However, this setting does not seem to take effect on the iPhone version of SQLite which was somewhat disappointing. That said, the restructuring of my IN clauses did provided yet another significant performance improvement. I wouldn't be surprised if the row inserts into the temp table actually take longer than the execution of a given IN clause. But in this instance I am avoiding the costly preparation of a statement on each call.

Order sub-queries so that smaller results are returned first

The FAQ suggests in section 5.3 that sub-queries or criteria should appear in an order such that the criteria that will exclude the most rows should appear first. I take this to mean that this (poor) example query:

SELECT o.id

FROM owner o, pet p

WHERE o.age > 12 AND p.name = 'nathan' AND p.id = o.pet_id

Should be rewritten as:

SELECT o.id

FROM owner o, pet p

WHERE p.name = 'nathan' AND o.age > 12 AND p.id = o.pet_id

Because the p.name criteria is far more selective than that using o.age. Okay, so it's not a great example query. However, in our queries it was quite clear which criteria would be the most selective.

Other practices

Prior to implementing these optimizations we were using many of the best practices recommended in the FAQ including:

Batching commands into transactions
Using indexes where appropriate and justifying the indexes with the EXPLAIN command
VACUUMing the database file before making release builds - this had a noticeable effect on the database file size but I couldn't say that it improved the performance.

Never forget

2009-05-28T18:00:00.004+01:00

Often when we are developing applications for the iPhone we want to enable extra 'tools' in the execution environment so we can get a better grasp of what our software is actually doing. Typically we'll use some kind of logging, and after reading Adhamh Findlay's post on the use of NSZombie I'll often have NSZombieEnabled turned on.

Both of these tools will have an impact on the behaviour of our application if enabled. Logging will certainly slow the application down and NSZombie can make the app run out of memory. Therefore, we need to be conscious of these potential hazards so that we don't try to start fixing problems that are actually just artifacts of the tools. More importantly we must be certain that none of these useful developer settings make their way into released code. It's not hard to imagine that one could let logging slip into a build - at a minimum this will cost you another cycle of building a release and potentially much, much much more.

We found ourselves making this mistake a couple of times with internal releases so thankfully it was only QA who complained and not customers. But having made this mistake we resolved to make it very difficult to repeat. So here's the first thing that our developers see when they start-up the application in a development mode:

Sure, dismissing the alert is a little annoying but it reminds us of the particulars of the current execution environment and saves us from making a costly mistake. We can then release our software with greater confidence. From a code perspective it's lightweight - in our viewDidLoad method of our root UIViewController we call:

[ForgetfulDevelopersAlert showDeveloperWarningIfRequired];

In the ForgetfulDevelopersAlert implementation we check for logging like so:

BOOL logging = NO;

#if LOG_LEVEL != NONE

logging = YES;

#endif

And we detect for NSZombie usage with:

+ (BOOL) __isNSZombieEnabled {

return getenv("NSZombieEnabled")

|| getenv("NSAutoreleaseFreedObjectCheckEnabled");

}

With these flags available it is straight forward to construct a message and show the UIAlert:

if (logging || zombies) {

UIAlertView* alert = [[ForgetfulDevelopersAlert alloc]

__initAlertWithLogging:logging andZombies:zombies];

[alert show];

[alert release];

}

This can of course be extend to check for other development settings. For example I know of one particular case where an app was submitted to the AppStore and it was not noticed until it had finally been approved that only 'test' ad banners had been enabled. Potentially this lost some revenue and required another approval cycle with Apple - but it is a very easy mistake to make that perhaps could have been avoided with something like:

[ForgetfulDevelopersAlert showWarningIfTestAdsEnabled];

:-)

Private properties for iPhone Objective-C

2009-05-27T13:05:00.007+01:00

Keeping members private is extremely important in Object Oriented design as it allows us to adhere to the principles of encapsulation and information hiding, and makes it easier to keep our objects thread safe. We often want to use @properties in Objective-C to take care of retain counts in setters for us. However, unless you are careful these properties will always be public. This 'kitchen sink' approach results in all of your internal object state being exposed on your public API. This is dangerous because:

Developers can modify the internal state of your objects when they shouldn't
Developers are 'tempted' to access things that they shouldn't as they can see 'apparently useful' things on the interface.
Developers are confused when they read the interface - they need to somehow work out which public properties they can use and which they can't.

In short: NEVER expose class internals publicly - it is very bad OO practice.

Private setters are discussed in Scott Stevenson's Objective-C tutorial, but the post does not explain how to make both the setter and getter private - furthermore I was tripped up by a coupled of points that are not illustrated in Scott's examples. So how do we create completely private properties in Objective-C? The steps are as follows:

Make the member variable @private. This is not essential to create the property but if we're making the property private then it'd be wise to make the member variable accessible only from within our class.
DO NOT declare the property in the main @interface in the header (.h) file
Create an @interface for an extension (unnamed category) in the .m file ABOVE the @implementation
Declare your private @property in the extension interface
@synthesize the private property in your @implementation as normal.

See code below for an example:

ClassWithPrivateProperty.h

@interface ClassWithPrivateProperty : NSObject {

@private

NSString* member;

}

- (void) trySettingPrivateProperty;

@end

ClassWithPrivateProperty.m

#import "ClassWithPrivateProperty.h"

@interface ClassWithPrivateProperty ()

@property (nonatomic,retain) NSString* member;

@end

@implementation ClassWithPrivateProperty

@synthesize member;

- (void) trySettingPrivateProperty {

self.member = @"A Value";

NSLog(@"myClass.member = %@", self.member);

}

@end

A simple concurrency framework for the iPhone

2009-05-25T10:36:00.023+01:00

The iPhone app we're working on has become quite large and complex - necessarily so. However, from the start of development many months ago the product has grown organically. Although almost feature complete - the app was quite unstable and failed to deliver in terms of performance so some refactoring was needed.

As I worked my way through spaghetti code, I came across many threading objects and asynchronous calls that were initiated and 'managed' all over the application, sometimes in the view, sometimes the model, and sometimes on the controllers. This effectively made it impossible to determine what the application was doing at any given time. To make matters worse it it was not clear that we were being thread-safe as access to some shared data was unsynchronized. These findings were the likely root of our stability issues. In addition to this we found some tight thread-sleep loops. These were a possible candidate for some performance issues but also a total abomination.

To tackle these issues I had a plan. I would create a framework that provided the threading functionality required by our application use-cases in a safe and centralized manner. I'll now describe the framework.

The foundation of the framework is an old favourite - the command pattern. Any piece of work we want to do on a thread - be it make an HTTP call, parse a document, or asynchronously write to the database - is expressed as a command. In practice we must implement a protocol:

@protocol Command

- (void) execute;

@end

Concrete command classes usually pass some input parameters in the constructor and provide an accessor so that the caller can extract any result of the processing that takes place in the execute method. The execute method implementation is the 'stuff' you actually want to DO be it synchronously or asyncrhonously.

Fundamentally the framework executes commands. However, regardless of your concrete command implementation - the framework can execute your command in a synchronous (blocking) or asynchronous manner. What a relief for the developers - forget about how we safely do something asynchronously and concentrate on the thing you actually want to DO. The framework provides the following methods on the core class - CommandSchedulerQueue - for command execution:

- (void) addCommandToQueueAndReturn:(id<Command>)command;

- (void) addCommandToQueueAndReturn:(id<Command>)command

withCallback:(id<MutableCallback>)callback;

- (void) addCommandToQueueAndWait:(id<Command>)command

withTimeoutInSeconds:(NSInteger)timeout;

As the method names suggest - the framework provides a command queue internally which mandates that the commands be executed in the sequence that they were added to the queue. This may sound a little restrictive but it is perfectly possible to create multiple command queues or even allow more than one command to be executed concurrently on a given queue by allocating the queue more threads.

So before I describe the functionality given to commands and callbacks by the framework, let me mention what's going on inside the framework - and specifically the thing we call the CommandSchedulerQueue class. From the outset I wanted to stick to using well understood Foundation components and classes. Indeed the Foundation framework provides a rich set of classes to deal with concurrency - so use them! At the core of the CommandSchedulerQueue class is an NSOperationQueue, we wrap our command execution in an NSOperation and schedule it on the operation queue. This is nothing new - our application used NSOpeationQueues in the past but often created them all over the place and applied them in an inconsistent manner. By wrapping an NSOperationQueue in our CommandSchedulerQueue we can add useful behavior and hide NSOperationQueue specifics that previously tempted developers to do undesirable things.

So what kind of behavior do we add to the command execution?

We can block the caller until the operation - or rather the command - is complete. We do this in a safe and performant manner using the NSCondition class.
We can invoke a callback to the caller if they have scheduled a command to be executed asyncronously.
We can capture an exception raised during the command's execution and either throw it back to the caller immediately if the command was executed synchronously, or we can deliver the exception in the callback in the case of asynchronous execution.

Let's take a look at the callback:

@protocol Callback

- (void) callbackInvokedForCommand:(id<Command>)command;

- (void) throwExecutionException;

@end

@protocol MutableCallback <Callback>

- (void) setExecutionException:(NSException*)exception;

@end

When implementing the callback for a command we need to provide the behavior of the callbackInvoked method - i.e what we want to happen when the callback is finally fired. Often we'll want to send a message to the original caller to tell them that their command is no longer executing. The receiver of the callback can then invoke throwExecutionException to handle any exception that occurred during the execution of the command. An implementation of throwExecutionException is actually provided in an abstract <MutableCallback> implementation and the CommandSchedulerQueue knows how to set the exception within the callback object.

So that's the basic framework. In our iPhone application we now put all concurrent functionality through this framework which allows us to keep the threading complexity in one place and provides us with excellent visibility on what the app is doing at any given time. We can schedule commands knowing that they'll be executed in sequence and with the confidence that we won't miss any exceptions thrown - even if they're thrown on another thread. Finally we can schedule operations and block until completion in a clean manner (no tight thread-sleep loops!) while hiding the specifics of NSCondition.

Code as prose

2009-05-03T16:32:00.000+01:00

I recently started reading Clean Code - and immediately felt guilty for not reading it earlier. In the first few pages Grady Booch suggests that clean code should read like prose. If we take this a little further use an analogy where the code of an application could be thought of as a book we could then ask the question: 'How would the the shelves of our local bookshop appear?' Their contents would surely reflect the current state and quality of IT projects at large.

Personally I think there would be a fair few fine works of prose and many of those you could take home for free. However, the majority of those shelves would be chock full of vaguely similar children's colouring-in books that have been carelessly scribbled in. Markings from the 'crayon of implementation' would wildly stray over the clear and purposeful black outlines of original intent.

Flickr is surprisingly devoid of badly executed 'colouring-ins' but has no shortage of perfectly filled pages from such books - perhaps this is yet another example of sunlight being the best disinfectant.

Revisiting JDBC (pt. 1)

2009-05-03T08:58:00.022+01:00

About 6 or 7 years ago I was writing a lot of SQL and JDBC - I remember being particularly pleased when I developed an efficient implementation of Celko's Nested sets to represent hierarchical data in a Content Management project. At the time JDBC was a pretty neat way of interfacing with a relational database. However, we Enterprise Java developers have for the most part left JDBC behind in favor of excellent ORM frameworks such as Hibernate and although we are using JDBC more that ever, we do so with it operating under the covers - tucked away within our ORM framework. Sure there may be times when we have to step back to JDBC - how well would Hibernate handle hierarchical data? - but they are infrequent.

Now as I mentioned in previous posts, the main reason I found myself developing - well, debugging at first - on the iPhone platform was to investigate why a SQLite based feature of our application wasn't functioning as well as the original Java proof-of-concept. Fairly soon I was immersed in the world of SQLite's C/C++ interface - JDBC this was not. From a Java point of view it's low-level: Error conditions signaled by return value on almost every function and pointers aplenty. What I wanted was JDBC - or rather OBJCDBC - but in fact I wanted much more because in the JDBC world I had also become used to:

Excellent connection and prepared statement pooling with the likes of DBCP.
Concise utility methods that allowed me to avoid JDBC boiler-plate in the form of DbUtil.

I Googled a while to see if such a thing existed in the iPhone domain and thankfully found many likely candidates on the SQL Wiki (see: Objective-C section) ranging from simple wrappers to ORM frameworks. However, the simple wrappers were not as clean and object orientated as I was used to with JDBC and the ORM frameworks would not give me enough control to write some of the highly optimized SQL queries that our application demanded. I set about writing my own wrapper. One could argue that I was reinventing the wheel - but I'm always happy to learn more about wheels. My requirements were as follows:

Option to pool connections and statements
Check for every error condition that SQLite could possibly set and convert these into exceptions so we can adopt a try/catch/finally approach when accessing the database.
Provide a clean and simple programmatic interface.
Move all direct interactions with SQLite into a few sensible classes - C based SQLite code had previously been spread liberally throughout the application.

My core classes were to be as follows:

PooledDataSource - A connection data source that also pools connections. Calling close on a connection actually returns it to the pool.
Connection - Encapsulates a SQLite database handle - can also pool statements that have been prepared from this connection. Calling prepare on a connection might actually fetch and reuse a pooled PreparedStatement rather than creating a new instance. rovides methods to manage transactions.
PreparedStatement - Prepares transient and non-transient statements, binds parameter values to statements, and executes statements. Returns ResultSets for SELECT queries. Calling close on a prepared statement returns it to the statement pool if it is not transient.
ResultSet - An interface for stepping through a cursor and retrieving values from the row.

With these classes in place I could write some typical Data Access Object code:

PreparedStatement statement;

ResultSet results;

NSNumber maxId = nil;

@try {

stmt = [con prepare:@"SELECT MAX(id) FROM foo WHERE bar = ?"];

[con begin]; // OK - so we don't need this for a SELECT

results = [stmt executeWithValues:@"dog", nil];

if ([results next]) {

maxId = [results getInt:1];

}

[con commit]; // for illustration only

@catch (NSException* sqlX) {

[con rollback]; // for illustration only

// handle error

} @finally {

[DatabaseCommons closeQuietly:results, statement, con];

}

I'll get more into the actual class implementation details in part 2.

Dynamic Proxies

2009-05-02T17:10:00.002+01:00

Part of our iPhone application uses proxy objects lazily load the full-fat objects behind the scenes. The initial implementation simply used an object that had the same core interface of the proxied object and used a factory to load the full-fat object in the event that a property was called on the proxy that it couldn’t service with it’s own internal state.

@implementation MyProxyClass // : NSObject ...

-(NSString*)doSomethingIntensive {

if ([self fullFatObjectNotLoaded]) {

[self loadFullFatObject];

}

return [fullFat doSomethingIntensive];

}

...

This was all well and good - but eventually the model sitting behind the proxy grew and grew until we had a rather large hierarchy of classes that had to be managed by the proxy. To do this the proxy would have to present all of the varied properties on all of the classes in the model hierarchy. In development terms alone this wasn’t scalable - we’d keep having to add new properties to the proxy as they were added to the model; instead a shortcut around this issue had been implemented. The proxy exposed the full-fat object with it’s own getter:

@interface MyProxyClass : NSObject ...

-(MyClass*)getFullFat;

...

The problem with this is of course that now the caller to the proxy must actually know about the proxy - it can no longer just use the MyProtocol protocol (Java: ‘Interface’) and must now be aware of the type ‘MyProxyClass’. This makes the calling code tightly coupled to the lazy loading process - exactly what we don’t want.

As enterprise Java developers we see dynamic proxies intercepting calls to our classes everywhere in our EJB containers, Dependency injection frameworks (e.g: Spring, Seam), and ORM frameworks (Hibernate for example). In truth we rarely see them - perhaps in a call stack in the debugger - but we know they are there wrapping rich services around our objects without our intervention.

What I wanted was something similar for our iPhone application - some kind of Objective-C dynamic proxy that could seamlessly proxy our (perhaps overly) complex model and remain hidden from the classes who would actually be be calling the proxy.

Now writing a dynamic proxy service in Java is probably difficult. I haven’t written one but I imagine it entails reflection and byte code generation - not necessarily the stuff that the average Java developer gets stuck into. Besides - there are good libraries that do this already and do it well in the Java world. However - in the world of Objective-C it is surprisingly easy to do out of the box using a Foundation class named ‘NSProxy’.

Any selector messages (Java: ‘method calls’) invoked on the proxy invoke a default method on the proxy called ‘forwardInvocation’ including a description of the invocation (selector, arguments, etc.) By overriding the ‘forwardInvocation’ method we can route the method invocation wherever we like. In the case of our lazy loading proxy we’d like to check to see if our proxy can service the invocation (we can use 'respondsToSelector' for this) and if not - load up the object we are the proxy for and then forward the invocation to that full fat object like so:

@implementation MyProxyClass // : NSProxy ...

-(void)forwardInvocation:(NSInvocation*)invocation {

SEL selector = [invocation selector];

if ([self fullFatNotLoadedAndCanBeHandledByProxy:selector]) {

[invocation setTarget:lowFat];

} else if (fullFat != nil) {

[invocation setTarget: fullFat];

} else {

NSAssert(FALSE, @"Hope this never happens");

}

[invocation invoke];

return;

}

Of course - it’s a bit more complicated than that. NSProxy is not an actual object as such - it’s not a subclass of NSObject. So if you send an ‘init’ invocation to a NSProxy instance it doesn’t actually call the init (Java: ‘default constructor’) on the proxy instance - it doesn’t have one. Instead this is treated like an other method and we find that we have an invocation of ‘forwardInvocation’ with selector ‘init’. And in this event what object reference should we return to the caller? It gets even more confusing when we find that calls to extremely type specific methods such as: ‘isKindOfClass’, ‘conformsToProtocol’, and ‘respondsToSelector’ also get directed straight to ‘forwardInvocation’ and that we have to handle those too! How confusing - this would never happen in Java!

So this is the way that I chose to implement the lazy loading proxy:

The proxy would have an internal ‘low-fat’ skeleton object that acts as a placeholder for the proxied object - in my case it had a member that held the full fat objects database ID. The low fat object is alloced when the proxy gets a request for the NSMethodSignature for the initWithId method - the proxy passes a reference to itself - not the databaseId - we have to wait for the 'forwardInvocation' call to get at the method call argument.

@implementation MyProxyClass // : NSProxy ...

...

-(NSMethodSignature*)methodSignatureForSelector:(SEL)selector {

if (selector == @selector(initWithId:)) {

if (lowFat == nil) {

lowFat = [[LowFatObject alloc] initWithProxy:self];

} else {

NSAssert(FALSE, @"Hope this never happens");

}

...

}

...

@end

@implementation LowFatObject

@synthesize databaseId;

-(id)initWithProxy:(MyProxyClass*)aProxy {

if (self = [super init]) {

proxy = aProxy;

// NOTE: 'proxy' member of type MyProxyClass!

}

return self;

}

The ‘initWithId’ call to the proxy would actually be routed to the low-fat object to but note that the low fat object has already been alloced and init'ed by the proxy. So instead it adopts the databaseId value and (importantly) returns a reference to the proxy - not itself.

@implementation LowFatObject

-(id)initWithProxy:(MyProxyClass*)aProxy...

...

-(id)initWithId:(int)aDatabaseId {

databaseId = aDatabaseId;

return proxy;

// We want the caller to have a ref to the proxy!

}

We're still left with the issue of deciding when to load the full-fat item. To do this we need to check if the low-fat skeleton object is able to service the invocation and if not we need to load the full-fat object and set that as the invocation target. We do this when we're asked to supply the 'NSMethodSignature' for the pending invocation. Before we dive into this recall that the invocation could be for something where the return type is extremely type specific - such as 'respondsToSelector' - in those eventualities we MUST also load the full-fat object because only the can we really know what the object we are a proxy for is actually capable of.

@implementation MyProxyClass // : NSProxy ...

...

-(NSMethodSignature*)methodSignatureForSelector:(SEL)selector {

... init method handler ...

NSObject* target;

// Is the selector extremely type specific?

if (selector == @selector(isKindOfClass:)

|| selector == @selector(conformsToProtocol:)

|| selector == @selector(respondsToSelector:))

{

[self loadFullFatTarget];

target = fullFat;

} else if ([self fullFatNotLoadedAndCanBeHandledByProxy:selector]) {

// The low-fat item responds to the selector

// and the full-fat hasn't been loaded

target = lowFat;

} else {

// We need to load the full fat because the low-fat

// skeleton can't handle it

[self loadFullFatTarget];

NSAssert1(

[fullFat respondsToSelector:selector],

@"Neither full/low fat object can handle selector %@",

selector

);

target = fullFat;

}

return [target methodSignatureForSelector:selector];

}

Despite being a little fiddly this approach has worked quite well in practice. As a Java developer it's quite refreshing to be able to construct something as powerful as a Dynamic Proxy using a core class supplied in the SDK. Although the model we are proxying probably has much room for refactoring we can now at least add and remove properties from the model classes and have them implicitly supported by the proxy without any further modification to the proxy itself.

From (My)Eclipse to XCode

2009-05-02T16:59:00.001+01:00

As any Java developer worth his salt knows - if you’re going to be writing code in a productive way - you should at least know a handful of keyboard shortcuts in Eclipse. Yes I’m sure others use Netbeans and IntelliJ IDEA - but I have met them rarely and they often seem to have selected their IDE just to be different, awkward, or both (flame war starts here).

So important is the knowledge of shortcuts that I’ve often seen them on cheat sheets, stuck on the side of mugs, and described incredulously in code reviews when one developer who knows a shortcut, watches the other developer painfully scroll through a menu or type out a class name. Some developers - so happy that they’ve discovered something powerful - email all of their developer friends with the newly learnt shortcut only to be ridiculed in a barrage of replies with sentiments to the effect of: ‘You’ve been earning £X00 a day developing with Eclipse for 5 years and you didn’t know about shortcut X?’

So anyway, my first big hurdle with XCode was shortcuts. Without those I could not be as productive as I’d like. In fact - that wasn’t my first hurdle - first I needed to stop using Eclipse shortcuts in XCode.

So I’ll list my favorite XCode shortcuts. They are there in the preference panels, in books and on the side of mugs. But if like me you can’t be bothered to look and would rather have someone else tell you here they are:

alt-cmd-up: Switch between header and implementation file
alt-cmd-left: go to previous file
alt-cmd-right: go to next file
cmd-b: start/stop build
shift-cmd-k: clean all targets
cmd-return: build and go (launches the iPhone simulator/device with your app)
shift-cmd-d: find a source file
shift-cmd-f: find text in the project sources

Background

2009-05-02T16:52:00.002+01:00

So a little bit of background. I have been happily developing with Java for over 9 years and am very appreciative of the wealth of frameworks available that make my job easier and more productive. In the company I work for currently I have been developing an enterprise server side Java application whose job is to aggregate and feed data to an iPhone based client. It got to the point where the server was virtually complete, scaling well and had few additional features remaining in the product backlog. We ‘server guys’ had applied best practices, patterns, and frameworks with a very satisfactory result.

I then began architecting features of the iPhone client application - with no intention of actually developing on the platform but merely providing the iPhone developers with a proof of concept that they could effectively ‘transcribe‘ into the iPhone domain. The feature in question required an SQLite database on the iPhone and as a server guy I could throw SQL together with ease - so it made sense that I should do the design. However, as the iPhone implementation of my designs progressed, many issues presented themselves on the client that just didn’t exist in my Java-based proof of concept. It was at this point I realized that I’d have to delve into the world of Objective-C and XCode. Having done a bit of C programming at university and written one MFC based OpenGL app for my coursework 12 years previous - I was struck with fear at the learning curve I probably faced.

I was very pleasantly surprised. In terms of language structure and syntax - the core things that make Java development easier (or rather: less difficult) than C were all in place in Objective-C. Exceptions, Thread classes, synchronization, interfaces, etc. were there - although often they are often called something totally different and aren’t quite like the Java equivalent. I was given Dylan McNamee’s ‘Java to Objective-C cheat sheet’ which proved a useful starting point and I was soon at ease. Then, having had a quick look at the language I wanted to get started debugging the iPhone implementation of the SQLite POC.

I’d recommend that any Java developer interested in the iPhone platform jump right in - they won’t find the learning curve that steep and in my opinion you can apply all the software development fundamentals that one is often required to know in the Enterprise Java domain to this (much smaller) platform.

Why this is here

2009-05-02T16:51:00.003+01:00

As an experienced Enterprise Java developer forced onto the iPhone development platform, I have noticed many opportunities where the experience I have gained in the enterprise can be used to good effect on even Apple’s smallest public platform.

To me at least it seems that Java developers with some good development experience behind them can lend much to this relatively new platform and the community that is rapidly building up around it. I did not find this so much to be the case when working with J2ME which at the time (2004) made it prohibitively expensive in performance terms to stick rigorously to respected patterns and frameworks. The iPhone platform is arguably far more powerful than that J2ME stack I developed for in the past and therefore allows the developer to pay more attention to good design and development practice.

In this blog I hope to look at problems encountered on the iPhone platform and how they were solved with lessons learned from J2EE development.