I've used Commons HttpClient in older versions on several occasions in the past and have found it to be extremely useful. I've only just started working with the new version, but there seems to quite a lot of good stuff in there. For example I'm thrilled to see that the Template pattern, heavily used in Spring, has now made its way to the Apache world (e.g. ResponseHandler, a callback interface to be used with HttpClient for handling results).

Now, configuration of HttpClient has always been a little bit tricky. There are so many features in there, and most of these are configured using generic parameters (HttpParams), basically name-value pairs of a setting identifier and its value. This has not been made that much easier in the new version.

In my current project I was struggling to find the appropriate parameters for configuring timeouts with the new version of the framework. It turned out to be quite difficult to find clear information on this - the documentation on the 4.0 version of HttpClient is still quite sparse. Since it took me a while to find out how to do this I figured I wasn't alone, so here goes:

It seems that most of the Constant Values for the 3.x version are still applicable - I was just unable to find the corresponding document for 4.0. Now, to specify timeouts, I've used two separate parameters: http.connection.timeout and http.socket.timeout. The former is used for specifying the timeout to wait when acquiring a connection to the server; the latter is the socket timeout - this is the timeout used on each individual read operation on the target socket.
Right, the code looks as follows:

 
DefaultHttpClient httpClient = new DefaultHttpClient();
HttpParams params = httpClient.getParams();
params.setIntParameter("http.connection.timeout", connectionTimeoutMillis);
params.setIntParameter("http.socket.timeout", socketTimeoutMillis);
 

Simple as that - hard to understand why that should take me so long to figure out

Problem

If you have ever tried doing this before with Maven, you have probably used maven-assembly-plugin, which would leave the door open for classpath problems!

It would extract all your dependency jars in one directory together with all your class files and all other classpath resources. The problem is that everything ended up in a big mix, with classpath resources possibly overwriting each other. For example, if two dependencies each had a log4j.properties file in their jar, one log4j.properties would overwrite the other.

No more of that mess!

Solution

Enter maven-onejar-plugin. It lets all your dependency jars stay jars, and your code is in its own jar. All of those jars are put in a bigger jar, which is made executable.

Configuration

It may sound weird, but it's quite elegant! Just put this in your pom.xml's <plugins> tag to make it work:

<plugin>
  <groupId>org.dstovall</groupId>
  <artifactId>onejar-maven-plugin</artifactId>
  <version>1.2.3</version>
  <executions>
    <execution>
      <configuration>
        <mainClass>your.package.YourMainClass</mainClass>
      </configuration>
      <goals>
        <goal>one-jar</goal>
      </goals>
    </execution>
  </executions>
</plugin>

You also need to add this to the pom:

<pluginRepositories>
  <pluginRepository>
    <id>onejar-maven-plugin.googlecode.com</id>
    <url>http://onejar-maven-plugin.googlecode.com/svn/mavenrepo</url>
  </pluginRepository>
</pluginRepositories>

Please note the new Maven repository URL. Me and onejar-maven-plugin founder Drew Stovall just recently moved the project to Google Code to make it more open and easier for others (like me!) to pitch in. Yesterday, I released version 1.2.3 of onejar-maven-plugin to our new Maven repo at Google Code. Make sure you get the <pluginRepository> URL right so that the latest version will be available to you!

Use

Then do this to build everything:

mvn install

That will build both your normal jar, as well as another jar. You will get these:

Standalone one-jar.jar file, along with the original .jar file.

myApp.one-jar.jar is the big executable that includes both myApp.jar, and all dependency jars.

You can run it standalone without any extra files, like this:

java -jar target/myApp.one-jar.jar

If you found this interesting, you might find my post about winstone-maven-plugin enlightning as well. It shows you how to make an executable .war file.

Credits

Thank you Drew Stovall for creating this Maven plugin in the first place, and thank you to the other contributors who have also submitted patches.

Project homepage: http://onejar-maven-plugin.googlecode.com

