When OS X 10.5 (Leopard) was released back in late 2007, I told a colleague at the time that Leopard was, by far, the worst release Apple ever put out. You can pardon a bit of hyperbole there, but after a healthy string of solid releases of OS X that just “worked”, the problems produced by Leopard were numerous (one might counter that this is all relative– four to five issues might not sound as numerous to users of other operating systems, but for OS X, these were a pretty big deal, and kept me from switching for months).

By comparison, Snow Leopard marks a great return to the kind of releases the Mac community came to expect. Yes we still have a month left to wait for its release, and yes there might always be small glitches, but as one long-time Mac user the answer to the question of “is it really all that?” the answer is pretty clear to me at least: “Yes, yes it totally is.”

There are two ways of looking at an operating system: the underpinnings of the platform (in the technical sense), or, in the popular sense, the body of applications surrounding and defining a baseline of functionality all users can expect each other to have. The great thing about Snow Leopard is, without getting into details itself, that there are enough improvements in both areas to make this a must-have upgrade. And as a footnote, the number of issues I have had with the betas so far have been relatively minor in comparison with 10.5. There really is no contest. Whereas the initial release of 10.5 brought some improvements to the operating system at a very large cost for early adopters, 10.6 brings a lot of improvements with much lower risk.

I’m not going to rehash what’s new in Snow Leopard, but suffice to say that it proves out the wisdom of Apple’s strategy to focus on improving the internals ‘under the hood’ for this release. Since the release of 10.5, Mac users have been fortunate enough to see improvements with other technologies on the platform (Safari 4 comes to mind), and hardware that continues to improve both in features and price. OS X by itself does not need to draw people to the platform– the iPhone and Mac hardware will do that. So it seems to me that, thanks to these other factors, the keys to the OS have been given back a bit to the engineers– and if my instincts are right, it’s going to be a great release.

Share/Bookmark

Recently I have taken a bit of a detour into the world of telephony, working with Asterisk-Java, which by itself is a very valuable tool, and worth knowing a bit about if you are integrating a system with Asterisk. While it is a Java-based library, I am integrating it into a Grails application.

We have a fairly comprehensive suite of unit tests asserting that desired behaviors are triggered upon certain events initiated through the Event API. This is made even easier, as usual, with Groovy– specifically on the testing front. Here I show two hypothetical test cases, followed by supporting code that works specifically with the Asterisk-Java classes…

import org.gmock.GMockTestCase
import org.asteriskjava.manager.event.JoinEvent
import org.asteriskjava.manager.event.LeaveEvent

def queueObject = // .... some object representing an internal queue

/*
 * Verifies caller entering a call queue will trigger behavior
 */
void testCallIAddedToQueue() {
  mock(queueObject).add('SIP/123', '3125551234').once()
  dispatchJoinEvent([channel: "SIP/123", callerId: "3125551234"])
}

/*
 * Verifies caller leaving call queue will trigger behavior
 */
void testCallRemovedFromQueue() {
    mock(queueObject).remove("SIP/123").once()
    dispatchLeaveEvent([channel: "SIP/123", dateReceived: new Date()])
}
// ...

The testcases above are fairly straightforward, hiding much of the details involved when working with Asterisk-Java. The ‘queueObject’ can be anything, really, as long as it contains behavior which we wired into the event-handling system Asterisk-Java provides. The important part here is how we can easily bind properties to the underlying Event types, and dispatch them so that our behavior is invoked.

private def dispatchJoinEvent(properties) {
  dispatchEvent(JoinEvent, properties)
}

private def dispatchLeaveEvent(properties) {
  dispatchEvent(LeaveEvent, properties)
}

private def dispatchEvent(eventType, eventProperties) {
  def event = eventType.newInstance([:])
  eventProperties.each { name, value -> event."${name}" = value }
  play {
    asteriskService.connection.dispatchEvent(event)
  }
}

Here I have a ‘service’ class defined in Grails which I call ‘asteriskService’. It encapsulates access to the Asterisk-Java ManagerConnection instance, which in turn can dispatch specific events.

Of interest to those new with Groovy is the binding of properties within ‘dispatchEvent()’. It looks perhaps a bit more complex than one would hope, but unfortunately JoinEvent and LeaveEvent do not have default constructors, requiring the code to ‘new’ them up with a placeholder argument, and then set any properties on the fly.

