The Anecdotal History

We are developing a custom application framework on top of MIDP, adding a MVC application model, and modern interface components with touch and animation support. All this is build on top of a shared subclass of Canvas, and our own custom drawing with screen transitions, etc. is implemented on top of that.

An interface component is called a View, and any interface component that can host other interface components implements the ViewParent interface. Simple until I introduces the method hasFocus(). All of a sudden the application refused to run on target Sony Ericsson device. The emulator worked nice, our P1i worked, even the Xperia X1 run. But none of the cybershots, or walkmans with JP-7 or JP-8.

"Application error". Oh well, that means that something threw an exception during the MIDlet constructor or appStart() call. So add pedantic catches, and display the error in an Alert; "NoClassDefFoundError".

The Problem

NoClassDefFoundError on the OSE phones, but no other installed with the same jad/jar-files, that is strange. Unfortunately Sony Ericsson has a policy of removing all error messages from exceptions, so no clue as to what class is missing either. Turn off Proguard optimization, still does not work, still NoClassDefFoundError. Head back to the Subversion logs and binary search, what is the latest revision that worked? And what was changed?

Turnes out that the shared Canvas subclass that implement the aforementioned interface ViewParent got the new method hasFocus(), and that is the only change from the working revision, to the broken revision.

- "I'm pretty sure that is working.", one of the half dozen bug-hunting team member said looking at:

public boolean hasFocus() {
    return true;
}

As it turns out the platform implementation of the MIDP class Canvas has a hidden method named hasFocus(). It is not private, but declared as public and final, but not exposed in the public API. So when our subclass is loaded, our public hasFocus() method clashes with the unexposed public final hasFocus() of the platform's implementation.

Solution, and Lesson Learned

The method hasFocus() was renamed to isInFocus(), and now everything works again.

From now on we will:

• Never trust subclasses of MIDP classes.
• Test on device early and often, also for obvious changes.
• Always keep commits small and atomic.

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.

BDD in Java with easyb (John Ferguson Smart)

John started out by arguing that TDD is not about testing, it's about writing better code. That is, it's about making your code more maintainable, flexible, reliable and simple. TDD is forces the programmer to think about how to test the class before actually writing the class. BDD, on the other hand, helps to determine what to test and to write more focused code, by starting with the behavior. Instead of thinking that you're testing your class, you should think that you're validating your requirements!

easyb is a BDD testing framework for Java, written in Groovy (hence providing full access to all Java API's). It ensures that tests become clearer and easier to both write and read! It helps the developer to focus on the requirements only. A competitor to easyb is JBehave, which is an extension to JUnit. However, according to John, JBehave is more cumbersome than easyb.

easyb makes use of stories, much like the story cards in the Agile world. In a story, a narrative approach is used to describe a precise requirement. In easyb, a story could look like this:

 
scenario “Make initial deposit onto a new account”, {
	given “a new account”
	when “an initial deposit is made”
	then “the balance should be equal to the amount deposited”
}
 

This scenario is quite clear and readable, isn't it!? Furthermore, it's self-documenting - a very appreciated feature =) And the syntax is so trivial that even a non-technical stakeholder would have no problem understanding it. The developer can then reuse the given scenario (pseudo) code and implement the test case, like this:

 
import com.mycompany.bankonline.domain.Account
 
scenario “Make initial deposit onto a new account”, {
	given “a new account”, {
		account = new Account()
	}
	when “an initial deposit is made”, {
		initialAmount = 100
		account.makeDeposit(initialAmount)
	}
	then “the balance should be equal to the amount deposited”, {
		account.balance.shouldBe initialAmount
	}
}
 

The shouldBe call is an intuitive and readable way to verify that the requirement holds. Another way to verify the outcomes is to use the ensure syntax. Example:

 
ensure(account.balance > 0)
 

or

 
ensure(account) {
	has([balance:100])
}
 

easyb could be extended to use DBUnit (and further plugins for Grails and Excel are on the way). On the IDE support, the only good option is IntelliJ IDEA. It really comes down to the Groovy support, and Eclipse and NetBeans doesn't shine here. In those cases, you're better off running the tests in Maven or Ant, which both are well supported. In the upcoming version, easyb will have full support for Continuous Integration (CI), enabling automatic test execution in a CI-server such as Hudson.

Furthermore, easyb comes with a web application - Easiness (cmp. Fitnesse) - where stakeholders can create stories in plain text. The developers can then go ahead and implement the stories defined by the stakeholders. This is an important features, that further improves the cooperation between the customer and the provider. It really seems like a quite nice little framework! If you agree, have a look at it at http://easyb.org/.

From Concurrent to Parallel – Library-based parallelism in JDK 7 (Brian Goetz)