The eclipse plugin has pretty basic support for code completion, syntax highlihting, and some wizards to create projects, scala classes, objects and traits.
We started out with one java project and one scala project. Testing with the latest release, it was a bit tricky to resolve our imported java classes at build and runtiime and vice versa:

To use a Scala class in your Java project:

• add the scala project to the build path of your java project (project properties -> Java Build Path -> Projects -> Add...)
• add the scala nature to your java project (rightclick your java project -> Scala -> add Scala nature)

To use a Java class in your Scala project:

• import of java.* works fine (for example using java.util.Date in scala, like in the Scala Tutorial for Java programmers)
• add the java project to the build path of your scala project

With the current eclipse plugin it is not possible to use scala objects in your java classes. This seems to be a known issue.

It's even possible to create scala and java classes in the same project if your project has both scala and java nature. But the mixed project support in the plugin is still quite buggy: adding a java class to your scala project sometimes make eclipse think that your scala class is a java class. Closing and reopening your project is a way to get around this.

Overall working with the scala eclipse plugin is quite frustating, as it is still very buggy. Actually the first impression was that interoperability does not work at all in the plugin.

The IntelliJ Scala plugin 0.2.22340 had much better Scala support with all the above and then refactoring support (rename, move, introduce variable) and open declaration navigation. IntelliJ also supported Java and Scala interoperability even within the same module.

Simply replacing the original delegate will break the default functionality. We need to somehow insert our own code to execute before the original delegates call. Or in AOP speak; a before advice.

The Wanted Solution

What we want is a proxy that can forward invocations both to our own delegate, and to the original delegate. The interface for said class looks looks like this:

@protocol CWDelegateOverrideProxyDelegate
@required
-(BOOL)shouldCallOriginalImplementationForSelector:(SEL)aSelector;
@end
 
@interface CWDelegateOverrideProxy : NSProxy {
@private
  id<NSObject> _originalDelegate;
  id<NSObject> _overrideingDelegate;
  id<CWDelegateOverrideProxyDelegate> _delegate;
}
 
@property(nonatomic, retain, readonly) id<NSObject> originalDelegate;
@property(nonatomic, retain, readonly) id<NSObject> overridingDelegate;
@property(nonatomic, assign) id<CWDelegateOverrideProxyDelegate> delegate;
 
-(id)initWithOriginalDelegate:(id<NSObject>)originalDelegate
     overridingDelegate:(id<NSObject>)overridingDelegate;
 
@end

And then we could use this class to replace an existing delegate with a short piece fo code like this:

UITabBar* tabBar = (UITabBar*)[self.tabBarController.view
    viewWithKindOfClass:[UITabBar class]];
CWDelegateOverrideProxy* proxy = [[CWDelegateOverrideProxy alloc]
    initWithOriginalDelegate:tabBar.delegate overridingDelegate:self];
tabBar.delegate = (id<UITabBarDelegate>)proxy;

See my previous post for the implementation of viewWithKindOfClass:.

Easy enough to use, only thing left is to implement CWDelegateOverrideProxy.

Enter NSProxy

Java only have one root class; java.lang.Object. Objective-C can have many, and Cocoa defines two; NSObject and NSProxy. Both of them conforms to the protocol NSObject, wich can be confusing. What we need to know is that class names, and protocol names have two different name spaces in Objective-C. Imagine it as if you could have a class and an interface with the same name in Java; in Objective-C you can. NSObject class is the root class for all concrete classes, and NSProxy class is the root class for proxies, both implements NSObject protocol allowing them to be interchangeable.

Without much ado, here is the base implementation for the initializer:

#import "CWDelegateOverrideProxy.h"
 
@implementation CWDelegateOverrideProxy
 
@synthesize originalDelegate = _originalDelegate;
@synthesize overridingDelegate = _overridingDelegate;
@synthesize delegate = _delegate;
 
-(id)initWithOriginalDelegate:(id<NSObject>)originalDelegate
     overridingDelegate:(id<NSObject>)overridingDelegate;
{
  _originalDelegate = [originalDelegate retain];
  _overridingDelegate = [overridingDelegate retain];
  return self;
}
 
