The Singleton Pattern Revisited

Need to test a singleton ?

Suppose you have singleton class A:

class A {
public static A getInstance() {...}

private A() { ... }
public int doStuff() { ... }
}

How can you test it if you can’t use your mocks ? Simple put it in a package and make ASingleton that creates A using a constructor package default ! Since your tests run in the same package you will be able to extend it and use your mocks while still having a semi-private constructor.

class A {
A() { ... }
public int doStuff() { ... }
}

class ASingleton {
private ASingleton() {}
public static A getInstance() { ... }
}

Responsive Design: don't block the workflow

I’m currently designing the interface and testing the workflow for the whole iPad/iPhone application I’m making and everything is well when everything works. However, in the current setup that I have the Insteon nodes don’t get messages from time to time; with power line signaling there is always something that can go wrong and this is why I prefer dedicated wiring but I had no choice. What happens when a message is lost is quite irritating; the GUI just sits there util the server hits a timeout. This really breaks the flow of the user. So let’s look at why this happens.
Continue reading