Brian is an expert in the concurrency area, but he's not a good presenter! He speaks faster than I can read, and his slides are so packed with info that he doesn't have time to say the half of it. That put aside, in this very interesting session Brian presented some really cool concurrency features to be included in JDK 7.

As you probably know, JDK 5 introduced a set of very useful classes for course-grained parallelism. JDK 7 will introduce a framework for fine-grained parallelism - the "fork-join" framework.

We have now reach a point in time when Moore's laws isn't valid anymore. The new reality is not faster CPUs but more CPUs. To adapt to these changes, programmers have to change the way they think about parallelism. The unit of work (UoW) that represents a task to be solved must be split into even smaller parts to be able to keep all hardware busy. Nowadays, it isn't enough to for ex. spawn a new thread for each service call in a server, the UoW must be split up even further.

Examples of finer-grained parallelism is searching, sorting and filtering a data set. Such a task is preferably solved by dividing it into sub-problems and combining the sub-results at the end. We could use the course-grained concurrency tools (for ex. Executor + Future) introduced in JDK 5 to solve this problem. However, with multiple CPUs available, these tools doesn't perform optimally. For ex., the shared work queue in the Executor becomes a bottle neck when the number of threads/CPUs increases. Furthermore, these tools provide no form of load balancing, i.e. if one thread finishes before the others, it is never reused.

The divide-and-conquer algorithm could also be applied to solve the problem. This great advantage of this approach is that it's independent of the number of CPUs used! Using plain threads for this approach is too expensive though, since thread creation costs way too much. However, the fork-join-operation in JDK 7 solves problems like these using the divide-and-conquer algorithm in a much more effective way! Internally, it uses an slim thread pool to overcome the cost of thread creation. Furthermore, no data-copying penalty exist since the data set (for ex. an array) is not divided/copied during the solution. Instead, the indexes within the data structure is used to define each data subset. Another advantage is that the code doesn't know how many CPUs it executes on, hence it's portable!

While the Executor (JDK 5) should be used for tasks consisting of both IO and computing, the fork-join-operation (JDK 7) should be used for highly compute-intensive tasks. Examples of such tasks are matrix operations, numerical integrations and game playing. The JDK 7 class to be used for these kind of problems is ParallelArray. It's a utility class that greatly simplifies the work of solving a task in parallel. You can think of it as an in-memory database for data sets. Typical usage is:

 
ParallelLongArray pa = ParallelLongArray.createUsingHandoff(array, forkJoinPool);
long max = pa.max();
 

The ParallelArray class provides operations for:

• Filtering (nestable)
• Mapping
• Replacement
• Aggregation (max, count, sum, ...)
• Application (one action performed for each selected element)

To compare, the ParallelArray class acts much like the Map-Produce concept introduced by Google but it works in a different domain (local system instead of in a distributed system).

The only downside really is that JDK 7 isn't scheduled until mid 2010, meaning we'll have to wait quite some time before we can actually use these new concurrency features. But from the looks of it ... it may be worth the wait!

The SpringSource DM Server (Joris Kuipers)

The reasons why SpringSource decided to develop a new application server were many. Today, modularity is important and developers spend much time on achieving it in their applications (layering, separation of concerns, etc.). However, when the application is deployed, all modularity is lost - the deployable unit is one huge, monolithic WAR file. That means that sharing code (let alone services) between applications become hard if not impossible. In order to perform the smallest update on the application, whole WAR file have to be redeployed. Furthermore, the servers themselves lack modularity; they come prepackaged with a lot of modules but there's no way to configure that your application only make use of a couple of them. Hence, they are all left in there, consuming unnecessary CPU cycles and memory.

The DM (Dynamic Modules) server was developed to tackle these issues of non-modularity. In order to achieve true modularity, is has been built on top of OSGi (namely the Equinox container). Since OSGi can be quite hard sometimes, the DM server conceal the complexity of OSGi in the same way as the Spring framework does with for ex. Remoting or JMX.

In order to be able to use a third-party library from within the DM server (and from any other OSGi containers), the standard JAR library needs to be extended with OSGi-specific meta data - the OSGi manifest. SpringSource has therefore created the Enterprise Bundle Repository, where they have started to upload and publish OSGi-ified Java EE libraries. If you're using Maven or Ivy, the bundle repository can easily be configured as a remote (or local) repository.

The DM server also introduces a couple of new OSGi import constructs, enabling ease of development. One example is the "Import-library" that can be useful if you want to make use of a framework (for ex. Spring) but don't want to waste your time having to specify every single Import-package (for example Spring-Remoting) within the framework (as you normally would have had to do). This doesn't affect performance improvement since (thanks to OSGi) none of the pre-installed bundles are loaded before they are actually used! Furthermore, with the DM server it's now possible to remove the library bloat of monolithic Java EE WARs. Instead of building the external libraries into your WAR, you can instead declare them as dependencies in the OSGi manifest headers. The server will then convert these into plain "Import-package" constructs during deployment. That way, the size of the built/deployed WAR can be reduced significantly!