// More code goes here!
 
@end

Introspection

In Objective-C, just as in Java, an instance can be queried for its class, and conformance to protocols (interface in Java speak). But as a bonus an instance can also be queried for specific methods per instance.

Our CWDelegateOverrideProxy class inherits from NSProxy. And it makes a simple assumption; if the original delegate, or the overriding delegate is capable of something, then so it is. So if queried for type of class, protocol conformance, or implemented methods, then we reply with whatever our managed delegates replies.

The NSObject protocol defines methods, equivalent of the java.lang.reflect package, that allows us to implement this as such:

#pragma mark --- Testing Object Behavior, and Conformance
 
-(BOOL)isKindOfClass:(Class)aClass;
{
  return [self.overridingDelegate isKindOfClass:aClass] ||
         [self.originalDelegate isKindOfClass:aClass];
}
-(BOOL)conformsToProtocol:(Protocol *)aProtocol;
{
  return [self.overridingDelegate conformsToProtocol:aProtocol] ||
         [self.originalDelegate conformsToProtocol:aProtocol];
}
-(BOOL)respondsToSelector:(SEL)aSelector;
{
  return [self.overridingDelegate respondsToSelector:aSelector] ||
         [self.originalDelegate respondsToSelector:aSelector];
}

Invocation Forwarding

The NSObject protocol also defines methods for functionality equivalent of java.lang.reflect.InvocationHandler and hooks to act as a java.lang.reflect.Proxy. The details are different as Objective-C do not enforce calls to only known methods at compile time, which means that at run-time unimplemented methods can be called.

When an unimplemented method is called the run-time will call methodSignatureForSelector:, that can return a NSMethodSignature instance, sort of the equivalent of a java.lang.reflect.Method. The run-time will then use the information from the NSMethodSignature instance to create a correct NSInvocation (other half of a java.lang.reflect.Method) instance, and set the correct arguments. This NSInvocation instance is then used as argument to call forwardInvocation:.

And thus our implementation is completed with:

#pragma mark --- Handling Proxy Methods
 
-(NSMethodSignature*)methodSignatureForSelector:(SEL)aSelector;
{
  if ([self.overridingDelegate respondsToSelector:aSelector]) {
    return [self.overridingDelegate methodSignatureForSelector:aSelector];
  } else if ([self.originalDelegate respondsToSelector:aSelector]) {
    return [self.originalDelegate methodSignatureForSelector:aSelector];
  } else {
    return [super methodSignatureForSelector:aSelector];
  }
}
 
-(void)forwardInvocation:(NSInvocation*)anInvocation;
{
  BOOL shouldCallOriginal = YES;
  SEL aSelector = [anInvocation selector];
  if ([self.overridingDelegate respondsToSelector:aSelector]) {
    [anInvocation setTarget:self.overridingDelegate];
    [anInvocation invoke];
    if (self.delegate != nil) {
      shouldCallOriginal = [self.delegate shouldCallOriginalImplementationForSelector:aSelector];
    }
  }
  if (shouldCallOriginal && [self.originalDelegate respondsToSelector:aSelector]) {
    [anInvocation setTarget:self.originalDelegate];
    [anInvocation invoke];
  }
}

And that rounds up how to implement a class that handles proxy based AOP, in order to introduce a before advice for delegate methods. For a more complex code base you can look at HessianKit, a framework that uses proxies, invocation forwarding and dynamic class creation in order to use a web service as distributed objects.

It is often nice to be able to reuse existing functionality when you subclass UITableViewCell. Properties such as image and textColor maps directly to the embedded UILabel and UIImageView subviews, and reimplementing them all when introducing a custom layout is tedious and error prone. Would it not be better to be able to get access to the original subview instances and just add a custom layout to them?

You can find subviews by class

Would it not be nice if the Cocoa Touch framework had a method such as this:

- (UIView*)viewWithKindOfClass:(Class)aClass;

Kind of like what viewWithTag:, does but instead of searching for a subview matching a tag, it searches for a subview matching a class.

Good news for us is that this is very easy to implement, by just adding a new category to UIView. Add a new .h/.m file pair to your Xcode project and type this down in the header file:

#import <UIKit/UIKit.h>
 
@interface UIView (CWViewWithKindOfClass)
 
- (UIView*)viewWithKindOfClass:(Class)aClass;
 
@end

Now we have to implement it. The existing viewWithTag: method is not documented as such, but my experimentation tells me that it uses a breadth first search algorithm. Quite logical as the wanted subview most commonly is close to the root view, and we want to find it fast. Since viewWithTag: always returns the first found matching view, we can do the same assumption.

The quite short implementation goes like this:

#import "UIView+CWViewWithKindOfClass.h"
 
@implementation UIView (CWViewWithKindOfClass)
 
- (UIView*)viewWithKindOfClass:(Class)aClass;
{
  NSMutableArray* nodeQueue = [NSMutableArray arrayWithObject:self];
  while ([nodeQueue count] > 0) {
    UIView* node = [nodeQueue objectAtIndex:0];
    [nodeQueue removeObjectAtIndex:0];
    if ([node isKindOfClass:aClass]) {
      return node;
    } else {
      [nodeQueue addObjectsFromArray:node.subviews];
    }
  }
  return nil;
}
 
@end

And that is it, not you can use it with something like for example this:

UITabBar* tabBar = [myTabBarController.view viewWithKindOfClass:[UITabBar class]];

Wich is an introduction to a future post, where I will discuss how to access the managed UITabBar of a UITabBarController, and introduce a UITabBarDelegate without interfering with the delegate already in place from the Cocoa Touch framework.

The four corners are coped as is, the four borders scaled in a single direction, and the center is scaled in both directions. Since MIDP do not support image scaling this must be implemented by hand using the ARGB values fetched using Image#getRGB(). The documentation is quite straight forward, but fail to mention one pecularity in many implementation...

Clearing unwanted data

I want to create the target image in a single int[] array to reduce memory usage. No problem copying image data into this structure, it is just what the quite straightforward API is designed to do:

public void getRGB(int[] rgbData,
                   int offset, int scanlength,
                   int x, int y,
                   int width, int height)

Unfortunately the documentation fails to mention that many implementations will not as expected just ignore data in rgbData that is not copied. Instead zeroes, or transparent pixels, will be filled in for any image data that has not been requested on a per row basis. I dare anyone to find where this is mentioned in the MIDP spec.

A solution

The solution is to write your own wrapper method for Image#getRGB() that copies just a single row of image data at a time, and the requested scanline length must be lied about to avoid having the remainder of lines filled with zeroes. Here is tho code ready for copy and paste:

public class ImageUtils {
    public static void getRGBFromImage(Image image, int[] argbData, int offset,
            int scanline, int x, int y, int width, int height) {
        for (int row = 0; row < height; row++) {
            image.getRGB(argbData, offset, width, x, y + row, width, 1);
            offset += scanline;
        }
    }
}

One interesting problem was that in some of my tests, I had to mock the org.eclipse.core.resources.IResource interface. Nothing too hard about that, just write the following code, using EasyMock 2.4:

 
@Override
protected void setUp() throws Exception {
   super.setUp();
   resource1 = createMock("resource1", IResource.class);
   resource2 = createMock("resource2", IResource.class);
}
 

Now to my problem. First, I will discuss what the IResource.accept(IResourceVisitor visitor) metod does:
The IResource.accept(...) method traverses the directory structure under the resource. For each resource found, starting with the IResource on which accept() was called, the visitor.visit(IResource resource) method is called. If the visit(...) method returns true, the directory structure under the resource is traversed, otherwise traversing stops for that specific resource. This way parts of the directory structure under an IResource can be visited.