Asterisk-Java is worth checking out, but particularly nice is using a bit of Groovy to tie it in nicely. While this can benefit the application, you can see how it helps ease testing– particularly as you start using more and more of what the library offers.

Share/Bookmark

I have a native iPhone application in development which requires me to interact with a server that uses a stateful protocol over a persistent connection to transfer messages over the wire. This is definitely not a trivial application to write, even though the UI itself is very simple.

The Problem

Stateful protocols and persistent connections are often interrelated, but not by design. My first problem was to divide the original problem in two: how to manage the persistent connection, and how to handle the underlying protocol so that the stateful aspects did not bubble up throughout the UI.

Persistent connections can be difficult to manage, particularly when the network topology can change so drastically (such as on mobile devices). In this sense, there is nothing new here– while the framework can notify you of connection events, it is still up to the developer to decide on the appropriate action.

The statefulness of the protocol, however, is trickier to deal with. We must track the state of the connection, and notify the caller of ‘certain’ errors. I say ‘certain’ because there is a class of errors that can be dealt with on behalf of the client in a reliable way, affording the rest of the application to treat the protocol as if it were stateless in most cases.

In dealing with the issue of maintaining the persistent connection, I wanted a solution which prevented me from having to manage separate thread(s), run loops, or NSOperationQueue. It is not that these approaches could not work, only that I wanted fewer failure points in the code, and experience has shown that many times there is a better way. Synchronous network calls were obviously not an option (if you didn’t get a visceral reaction upon the very idea, just try and go that route– it is not a happy place to be).

Managing the Persistent Connection

Luckily, AsyncSocket can do much of this for you. It’s a great library for this sort of work, and I would recommend it over just using the NS connection classes alone. This library, however, does not do everything for you. You still have to refer to the connection from your code (either through a shared singleton approach, or as an injected dependency).

Managing the Stateful Protocol

I first attempted to create an interface on top of the network protocol, and quickly realized that this path would involve quite a bit of ‘target/action’ callbacks. So the choice was to either create a delegate protocol around my interface, or else use the NSNotification model to notify interested parties when certain events completed. Again, both of these options are possible, but there was just one problem…

…NSURLConnection and NSURLConnectionDelegate provide a lot of this for you. Knowing this, why wouldn’t I want to capitalize on the framework? No synchronous calls, no extra delegate protocols to write. You get certain faculties for free using this route as well– an established architecture for managing credentials, caching strategies, and in some cases, a way in which you can write and test your application against stateless protocols (say, HTTP) in a controlled, test environment, before actually testing against your custom, stateful protocol (let’s presume access to the server is limited).

I was sold.

The Work

At this point, the problem became one of first developing a URL scheme for my needs, and then subclassing NSURLProtocol. My own implementation of NSURLProtocol checks the state of the single, persistent connection on each request, and issues an authentication challenge to the caller if the connection could not be created (this gives the user the ability to intercede, enter a password, or just cancel the connection).

The URL scheme is fairly straightforward, as the ‘path’ element of NSURL translates directly to commands on the server. Query parameters represent arguments.

The Way Forward

There is still more work to be done, of course, but the architecture is very clear. As mentioned above, I plan to handle changes in the network connection. Without this, a slow cellular connection, say, would still be used even when a faster connection type suddenly became available. Since the handling of the underlying connection is behind the protocol layer, this becomes an easier change to manage than if all parts of the code had to concern themselves with changes in the network connection itself.

My experience so far has taught me a few things about both the URL loading system in Cocoa, and how to deploy these kind of apps in the wild. There are not many examples of NSURLProtocol out there. This is a common complaint, but the points above, along with the existing sample code, should help steer you in the right direction.

Related Services: iPhone Application Development, Custom Software Development

Share/Bookmark

Security is unlike other aspects of software in that it follows a steep value curve: either your system is secure, or it is not. Either it provides its full level of value, or it provides none at all. There is often a tendency to address security up front (even when other aspects of the system are built iteratively). What others sometimes fail to see is how this generates unneeded cost and complexity as the project matures.

Balancing Security & Flexibility