In the DM server, one can of course deploy plain OSGi bundles but also WARs, EARs etc. Typical scenarios for deploying a plain OSGi bundle are stand-alone libraries, global services and small stand-alone applications. However, being able to deploy a bundle is not enough in most cases ... A normal application normally consist of multiple bundles, which becomes hard to un/deploy since there is no single deployable unit. Furthermore, with multiple bundles you don't get a common log file or a notion of an application scope. To tackle this issue, the DM server adds the notion of an application by introducing the PAR (Platform Archive) format. It's basically a JAR with a number of 'Application-*' manifest headers. You can think of it as an EAR in Java EE. PARs are versioned and the versions apply to all of their bundles. This mean that one can deploy a PAR twice with different versions but with the same bundles, without conflicts.

The DM server comes in several versions. Of course there's the community version, using a GPL and SpringSource license. Then there's the commercial license where full support from SpringSource is included. On the extension side, better Maven support will soon be released so that the dependencies can be specified in a single place (not like now when you have to duplicate them in the pom and in the manifest). There's a Eclipse-plugin available that enables re/deployments from within the IDE.

These are some of the features in the DM server. There are plenty or more cool ones, read all about them here. There, you'll also find a lot of sample applications that can get you going! With the DM server, SpringSource feel that they are filling the (up until now) empty space of server side OSGi and states that "The DM server is the healthy new way to run your apps!". I must say it looks very promising! Why don't you go ahead and try it out!? I know I will!

If you appreciated these posts, you will definitely enjoy next years conference! Pick up your calendar and reserve December 2009 for a great week at Devoxx!

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.

Framework independence

First of all the internal structure of the project has undergone major changes. PowerMock core is no longer coupled to EasyMock which means that PowerMock can now be used as a foundation for testability for other mock frameworks. Our intention is that in the future you pick a combination of a mock extension API of choice (such as EasyMock, Mockito or JMock) and a test framework of choice (such as JUnit or TestNG) to enable increased testability for your code. With the new release PowerMock has some basic support for Mockito using the Mockito extension api. This means that you can mock final and static methods, use annotations, enable partial mocking, mocking of signed classes even if they're package private and spying of final classes and methods. Expect more features in the upcoming releases! It's possible to create your own extension API's as well so you can benefit from the PowerMock features in virtually any mock framework.

Test listeners

Another noteworthy feature of the new release is the test listener support. This means that you can create listeners and get notifications of various events, such as before a test method is about to execute or the outcome of an executed test method etc. The purpose of these test listeners is to provide a framework-independent way to get and react to these notifications by implementing the org.powermock.core.spi.PowerMockTestListener and pass it to the PowerMockListener annotation. PowerMock has some built-in test listeners for you to use, for example it has an AnnotationEnabler that let's you use annotations to create your mock objects. For example consider the following piece of code:

@RunWith(PowerMockRunner.class)
@PowerMockListener(AnnotationEnabler.class)
 public class PersonServiceTest {

 	@Mock
  	private PersonDao personDaoMock;

  	private PersonService classUnderTest;

  	@Before
  	public void setUp() {
  		classUnderTest = new PersonService(personDaoMock);
  	}
   ...
  }

Using the @Mock annotation eliminates the need to setup and tear-down mocks manually which minimizes repetitive test code and makes the test more readable. The AnnotationEnabler works for both the EasyMock and Mockito API's. You can also supply the names of the methods that you wish to mock if you want to create a partial mock, for example:

@RunWith(PowerMockRunner.class)
@PowerMockListener(AnnotationEnabler.class)
 public class PersonServiceTest {

 	@Mock("getPerson")
  	private PersonDao personDaoMock;

  	private PersonService classUnderTest;

  	@Before
  	public void setUp() {
  		classUnderTest = new PersonService(personDaoMock);
  	}
   ...
  }

This piece of code will instruct PowerMock to create a partial mock of the PersonDao where only the "getPerson" method is mocked. Since EasyMock has support for nice and strict mocks you can use the @MockNice and @MockStrict annotations to get the benefits of this.

Mock policies

One really cool feature of the 1.1 release is something that we refer to as mock policies. A Mock Policy can be used to make it easier to unit test some code with PowerMock in isolation from a certain framework. A mock policy implementation can for example suppress some methods, suppress static initializers or intercept method calls and change their return value (for example to return a mock object) for a certain framework or set of classes or interfaces. A mock policy can for example be implemented to avoid writing repetitive setup code for your tests. Say that you're using a framework X that in order for you to test it requires that certain methods should always return a mock implementation. Perhaps some static initializers must be suppressed as well. Instead of copying this code between tests it would be a good idea to write a reusable mock policy.