The problem I encountered was that since I have an IResource mock, there is no code for the accept() method. The mock will just register that there has been a call for accept(), but the code in the IResourceVisitor.visit(IResource resource), which I want tested, is never called.

What to do? There are different solutions, one example is to use an implementation of IResource, for example org.eclipse.core.internal.resources.Folder, and create a partially mocked object and keep the code for accept(). Not a nice solution though, my test would depend on internal code in the Eclipse project. What I did instead was to use the org.easymock.EasyMock.expectLastCall().andAnswer(IAnswer answer) functionality. The andAnswer() method takes an IAnswer callback implementation, like this:

 
public void testCollectRefreshStatus() throws CoreException {
   // Normal mock expects
   expect(resource1.getLocation()).andReturn(iPath1);
   expect(iPath1.toOSString()).andReturn(RESOURCE_PATH_1).times(2);
 
   // Provide code for accept(...)
   resource1.accept(isA(IResourceVisitor.class));
   expectLastCall().andAnswer(new IAnswer() {
      public Object answer() throws Throwable { // 1.
        IResourceVisitor visitor = (IResourceVisitor) EasyMock.getCurrentArguments()[0]; // 2.
        visitor.visit(resource2); // 3.
        return null;
      }
   });
   expect(resource2.getName()).andReturn("file.txt"); // 4.
 
   replayMocks();
 
   // Perform test
   myTestTarget.someMethod();
 
   // Verify test
   assertEquals(1, myTestTarget.getNumberOfResources());
   verifyMocks();
}
 

Here are some comments to the marked lines in the code above:

1. The answer() method is dictated by the IAnswer interface.
2. EasyMock provides a method to get access to the objects sent as parameters for the expected call. In this case, the call is resource1.accept(...) and the parameter is the IResourceVisitor implementation defined in myTestTarget, which is the code that should be tested.
3. Here the test code has control of the call to the IResourceVisitor.visit() and a mock IResource is provided as parameter. To make the test even better, the boolean return value from the visit() call should be saved and asserted for the correct value to ensure that the intended traversing works as expected.
4. Here the expectations on the mock IResource, for the visit(IResource ...) call, is defined. In this case myTestTarget calls getName() on IResource for some reason, so expectations for that is defined together with a resulting return value that would steer the logic in some direction.

This way the test has full control of the visitor implementation and it is fairly easy to test all the criterias that makes the IResourceVisitor.visit(...) implementation return true or false. Also, the visit() method often changes state of something else, and here it is also possible to test that the state is changed correctly by simulating multiple visit(...) calls, by adding more calls to visit at 3. in the code above.

/Tobias Södergren

Update: Buttons created with UIButtonTypeRoundedRect is a special case returning a private subclass of UIButton, this bugfix can therefor not safely be used with rounded buttons. Good news is that they already have a large nice touch area.

With Objective-C you can

In short the problem is that the implementation of the factory method buttonWithType: in UIButton do not respect subclasses, so it will always return instances of UIButton. This is bad since it is the only method available to use to get custom buttons. Without access to the source code for UIButton changes can not be made to the implementation, so in order to fix the bug in UIKit we must wrap the original implementation of buttonWithType: with our own method that applies the bugfix.

Adding a category with a new implementation will not work, since that would shadow the original implementation. What is need is some sort of AOP, and Objective-C gives us enough of this but under the name of method-swizzling.

We can intercept method calls to buttonWithType: by swizzling the implementation with the implementation of our own method. In Objective-C all method implementations are called by name, that name is what is know as a selector. By swizzling the implementations we can make messages with the old selector call our new implementation, and vice versa.

We do this by adding a category to UIButton with this class method:

#import <objc/runtime.h>
+(void)load;
{
  Method oldMethod = class_getClassMethod(self, @selector(buttonWithType:));
  Method newMethod = class_getClassMethod(self, @selector(__buttonWithType:));
  method_exchangeImplementations(oldMethod, newMethod);
}

The class method load is called once for each class and category as they are loaded into the run-time, and is the optimal place to add initialization code. Think of it as static initializer blocks in Java.