It is simple to expect our software to be highly secure and highly flexible all the time, but as a product matures the trade-offs become apparent. Unlike security, other aspects of the application follow a different value curve. While the organization evolves. Security may be stuck reflecting an organization that no longer exists. The reason why this is so is easy: we often build it without the right kind of flexibility in mind.

Imagine a large, hierarchical organization and an application that helps manage it. We might want to reflect the entire organizational structure in our security model (regions have divisions, divisions have departments, departments have units, etc). Conventional wisdom says that future functionality will span any given sub-unit of the organizational hierarchy. Hence, you implement a rigorous security infrastructure, even though your business features are only take advantage of it bit by bit. This up-front cost is often justified by the notion: “either my system is secure, or it is not.”

I have seen examples of this kind of thinking, and it can end up costing more money than you think. While these initial design is intended to speed up development down the line, they are often predicated on the notion that the organizational structure will either remain static, or be infinitely flexible. What you get is overhead from day one of being in production.

Addressing all of security up front trades a real, fixed cost for the possibility of increased efficiency at an unknown, future date. Only in hindsight do many organizations realize how risky this type of proposition can be, since it makes a few dangerous assumptions:

• “Will I have the same development team writing those features later on?”
• “Will I have the budget for those features that take advantage of the security infrastructure?”
• “Will my vendor relationships change by then?”
• etc.

So What’s the Answer?

The needs of security can (and will) change over time. We strive for flexibility in other aspects of application architecture, but often demand stringency in tackling security. The right balance between these two concerns can only be found over time, and not up front. Remind yourself of this early on and challenge any presumptions up front. Don’t build in more security measures than you have to, and expect these measures to evolve. The right development team will understand this as well.

Next, design security around the most important aspects of your organization, not the entire organization all at once. Decisions you make up front need to reflect idiosyncrasies of the organization, keeping things as simple as possible to lock down the immediate features you have the budget to implement.

One of the benefits of iterative development is that your security model can (and should) evolve along with your features. Start simple, let the ideas prove themselves out, and you have a much better chance of finding the right balance between keeping your application secure and maximizing its flexibility.

Share/Bookmark

‘hieroglyphics’ by Em_G

One of the things I most admire about Ward Cunningham’s work is that you can read something like ‘Signature Survey‘ and still find new things to appreciate, even years later.

Ward’s original article discussed a method to tackle large code bases (based somewhat on Tufte’s ideas on data visualization). To quote the original article, he summarized the process as the iterative application of two steps:

1. Inspection. Browse the report looking for startlingly regular or startlingly irregular structure. Examine the source code associated with each (ir)regularity.

2. Projection. Modify the summarization program (the cgi script that generates the report) so as to represent aspects of the inspected code that seem relevant to the inquiry at hand.

The real lesson I took years ago from ‘Signature Survey’ is that, when dealing with any sufficiently complex problem, knowing which questions to ask may not be obvious. And rather than approaching each problem with the same set of questions or criteria in mind, it is useful to let the problem itself guide you to the right questions.

All of this should seems obvious right? It is, after all, a simple idea. Still, if you have never done so, I would ask you to really give this idea some thought. Sleep on it. Think about it during your walk back from lunch tomorrow and take your time with it. Toy with the idea and some current problem you are working on. I’m not kidding– the exercise will be worthwhile in the end, and will continue to pay off.

Share/Bookmark

One of the new features of Groovy 1.6 includes support for per-instance metaclasses. This is a nice addition to the language, since it allows to change the behavior of objects without affecting all instances of the class as a whole.

For testing, it is often useful to mock out specific behavior of an object without affecting the class as a whole. While some mocking frameworks already allow this, they usually run through a few hoops (i.e. “partial mocks”). Allowing support directly in the language can simplify this kind of approach.

Another case where per-instance metaprogramming can be useful is in employing template patterns on a per-instance basis. Picture the case where the domain decides that one of its children is no longer in a valid state. Most domain models handle this by embedding some sort of state object within the children, so that any object holding a reference to the children know what the child can or can not do. With a per-instance metaclass, however, the aggregate root can simply add or replace behavior of that instance of the object alone.