PowerMock 1.1 provides three mock policies out of the box for mocking slf4j, java commons-logging and log4j. Let's pick slf4j as an example and let's say you have a class that looks like this:

public class Slf4jUser {
        private static final Logger log = LoggerFactory.getLogger(Slf4jUser.class);

        public final String getMessage() {
                log.debug("getMessage!");
                return "log4j user";
        }
}

To stub all calls to the logger you can use the Slf4j mock policy that takes care of doing all necessary setup for you. You use it like this:

@RunWith(PowerMockRunner.class)
@MockPolicy(Slf4jMockPolicy.class)
public class Slf4jUserTest {
     ...
}

Note that we don't have do any setup at all to mock slf4j, the Slf4jMockPolicy takes care of this.

Mock policies can also be chained or nested like this:

@RunWith(PowerMockRunner.class)
@MockPolicy({MockPolicyX.class, MockPolicyY.class})
public class MyTest {
    ...
}

You can of course create your own mock policies by implementing the org.powermock.core.spi.PowerMockPolicy interface. For more information on mock policies please have a look at the documentation.

Other

There are of course many other smaller features and improvements such as the ability to suppress individual fields and better support for resetting mocks in the EasyMock API. You can read about all the new features and bug fixes in the changelog. Please visit our web-page for more information and downloads.

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.

So I took out my laptop during the next 60 minutes of Panel Debate, and wrote an iPhone app, and as I expected the code landed on 46 lines of code for the actual application logic, physics, grits and all. Or 112 lines of code if headers and boiler-plate should be counted as well.

This blog post will describe what I did, in a quite nice model-view-controller fashion (Model and Controller is implemented in the same class).

• First of all I needed a view to display my bouncing ball on, I choose to subclass UIViewController to handle this view.
• A standard UIView instance with a UIImageView sub-view for the ball is all I need for my view, this I setup using Interface Builder.
• And the model/logic is handled by one CGPoint for the current location, and one CGPoint with the current delta movement of the ball.

First the custom view controller sets up itself as the accelerometer delegate when awakening from it's nib-file.

-(void)awakeFromNib;
{
  self.location = CGPointMake(160, 230);
  UIAccelerometer* accelerometer = [UIAccelerometer sharedAccelerometer];
  accelerometer.updateInterval = 0.02;
  accelerometer.delegate = self;
}

Then comes a private function for the quite faked physics, it is responsible for detecting if a value with a given delta movement has hit a min or max edge. If it do hits an edge, it flips it's delta movement with some deceleration, and corrects it's value.

static inline BOOL bounce(float* val, float* delta, float min, float max) {
#define FLIP(val, c) (c - (val - c))
  if (*val < min || *val > max) {
    *delta = -(*delta * 0.75);
    float loc = *val < min ? min : max;
    *val = FLIP(*val, loc);
    return YES;
  }
  return NO;
}

And lastly the delegate method that is called by the accelerometer. Here we update the delta movement, and use the bounce-function to detect and compensate location+delta when the ball hits any edges. If an edge it hit, a vibration is also triggered.

-(void)accelerometer:(UIAccelerometer*)accelerometer
       didAccelerate:(UIAcceleration*)acceleration;
{
#define CAP(val, max) (val < -max ? -max : (val > max ? max : val))
  CGPoint delta = CGPointMake(CAP(self.delta.x + acceleration.x, 32),
                              CAP(self.delta.y - acceleration.y, 32));
  CGPoint location = CGPointMake(self.location.x + delta.x,
                                 self.location.y + delta.y);
  if (bounce(&location.x, &delta.x, 8, self.view.bounds.size.width - 8 ) ||
      bounce(&location.y, &delta.y, 8, self.view.bounds.size.height - 8))
  {
      AudioServicesPlayAlertSound(kSystemSoundID_Vibrate);
  }
  self.delta = delta;
  self.location = location;
  self.ballView.center = self.location;
}

In conclusion Cocoa Touch requires surprisingly little code for accessing and using the accelerometer and trigger a vibration. Triggering a vibration is literary done with a single line of code. The lines of code needed to setup and listen to the accelerometer can literary be counted on the fingers of one hand.

On the downside there is no finer control of the vibration, and if you like to have the rotation angles of the device instead of simple gravity forces of the x, y and z axis, then you must do the math for yourself. Simple enough, but it would had been nice to have to current rotations around each axis as well.

The full source code can be downloaded here.

ps. I dare Mike Jennings to best this :). ds.

We have received some feedback and have also started some evaluation in one of our customer's project. Besides bug-fixes and documentation updates we are starting to stabilize the API and preparing for the 1.0 release. We are also presenting PowerMock at this years Øredev conference. You're more than welcome to try it out for yourself.