And that is it, apart from implementing the actual bugfix in our __buttonWithType: method.

A better bugfix

The fix I did in my previous post only worked if the new subclass of UIBUtton did not introduce any new instance variables. This is a limitation, and not quite as obvious to new users of our bugfix, so this time around the bugfix will work with any subclass.

The trick here is allocate a new instance of the correct subclass if needed, and copy over the instance variables. Implementation:

+(UIButton*)__buttonWithType:(UIButtonType)type;
{
  UIButton* button = [self __buttonWithType:type];
  Class buttonClass = [button class];
  if (button && buttonClass != self && buttonClass == [UIButton class]) {
    size_t oldSize = class_getInstanceSize([button class]);
    size_t newSize = class_getInstanceSize(self);
    button->isa = self;
    if (oldSize < newSize) {
      UIButton* newButton = [self alloc];
      memcpy(newButton, button, oldSize);
      button = [newButton autorelease];
    }
  }
  return button;
}

At first glance the first statement might look like a recursive call, but remember that we have swizzled the implementations so it will call the original implementation of buttonWithType:.

Also note that we must autorelease the new instance that we allocated, and that we must not release the original instance as that one is already owned by an auto release pool.

And that is how you go about fixing bugs in Objective-C for code that you do not have access to the source code for.

First the preface

I wanted to add a star button to the right side of each row, subclassing UIButton that can manage selected states, images and all I needed, and use it as the accessory view of the UITableViewCell felt natural. It works and is the right thing to do. The simple factory method is:

+(CWFavouritesButton*)favouritesButtonWithTarget:(id)target action:(SEL)action;
{
  CWFavouritesButton* button = [self buttonWithType:UIButtonTypeCustom];
  if (button) {
    [button addTarget:target action:action forControlEvents:UIControlEventTouchUpInside];
    button.frame = CGRectMake(0, 0, 29, 31);
    button.backgroundColor = [UIColor clearColor];
    [button setImage:[UIImage imageNamed:@"star-deselected.png"] forState:UIControlStateNormal];
    [button setImage:[UIImage imageNamed:@"star-selected.png"] forState:UIControlStateSelected];
  }
  return button;
}

Now if this had been all then, simply adding the factory method with a category on UIButton would have been enough. But as it is, a UIButton uses the alpha mask of its' image as hit target. That hit target is quite small, at least 44 pixels should be used with fingers on a touch screen. Therefor I subclass UIButton so that I can override the hit test as this:

-(BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event;
{
  CGRect bounds = self.bounds;
  bounds = CGRectInset(bounds, -32, 0);
  return CGRectContainsPoint(bounds, point);
}

This would allow for an extra 32 pixels to hit on the left and right side of my star button. But now problems arise! Turns out that the overridden implementation of pointInside:withEvent: is never called.

Many hours of troubleshooting later I figured out that the buttonWithType: factory method is the culprit; it do not respect subclasses. Meaning that it will always return instances of UIButton, and thus always call the original implementation of pointInside:withEvent:. Unfortunetely this is the only public factory or init method that can be used to create a button with images only. What to do?

Objective-C to the rescue

With Objective-C we can change the class of an already live object instance, one nice feature of having a dynamic run-time.

All books will tell you that all classes inherits from NSObject. This is not quite true, there is among others NSProxy as well, and you could actually introduce your own root classes if you like. All of them will inherit from the run-time class id. The run-time class id do not implement a single class method, nor instance methods, all it has is a single instance variable: isa of type Class.

As we all should know classes in Objective-C are also object instances, instances of their meta-classes. The isa instance variable is the reference to the object instance's class instance. And here is the gold nugget; it is write-able. So we can change an object instance's class by simply assigning a new value to isa.

So lets update the previous factory method to this:

+(CWFavouritesButton*)favouritesButtonWithTarget:(id)target action:(SEL)action;
{
  CWFavouritesButton* button = [self buttonWithType:UIButtonTypeCustom];
  if (button) {
    button->isa = [CWFavouritesButton class];
    // More init code...
  }
  return button;
}

Some precaution

This might look dangerous, and it is. But not so dangerous that you should shun it, the Cocoa frameworks uses it to it's advantage, and so should you. The only thing you need to be aware of is that the instance size of the original and new classes must be the same. This is easily done by importing runtime.h, and use class_getInstanceSize().

#import <objc/runtime.h>
+(CWFavouritesButton*)favouritesButtonWithTarget:(id)target action:(SEL)action;
{
  CWFavouritesButton* button = [self buttonWithType:UIButtonTypeCustom];
  if (button && (class_getInstanceSize([button class]) == class_getInstanceSize([CWFavouritesButton class]))) {
    button->isa = [CWFavouritesButton class];
    // More init code...
  }
  return button;
}

And finally our factory method safely return a new button of the correct subclass, and pointInside:withEvent: is called as expected.

The full source code for SC68 Player where I implemented this is available for download here.

The sessions are confidential so I will keep this post vague on the technical parts, not revealing any thing that might or might not come to an iPhone or iPod touch near you in the future. And I can not mention any specific sales numbers, but I do can say that any predicted numbers you might have seen; is probably an underestimation with a margin and then some.

The sessions where on a high level, not going too deep on technical details. Instead the sessions concentrated on the overall design philosophies, and common gotchas. For the nitty gritty details Apple engineers where available, and I missed half a session discussing the ins and outs of the UIToolbar class with Alberto Arauz. Alberto is one of the european software evangelist, and was most impressed, and interested, when I described the successful Mobile 2.0 track at Øredev 2008. Apple's overall impression with Scandinavia has so far been a mostly cold hand regarding anything with Apple, going as far as only six people registering for a Tech Talk in Oslo two years ago.

Apart from the speakers and engineers, Apple also brought a video-team. So yours truly has been intervjued about the applications I have on App Store, and my experience with the iPhone SDK. The video will be cut and edited for promotional purposes, and hopefully me mentioning both Malmö and Jayway will not be cut out. The odds of my short talk being included is quite good, as most developers seems to be focusing on games, not utilities as I and Jayway has done.

The best part to take home is not technical, just solid advice for any development, not even under NDA, and the sole point repeated by Apple over and over: Developing great applications is not about adding features! The trick is not to cram in as many features as you can, the trick is to know what features to leave out, so that time can be well spend on the key features that do make the cut. And this is tenfold as important on a mobile device where real estate is limited. A quote from Mark Twain:

I apologize for writing you a long letter, but I did not have the time to write a short.

Writing short, and cutting features is hard. How to decide on the features to drop or implement? Apple uses a simple technique, called a product statement. The product statement for the Photos application is for example; "An easy to use photo sharing application for all iPhone users". Any feature that do not help fulfilling this statement do not make it. How about simple photo-editing? Nope, does not comply with statement. The wording of the product statement is important, by simply changing it to "An easy to use photo sharing application for professional photographers", would be a completely new application. Only when the product statement is agreed upon, can an approved list of features be made. An omnipresent Steve Jobs approving and dismissing features, is an exaggeration, this simple method is what do the trick.

Now this might sound both obvious, and counterintuitive. Surely adding that last nice feature would add value? Not at the expense of a cluttered user interface, that is meant to be used while standing in line for 30 seconds. Features thought to be must haves, most of the time are not. Some features thought to be must haves are MMS and video recording. Looking at the raging success of the iPhone, it is very obvious that they are not must haves. We as software engineers must at long last learn that it truly is quality over quantity.

And lastly a personal reflection; from a developer's point of view the best part about iPhone SDK is that it is not an UI framework, it is an Application framework. It do not settle with providing the tools for collections, persisting data, displaying a UI, and then leave the rest of the architecture to the developers. The iPhone SDK supports all three parts of the Model-View-Controller paradigm equally well, and that is what makes it so productive.