Here’s a made-up example of how this could work. Picture an online booking engine where a ‘Reservation’ handles the domain logic for booking a flight. Part of this may involve reserving a seat through an external airline booking system.

//
// Representation of an airline booking system
//
class ReservationService {
    def name
    def reserveSeat(flightNumber) {
        /* some network call.. */
        return true
    }

    def postProcess() { }
}

class Reservation {
    def bookFlight(flightNumber, service) {
        def confirm = service.reserveSeat(flightNumber)
        if (!confirm) {
            service.metaClass.postProcess = {
                println "Error for provider '${service.name}'"
            }
        }
        service.postProcess()
        return confirm
    }
}

reservation = new Reservation()

delta  = new ReservationService(name: "Delta")
united = new ReservationService(name: "United")

assert true == reservation.bookFlight("1234", delta)
assert true == reservation.bookFlight("1234", united)

// Mock out our connection to Delta
delta.metaClass.reserveSeat = { return false }

// The following prints an error, due to 'postProcess'
assert false == reservation.bookFlight("1234", delta)

Clearly this is a made-up example, but as you see from the above code, we have a situation here where we can associate specialized behavior with a specific object at runtime. I imagine you can use the same approach with things like exceptions which can themselves be called upon to report or behave in certain ways as they are caught further up the stack. Whether or not this is a good design approach is a separate issue however.

Share/Bookmark

Testing your iPhone application, you may at some point in time need to stub a method call whose return type is a boolean (or some scalar value, or C based structure). The way to implement this (as described in a discussion on CocoaDev here) is to wrap the boolean in an NSValue using the OCMOCK_VALUE() macro defined in OCMockRecorder.h.

While this solution technically works, I find that doing this within the test class itself makes the test cases a little less readable along the way. Instead, I found it useful to extend OCMock to do this type of conversion for me, keeping my test code a bit cleaner as a result.

Let’s take a look at an example by examining the set up for a simple test case..

Imagine that we have a class (‘MyTreeNode‘), which models a typical tree-like structure. Each node in the tree must respond to the selector ‘hasChildren‘, which returns a boolean of type BOOL.

Initial Testcase

BOOL yes = YES;
NSValue *wrappedValue = [NSValue valueWithBytes:&yes
                                       objCType:@encode(BOOL)];

id mockRoot = [OCMockObject mockForClass:[MyTreeNode class]];
[[[mockRoot stub] andReturnValue:wrappedValue] hasChildren];

(Note that I am using valueWithBytes:objCType: on NSValue instead of value:objCType:, as found in the OCMOCK_VALUE macro. It’s a slight difference, but since the API docs for NSValue suggest that the latter may deprecated at a future date, I would use the preferred method call instead).

This test case is all fine and good, but those top two lines have nothing to do with expressing the real intent of this test case. In the end, it’s all just noise. Improving on this, you can encapsulate the creation and use of the NSValue behind the mocking framework. This is accomplished using a simple category.

Extending OCMock

The interface is defined as follows, in a file I named “OCMockExtensions.h”:

#import <OCMock/OCMock.h>

@interface OCMockRecorder (BooleanMethods)
- (id) andReturnBoolean:(BOOL)aValue;
@end

The implementation itself is also straightforward. We basically implement the same logic, but hide it behind a new method on OCMockRecorder itself.

@implementation OCMockRecorder (BooleanMethods)

- (id) andReturnBoolean:(BOOL)aValue {
    NSValue *wrappedValue = nil;
    wrappedValue = [NSValue valueWithBytes:&aValue
                                  objCType:@encode(BOOL)];

    return [self andReturnValue:wrappedValue];
}

@end

Resulting Testcase

All of this allows us to stub out our hasChildren method in the original test case using a more readable form.

  id mockRoot = [OCMockObject mockForClass:[MyTreeNode class]];
  [[[mockRoot stub] andReturnBoolean:YES] hasChildren];

Short and sweet. There are probably other variations on this theme, each of which might make more sense for you. But I hope this gets you thinking of how best to handle these types of test scenarios without having to clutter your test method with a lot of set up code for your mocks. If experience is any guide, set up code for mock objects can easily get out of hand as a code base matures, so anything you can do to reduce this clutter and help the test cases express their intent in a clear and succinct manner can go a long way toward having your tests work for your team.

Related Services: iPhone Application Development, Custom Software Development

Share/Bookmark

As I have discussed earlier, you can go very, very far in unit testing your view controllers using the following recipe, without the need to bend over backwards or employ any mocking frameworks:

1. Initialize the view controller in your setup using initWithNibName:bundle:.
2. Force the view to initialize by invoking the controller’s loadView method within your setUp method.
3. Write tests to assert dependencies or behavior.

This works well enough for view controllers, but when it comes time to test your application delegate, this simple approach can begin to break down. Unlike UIViewController, your application delegate is only initialized as a by-product of loading the NIB. Thus, to get this code under test I find OCMock particularly useful.

I show an example unit test below, and discuss how I approached the problem..

Background

The UIApplicationDelegate protocol defines a series of optional methods which allow you to respond to application-level events. While the app delegate will not contain much code, the code it contains is certainly important enough to test. The problem however is that the delegate is initialized as a by-product of UIApplication itself.. something which, if you build your project using one of the predefined templates, is performed as MainWindow.xib is loaded. Unlike the recipe above, however, you might find issues (this boils down to a chicken & egg problem, as there can only be one instance of UIApplication at a time, so loading MainWindow.xib as part of a test can present problems when you are running in debug mode).

The Code Under Test

Let’s look at a test case that uses mock objects instead. Here I have chosen to test a simple, navigation-based application. The default application delegate essentially contains the following code:

- (void)applicationDidFinishLaunching:(UIApplication *)application {
	[window addSubview:[navigationController view]];
	[window makeKeyAndVisible];
}

If you’re familiar enough with this example, you’ll know that this method is invoked by the framework. It is also the point in time in which you can initialize anything which needs to be initialized on startup (note that navigationController and window are initialized for you via the NIB). Now then, without adding any more code, there are already two things we would like to test:

• The UINavigationController‘s view is a sub-view of our window.
• The window is made ‘key’ and ‘visible’ on start.

Assumptions

Since we are not loading the actual NIB file, we need to set up the following assumptions.

• The reference to a UINavigationController instance variable is properly set.
• The reference to a UIWindow instance variable is set.

Making these assumptions means we will not be testing them directly, but it’s a compromise which is better than not testing our delegate at all. Moreover, if either of these assumptions are ever invalidated, we can trust that the error will be easily noticeable upon application start up.

Test Setup

Here is the setUp method of my test class. Notice that my mock objects don’t really come into play yet.

- (void) setUp {
	//
	// Create placeholder for controller
	//
	UINavigationController *nav;
	nav = [[UINavigationController alloc] init];
	nav.view = [[UIView alloc] init];

	//
	// Initialize delegate with placeholder
	//
	delegate = [[MyApplicationDelegate alloc] init];
	delegate.navigationController = nav;
}

The delegate is missing a reference to it’s UIWindow. Rather than setting that dependency in the set up, I choose to add it in the test method below, grouped with expectations on the mock itself before invoking applicationDidFinishLaunching:.

The Unit Test

- (void) testDelegateInitializesWindowSubview {
	//
	// Mock window on our delegate
	//
	id mockWindow = [OCMockObject mockForClass:[UIWindow class]];
	delegate.window = mockWindow;

	//
	// Set up expectations
	//
	UIView *expectedView = delegate.navigationController.view;
	[[mockWindow expect] addSubview: expectedView];
	[[mockWindow expect] makeKeyAndVisible];

	//
	// Invoke & verify
	//
	id myApp = [OCMockObject mockForClass:[UIApplication class]];
	[delegate applicationDidFinishLaunching:myApp];
	[mockWindow verify];
}

Whether or not you set up the mock window object in the test method or setUp is up to you. I find it good practice to only put code in setUp that applies to all test methods. Since this is the only test method I expect will exercise the UIWindow dependency, I move it closer to the test case itself. To leave it in setUp may suggest to another developer that all test cases require this dependency to be set at all times. Because of the nature of the application delegate, however, that is likely not to be the case.

I hope this shows you a way in which you can test your delegate methods, and more importantly, dispel any notions that the delegate itself is too hard to test.

If you take a look at UIApplicationDelegate, you will quickly find that the methods here are not at all trivial, and relying on manual testing alone is risky. In this regard, I think using OCMock for this purpose is not only a smart move, but also necessary to avoid any collisions with the bootstrapping of your test environment itself.

Related Services: iPhone Application Development, Custom Software Development

Share/Bookmark

I recently ran into an issue building an app which hit an existing (protected) website. Passing credentials along with each request, responses at first appeared to be cached, even after the user credentials changed from within the iPhone app. In sorting through this issue, it gave me a chance to get a bit more familiar with NSURLRequest, and NSURLRequestCachePolicy. As I later found, however, my problem turned out to be cookie-related..

Starting out, I assumed there to be a relationship between setting the cache policy on NSURLRequest and the behavior I would see when implementing connection:willCacheResponse: from within my delegate. When setting the cache policy to NSURLRequestReloadIgnoringLocalCacheData did not solve my problem, I implemented the latter delegate method in order to intercept any cached response.

I spent an hour or so of looking into this issue, with no success. Grabbing a late cup of coffee, I rolled back my changes and took a fresh look at things.

On the one hand, I was convinced by this point that the responses were not actually being cached. In fact, I felt had the feeling that the problem had nothing to do with cached responses at all. After double checking to make sure I was not holding on to the original credentials elsewhere in my code (stuffed inside an instance variable perhaps), it finally dawned on me that the problem might be related to the site I was connecting to, and its use of cookies to keep track of the user’s identity after a successful login.

Fast forward ten minutes and one cup of coffee to the realization that this was indeed the case. Upon the first successful login, the site sets a cookie which NSURLRequest passes along on subsequent requests, even when the underlying credentials had changed! The fix here (in my adapter code) seemed pretty straightforward:

• When the user credentials change, ignore any cached responses
• When the user credentials change, invalidate any cookies

I changed my HTTP adapter class to expose the underlying ‘cachePolicy’, and to then contain the following code when constructing new instances of NSURLRequest:

NSMutableURLRequest *req;
req = [NSMutableURLRequest requestWithURL:url
                              cachePolicy:cachePolicy
                          timeoutInterval:60.0];

if (cachePolicy == NSURLRequestReloadIgnoringCacheData) {
    [req setHTTPShouldHandleCookies:NO];
}

This solution is a bit of a stopgap– the only time I ever need to ignore the cache is when the user credentials change while the application is running. Every other caller of this class expects the default cache policy. And this “fix” has more to do with the behavior of the existing website I access (and its use of cookies) than NSURLRequest per se.

In short, there is good news and bad news. The good news is that it works. The bad news is that I am still not completely happy about the solution. The only silver lining here is that the implementation did not involve too much hand waving, and should be easy to remove once I find a better way.

While it is good to know that one can disable cookie support on a request-by-request basis, I will probably take the next step and model the user credentials in a way that makes this type of behavior transparent to all other kinds of HTTP requests.

Related Services: Custom Software Development

Related Services: iPhone Application Development, Custom Software Development

Share/Bookmark

A new version of TeamCity is out, and while I have not taken it for a ride yet, I found this feature particularly interesting:

Risk Group Tests, Tests Re-ordering
TeamCity 4.0 is now able to determine a set of tests which are likely to fail (i.e., recently modified, those with frequent failures history, etc.), and perform those tests first the next time the project builds. This allows teams to confirm potential fixes sooner, reducing feedback time.

There are strong cases to be made for risk-based testing in certain environments. The reason why it is not more commonplace is that implementation is tricky since it requires the CI system to know a few things which are hard to generalize:

• The type of build and testing framework
• Historical perspective across multiple builds
• A good set of heuristics along the way

Since a risk-based approach may mean skipping certain tests on some builds, this may sound like a step backwards to the agile developer. But consider it an alternative to improving overall build time (i.e. “based on very low risk assessment, tests which never failed will not be run every time.”). The hard part is defining what “low risk” means to your project, and how much value you would get reducing overall build time.

This is obviously not an issue on well-run projects with sub-minute builds, but if you were to be dropped into an existing project with, say, a large code base and a fifty-two minute build (I’ve seen it), this can become one way to perform triage on an otherwise untenable position. You don’t need a new CI system to implement risk-based testing, but having this alternative can’t hurt.

Share/Bookmark