my take on things

303

2011-03-01T06:07:00.000+01:00

This is my last blog post here on blogger.com! You'll find my new thoughts, projects and development ramblings at http://dlinsin.github.com. I migrated to blogger.com in late 2005 and was always quite happy with it. More than 5 years and exactly 502 posts later it's time to move on to something new. Subscribe to my new blog feed, check my stuff on github or follow me on Twitter.

ShareKit Pimping

2011-02-15T19:30:00.000+01:00

A couple of months ago, I improved Word Buzz' Twitter sharing feature significantly, by leveraging a tweaked version of an existing framework. Unfortunately, I had only heard of ShareKit at that time, that's the reason why I decided to implement my own solution!

In case you don't know about ShareKit or like me only heard about it:

SharKit adds full sharing capabilities to your App. It's a drop-in library, which supports services like Twitter, Facebook, Instapaper and many more. You can share links, text and pictures with a customizable user interface. It evens queues shared items until an internet connection is available.

SharKit is awesome and I really regret not using it to add Twitter sharing to Word Buzz. It has a well documented API and is really easy to extend, there's even a step-by-step guide on ShakreKit's website, which describes the process. I followed that guide to add TwitPic and yfrog capability to ShareKit for one of our next furryfishApps projects and that's what I'd like to write about in this post.

ShareKit comes with built-in Twitter support, which you can find in SHKTwitter and its authentication form SHKTwitterForm. It uses bit.ly to share images, which has a similar API as TwitPic and yfrog. I piggybacked on that implementation, however dropped oAuth support in favor of xAuth.

I know there are a lot of discussions on xAuth, however I found it the easiest way to provide the most benefit for iPhone App users, without compromising security in a hurtful way. In order to get your iPhone App ready to use xAuth with Twitter, you need to sign up at http://developer.twitter.com/. I described the process in a previous post.

The previously mentioned class SHKTwitter inherits from SHKOAuthSharer, which does all the heavy lifting in terms of authentication for you! All you need to do is hook into the API calls and customize your authentication screen:

So let's say the user wants to share a picture, taps on the share icon and select TwitPic. He authenticates after being prompt for his Twitter credentials. When the authentication was successful, you want to show some sort of form to your users, where they can enter a comment or in case of Twitter, their status. You can totally customize the UI, without any dependency to ShareKit. In fact SHKTwitterForm, ShareKits built-in Twitter form, is a simple UIViewController with its delegate set to SHKTwitter.

The actual sharing part of the code is as straight forward as the rest of ShareKit. It's a little verbose, but once your understood the concept, it's easy to extend:

As you can see most of the work goes into setting up the authentication headers for the request, as well as filling in the elements of the request body. There are APIs like ASIHTTPRequest, which handle this for you, however ShareKit doesn't use them and I didn't want to introduce a 3rd party library. If you take a look at Gurpartap's TwitPic engine, you can see how easy and simple the code would be.

Overall it's a breeze to develop with SharKit and I'm glad I digged in deeper. For our next project we'll definitely use it and you should at least take a look at it before rolling your own implementation.

UI Test Automation with Instruments

2011-01-31T17:03:00.000+01:00

One of the most impressive talks for me at WWDC 2010 was session 306 - "Automating Use Interface Testing with Instruments". I've been wanting to check it out ever since iOS 4 was released. A couple of weeks ago, I finally had a chance to give it a test ride with "I think I spider", one of the Apps I developed.

All you need to get started is an App, Instruments and some basic JavaScript skills. Apple provides a set of JavaScript libraries, that you can use to drive your tests and simulate user interaction. Your custom test scripts are run using the Automation Instrument in Apple's Instruments App, targeting your App either in the Simulator or on an actual device.

You can test almost every aspect of user interaction, using Apple's JavaScript library. No matter if you want to test shaking, device orientation or the basics like tapping and swiping, you can do all that using basic JavaScript function calls. Apple's documentation is quite solid, as most of them are, and explains the process in detail.

For "I think I spider" I covered the basic use cases in terms of UI, to make sure it still works after adding new features. Here is a basic example of the JavaScript involved to test "opening" the book, after starting the App:

// setup
var target = UIATarget.localTarget();
var appWindow = target.frontMostApp().mainWindow();
var element = target;

// first test
var testName = "Start Screen Test";
UIALogger.logStart(testName);

UIALogger.logMessage("Tapping start screen");
appWindow.elements()["start_screen"].tap(); // open the book

if (appWindow.elements()["main_screen"].isValid()) {
UIALogger.logFail(testName);
} else {

UIALogger.logPass(testName);
}

You can see that the JavaScript API is quite easy to use and yet very powerful! After setting this up in the Automation Instrument and running it, you can see the Simulator firing up and tapping the UIImageView with the accessibility label "startscreen" after it became available. It then tests, if the main screen of the App was loaded and either passes or fails the test.

In order to make our App testable, I had to set the accessibility labels on the elements we wanted to reference from the script. That was the only change I had to make in our code. Since you should take accessibility into consideration anyways, it was a reasonable effort.

Apple did an awesome job giving us developers the ability to catch regressions and make our life easier. However, there is room for improvement, which has been nicely summarized by Air Source. For us, a missing UIALogger.warn function in the JavaScript library was the biggest downside. Sometimes it's okay for a test to fail under certain conditions, but you still want to get a warning about it. I use UIALogger.logMessage for those cases as a workaround, but it's quite easy to miss those lines, since they don't stand out.

Overall, I think it's a huge improvement to have a UI testing tool for iOS Apps at hand. There is room for improvement, but the current state of UI Test Automation is already priceless!

5 Star Rating

2011-01-10T19:54:00.001+01:00

A couple of months ago we release our first own App "I think I spider" at Synyx. It features German quotes and sayings directly translated to English. It doesn't make much sense to a none-native German speaker, but believe me it's hilarious for us.

The App let's you rate those quotes with a 5 star rating, which is directly incorporated into a ranking. Up until today the component in charge of the ranking is a simple bunch of UIImageViews wired up with Interface Builder and set appropriately when tapped. That means if you want to give a 3 star rating, tapping on the 3rd UIImageView would fill up the 2 previous one as well. Same goes for changing your mind and going from a 5 to 3 star rating. The logic would unhighlight the 4th and 5th star.

Now, this works great and it certainly looks beautiful, but have you ever rated an App in the App Store on your iOS device? This is how it looks like:

Apple did a great job of just getting everything right with this small little control. The way you can slide your finger over it and the stars light up is just great. Also notice that if you want to reset the rating and go down to 0 stars, you need to swipe your finger all the way to the left. Note, that you can also touch slightly below the star, in order to see the stars above your fingers.

All those little details were the requirements for the next version of the rating feature of I think I spider. However, having some spare time over the holidays, I though I'd write a little component, which does all of that and more: DLStarRating. You can find the code on github, along with a sample project of how to use the stuff in your next App.

DLStarRating consists of a configurable number of custom UIButtons called DLStarView. They have a different background image for their normal and highlighted state. Those buttons are wrapped in a UIControl called DLStarRatingControl, which does all the touch handling. The buttons are centered in the DLStarRatingControl so keep that in mind when configuring its size.

It's quite easy to use DLStarRating in your code. You can wire it up in Interface Builder (although you won't be able to configure it from there) or in your UIViewController subclass:

DLStarRatingControl *customNumberOfStars = [[DLStarRatingControl alloc] initWithFrame:CGRectMake(0, 230, 320, 230) andStars:3];
customNumberOfStars.backgroundColor = [UIColor groupTableViewBackgroundColor];
customNumberOfStars.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin | UIViewAutoresizingFlexibleBottomMargin;
customNumberOfStars.rating = 2;
[self.view addSubview:customNumberOfStars];

To customize the stars, you can replace star.png and star_highlighted.png in the images folder under DLStarRating with your own. The only requirement is that the two images must have the same size.

If you discover any bugs or have a great idea you want implemented, open an issue on github or fork the project and help me out!

Word Buzz Lite

2010-12-15T07:07:00.001+01:00

When we first planned Word Buzz, we didn't want to release a free version. It has a more exclusive feeling to it, if you can't test before you try. However, to boost your user base, there's nothing better than a free version. So here it is: Word Buzz Lite.

It's a universal App with no limitation except for one: no Game Center! It's not our decision, but more of Apple's technical limitation to only allow one App (bundle id) per Game Center instance. Another difference is the number of free built-in themes. The free version comes with only one free theme and more available through in-app purchases.

When developing Doublemill, which is a separate App for iPhone and iPad, I decided to use different XCode projects for the lite, premium and iPad version, hence different source bases for the three Apps. For Word Buzz, we decided to use a different strategy. A multi-target project for full and lite version, which are both universal Apps.

Having different source bases has a couple of drawbacks, which I experienced the hard way. One of it is fixing bugs! It's is a copy-paste task, with all its pitfalls and pain in testing. In addition to that, XCode's support for handling multiple projects isn't exactly supporting you. However, evolving the 3 different Apps, was easy and didn't affect the others in any way.

Developing a multi-target project comes with its own set of challenges. You are basically programming based on a preprocessor conditional inclusion or exclusion, which I've explained in an earlier blog post. For Word Buzz is was quite easy to cut out the additional themes and the Game Center support. However, I can imagine it can become quite complicated if you want to exclude sophisticated features. XCode comes with awesome support for multiple targets and its Organizer can still handle releases for two different versions, although it's one source base. In order to get me started, I used Chris Fletcher's blog post on building a lite version for your iPhone App. It covers the basics and brings you up to speed.

When it comes to evolving Word Buzz, we needed to shift our minds from the source-based to a SCM-based evolution model. We needed to maintain different branches, which would get quite complicated from time to time. Thanks to Git and github, we never experienced any problems bringing the various versions (branches) back together. Once you've changed your mental model to a DSCM system, it's hard to switch back, at least for me.

We are quite happy to have used multiple targets. Everything is covered under the hood of one XCode project and fixes go right into both versions. Check out Word Buzz Lite and let us know what you think!

Why Word Buzz doesn't support iOS 3.1

2010-12-06T06:30:00.000+01:00

Word Buzz supports 3.2+, which means it doesn't support iOS 3 on iPhone. Although, my software developer ego doesn't like the fact, that we don't support the older versions of iOS, it was the right decision to do so.

It was a business decision to not support iOS 3.1, that's the short story. Rumors have it, that there are less than 10% of iOS 3.x devices out there - including iPads. That's a small enough number, to justify locking out the folks, which haven't upgraded yet.

The long story is, that we simply didn't develop with iOS 3.1 in mind. The are so many new features in iOS 3.2, which we wanted to use, that we couldn't just port it back. Let me give you a few examples:

Since iOS 3.2 you can use custom fonts in an easy and simple fashion. You add an array to your Info.plist called UIAppFonts and each item contains the filename of the font you put into your App bundle. There has been no easy way of accomplishing this before iOS 3.2, so we didn't want to sacrifice design and roll-out the 3.1 version with a system font.

Another great new feature in iOS 3.2 are Gesture Recognizers. If you don't know what I'm talking about stop right here and go read up on it - you are missing out! Although, Word Buzz doesn't use Gesture Recognizers extensively, we didn't wanna g back to the 19th century and use those old UITouch event handling stuff.

Those were just the two most obvious examples out of many! We sat down and tried to make Word Buzz run on our iPhone 3G, which still runs 3.1.3, but after a day worth of coding, we gave up. We'd love to make it run, but we'll rather invest in future proofing Word Buzz, using Blocks and GCD! We can't wait to drop iOS 3.2 support!

Word Buzz to support Game Center

2010-11-29T18:17:00.000+01:00

Today furryfishApps is proud to announce, that Word Buzz now supports Game Center. A lot of work went into making this happen and we learned quite a bit on the way. I won't go into technical detail here, but rather cover what we've implemented.

Word Buzz lets you share your highscore and achievements on Game Center. It comes with over 16 different themes (set of words) and a lot more available for download. Each of those themes gets its own score, which will be added to your overall highscore. The sum of all highscores is shared on Game Center.

Why didn't we just share the highscore of each theme? We couldn't! Game Center lets you only share up to 20 different highscores, which is probably reasonable. It might be a bit confusing to have 40 different highscore lists.

Word Buzz is available on all iOS devices. You can play on your iPhone as well as on your iPad or iPod touch. Unfortunately, there is no way with Game Center to sync more than 20 highscores between devices. That means, you cannot just pick up with your iPad, where you left off with your iPhone. We are working on a homegrown solution, but until that happens, it's best to stick on one device.

When playing Word Buzz, you can unlock over 10 different achievements. All of them are shared on Game Center automatically, as soon as you unlock them.

What happens if you are offline? Don't worry! Your achievements and highscores are safely stored on the device and uploaded to Game Center as soon as you sign in!

Go challenge your friends and enjoy Word Buzz with Game Center.

Game Center Presentation at Cocoa Heads Karlsruhe

2010-11-22T17:10:00.001+01:00

On Wednesday, I'll be giving a presentation on Apple's Game Center at the local CocoaHeads Group, here in Karlsruhe.

Game Center is Apple's social gaming network, that lets you invite friends to play, share your highscore and achievements through leaderboards and it even auto-matches you with other players for online-multiplayer games.

If you are interested in Game Center, drop by RetroGames on Wednesday 24th of November at 19:00.

Universal App - Word Buzz goes iPhone/iPod touch

2010-11-15T17:10:00.000+01:00

We have been working on bringing Word Buzz to iPhone and iPod touch for more than a month now. We started out with an iPad only version, because in the beginning we thought the concept of Word Buzz wouldn't work on a smaller device. After a none-stop coding weekend and a heavy testing session, we knew it would work and started hacking on iPhone and iPod touch support.

We decided to build a universal App, because of pervasive Game Center support and a unique selling point! The latter is a no brainer: you are willing to spend a couple more bugs, if you get an iPad version for free. The former is a technical limitation of Game Center. You can only hook up your leaderboards and achievements with one App Id.

Although it was easy enough to port Word Buzz to iPhone and iPod touch, we ran into a couple of pitfalls and one of them is worth sharing with you: the default device of your universal App! What does that mean? Well, if you want to have different xib files in your App for iPhone and iPad, you need to qualify them with a suffix -iPhone / -iPad. In your Info.plist, you configure your alternate main xib with NSMainNibFile~iphone / NSMainNibFile~ipad. Since we started out with an iPad App, we decided to make iPad the default, meaning my alternate main xib configuration in Info.plist was NSMainNibFile~iphone and point to MainWindow-iPhone.xib.

This works great for iPhone and iPads, but it doesn't work for iPod touches and it also doesn't work with iOS 3.x. Somehow iPod touches (even with iOS 4) and iPhones with iOS 3.x don't respect the NSMainNibFile~iphone configuration in Info.plist. They always use the NSMainNibFile config without any suffix.

We only found out about this after testing on an actual device, which shows how important testing on each and every device is. We decided to make iPhone / iPod touch devices the default and qualify every iPad resource with -iPad, just like Apple actually intended it to be done.

Word Buzz for iPad is available on the App Store, the iPhone / iPod touch version is coming in a couple of days as a free update. Let us know what you think about it in the comments or on Twitter.

Word Buzz getting a better Twitter integration!

2010-11-06T08:48:00.001+01:00

If you follow our tweets, which you should, you might have seen that we have been working hard on a better Twitter integration for Word Buzz. When looking around on github, I found a lot of frameworks for Twitter and iOS, but only Stefan's was lightweight and easy enough to integrate it into Word Buzz.

Most of the frameworks are full blown Twitter engines, which is not what we need for Word Buzz. Our requirements are simple: share your achievements (maybe your highscore in the future) with your followers. In addition to that, Twitter is our support channel. We wanted to allow posting public messages to @WordBuzzApp from within the App. Sounds easy, right? No need to pull in a full fledged Twitter engine for that!

Stefan's provides an API, which is really easy to use and integrate. There are no 3rd party dependencies, no need to fiddle with your linker flags - just an API to use! It even comes with a reasonable UI in Twitter style colors. Unfortunately, there was no iPad UI, which we had to implement myself. However, it was easy enough to come up with a Xib for iPad. Stefan's API provides delegate protocols, which you can implement to handle events such as "authentication succeeded". This way it's easy to separate the Twitter logic from your own code. The UIViewControllers provided, handle the most basic tasks like checking if you entered enough information to process with authentication.

We are using xAuth for authentication, which Twitter has to enable for your App. It took a couple of days until they came around to let us in, but it was the best solutions. Stefan's API provides xAuth out of the box and it works seamlessly. We added a Keychain integration to save your credentials and a flag in Settings.app to reset them.

Overall, it took us about 1 days to natively integrate Twitter into Word Buzz - thanks to Stefan's API! If anybody is interested, we are happy to provide the iPad UI and the Keychain integration.

What's new?

2010-10-28T21:47:00.000+02:00

For the past couple of weeks it has been rather quiet here on my blog and there's a reason for that, as you can imagine.

First of all, I'd like to announce our new company furryfishApps, which I've co-founded with my wife Sutini. My future private endeavors in terms of iOS development will all take place under the hood of furryfishApps. Sutini is in charge of all the marketing, social media and publicity tasks, which are so important, but we developers never have time for. I'm glad to have her on board!

We are still in the midst of figuring out what to put on our website, but we already have an awesome logo and you can follow us on Twitter.

Our first App is a fast and engaging spelling game called Word Buzz! It's your job to spell a bunch of words as fast as possible, without making any mistake. You'll be scored on how fast you can spell and there are a whole lot of achievements for you to unlock. Go grab it here on the App Store. We welcome any feedback on Twitter or Email.

Word Buzz is iPad only at the moment, but an iPod/iPhone version with Game Center support is underway. I'll have some posts coming up soon on how the development of Word Buzz came along. It was a pretty exciting ride, as you can imagine.

APN Device Tokens

2010-09-22T07:00:00.000+02:00

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.

When you enable Apple Push Notifications (APN) for your App, your device generates a unique device token and pass it to the didRegisterForRemoteNotificationsWithDeviceToken method in your App delegate. Usually, you'll hand the token to your server in order for it to push notifications to your device.

There are different tokens for production and sandbox, depending on which provisioning profile you build/sign your App with. One more gotcha, you need to be aware of when it comes to those device tokens: don't mix production and sandbox tokens!

If you try to send a push notification to the production servers, using a device token meant for the sandbox, Apple's servers totally block all other notification, which you are trying to send with the same connection. If you have a scheduled push notification like we do with "I think I spider", one wrong device token ruins the fun for everyone!

We decided to separate our production and test environment and use preprocessor conditional inclusion to point to different urls in our App. Unfortunately, we had to learn the hard way how tedious this gotcha can be to track down!

Supported by:
Sherweb - Hosted Exchange Hosting
Vircom - Email Security Software

I think I Spider

2010-09-14T07:32:00.001+02:00

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.

I'm proud to present, that our first own App has made it to the App Store last week. It's a beautiful mobile interface to the web site http://ithinkispider.com. You can find out more over at the Synyx Mobile Solutions Blog, or just hit the App icon and download it for free from the App Store!

My lovely mister singing club!

Testing Apps with In App Purchases in Simulator

2010-08-31T07:29:00.001+02:00

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.

If you add a store to your app and use In App Purchases to collect your payments, there are a couple of limitations your have to live with. One of those limitations is not being able to fully test your App in the iPhone Simulator:

Store Kit does not operate in iPhone Simulator. When running your application in iPhone Simulator, Store Kit logs a warning if your application attempts to retrieve the payment queue. Testing the store must be done on actual devices.

Although, there is not way to test Store Kit itself, you can still test the parts of your App that use and build on the information retrieved from Store Kit. You can use a preprocessor conditional inclusion to determine, whether you are running on the simulator and then "mock" the Store Kit calls or don't execute them at all.

#if TARGET_IPHONE_SIMULATOR
// mock product description
#else
SKProductsRequest *productRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:productIds];
productRequest.delegate = self;
[UIApplication sharedApplication].networkActivityIndicatorVisible = YES;
[productRequest start];
#endif

Keep in mind: this might not work for your App, however, it did work for my Apps and it's better than not testing your code at all. The optimal solution would definitely be to connect to the In App Purchase Sandbox environment from the Simulator.

Private Properties in Objective-C

2010-08-12T06:56:00.001+02:00

When a co-worker asked me if there's a way to declare a Objective-C property to be private, I could come up with an answer. Even after googling for a while, I couldn't find an example, easy enough to understand. Every time I have to search for something more than a couple of minutes and I can't find a definite source for an answer, I think it's worth a blog post.

Declaring a private property is easy, once you understood the concept of Categories and Extensions:

A category can add methods to any class, including the root class. Methods added to NSObject become available to all classes that are linked to your code.

Maybe you've used this before to enhance the functionality of a framework class. I've used it e.g. to add a shuffle method to NSArray. Extensions take the concept of a category one step further:

Class extensions are like “anonymous” categories, except that the methods they declare must be implemented in the main @implementation block for the corresponding class.

With an extension, you can easily implement private property declarations:

// Person.h

@interface Person {
NSString *name;
@private
NSNumber *age;
}

@property (retain) NSString *name;

@end

// Person.m

#import "Person.h"

// class extension
@interface Person () {
}

@property (retain) NSNumber *age;

@end

@implementation

@synthesize name,age;

// other stuff

@end

The @private declaration takes care of protecting the instance variable age, only the Person implementation is allowed to access it. The class extension in Person.m declares the property and it's being synthesized just the way you would with a public property.

Due to the anonymous nature of the class extension, nobody including the Person.h file can see the synthesized getters and setters, hence a private property.

Improve your dealloc method

2010-08-06T09:52:00.001+02:00

If you are programming for any iOS device, chances are high, you've came across properties. They give you these tedious accessor methods for free and in addition to that some nice memory management features.

While explaining a colleague how to implement dealloc, he pointed me to the excellent Objective-C guide of Cocoa Dev Central.

// Person.h

@interface Person {
NSString *name;
}

@property (retain) NSString *name;

@end

// Person.m

#import "Person.h"

@implementation

@synthesize name;

// other stuff

- (void) dealloc {
[name release];
name = nil;
[super dealloc];
}

@end

You can see a pretty straightforward implementation of an Objective-C class there, with an implementation of dealloc, the way you are used to. However, since we have synthesized getters and setters, we can simply write the following:

Basically, the implementation of the accessor at runtime handle memory management for us here, which I think is pretty neat.

Apple Push Notifications on Google Appengine

2010-07-19T06:10:00.000+02:00

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

I've written about the Google Appengine (GAE) a couple of times before and the same goes for Apple Push Notifications (APN). For Doublemill I had to bring those two technologies together and it was a pain and pleasure at the same time.

Let me start with the pain! Apples Push Notifications in a restricted environment like the Google Appengine is no fun to implement! My first approach was to use notnoop's java-apn, which I've used before and works quite well. Unfortunately, there is currently no way of using a client certificate, which you'll need in order to talk to Apple's server on the Google Appengine. There are some javax.security classes missing on GAE.

That's where the pleasure part begins! Thanks to Urban Airship, it's easy to hook up your application running on Google Appengine to Apple's Push Notifications! And the best part - it's free (although not unlimited)! Urban Airshipe provides an easy to use REST interface, which you can call from your Java code on GAE with a good old HttpURLConnection. It uses Basic Auth over Https to ensure that only your application can send Push Notifications to your iPhone App.

I won't provide any code for you here, because it's the basic concept that's the most interesting part when bringing APN to GAE. The first thing you need to do, is store your user's deviceToken. You should do that each time the App launches, to ensure it's the correct token. That token, along with the information you want to present to your user, needs to be passed to Urban Airship's REST interface, everytime you want to send a notification. A Cron Job or Task on Google Appengine could handle that for you.

If your application is designed with notifications in mind, then it's quite easy to bring Apple Push Notifications to the Google Appengine, thanks to Urban Airship!

Push Notifications in Production

2010-07-06T06:08:00.000+02:00

The first problem I ran into, had to do with my provisioning profile for development. I enabled APN in my Provisioning Portal, installed the certificate and implemented all the delegate methods according to the documentation, but somehow the method
- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error
was called with error code 3000 - "no valid 'aps-environment' entitlement string found for application". I was pretty sure, I setup everything correctly. However, I missed one little thing:

After you have generated your Client SSL certificate, create a new provisioning profile containing the App ID you wish to use for notifications.

This bit me after submitting Doublemill Premium to the App Store and being rejected for promoting Push Notifications in my App description, but according to Apple, not implementing it. During beta testing, everything worked fine. I had a correct implementation and the App was asking me for permission to use Push Notifications.

However, I did forget to create a new distribution provisioning profile for the App Store, after enabling Push Notifications for production. So, it didn't work for the reviewer at Apple. Forgetting about something like this is very painful, especially since I'm waiting for the 3rd round of review for the next release of Doublemill. That makes it 3 weeks since the initial submission.

When asking about this on the Apple Developer Forums, Mike was so kind to point out a neat trick on the command line, which helps you identify, whether APN for production is enabled:

codesign -dvvvv --entitlements - /path/to/App

<key>aps-environment</key>
<string>production</string>

If you see aps-environment=production, you should be save. Push notifications should work. If the key is missing, then you should create a new provisioning profile and rebuild you App with that.

It would be nice if Apple built this kind of checks into XCode or at least invalidate the provisioning profiles as soon as you enable Push Notifications in your App ID.

UI Prototyping iPhone Apps

2010-06-30T06:20:00.000+02:00

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.

Before flying off to WWDC last month, I watched a whole bunch of sessions from 2009. Among others a session on "Prototyping iPhone User Interfaces" by Bret Victor. If you haven't watched it and you've got access to the WWDC videos - stop right here and watch the video!

In his session, Bret shows how to prototype an interface only by interacting with screenshots! It's amazing that a simple screenshot on the device can show you so much more than by just looking at it in a document or print out. It inspired me to use his framework and the whole process for our own development.

Unfortunately, the code for the session isn't available and neither Bret nor the frameworks evangelist, mentioned in the presentation, got back to me about the code. After some digging, I found Michael Fey's blog, who was able to successfully reverse engineer the missing parts of source code, which were not shown in the presentation.

Michael's UIViewAdditions basically allow easy access to frame properties and give you a neat init method, which adds the passed UIView as a parent:

- (id)initWithParent:(UIView *)parent {
self = [self initWithFrame:CGRectZero];
if (!self)
return nil;
[parent addSubview:self];
return self;
}
+ (id) viewWithParent:(UIView *)parent {
return [[[self alloc] initWithParent:parent] autorelease];
}

There wasn't much left to do for me. I only coded the class Root, which is the parent of all UIImageView instances. It provides a couple of methods to slide images back and forth:

@synthesize pageIndex = _pageIndex;

- (id) initWithParent:(UIView *)parent {
self = [super initWithParent:parent];
if (self == nil) {
return nil;
}
self.userInteractionEnabled = YES;
self.size = self.window.size;
[[UIImageView viewWithParent:self] setImageWithName:@"dailies"];
self.pageIndex = 0;
return self;
}

- (void)setPageIndex:(int)index {
if (index < 0 || index >= [self.subviews count]) {
return;
}
_pageIndex = index;
for (int i = 0; i < [self.subviews count]; i++) {
UIImageView *page = [self.subviews objectAtIndex:i];
page.x = (i < _pageIndex) ? -self.width : (i > _pageIndex) ? self.width : 0;
}
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
self.pageIndex++;
}

With those two classes and a couple of screenshots, it is fairly easy to create an App that looks and feels almost real. I created a short demo video, which shows how easy it is to get a good feeling if your App is going to work or not:

Now don't forget those are only screenshots and the App might need to load stuff over the network or do some animation, hence it might not feel the same. However, this process of prototyping an UI is powerful enough to give you an idea, whether the workflow or the UI in general is going to "work" or needs some tweaking.

You can download the source code for the two classes, along with a sample project from github.

WWDC10

2010-06-14T06:01:00.000+02:00

It was my first WWDC this year and I'm blown away in any aspect! In order to not sound like an Apple fan boy, I'll highlight 3 aspects, which every conference has and compare them to my previous developer conference experiences.

The speakers were all Apple engineers. They knew how to present and almost all of them were very entertaining and fun to listen to. Most important of all - they knew what they were talking about! This is something no conference I've ever been to can compete with - not even the Spring Source conferences! They were close, but mostly featured some pretty bad talks from none Spring Source consultants, which kind of ruined the experience!

This is one aspect that makes the conference worth attending. I could simply go up to the Core Animations guy and ask him why the stuff is not working as I expect it to. The best thing was, I got and answer that actually solved my problem!

Another aspect is the choice of topics and the quality of the presentations! Everything kind of fits in nicely to the whole App theme. You could listen to talks on Interface Design, followed by an in depth session on Core Animation and finish off with listening to the latest innovations on the new iPhone 4. The quality of each talk was amazing! This is the first conference ever, where I wasn't close to dozing off once! Every session was interesting and inspiring, although they sometimes overlapped in terms of content!

To be fair, I'm kind of new to the iPhone platform, so if everything was interesting for me. I don't know how that holds true for fellow developers working on iPhone Apps for a couple of years. Other conferences I attended had quality talks, too - no doubt! Devoxx, e.g. always had great talks, but there was mostly one or two a day and the rest was mostly boring.

Third and last is the organizational aspect of the conference. It's amazing how Apple manages to keep 5000 developers under control. The food, although not extensive, was very good. Soft drinks all through the day, as well as breakfast and lunch. Another thing that I was blown away is the Wifi. Apple managed to provide a fairly stable internet connection for 5000 developers with probably more than 10000 devices. It didn't always work, as you could see in Steve's keynote, but most of the time it was stable and fast.

Even though I had to travel almost a day, going back and forth to San Francisco and the conference tickets are super expensive, it's definitely worth it. So WWDC11, here I come!

Book Review: The Business of iPhone App Development

2010-06-02T06:43:00.000+02:00

Apress was kind enough to pass me a copy of this book, which I agreed to review in return.After the last book I reviewed, which was rather technical, I decided to go for a book with a tad more business angle. Personally, I was disappointed by this book, but that might not be the case for you.

Business of iPhone App Development covers exactly what the title promises: the whole process, beginning with the idea of an App over development to submitting it to the store. It's chopped up in 10 chapter, covering various steps of the process.

I'm not going into great detail explaining the content of the book. Instead, I'll write about what I didn't like. I think that should help you make a decision whether to get the book or not.

The reason why I didn't like this book is very simple: most of the information in this book can be obtained from the net or using common sense!

Let me elaborate: I think being able to obtain any information on the net these days is quite obvious. That doesn't mean you shouldn't buy this book. If you need a compact resource on topics like "Setting Up Xcode" or "Submission to the App Store", this book is definitely worth getting. If you have done this before, like me, you will be disappointed, because there's nothing new! If you are looking into more business-related topics, there's definitely topics worth reading. However, most of the technical content can be found in Apple's documentation or on stackoverflow.com. Since the book has a lot of technical chapters, I was a little bored revisiting information I already knew.

The more business-like chapters are definitely worth reading, especially if you are new to the whole App Store game. However, in my opinion a huge portion of the presented information are simple common sense! Using marketing channels like Twitter or Social Media like Facebook is standard these days and I believe there are no developers out there not knowing about those. However, some of the information seem like common sense, but it's great to have a resource to revisit from time to time, like e.g. App Store Rejection reasons. Another great chapter is "Protecting Your Intellectual Property", which you probably can't find anywhere else. It covers EULAs, licensing and trademarks.

Overall, Business of iPhone App Development encompasses a lot of information and the authors did a great job, trying to cover a lot of ground. However, I can only fully recommend this book to you, if you are new to the world of iPhone development. Otherwise, you might want to think about it twice.

Apple Push Notifications Gotchas

2010-05-28T06:05:00.000+02:00

- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error

was called with error code 3000 - "no valid 'aps-environment' entitlement string found for application". I was pretty sure, I setup everything correctly. However, I missed one little thing:

After you have generated your Client SSL certificate, create a new provisioning profile containing the App ID you wish to use for notifications.

That's what the Provisioning Portal tells you to do after you enabled APN. Your existing provisioning profiles are not being hooked up to APN, you really need to create new ones.

Another problem I ran into is a blocked Wifi port. Apple's documentation says:

If a cellular or WiFi connection is not available, neither the application:didRegisterForRemoteNotificationsWithDeviceToken: method or the application:didFailToRegisterForRemoteNotificationsWithError: method is called. For WiFi connections, this sometimes occurs when the device cannot connect with APNs over port 5223.

That also means neither of the methods is called when 5223 is blocked. Fortunately I came across a very helpful post on the Apple Developer Forums (sorry can't link to that here), which pointed me to a mobileconfig, enabling APN logging. If you have your phone connected and can see the log statements, you can find out if your port is blocked or something else is wrong. Don't forget to restart your phone after installing the mobileconfig, in order to enable the logging. For Doublemill the statements look something like this:

Connecting courier stream to sandbox.push.apple.com on port 5223

Connecting courier stream to push.apple.com on port 5223

Connecting to courier 2-courier.sandbox.push.apple.com

Connecting to courier 19-courier.push.apple.com

Connected to courier 2-courier.sandbox.push.apple.com (17.000.34.73)

Sending connect message with token 'xyz'

Connected to courier 19-courier.push.apple.com (17.000.36.88)
Sending connect message with token 'abc'

Recieved connected response OK

Sending filter message for enabled hashes { 34345 = "de.linsin.games.doublemill"; } and ignored hashes {}

...

Recieved connected response OK

These log statements are priceless, when hunting down the reason why you won't receive push notification in your application!

The last gotcha for today is one that I couldn't really find in Apple's documentation or at least I didn't really understand it that way. Anyways, if you distribute your App with an Ad-Hoc provisioning profile, which you would do for beta testing, the destination of your push notifications are not the sandbox, but the production. Come to think of it - it does make sense. However, you do need to create the production certificate and a new provisioning profile for it. Of course, your backend needs to be able to handle both destinations, as well!

Overall, APN is a cool feature and if you are running a server for your App anyways, it actually is for free! If your backend is running on Google App Engine, it's a different story, which I'll talk about in a future blog post.

Lessons learned - iPhone Review

2010-05-20T06:22:00.004+02:00

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.

When you submit an App to the Apple App Store it has to go through a "rigorous quality check", conducted by Apple. Although there are plenty of resources out there, here's a short rundown of what we've learned ourselves so far:

Marketing Apps are not allowed

You cannot tease your users with features that they have to pay for

Don't ask your users to upgrade

Build a working App

it happens

Don't infringe Trademarks or Copyrights

Android

If you respect all of these restrictions and gotchas, you should be save to get your App through the review process. I say "should", because it all appears to depend on the person who reviews your App. Let us know what you experienced, submitting your Apps, I bet there are a lot more of these gotchas.

Don't Forget your Linker Flags

2010-05-10T07:16:00.000+02:00

#import "NSObject+YAJL.h"

NSDictionary *vals = [jsonResponse yajl_JSON];
[player fill:vals];

- (void)fill:(NSDictionary *)vals {
NSString *key;
for (key in vals) {
[self setValue:[vals objectForKey:key] forKey:key];
}
}

Okay it's not a two liner, but it's close! Anyways, in order to add this library to your project, one way is to download the build and add the static library to your Xcode project. It'll work seamlessly in the Simulator. If you want to deploy it to your iPhone or any iPhone, you need to add linker flags:

Under 'Other Linker Flags' in the Test target, add -ObjC and -all_load (So NSObject+YAJL category is loaded).

This is very common and no big deal actually. If you want to know more about why you need this, check out the Apple Developer Connection.

I added those flags for the my development environment and also for my beta testers. However, I totally missed this in my Xcode AppStore build configuration settings and since you cannot really test your final build, it went in review without those linker flags.

The reviewer at Apple found the bug, which even resulted in a crash of Doublemill. I'm grateful they found it, however I'm not really happy, that I had to wait another week to get Doublemill out the door. In the end it was my mistake and I'm sure in the future, I'll make sure to have those build profiles setup more carefully.

iPad Apps have priority

2010-05-03T06:16:00.001+02:00

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

I had to wait for a week, after submitting Doublemill Premium for review to the App Store, until Apple decided to have a look at it. Unfortunately, we were rejected - for a good reason! As it turned out, I didn't link my libraries correctly, which turned out to cause a crash every time you wanted to play online, but I digress...

It took me roughly 2-3 hours to find the bug, fix it and resubmit the App. Now I'm waiting for five days again.

Yesterday, I finished polishing Doublemill for iPad, after reworking the UI and implementing a nicer Player vs. Player experience. Since it was a rainy day and there was only Star Trek on TV, I decided to submit it for review, since it would take at least a week until they had a look at it. I want to be ready for the European start of the iPad and if there's anything wrong with Doublemill for iPad, it would take at least 2 weeks to get it into the App Store - that's what I thought!

After the usual email, you get after submitting, I instantly received another, saying my App is in review. Just like that - without waiting for a week. That got me really upset! I invested almost 4 weeks of my spare time, to gett Doublemill Premium ready and polished and I had to wait for a week until it was in review.

To me this is a clear signal, that iPad Apps are more important to Apple than iPhone Apps - at the moment. I hope this will balance again soon. It is understandable, that they want the iPad App market filled as soon as possible, but that's no reason to make the iPhone App developers wait more than a week. That takes us back to where we were a year ago: waiting and waiting and waiting - just to be rejected!

Is your App Accessible?

2010-04-26T06:05:00.000+02:00

I recently bought an iPhone 3GS and while nothing is really new, just a lot faster, there's a menu in the settings which is called "Accessibility". I haven't noticed it before, but after reading through Apress' "The Business of iPhone App Development", I got curious. There is one setting, which is very interesting, called "White on Black".

This setting is for folks with any form of color-deficient vision. It helps them to still recognize the difference between certain colors. According to "The Business of iPhone App Development" roughly 1 out of 12 males of European decent are affected by this problem.

After reading this, I had to check how Doublemill looks like with this setting switched on. I'm proud to say, that it looks kinda cool and everything works as expected! See for yourself:

If you want to make your App accessible to the broadest audience possible, check if it works in Apple's "White on Black" mode.

iPhone App Beta Testing

2010-04-16T07:01:00.001+02:00

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

I'm closing in on the first release of the paid version of Doublemill. The only thing missing is a beta test. I'm past the technical problems, which I encountered when I released a beta version of Doublemill Lite a couple of weeks ago. This is more about how to find people, willing to thoroughly and extensively test your App.

Unfortunately, I can't use Amazon's Mechanical Turk - although I'm willing to pay a small amount for people to find bugs in my App. Amazon doesn't let me use it without a US credit card, so I had to look for an alternative. I came accross iBetaTest.com. I used it for Doublemill Lite and I'm also using it for the paid version. Although the site has little flaws (it's still in beta itself), the idea is great and it works pretty well. However, there is still a problem: the people who are using the site and who are supposed to test your App.

After I added the beta for Doublemill, I received a lot of requests, mostly from testers which are not testing any other Apps or look like they have just signed up. I gave a couple of them the benefit of the doubt and let them in, only to experience, that I wasted my valuable device IDs.

At the time this blog was published, I have only received feedback from 2 of my 7 testers. The other just haven't replied. I know, that at least one has downloaded and signed up for the multiplayer feature, but hasn't provided feedback on any aspect of the App. That's just plain disappointing. After Doublemill Lite, this is the second time I wasted device IDs, it won't happen to me anymore.

After all, there's always something to learn from your mistakes: be picky on beta testers and choose people you know they'll give you valuable, honest and thorough feedback! It takes quite some time to setup a beta test and organize all device IDs, so don't neglect Q&A in your project planning.

I'm fortunate enough to have a couple of people around me, which help out with testing and give me exactly the feedback I need - although it's not always what I want to hear.

One week in the App Store

2010-04-01T07:47:00.000+02:00

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

One week ago Doublemill Lite hit the App Store and it has been received very well, according to the download numbers. I'm pretty stunned by the magnitude of more downloads we have compared to the Google Marketplace. It could be that we only have full fledged paid version for Android out there. However, you can refund your money with Google within 24 hours, if you don't like the game, so basically every App is also a Lite version.

I believe in the App Store as a channel of distribution, although only after one week we already see the negative sides of it: user ratings. Doubemill Lite started off pretty good with 3-4 stars the first couple of days, but then rapidly dropped down to 1-2 stars. First, I was pretty bumped about it, but then realized that you are only asked to rate the App when deleting it from your phone. Considering, that less than 3% of people who downloaded the App also rated it, I guess most of the others might still happily play with Doublemill Lite.

We received some feedback, mostly about the controls, which we've already addressed and improved. There should be an update in the next couple of weeks, but at the moment I'm kinda handicapped, because my MacBook Pro died on me and I have to wait for my new one to arrive next week. With the soon to be released update, we've also added iPad compatibility, so you can have a virtual Nine Men's Morris Board sitting on your table.

There's also been progress on the premium version of Doublemill, which will go Beta any-time soon. So if you are interested in testing it, drop me a line and I'll hook you up!

Being Rejected

2010-03-20T10:26:00.001+01:00

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

Tonight I got an email from Apple telling me that they have rejected Doublemill Lite! Although it is kind of annoying, the email was somewhat clear on what I need to to do to fix the problem. It even had a screenshot attached, pointing out what my mistake was - if it really was one.

This is the screenshot apple sent back to me:

What's wrong here, you might think? At least that's what I thought! It turns out that you cannot tease your users with features they can never get with that particular version of your application.

Doublemill Lite features a Player vs. Player and Player vs. iPhone mode. You can challenge your friend by using the same device or play against your iPhone. The upcoming Doublemill Premium version will feature a Player vs. World mode, where you can challenge the world over any kind of internet connection.

My idea was to point out that this is a Lite version by putting the Premium features in the menu. People could immediately see, what's to come or what they are missing out on. However, Apple doesn't think that it's a good idea. And they might even be right. Doublemill Lite is not going to be updated with those features, because we will release a dedicated Premium version soon. People only using the Lite version will always see the disabled menu items and that's kind of messy.

I took the liberty to fix two other things in addition to addressing Apple's issues to remove the two menu items. Now we are back on track and hopefully in the App Store early next week.

Doublemill Lite submitted to the App Store

2010-03-18T20:17:00.001+01:00

Is the Future of Mobile Apps the Web?

2010-03-08T06:25:00.000+01:00

The Mobile Times 2010 conference in Dusseldorf, which took place last Thursday, featured a lot of talks on how to do approach cross platform development. A lot of them suggested web development technics as a way to escape native vendor lock-in, such as Apple's iPhone OS.

There are mainly two approaches:

1. You develop a web site using HTML, JavaScript and CSS zip it and deploy it together with a Player

2. Or you develop a custom website which is served from your servers

The first approach is usually tackled using a framework such as PhoneGap. It event provides an API to include platform specific functionality such as GPS in your application.

The second approach either uses traditional web development technics or targets a specific browser, such as WebKit. One example is jQTouch, a jQuery plugin with cross platform support - unfortunately only WebKit.

The presentations, advocating those two approaches, mentioned mainly two advantages:

1. No need to comply with platform policies (think of Apple's App Store)

2. And you can leverage cheap web coding skills

Those are the facts, I collected during Mobile Times 2010. Unfortunately, the benefits using the web development approaches were not really balanced by any downsides.

I really doubt that the web development approach is the way to go in terms of cross platform mobile app development. I think frameworks like PhoneGap are doing an awesome job, putting an abstraction around the native platform.

Unfortunately you get the least denominator of your platform is capable of and that's a real downside to me. If I put on "average Joe head", I want an app that is using the full potential of my phone. I don't care that it was cheaper to develop a web-based solution and I definitely don't care that the framework I'm using is only offering partial support for my phone features.

Another problem is platform defragmentation! I won't go into it - don't worry - I simply want to point out one downside: In my humble opinion, it is not possible with web development technics to "write once, run anywhere"! You will have to tweak the CSS and work around the abstractions of the framework your are using! It might be cheaper, because we all know that the average web development frickler (amateur craftsman), only charges what he deserves. However, I don't think it gets you anywhere in the long run.

I think we shouldn't approach mobile application development with only the engineering side in mind. Instead we should rather focus on the customer and what he asks from a mobile app. I think the success of the App Store has proven that native apps are the way to go, even if they mean more effort on the development side.

Doublemill Private Beta

2010-03-06T16:13:00.001+01:00

Mobile Times 2010

2010-03-01T05:31:00.001+01:00

On Thursday, I'll be attending the mobile times 2010 conference in Düsseldorf, Germany. It's a rather small one day event and as the name suggests, all about mobile development.

There's only a two or three sessions, I'm really interested in, since my focus is iPhone and Android. However, there's one session which I'm really looking forward to: "Cross-compiling Android Apps for iPhone with XMLVM". The reason why I'm interested in this is that I just went through a rather unpleasant experience of porting our Android game Doublemill to the iPhone OS. If there was a faster and more efficient solution, I'd be happy - frankly, I don't think it works!

I'll blog more about my roller-coaster ride from Android to iPhone in a future post, but for now I'm looking forward to Mobile Times 2010.

iPhone Development

2010-02-22T05:59:00.001+01:00

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

This will be a series of blog posts on how a rookie at Objective-C and the whole iPhone OS came about to release an iPhone app.

I started out with a complete UI, stitched together in Interface Builder in only 15 minutes and ended up on a roller-coaster ride with 3 weekends straight spent on coding and a lot of understanding from my wife. It was really amazing bringing the game to life.

That brings me to the first difference between being a Java back-end guy and an iPhone developer. It's not so much the different programing languages or operating systems, but the fact that you bring something to life. You can hold it in your hands an show it to people. I can even show it to my parents and they can give it a try.

When I was working on the back-end of Doublemill, the only thing I was able to show someone was an URL and the JSON response when you make a HTTP GET. Although my wife is very supportive, when it comes to my pet projects, she's much more pleased with an iPhone App than with a JSON response.

I learned a lot about the iPhone platform, the tool chain and Objective-C during the past couple of weeks and I must say, I get more and more intrigued with diving in completely. I'll blog a lot more once Doublemill Lite, the first version is out the door, until then there's still a lot to do.

GWT @ JUG-Ka

2010-02-09T08:06:00.001+01:00

Tomorrow night there'll be the another event of the Java User Group Karlsruhe. It'll feature a talk on the Google Web Toolkit by Papick Taboada, who is quite an expert on the topic. The second part of the event will be a get-together after the talk, where you can discuss GWT over a beer. My company Synyx GmbH & Co. KG is kindly sponsoring the drinks.

The talk will take place at University Karlsruhe in room 101 and start at 7:15pm. The room is located in the basement, which you will find easily, if you follow our duke featured logo.

If you are interested in our lottery, where you can win a JetBrains or ZeroTurnaround license, submit your details through our online form. The winners are going to be announced at the end of the talk and must be present.

Last but not least, check us out on Twitter and subscribe to our Google Calendar or join our Xing Group.

Community Gathering @ JUG-Ka

2010-01-25T05:40:00.000+01:00

After the first successful JUG Karlsruhe talk on Groovy, we will kick off the community involvement with a gathering this coming Wednesday.

Everybody who wants to get involved in our little Java User Group here in Karlsruhe is invited. We are looking for people with lots of ideas, sense of community and passion. I prepared a couple of slides, which will help us structure the gathering, but mainly we are hoping to get your feedback and ideas heard.

You can help steer the JUG in the direction which you want it to go. Just join us on Wednesday at 7:15pm, the usual time and the usual place. The University of Karlsruhe kindly sponsored a room (SR-107), which is located in the basement, next to the usual location.

I'm looking forward to see you guys on Wednesday to share some ideas on how to improve your Java User Group Karlsruhe.

Adding a UINavigationBar to a UITableView

2010-01-18T05:25:00.000+01:00

A couple of days ago, I implemented a RSS-Reader feature for an app, I'm coding at work. There's a nice tutorial on this topic, which I can highly recommend to you, although it's a little outdated. I'm using a UITableView to implement the RSS-Reader feature and I wanted the header section to be a UINavigationBar. Somehow I couldn't find a proper tutorial on how to achieve this. At least there wasn't anything that explained it in a simple manner.

You will need a UINavigationController, in case you want to navigate through the hierarchy of UITableViews, but we put that thought on hold and I'm gonna show you how to add a custom UINavigationBar.

This is roughly what the final result should look like. You can see my company's logo at the top, inside of a UINavigationBar, which in return is inside of a UITableView. All the components are wrapped in a UITabBarController, which you can see at the bottom in the form of a tab bar.

My first approach was to tackle this kind of interface solely in Interface Builder. It's very straight forward, there's nothing fancy here and my first impression was, that it should work out of the box - the box being InterfaceBuilder. Well, I was able to design almost everything through Interface Builder, just the part with the UINavigationBar made me throw in the towel.

- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];

tableViewNavigationBar = [[UINavigationBar alloc] initWithFrame: CGRectMake(0.0f, 0.0f, 320.0f, 44.0f)];

UIImage *image = [UIImage imageNamed:@"synyx_150_no_os.png"];
imageView = [ [ UIImageView alloc ] initWithFrame:CGRectMake(84.0, 1.0, image.size.width, image.size.height) ];
[imageView setImage:image];

[tableViewNavigationBar addSubview:imageView];

[super.tableView addSubview:tableViewNavigationBar];
}

This is what the code looks like. It is implemented in the custom UITableViewController, which is assigned responsibility from the UITabBarController, as soon as its' tab is active.

First step is to initialize the UINavigationBar. In my case, I assign it to an instance variable, which is released in the dealloc method. You can see, that you also have to initialize and add the image yourself, which is usually a simple drag & drop in Interface Builder. That image is then added to the initialized UINavigationBar.

You can see that the solution is only a couple of lines of code, but note that it only works, if you don't want to navigate to a sub view. For that you'd need a UINavigationController.

Watch the Java User Group Karlsruhe Online

2010-01-15T13:42:00.001+01:00

This is our first attempt to record a talk of the Java User Group Karlsruhe. Please forgive us the weird camera angle and the volume, we promise to improve that. Other than that I think it's quite reasonable.

I'm really impressed by the tools and platform Parleys.com provides. The best part is - it's free for JUGs. A big thank you from Karlsruhe to Belgium for that!

Groovy @ JUG-Ka

2010-01-11T05:55:00.000+01:00

The first talk of 2010 at the Java User Group Karlsruhe is this coming Wednesday. After a successful finale in December 2009 with a talk on Scrum, we are turning our attention to the technical side of things again - Groovy.

We had a talk on Groovy back in early 2008, in case you remember. It was an introduction, whereas this coming talk will target a more advanced audience.

The speaker of the night will be Dierk König from Canoo Engineering AG, Switzerland. He is a Groovy committer and author of the book Groovy in Action. He'll give us an overview of 7 scenarios in which to use Groovy in your project.

I'm excited, that we are going to have a Groovy expert in the house Wednesday evening. If you have any questions on Groovy, it's your chance to get an answer, so make sure to drop by.

The talk will take place at University Karlsruhe in room 102, located in the basement - just follow our duke featured logo. The talk will start at 7:15pm.

Our monthly lottery of JetBrains and ZeroTurnaround, which are each giving away a free license of one of their products is already on. If you are interested in participating in the draw, submit your details through our online form. The winners are going to be announced at the end of the talk and must be present.

To keep up with all the JUG goodness in 2010 subscribe to our Google Calendar or join our Xing Group.

Spring's ResourceBundleMessageSource

2010-01-08T08:56:00.000+01:00

Last week my colleague Marc spent hours trying to figure out why a ResourceBundle wasn't loaded in a Spring based web app we are developing here at Synyx. It turned out to be a broken Unicode representation, which wasn't properly reported by Spring's ResourceBundleMessageSource.

In case you don't know ResourceBundleMessageSource, here's an excerpt of its javadoc:

MessageSource implementation that accesses resource bundles using specified basenames. This class relies on the underlying JDK's ResourceBundle implementation, in combination with the JDK's standard message parsing provided by MessageFormat.

We are leveraging the basename functionality of ResourceBundleMessageSource in our application, the way it's suggested in the javadoc. It's pretty neat and you should definitely check it out, if you've never used it.

The problem we encountered indicated that the bundle could not be found. This is what we saw in our log statements:

WARNING: ResourceBundle [broken_messages] not found for MessageSource: Can't find bundle for base name broken_messages, locale en_US

Of course, we tried to fiddle with the classpath, changed the names of the properties files and moved them to different directories in our WAR file - it would only print the above log statement. After hours of trying and failing, Marc discovered an invalid Unicode character representation (something like d\u00Fvid instead of d\u00FCvid) in the ResourceBundle, which wouldn't let ResourceBundle load the damn thing.

So where's the problem with ResourceBundleMessageSource? The problem is that it swallowed the cause of its own MissingResourceException. Here's what Java's good old ResourceBundle class tells you in case of a broken \uxxxx representation:

java.util.MissingResourceException: Can't find bundle for base name broken_messages, locale en_US
...
Caused by: java.lang.IllegalArgumentException: Malformed \uxxxx encoding.

You can clearly figure out what the problem is and how to solve it. Whereas, with the message of MissingResourceException the least you would expect, is to look for the problem in the properties file itself.

I created a small test case to reproduce the problem and filed a request for improvement. I hope there'll be a fix, so that other people don't have to suffer the same way we did.

Book Review: Beginning iPhone 3 Development

2009-12-21T05:48:00.000+01:00

Apress was kind enough to pass me a copy of this book, which I agreed to review in return.

I reviewed a couple of fine books for Apress over the past two years, but I must say that "Beginning iPhone 3 Development" is one of the finest! The authors did an excellent job, addressing the code and complexity of the underlying platform.

When I first got my hands dirty with iPhone development everything was new: the IDE, the programming language and the environment to which my code is deployed. I didn't know my way around Xcode and I had no idea what Protocols are in Objective-C. This kind of knowledge is what the authors of "Beginning iPhone 3 Development" assume and work with very nicely. They are not trying to explain Xcode in every detail or tell you all about Objective-C, instead they focus on what you need to know right there and then to solve the problem the chapter is focused on.

I like this concept a lot! This way you get to know Xcode and Objective-C step-by-step in bits and pieces, with really good examples. Although the authors are not explaining all the tools and language features in detail, I think you really get a good sip of background information.

Another thing which really makes "Beginning iPhone 3 Development" stand out from other books I read lately, is the style of writing. It's not only the words the authors chose to describe a complex junk of Objective-C code, but also the way they approach it. They keep repeating the basic concepts, but always in a different way, so it doesn't get boring to read about stuff like Delegates and ViewControllers over and over again. It's just exactly what you need to wrap you head around this sort of topics.

If you follow the blog of Jeff Lamarche, one of the authors, you can really see that this guy is all about writing. You can find tons of tutorials there for iPhone development, which immediately remind you of "Beginning iPhone 3 Development". The style and tone of writing are quite similar.

After all the praise there is one downside, it's a minor one, but then again, to you it might be important: the website. It's really just a pointer to a phpbb forum, which is meant to be a place where people can discuss or ask questions about the book. That's all well and good, but the thing wants you to register, even if you merely want to download the source code, which sucks. I just don't need another forum account.

A colleague raised the question why you need a book, in order to develop for the iPhone? After all, the documentation Apple provides is pretty extensive and of high quality. That is true! Apple's Developer Connection provides a plethora of documents on all sorts of topics, all very well written. The problem with those documents is that they don't give you a coherent picture. It's more of a reference documentation. You go there, if you need an answer to some specific problem.

"Beginning iPhone 3 Development" on the other hand, provides a nice example for each chapter, which leads you through all the features of a certain angle of iPhone development. You can tag along and at the end of the chapter, you have a pretty good understanding of what just happened the past 50 pages.

For me, "Beginning iPhone 3 Development" gave me a good insight of what it takes to develop an iPhone application. It even encouraged me to dive deeper and change my development perspective from solely Java towards the iPhone platform. If you are planning to get started with iPhone development, go and buy this book! You won't regret it!

Scrum @ JUG-Ka

2009-12-07T05:47:00.001+01:00

The upcoming talk at the Java User Group Karlsruhe this Wednesday is kind of an experiment. It features Scrum, which according to Wikipedia:

... is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development.

It's an experiment, because we usually feature sessions on development topics like REST, Hibernate and Flex. A talk on a management framework, although it's closely related to development, is rather unusual for us. If you are not interested in this kind of topic, let me know, we appreciate your feedback.

The talk will take place at University Karlsruhe in room 102, located in the basement. Unusual topics call for unusual timings, so we'll start at 8:00pm this time. Our speaker is Dr. Jürgen Hoffmann of scrumcoach.de.

This month we are giving away a free book called "Growing Object-Oriented Software, Guided by Tests by Freeman&Pryce". If you are interested in participating in the lottery, drop me an email. The winners will be announced at the end of the talk.

This is the last gathering of the year 2009. There's even more to come in 2010, so subscribe to our Google Calendar and stay up-to-date.

Playing with Spring's RestTemplate

2009-11-30T05:40:00.000+01:00

A couple of week ago, I saw a talk on Spring 3.0's MVC REST support. It's quite impressive how simple SpringSource made REST development by applying the proven concepts of the core Spring Framework.

One of those great core concepts is Templates. Spring's Data Access Framework is an example, where templates are used extensively. One of the templates is the JDBCTemplate. It provides a set of predefined methods to access a database, without worrying about Connection management or Exception handling. Templates are a nice way to help you the the job done, without constraining flexibility. The book "Building Spring 2 Enterprise Applications", which I reviewed last year, there's a whole chapter on Data Access and the corresponding Templates.

The RestTemplate is the latest child in the family. Arjen Poutsma from SpringSource wrote a blog entry about it and describes it as follows:

The RestTemplate is the central Spring class for client-side HTTP access. Conceptually, it is very similar to the JdbcTemplate, JmsTemplate, and the various other templates found in the Spring Framework and other portfolio projects. This means, for instance, that the RestTemplate is thread-safe once constructed, and that you can use callbacks to customize its operations.

In the before mentioned blog post, Arjen shows how to pull pictures from Flickr, using their REST API, and display them in a JFrame. He uses an XML based approach, whereas I'll show you some code, which handles JSON:

public Issue browse(Repository argRepository, int argIssueNo) {
RestTemplate template = new RestTemplate();
template.setMessageConverters(new HttpMessageConverter[] {
new MappingJacksonHttpMessageConverter()});
IssueResponse resp = template.getForObject(BASE_URL + "issues/show/{username}/{repo}/{no}", IssueResponse.class,
argRepository.getOwner(), argRepository.getName(), String.valueOf(argIssueNo));
return resp.getIssue();
}

You can see it's quite easy to work with a RestTemplate. You simply create an instance, tell that instance what your expected content is going to be and you are good to go. In this case we expect the request and response to be JSON. Spring is using the Jackson JSON Processor, to automagically map POJOs to JSON and all the way back.

The concept of a MessageConverter is really neat. You can set multiple converters and specify to use a certain converter for certain POJOs. You can also handle multiple content types by setting multiple instances of MessageConverter.

In order to make a REST call with the predefined MessageConverter, you simply use the getForObject method. You pass the url to call, the type the response is supposed to be mapped to and the values to be replaced in the url. The type of the response is actually a wrapper class:

public class IssueResponse {
private Issue issue;
public Issue getIssue() {
return issue;
}
public void setIssue(Issue argIssue) {
issue = argIssue;
}
}

It is necessary since the following JSON response, which is represented in the POJO Issue, needs some kind of holder object:

{"issue":
{"number":1,"votes":0,"created_at":"2009/11/01 07:27:56 -0800",
"body":"This is a sample issue! Used in my RestTemplateSample!",
"title":"Sample Issue",
"updated_at":"2009/11/01 09:16:58 -0800","closed_at":null,
"user":"dlinsin","labels":["minor"],"state":"open"
}
}

As you can see, it's really easy to work with Spring's new RestTemplate. These couple of lines are enough to retrieve a JSON or XML response from a REST call. With the Template approach, you have the full flexibility to hook almost every method and tweak it to your needs.

Finally Running with the Snow Leopard

2009-11-23T01:01:00.000+01:00

A little note upfront - this is not about software development, so if you are solely here to read about my take on coding, this blog entry is not for you!

A little more than 2 months ago I pre-ordered Apple's new Mac OS X 10.6 aka Snow Leopard one week before the official release at Gravis. As it turns out, it was a bad idea, because it took Gravis more than 6 weeks to deliver, but I digress...

After finally receiving my Family Pack, I installed the Snow Leopard on my wife's brand new MacBook. The upgrade was smooth and finished after only about 40 minutes. However, when it came to my old MacBook Pro, the tragedy began...

The first attempt to install Snow Leopard resulted in the installer quitting and rebooting the old Mac OS X as if nothing happened. Booting from the 10.6 DVD and then running the installer didn't help as well. I tried a couple of times, but the Snow Leopard wouldn't come out of the cage. Instead, I got an error message like "An error occurred while installing Mac OS X".

My second attempt was borrowing a colleagues copy of Snow Leopard and trying to install it using my built-in DVD. You might have guessed it - it failed as well, with the same error message. The next attempt was getting an external drive, which I hooked up using FireWire. Unfortunately, neither my nor my colleagues Snow Leopard DVD would let me install.

After I spent hours of trying to tame this animal, I decided to leverage my wife's MacBook as a remote dvd drive. It's pretty easy to setup and worked like a charm, however it didn't get my anywhere installing the new Mac OS X. The same problem here: the installer hangs after a while no matter which DVD I tried.

My last resort was using a USB stick/drive for installation. I found a nice description (german) on the web, which included the following steps:

1. create an image of Snow Leopard using Disk Utility (I used my wife's MacBook for that)
2. restore that image to your USB stick (I got an 8GB stick)
3. boot from your USB stick (hold option/alt while booting and select the USB drive)
4. run the installer

My stick didn't work out of the box, I had to reformat it - since it came FAT32 formatted and I had to run "Scan Image for Restore", which you can find under the Image menu in Disk Utility. After getting my USB drive ready and following the steps above, it worked like a charm. The installation took about an hour and went smoothly, without any problems.

Although I had so much trouble getting Snow Leopard installed, it was worth the pain! My system feels much more snappy and responsive now. Snow Leopard needs less space on my quite limited hard drive and Time Machine backups are reasonably fast now.

Overall, I'm quite happy jumping though all those hoops to the new Mac OS X Snow Leopard, although the experience wasn't very Apple-like.

Dependency Injection Obscures Your Code

2009-11-16T00:44:00.000+01:00

During listening to Software Engineering Radio's Episode 148 - "Software Archaeology with Dave Thomas", I got quite annoyed by a comment made by one of the respected authors of "The Pragmatic Programmer".

To quote Dave Thomas correctly, here's what he said at around 23 minutes into the podcast:

... that is one of the reasons why I, in general, are not very happy with the DI style of development, because I actually think it obscures the code quite a lot, when it comes to reading it ..... what it actually does is, it give you another dimension, that you have to read in order to understand the code.

My first reaction was "What the deuce!?!". I mean how can someone claim, that Dependency Injection obscures code and makes reading code harder? Are all those hours I spent blogging and promoting DI in vain? Are the SpringSource guys wrong or is Dave Thomas just crazy?

However, his statement and even his argument are completely reasonable, if you listen to the first couple of minutes of the podcast. Dave said at around 11 minutes into the podcast:

.... actually, I don't typically use an IDE, I use an editor like Textmate on the Mac.

And there you go! No wonder, you'll find it harder to read and understand code, if you compare the following two screenshots from a bunch of code, using Spring:

If you are reading the code above and don't understand where those two dependencies in the constructor come from, your IDE gives you a hint, without leaving the context of that particular file. You know that, they'll be injected by Spring. In addition to that, you can even directly navigate to the configuration file with a single click.

Now if you are using a text editor, you really have no idea where to look for. I guess you would have to grep for new TxTestService(). In case of using Spring, not even that would give you any more clues.

Don't get me wrong, if Dave likes Textmate better than an IDE - fair enough! I just think everyone should use the right tool for the right job! Frankly, an IDE makes a much better job here than a plain text editor.

I think the Java world has amazing tooling and in my opinion there's almost the philosophy, that if there is no tool support for a technology - it sucks. I don't fully agree with that. However, I do think that, when it comes to Java, tool support can definitely
assist you reading and thus understanding code.

RESTful applications in practise @ JUG-Ka

2009-11-06T05:44:00.003+01:00

This coming Wednesday Gregor Roth from 1&1, you might know him from his InfoQ article, is going to give a talk on RESTful applications at the Java User Group Karlsruhe.

He will show how to implement applications leveraging a RESTful architecture and point out the mismatch between a RESTful and RPC-style approach. Furthermore Gregor will highlight the difference between HTTP PUT and POST and finally demonstrate how to implement none CRUD operations using REST.

I'm really looking forward to this talk. In my spare time I developed the REST interface for an Android game and it's going to be interesting to see what we could have done better and hopefully what we've got right.

As usual, the talk will be held at University Karlsruhe in room 102, which is located in the basement. We'll start at 7:15pm, if the door opens as planned this time.

JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in participating in our monthly lottery, send me an email. The winners will be announced at the end of the talk. In addition to that, Atlassian sponsored a couple of great T-Shirts, which you can pick up at the end of the talk.

If you want to know more about upcoming talks, subscribe to our Google Calendar. You'll also be able to see the planned talks for 2010.

Having Fun with JDK's tools.jar

2009-11-02T05:44:00.000+01:00

This week I had to trace a bug in a legacy application, I'm maintaining at the moment, which drove me up the wall. The application uses a class from JDK's tools.jar, to determine the JVM instances currently running. Unfortunately, there are incompatibilities between JDK versions.

Tracking down the bug took a humongous amount of time, because the fun part of working on a legacy application is that all the developers, which are responsible for the code you are maintaining, are usually no longer available. Don't even get me started on documentation! However, as a good developer, I created the following JUnit test, to isolate the problem from the rest of the code.

package de.linsin.sample.tools.bug;

import static org.junit.Assert.*;

import com.sun.tools.attach.VirtualMachine;
import com.sun.tools.attach.VirtualMachineDescriptor;

public class ToolsJarTest {
@Test
public void testJVMInstances() {
assertTrue(VirtualMachine.list() > 0);
}
}

If you run this test with Sun's JRE 1.6 and tools.jar of Sun's JDK 1.6 on the classpath, you won't encounter an problems. However, with my current project, we need backward compatibility with other Java versions. That means, there are multiple tools.jar on the classpath, in different versions. Depending on their order, the test above fails or succeeds.

More precisely, there is a JDK 1.4 and 1.5 version of tools.jar on the classpath, in addition to the 1.6 version. 1.6 is needed, because in previous JDKs the class VirtualMachine doesn't reside in the package com.sun.tools.attach. So running the test without tools.jar in version 1.6, you'll get a NoClassDefFoundError.

So what's the problem you might ask? As long as tools.jar of JDK 1.6 is on the classpath, when running the aforementioned test, everything should be okay, right? It should be, but it isn't. As soon as tools.jar of JDK 1.5 is before the 1.6 version on the runtime classpath, the test fails. Every other combination works just fine.

Why tools.jar of JDK 1.5 causes this problem is a mystery to me. Sun's bug parade, doesn't contain any relevant information - at least I couldn't find any. Frankly, I think this problem is so absurd, that I cannot motivate myself getting to the bottom of it.

Nevertheless, the problem exists in our application and we'll have to find a solution. I guess that's the reason why it's a legacy application - I have to deal with problems that are totally outdated and nobody knows the answer to.

Push IRC messages to your iPhone

2009-10-26T05:35:00.000+01:00

In my new company one of the main communication channels is IRC. Unfortunately, I'm not able to hang out on IRC all day. That means, I'm not only missing interesting discussions, but I'm also always the last to get to know about interesting developments. To put an end to my offline-misery, I came up with a solution to push IRC messages to my iPhone.

First a couple of things you need to know. You'll need an iPhone app to receive push notifications, more about that later on. Furthermore, you'll need a server, which is able to host a Java-based IRC bot.

The bot is leveraging the famouse PircBot library, which unfortunately is based on inheritance:

public class Bot extends PircBot {
private boolean silentMode = false;
private Collection notificationServices;

private Collection messages;
private Timer messagesTimer;
static final int MESSAGE_BATCH_SIZE = 20;
static final int MESSAGE_BATCH_DELAY_MS = 60000;

@Override
protected void onMessage(String argChannel, String argSender, String argLogin, String argHostname, String argMessage) {
batchMessages(format(argSender, argMessage));
}

@Override
protected void onJoin(String argChannel, String argSender, String argLogin, String argHostname) {
User[] users = super.getUsers(argChannel);
switchSilentMode(users);
}

@Override
protected void onQuit(String argChannel, String argSender, String argLogin, String argHostname) {
User[] users = super.getUsers(argChannel);
switchSilentMode(users);
}

private void switchSilentMode(User[] argUsers) {
for (int i = 0; i < argUsers.length; i++) {
User user = argUsers[i];
if (user.getNick().equals(alterEgoName)) {
silentMode = true;
return;
}
}
silentMode = false;
}

private void batchMessages(String argMessage) {
if (messages.isEmpty()) {
messages.add(argMessage);
messagesTimer.schedule(new TimerTask() {
public void run() {
processMessages();
messagesTimer.purge();
}
}, MESSAGE_BATCH_DELAY_MS);
} else if (messages.size() < MESSAGE_BATCH_SIZE) {
messages.add(argMessage);
} else {
processMessages();
messagesTimer.purge();
}
}

private void processMessages() {
StringBuilder builder = new StringBuilder();
for (String message : messages) {
builder.append(message).append("\n");
}
sendToService("message", builder.toString());
messages.clear();
}

private void sendToService(String argTitle, String argMessage) {
for (NotificationService service : notificationServices) {
if (!silentMode) {
service.notify(argTitle, argMessage);
}
}
}
}

I stripped out some of the code, you can find the full version on GitHub.

The usage of PircBot, as you can see above (line 11, 16 and 22), is quite easy. You simply override the methods you want to hook into, and execute your code. That's pretty much all the magic that is to PircBot. In order to limit the notifications pushed to the iPhone, I batch a certain number of messages for a pre-configured time and eventually send them to a NotificationService. I'll come back to the NotificationService in a second, but there's another feature I'd like to point out - silent mode. I don't want to be notified on my iPhone, when I'm actually on IRC myself. So whenver a pre-configured user enters the channel, the Bot will switch to silent mode. As soon as the user leaves the channel, it'll switch back.

public class AppNotificationService implements NotificationService {
private final String credentials;
public static final String USER_CREDENTIALS = "user_credentials";
public static final String NOTIFICATION_LONG_MESSAGE = "notification[long_message]";
public static final String NOTIFICATION_TITLE = "notification[title]";
public static final String MESSAGE_LEVEL = "message_level";
public static final String URL = "https://www.appnotifications.com/account/notifications.xml";
public static final String HTTP_USERAGENT = "http.useragent";

public AppNotificationService(String argCredentials) {
credentials = argCredentials;
}

public boolean notify(String argTitle, String argMessage) {
HttpClient client;
PostMethod method = null;
try {
client = setUp();
method = setUp(argTitle, argMessage);
int returnCode = client.executeMethod(method);

if (returnCode > HttpStatus.SC_OK) {
return false;
} else {
logger.info("Sent notification!");
return true;
}
} catch (Exception e) {
throw new AppNotificationException();
} finally {
if (method != null) {
method.releaseConnection();
}
}
}

HttpClient setUp() {
HttpClient client = new HttpClient();
client.getParams().setParameter(HTTP_USERAGENT, "IRC Bot");
return client;
}

PostMethod setUp(String argTitle, String argMessage) {
PostMethod method = new PostMethod(URL);
method.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=utf-8");

method.addParameter(USER_CREDENTIALS, credentials);
method.addParameter(NOTIFICATION_LONG_MESSAGE, argMessage);
method.addParameter(NOTIFICATION_TITLE, argTitle);
method.addParameter(MESSAGE_LEVEL, "2");
return method;
}
}

As you can see, the NotificationService implementation, simply makes a Http Post request to a service called App Notifications. The request contains a couple of key/value pairs, which are used to configure your iPhone's push notifications.

I'm using Commons HttpClient to makes the Post request, since I have some experience with it. In order to use App Notifications, you'll need to setup an account. After the setup, you'll receive a credential String, which must be passed along with the Post request.

The only part missing is the iPhone app, that you need, in order to receive push notifications. The app is not free, but it's quite reasonable. Actually it's a good deal to pay for the app once and not on a request or monhtly bases. However, keep in mind, that the app can only receive push notifications - nothing else. If you that's what you need, this app is for you.

Putting together all parts of the puzzle, you'll get an IRC bot, which connects to the channel you want to be notified about. The bot batches messages and sends them to a service, which in turn pushes them to your iPhone. On your iPhone you have the notification app, which displays the messages from IRC.

The App Notification service is very reliable and super fast. However, there is one downside to the iPhoen app. You cannot switch off the notification sound without also switching off the vibration feedback. The App Notification developer told me, he'll address this issue in a future update.

I also had to play with the batch size and delay, since there are a lot of messages on the channel, I'm interested in and it got quite irratating getting pounded with notifications constantly.

Overall, I do admit, that this combination is quite adventurous, but it works very well. If you'd like to check it out, grab the code from GitHub and let me know what you think.

jBPM 4 @ JUG-Ka

2009-10-21T06:09:00.000+02:00

Today I'm pleased to welcome Bernd Rücker from camunda services GmbH to the Java User Group Karlsruhe. Bernd is going to talk about the Open Source Business Process Engine JBoss jBPM. I'm really excited about this talk, because it's a topic I was quite dedicated to a couple of years ago.

The session takes place today at University Karlsruhe, building 50.34 in the multimedia room 102, located in the basement. The talk starts at 7:15pm, our usual timing.

There will also be our monthly lottery, where JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in participating in the draw send me an email. The winners are going to be announced at the end of the talk.

There are still two more great talks coming up this year. You can subscribe to our Google Calendar to get the latest updates. There's also a Google or Xing Group to stay on top of things.

Spring DM with Annotations

2009-10-19T05:45:00.000+02:00

A couple of days ago, I implemented a sample application, based on Spring Dynamic Modules (DM) 1.2.0, with its annotation extension. Unfortunately the documentation doesn't contain any sample code, which might cause some unnecessary work, if you are not too familiar with Spring DM.

Spring DM's annotation extension allows you to pull in an OSGi service reference by annotating a setter of a property:

import org.springframework.osgi.extensions.annotation.ServiceReference;

public class MyService {
private LogService logService;

@ServiceReference(cardinality=ServiceReferenceCardinality.C0__1)
public void setLogService(LogService argLogService) {
logService= argLogService;
}
// other stuf
}

Unfortunately, you don't get rid of the XML configuration completely, but that's not so bad after all, because you still want to let Spring to all your wiring:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

<bean class="org.springframework.osgi.extensions.annotation.ServiceReferenceInjectionBeanPostProcessor"/>
<bean id="testService" class="de.linsin.sample.springdm.MyService"/>

</beans>

In addition to the instantion part, you need to configure a BeanPostProcessor. It tells Spring to handle your methods annotated with @ServiceReference. If you want all your bundles to use annotations, this might get a little tedious. That's why you can configure annotation processing for all bundles, by defining a fragment bundle, which overrides the default configuration of Spring DM's extender:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd">

<util:properties id="extenderProperties">
<prop key="process.annotations">true</prop>
</util:properties>

</beans>

Unfortunately, the configuration of the fragement bundle is not in the offical documentation.

Now, that you've got a glimpse of how to use annotations with Spring DM and the ways of configuring it, you might ask whether you want to use it or not? For me this boils down to the question, whether you want to have your dependencies in your xml file or in your code?

It's a tricky question and I think annotations only bring real value, if they make your life easier. Let's take a look at Spring's Web MVC for example: before annotations were introduced, you had to implement an interface in order to code a controller and thus you had dependencies on javax.servlet in your controller code. Spring Web MVC's annotation approach still leaves you with the dependency on Spring, but eliminates the javax.servlet dependency.

In addition to that, it improves testability of controller classes significantly, which I think is worth living with the dependency on Spring.

I think, that the features of Spring DM annotations, at least at the moment, are not compelling enough to have dependencies on it in your code. With the right tooling, Spring's XML configuration should be as easy to handle as annotations.

Book Review Dynamic Modules for OSGi

2009-10-12T05:48:00.000+02:00

Apress was kind enough to pass me a copy of this book, which I agreed to review in return.

I have been sitting on Pro Spring Dynamic Modules for Osgi(tm) Service Platforms for a while, although I got a fresh copy right after if was released earlier this year.

One reason for this might be, that after reading the first chapter, it felt like I was reading a manual rather than a book. Personally, I like a little bit more subjectiveness, because it improves the reading experience significantly. The author should spice up the dry material, so you won't get bored that easily. Unfortunately, that's what happened to me - I got bored. However, let's turn the spotlight to the content of the book.

The introduction chapter on OSGi is sufficient to get you up to speed. There are about 60 pages of Spring introduction. However, I think you should at least have some practical experiences with Spring, before digging into Spring Dynamic Modules or even Spring DM Server. It's simply not enough to explain the technicalities, to get someone an understanding of what Spring an its concepts is all about.

There's lot's of code in the book, which you can download and play with. If you like to read code, printed in a book, you are probably gonna like "Pro Spring Dynamic Modules for Osgi". For me, a book is not the preffered media to consume code. I have nothing against small code samples, but having pages over pages full of code, is really confusing and hurts readability.

The manual kind of feeling of the book continues the further you keep reading. Let me give you a concrete example: In chapter 4, called "Spring Dynamic Modules for OSGi", the author explains how the scope attribute of a bean declaration works:

Unfortunately, the how is all there is to the explanation. I expected a real life example of when to use the scope attribute and where it might not be suitable. I do understand, that the book can't go into details all the time, but especially those powerful Spring DM features like scoping, deserve more spotlight. Most of the time, the book stops when it gets interesting and you are left with your own imagination of how to apply that particular feature.

Despite the criticism, I got some neat tips from the book. The author suggests to split the OSGi dependent and traditional Spring configuration to make life easier for testing and mocking. I also gained a lot of knowledge from chapter 6, called "Versioning with OSGi and Spring". The author explains the concepts and implementation of versioning most of the time in a very understandable manner.

Overall, I think Pro Spring Dynamic Modules for Osgi(tm) Service Platforms is a reasonable reference book, with a nice sample application. If you are new to Spring and OSGi, you might have a hard time understanding the use case for those technologies, so I'd suggest to get this book as an addition to some basic reading material.

Google Sitebricks

2009-10-05T05:45:00.002+02:00

Last week I stumbled upon an interview on InfoQ with a Google developer working on a new web framework called Google Sitebricks. On my research day at Synyx, I had time to produce some sample code.

Google's mission statement goes as follows:

Sitebricks is a simple development layer for web applications built on top of Google Guice. Sitebricks focuses on early error detection, low-footprint code, and fast development. Like Guice, it also balances idiomatic Java with an emphasis on concise code.

A Sitebrick based web-application is deployed as a good old WAR file in a servlet container. That's the first information not explicitly stated on the website. If you have worked with another web framework before, you probably know the concept of a controller or a REST-based Resource. You can find the same concept in Sitebricks, too:

@At("/guestbook")
public class Guestbook {
private List entries;
private Entry newEntry = new Entry();

@Inject
private EntryDao entryDao;

public List getEntries() {
return entries;
}

@Get
public void load() {
entries = entryDao.readAll();
}

@Post
public String save() {
newEntry.setDate(new Date());
Integer id = entryDao.save(newEntry);
return String.format("/sample/guestbook/%1$s", id);
}

public Entry getNewEntry() {
return newEntry;
}

public void setNewEntry(Entry argNewEntry) {
newEntry = argNewEntry;
}
}

You can see that the class is pretty simple and it reminds me a lot of Restlet, which I used extensively the past few months. With the At annotation you declare the Uri under which your resource should be available. You can also define variable parts in your Uri, e.g. /guestbook/:id, which is used in my sample to access an entry of the guestbook.

The methods annotated with Get and Post are being called upon a request with the corresponding method. If you take a closer look at the method load(), you can see, that it doesn't return any value. That's where the convention or should I call it magic, of the framework begins:

<body>
@Repeat(items=entries, var="entry")
<p>
<a href="/guestbook/${entry.id}">${entry.id} on ${entry.date}</a></p>

<form action="/guestbook" method="post">

Name: <input name="newEntry.name" type="text"/>

Text: <input name="newEntry.text" type="text"/>
<input type="submit" value="save" name="save"/>
</form>

</body>

In your Html file, that you define along with your resource, there are expressions, that access members of your resource class. In the Html snippet above we iterate over a Collection named "entries". It's a member of the Guestbook class and is assigned whenever there's a Get request, which triggers the method load() to be called. The expression items=entries calls the getEntries() method on Guestbook, to return the Collection.

Frankly, this strikes me kinda odd. You call a method to populate a member and then its getter to retrieve the value? Shouldn't the annotated Get method return the value directly? I'm not quite sure what the design goal was here, but the first thing that comes into my mind is concurrency. If your resource class is a Singleton, you could run into quite some trouble.

Take a look at the form in the Html snipped above. It has two input fields, which are properties, mapped by name to the member newEntry. The member must be accessible under the resource declared in the action attribute of the form. This was not mentioned in the Sitebrick docs either. When you submit the form, the getNewEntry() method is called and the input field values are set at the returned instance. After that, the annotated save() method is called with the member newEntry already populated.

Again, the design here is rather unusual. You are working on a member, which in case of a Singleton resource, means there is shared state. Of course, if you define your resources not as Singleton, you don't have any problems. However, it's definitely a pitfall, in my opinion.

Overall, I think Google Sitebricks contains a couple of cool ideas. I like the expression language kind of approach, which makes it easy to work with Html snippets. The possibility to define little components (Bricks) and add them in other sites, is another really cool feature.

The project is still in its early stages and I hope they'll address those odd design decisions, mentioned above. Although it's not standards-based, with Google backing the framework, I could imagine Sitebricks getting some traction.

Tuning Hibernate and JPA @ JUG-Ka

2009-09-28T06:17:00.000+02:00

After two sessions on client development, we are now turning our attention to the server side again. I'm very happy to welcome Michael Ploed from Senacor Technologies AG to talk about "Tuning Hibernate and JPA Applications" at the Java User Group Karlsruhe.

Michael will show us how to approach tuning of your Hibernate powered applications and which options exist, to increase your application's performance. Furthermore he will talk about Hibernate's second-level cache, which I'm looking forward to in particular. Finally, he'll demonstrate his tuning advices with a demo application.

This month we have a special prize in our monthly lottery: a free pass to the W-Jax conference, held this coming November in Munich. All you've got to do is send me an email and be present at the end of the session, when Michael will draw the winner.

The session takes place this Wednesday at University Karlsruhe, building 50.34 in the multimedia room 101, located in the basement. The talk starts at 7pm, a little earlier as usual.

We have more great talks coming up, the next couple of months. In order to get the latest updates, sign up for our Google Group or join us on Xing.

Spring DM Web Extender Problems

2009-09-22T07:19:00.006+02:00

In my current project, I'm evaluating moving a large and very old code base to OSGi. Part of that is getting the the development team on board. I'm trying to point out, how much you can benefit from designing your application with OSGi in mind and the advantages you can have, running your application in an OSGi container.

I created some sample code with the help of the book "Pro Spring Dynamic Modules for Osgi(tm) Service Platforms" to highlight some of my OSGi presentation bulletpoints. One of the samples is running Tomcat inside of Equinox together with Spring Dynamic Modules. Although the sample is really simple and I sticked to the steps in the book precisely, Equinox spit out the following Exception:

17.09.2009 09:08:23 org.springframework.osgi.web.deployer.tomcat.TomcatWarDeployer afterPropertiesSet
SEVERE: No Catalina Service found, bailing out
org.springframework.osgi.service.ServiceUnavailableException: service matching filter=[(objectClass=org.apache.catalina.Service)] unavailable
at org.springframework.osgi.service.importer.support.internal.aop.ServiceDynamicInterceptor.getTarget(ServiceDynamicInterceptor.java:395)
at org.springframework.osgi.service.importer.support.internal.aop.ServiceDynamicInterceptor.afterPropertiesSet(ServiceDynamicInterceptor.java:455)
at org.springframework.osgi.service.importer.support.OsgiServiceProxyFactoryBean.createProxy(OsgiServiceProxyFactoryBean.java:185)
at org.springframework.osgi.service.importer.support.AbstractServiceImporterProxyFactoryBean.getObject(AbstractServiceImporterProxyFactoryBean.java:86)
at org.springframework.osgi.service.importer.support.OsgiServiceProxyFactoryBean.getObject(OsgiServiceProxyFactoryBean.java:137)
at org.springframework.osgi.web.deployer.internal.util.Utils.createServerServiceProxy(Utils.java:117)
at org.springframework.osgi.web.deployer.tomcat.TomcatWarDeployer.afterPropertiesSet(TomcatWarDeployer.java:90)
at org.springframework.osgi.web.extender.internal.activator.WarListenerConfiguration.createDefaultWarDeployer(WarListenerConfiguration.java:197)
at org.springframework.osgi.web.extender.internal.activator.WarListenerConfiguration.(WarListenerConfiguration.java:105)
at org.springframework.osgi.web.extender.internal.activator.WarLoaderListener$1.run(WarLoaderListener.java:353)
at java.lang.Thread.run(Thread.java:619)

After various failed attempts to google for a solution, I decided to consult the book again. Although, I thought I sticked to the steps closely, I missed an important point: start levels.

A start level is simply a non-negative integer value. The Framework has an ‘active start level’ that is used to decide which bundles can be started. Bundles themselves have an associated ‘bundle start level’ which is used to determine when a bundle is started. The bundles at a given start level will all have their start method completely executed before any bundles at a higher level are started. When booted, the Framework monotonically goes through each start level and starts relevant bundles (all the way until the active start level is met).
...
In the end, start levels are there to simply determine the start order of bundles.

I missed the fact that there is a start order in my Equinox run configuration. The bundles, which are in charge of bootstrapping Tomcat, need to be activated in special order, otherwise the previously mentioned Exception is raised. In particular the following bundles need to start in order:

...
org.springframework.osgi.catalina.osgi@3:start, \
org.springframework.osgi.catalina.start.osgi@3:start, \
org.springframework.bundle.osgi.web.extender@4:start, \ 
...

In "Pro Spring Dynamic Modules for Osgi" the config only orders the bundles and doesn't add any explicit start levels. However, I still ran into the same Exception from time to time, depending on other bundles I loaded. I put explicit start levels in my run configuration to solve those problems.

Git Svn

2009-09-14T06:22:00.000+02:00

Last week I started working for my new company and like most of the IT businesses today, we are running subversion for Source Control Management (SCM). While we are still discussing, moving to a Distributed SCM (DSCM), I didn't want to lose the advantages of working with git. Remembering Samuel's talk at Java User Group Karlsruhe and with a hint from Ollie, I started using git-svn.

The git manual describes the svn capabilities as follows:

git svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository.

git svn can track a standard Subversion repository....Once tracking a Subversion repository (with any of the above methods), the git repository can be updated from Subversion by the fetch command and Subversion updated from git by the dcommit command.

You can create a fully featured git repository from the trunk of a subversion repo with the following command:

git svn init -T https://svn.hostname.de/svn/projects/project/trunk

The git repository, that you just created is hooked to the trunk, passed with URL in the command. To get the HEAD, just run:

git svn fetch

Now you are ready to work with git, as if you had cloned a repo from GitHub. You can work with branches locally and commit your changes offline. When you want to share your work and push it back to subversion, you can use the following command:

git svn dcommit

You might ask yourself how to get the latest changes from your fellow developers? First, you should have no un-commited changes when you run:

git svn rebase

The reason for that, is this command is similar to svn update. It uses git-rebase instead of git-merge, in order to preserves linear history.

Those couple of commands got me started in no time and I didn't have to wait for a company-wide repository in order to have all the advantages that come with git.

No Improved Exception Handling

2009-09-07T06:03:00.000+02:00

Last week Joe Darcy announced the Project Coin finalists. There will be 7 "improvements" to the Java Language for the upcoming JDK 7 release. Unfortunately, one of my favorite proposals "Improved Exception Handling" didn't make it. Don't worry, I promise this is not gonna be a rant post, rather my personal view on what I have to work with for the next couple of years.

I have to admit I was a little pissed at first, when I read, that "Improved Exception Handling" didn't get in. Especially, because it was one of the most requested proposals. However, after reading Joe's explanation on his blog, I do see, that it is not easy to prefer one proposal over the other:

Improved exception handling would be a fine change for the language, but it ventures near the type system and we do not estimate we have resources to fully develop the feature within JDK 7. I would like to see improved exception handling reconsidered in subsequent efforts to evolve the language.

At this point I would start the ranting on how Sun couldn't have enough resources, but I made a promise I wouldn't. There's another reason I shouldn't start ranting:

If there are frustrations waiting for Java language changes, I assure you there are also frustrations working on Java language changes. For example, I find it frustrating (and self-inconsistent) that people state "I don't have technical expertise in this area" while simultaneously expecting their preferences to be selected without any contribution on their part. [LINK]

I guess I am one of those frustrated people. I have no idea, if I lack the technical expertise, but what I do know is that I have enough technical expertise to judge that this is a PITA:

Statement stmt = null;
try {
   // do stuff that uses Statement instance
} catch (SQLException e) {
  // handle state
  log.error("Bad database", e);
} catch (NullPointerException e) {
  // handle state
  log.error("Bad parameter", e);
} catch (Exception e) {
  // handle state
  log.error("Bad luck", e);
} finally {
  try {
    stmt.close();
  } catch (Exception ex) {}
}

It is quite irritating, that this is what Java developers have to work with for the next couple of years. It is annoying, that there is no standard in the Java Language addressing this problem. There might be workarounds or some OpenJDK whatever branch with a prototype hacked into it, which exactly solves this problem. In my opinion, that's not a solution whatsoever.

In order to reduce programming errors, I think the Java Language must address this problem with a standard solution like "Improved Exception Handling".

Java & Flex @ JUG-Ka

2009-08-31T06:17:00.000+02:00

I was amazed how many people showed up at our last session on JavaFX and I would love to see such a crowd at every session.

Was it the new technology, that made so many people show up? Was it the fact that it was about client development? Or was it simply because we had a speaker from Sun? I'm really curious to know and I would love to get some feedback, in order to improve the topics of our sessions.

This Wednesday, our new theme on client development continues with a session on Flex & Java. Adobe Flex is a framework for building web and desktop clients. Corneliu Vasile Creanga from Adobe, will give us an overview of the framework and how it can interact with Java. The session starts at 7:15pm, this Wednesday and takes place at University Karlsruhe room 101 in the basement.

There will also be our monthly lottery, where JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in getting a free copy of IntelliJ or JavaRebel, send me an email to participate in the draw. The winners are gonna be announced at the end of the talk.

We have a lot more exciting talks coming up this year. To stay on top of things, sign up for our Google Group or join us on XING.

Http Basic Authentication with Android

2009-08-24T06:00:00.000+02:00

The Google App Engine infrastructure, I'm developing in my spare time, is meant to be used by an Android client. To give our users at least a vague feeling of security, we decided to use a Basic Authentication together with HTTPS. Apparently, Android 1.5 is shipping with Apache's HttpClient 4.0 Beta2, which has a pitfall, when it comes to Basic Authentication.

When you search for HttpClient and Basic Authentication, Google will most definitely send you to the official documentation of HttpClient 3.x, which shows you, how to do Basic Authentication in a preemptive way. That means, sending the client's credentials with every request, instead of waiting for a 401 Unauthorized response and only then sending the credentials. That's probably what you want to in the first place, because it saves your client a request.

HttpClient client = new HttpClient();
client.getParams().setAuthenticationPreemptive(true);
Credentials defaultcreds = new UsernamePasswordCredentials("username", "password");
client.getState().setCredentials(new AuthScope("myhost", 80, AuthScope.ANY_REALM), defaultcreds);

This sample code won't compile with HttpClient version 4. The method called setAuthenticationPreemptive is missing. The problem is, if you omit this very method call, the code still works, but the authentication is not preemptive. We missed this little detail and only noticed after a while, that every request was preceded by a 401 Unauthorized request/response cycle. That doubled the amount of requests we served.

The HttpClient 4 documentation shows how to do preemptive authentication with the new API. You need to implement a so called HttpRequestInterceptor:

HttpRequestInterceptor preemptiveAuth = new HttpRequestInterceptor() {
    public void process(final HttpRequest request, final HttpContext context) throws HttpException, IOException {
        AuthState authState = (AuthState) context.getAttribute(ClientContext.TARGET_AUTH_STATE);
        CredentialsProvider credsProvider = (CredentialsProvider) context.getAttribute(
                ClientContext.CREDS_PROVIDER);
        HttpHost targetHost = (HttpHost) context.getAttribute(ExecutionContext.HTTP_TARGET_HOST);
        
        if (authState.getAuthScheme() == null) {
            AuthScope authScope = new AuthScope(targetHost.getHostName(), targetHost.getPort());
            Credentials creds = credsProvider.getCredentials(authScope);
            if (creds != null) {
                authState.setAuthScheme(new BasicScheme());
                authState.setCredentials(creds);
            }
        }
    }    
};

It basically sets the Basic Authentication headers, before each requests and thus avoids the 401 response. In order for the interceptor to work, you need to add it to the request chain:

DefaultHttpClient httpclient = new DefaultHttpClient();
httpclient.addRequestInterceptor(preemptiveAuth, 0);

You might also run into the problem of using the old HttpClient 3.x way of doing Basic Authentication. It does work, but it's not preemptive, which you might not notice right away. Save yourself some time and checkout the sample code provided by Apache.

Furthermore, I wasn't abel to find any official site, which states the version of HttpClient, used in Android 1.5. There are various sources, you might encounter, when searching Google, but I would like to see an official site, that states the version. A reason for Google not to reveal this information might be, that they adopted HttpClient and thus are not compatible anymore. However, to avoid mistakes and confusion, it would be nice to know, on which version the Android HttpClient is based on.

Cron Jobs on Google App Engine

2009-08-10T06:15:00.000+02:00

I've been developing for the Google App Engine (GAE) for a couple of months now and there's a lot, I want to talk about in future blog posts. This installment is about scheduled tasks on the GAE - cron jobs - and a couple of pitfalls that you should be aware of.

The configuration of a cron on GAE is pretty straightforward. You define your job in a file called cron.xml, which goes to your WEB-INF folder in your WAR file.

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
    <cron>
        <url>/cron/clean</url>
        <description>job to clean tmp every 5 minutes</description>
        <schedule>every 5 minutes</schedule>
    </cron>
</cronentries>

The file is easy to understand: url denotes where the GAE is supposed to send a GET request to, when the cron is triggered. Whatever you place behind the denoted url is your own choice. It can be a plain Servlet or some RESTful resource. The schedule tag contains a english-like syntax to define when the url is supposed to be requested. In this example GAE makes a HTTP GET request to http://yourname.appspot.com/cron/clean every 5 minutes.

One of GAE's subtle details is that your application is being shutdown, as soon as there are no requests coming in for a certain period of time. That's no a problem by itself, however, if you want to access the cached data of your application from within your cron, you are in trouble. It's not a severe problem, you just need prepared for it.

Another pitfall, that you might encounter, is configuring the url of the cron to be secured by SSL. You can define which urls are supposed to be confidential in your web.xml. As soon as you add your cron's url, you'll encounter an error message in your admin console under "Cron Jobs", which says "Too many continues". This indicates, that GAE wants to execute cron jobs using http instead of https, which leads to a HTTP 302 response. Browsers can easily interpret it as "don't use http, use https instead", but the GAE can't.

This is not a security problem, since the urls of your cron job should only be accessible by administrators anyways. You can easily exclude the cron's url from your SSL configuration and everything should work fine.

There are more little gotchas, that I encountered developing for the GAE and I'm going to blog more about it soon.

JavaFX @ JUG-Ka

2009-08-03T06:15:00.000+02:00

With our new logo, designed by Samuel Mellert, who held last month's session on Git, we want to start into the second half of 2009. There are a couple of exciting talks coming up at Java User Group Karlsruhe, beginning with an introduction to JavaFX this week. To get the latest updates of the JUG-Ka sign up for our Google Group or join us on XING.

Stefan Schneider from Sun Micorsystem is going to give an introductory level session on JavaFX, with samples and time for QA. Stefan gave a couple of talks here in Karlsruhe and I'm very pleased he is back with something new.

The session takes place this Wednesday at University Karlsruhe and starts at 7:15pm. As usual, JetBrains and ZeroTurnaround are each giving away a free license of one of their products. There'll be a lottery, so if you are interested in getting a free copy of IntelliJ or JavaRebel, send me an email to participate in the draw. The winners are gonna be announced at the end of the talk.

I'm sure you all know the DZone network, which provides all sorts of services and information for developers, like Javalobby, JRoller or EclipseZone. They also have a service called Refcardz - nice little cheat sheets on a variety of topcis. You can download those Refcardz and print them yourself or you can come by on Wednesday and get one for free. DZone was kind enough to provide a couple of professionally printed Refcardz, which I will give out at the end of the next talk.

Git Stash

2009-07-29T06:10:00.000+02:00

After a great talk on Git at the Java User Group Karlsruhe and a couple of other experiences, I started to really dig the Distributed Source Control Management (DSCM) notion and its advantages. A neat and quite helpful feature of Git is stashing.

The Git manual has as an exceptionally helpful description of stashing. They call it "Temporarily setting aside work in progress".

While you are in the middle of working on something complicated, you find an unrelated but obvious and trivial bug. You would like to fix it before continuing. You can use git-stash(1) to save the current state of your work, and after fixing the bug (or, optionally after doing so on a different branch and then coming back), unstash the work-in-progress changes.

$ git stash save "work in progress for foo feature"

This command will save your changes away to the stash, and reset your working tree and the index to match the tip of your current branch. Then you can make your fix as usual.

... edit and test ...
$ git commit -a -m "blorpl: typofix"

After that, you can go back to what you were working on with git stash pop:

$ git stash pop

Git's stashing feature saved me quite some trouble a couple of days ago, while working on a side project. I developed a feature on branch "B" and had quite a big change-set, while someone found a bug on the stable branch, let's call it "A".

Coming from SVN, I thought I had to check-in my changes in order to switch to Branch "A" and fix the bug. That's quite ugly, because it screws with your history of commits and even might break your builds. I know that there are other possibilities with SVN, like copying your changed files or creating a patch file. However, to me those all look like workarounds rather than solutions.

So I simply stashed my changes from branch "B" and got a clean branch with HEAD. I switched to branch "A" and was able to fix and commit the bug. After switching to branch "B" again, I simply poped the changes from the stash, as if I had never stopped working on the feature.

After working with Git for some time, I would really recommend people to switch to a DSCM. I'm not alone with this. SpringSource's DM server team migrated their repositories to Git a couple of weeks ago and they didn't hear any complaints from the community. No matter if you choose Git or Mercurial, the advantages of a DSCM really outweigh the initial costs of getting started.

Jug-Ka Summer Stammtisch

2009-07-13T06:00:00.000+02:00

Since we haven't had a Stammtisch of the Java Users Group Karlsruhe for a while, I thought it's time to get together again.

We are gonna meet on Wednesday, July 15th - 20:00, at a nice pub called Litfass, near Marktplatz. For further information you can send an email to our Google Group or join us on Xing.

When Unchecked Exceptions Go Wrong

2009-07-06T05:53:00.000+02:00

In the application I'm developing right now, we found a bug right before going live. A colleague of mine forgot to catch an unchecked Exception in a loop, which led the loop to exit, before iterating over each element. Bugs like this are so subtle and hard to track, that's why I think it was kind of my fault for not using a checked instead of an unchecked Exception.


// must work all jobs
private void workAllJobs() {
  for(MyJob job : allJobs) {
    job.work(); // throws RuntimeException
  }
}

Let me be clear, I don't want to engage into the checked vs. unchecked Exception war. I made my point clear a couple of times, however I simply think I need to revise my position.

I used to think forcing a client of an API to catch an Exception was evil! That's why I usually design custom Exceptions to inherit from RuntimeException and declare each and every case carefully in the javadocs of my API methods. I simply followed the expert's advice:

Always declare checked exceptions individually, and document precisely the condition under which each one is thrown using the Javadoc @throws tag. .... While the language does not require programmers to declare unchecked exceptions that a method is capable of throwing, it is wise to document them as carefully as the checked Exceptions.

Unfortunately, the expert's advice didn't work in my co-worker's case. Should I say in most cases? He is with the sad majority of developers, that don't ready javadocs - not even on public API methods. Maybe I should have listened to people telling me this:

I kind of disagree with your example; documenting everything in every tiny detail may be a requirement for widely used public APIs (like the JDK), but IMHO a more relaxed approach is useful for the rest of us. Like "configuration by exception" is considered a good idea, there should also be "documentation by exception". That is, don't document every tiny detail but instead follow some higher level conventions. Many people do that intuitively, but unfortunately forget to document those conventions.

Like Matthias, my co-worker argued, that he thinks conventions should define what happens if e.g. you pass null to a method or which Exceptions are being thrown from an API method. I do agree, conventions are a great tool to define this kind of behavior. The problem with conventions are: How do you get the whole team to agree on certain conventions and more important - how do you manage those convetions?

Getting a team of strongly opinionated individuals to even agree on minor details, e.g. how to name interfaces, is almost impossible. Believe me, I have been there! After more than a year, we still can't agree on wether to use Eclipse's notation of IService or my preference - simply Service. I cannot imagine how hard it will be to agree on really important topics like passing null to methods and wether to throw IllegalArgumentException or NullPointerException in that case.

The second issue with conventions is how to manage them. Who is responsible to maintain those agreements? Do you put those conventions on a wiki page, which nobody updates and nobody reads anyways? I argue, that for us developers code and eventually the IDE is where we live, thus I think that's the place those conventions should live as well. Code is the common single point of truth for us and hence javadocs are in my opinion the best way to document any code related conventions.

I guess you can see where this is going. It's a trade-off, as always in software development. However, it's a trade-off with a catch. I think it's simply not enough to "just have conventions", they need to be documented and managed in the code and my weapon of choice for doing that is javadocs.

Java Forum Stuttgart

2009-07-03T07:27:00.001+02:00

Yesterday, I was attending the 12. Java Forum Stuttgart and compared to the last time I went, which was in 2005, the event has really fledged.

The quality of the sessions was good and the hallway was filled with familiar faces. The theme of the conference for me, was JPA and O/R mappers. There were a couple of really great talks about it and it seems like there's a lot of going on in that area at the moment.

I'm definitely gone be there again next year and I would love for the conference to be extended to a 2-3 days event.

Wrapping-up Jazoon09

2009-06-29T06:03:00.000+02:00

I was attending Jazoon09 in Zurich, Switzerland last week. As with springOne 2009, I wasn't really satisfied with this content of the conference.

The problem was, that there were only a few really good speakers and thus only a couple of great talks. The keynotes were average, only Adrian Colyer's presentation on the last day was standing out. Even James Gosling's presentation or Danny Cowards talk were both not that exciting.

However, instead of telling you what sucked, I rather want to highlight, that the organization of the conference was great! The food was really good! There was an vegetarian alternative every day and the coffee was delicious. Jazoon took place in a movie theater, just like Devoxx, thus it was easy to get there by train and the seats were nice and comfy. Kudos to the organizers.

There were a couple of great talks I want to highlight: Neal Ford's "Smithying in the 21st Century" as well as Ed Burns' "Secrets of the Rockstar Programmers" were really awesome and I can only commend listening to them, in case they come up on the schedule of another conference.

I'm not too sure if I'll come back to Jazoon next year, although I think it could be a really cool conference and a great alternative to Devoxx, which takes place in Antwerp.

Jazoon 2009

2009-06-21T10:58:00.000+02:00

I'll be at Jazoon 2009, which is starting next week on Monday with a Glassfish Day. It's going to be my first time in Zurich this year and I'm really excited, because they have a great line up of speakers.

Among others, there's gonna be the father of Java himself Mr. James Gosling. For me it's always something special to listen to a keynote of him.

There's gonna be sessions on a wide range of topics, e.g. "Concurrency and Performance Reloaded" with Kirk Pepperdine, "Development for the iPhone" or "Design Patterns in Dynamic Languages" with Neal Ford, to name only a few of the first conference day.

Git talk @ JUG-Ka

2009-06-15T05:52:00.000+02:00

This coming Wednesday Samuel Mellert (1&1 Internet AG) is going talk about "Distributed SCM with Git" at the Java User Group Karlsruhe. I'm a newbie when it comes to distributed version control and especially Git, that's why I'm really looking forward to this meet-up. The talk starts at 7:15pm and takes place at University of Karlsruhe.

JetBrains and ZeroTurnaround are each giving away a free license for their products. We are gonna have a lottery, so if you are interested in getting a free copy of IntelliJ or JavaRebel, send me an email to participate in the draw. The winners are gonna be announced at the end of the talk.

To get the latest updates of the JUG-Ka sign up for our Google Group or join us on XING.

Git(Hub) Pain

2009-06-08T05:55:00.001+02:00

This is a little bit of a rant post, so if you are not interested in my subjective experience with GitHub, you should stop reading now.

A couple of weeks ago I started playing with Git. First of all, I love the notion of distributed version control, although it took me a while to wrap my head around it.

Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

I found it quite hard to explain Git or distributed version control in general. The best explanation I heard so far comes from Joel Spolsky, who talked about it on the stackoverflow podcast. It goes something like this:

You are working on a local clone of the full repository and a commit is basically a set of changes applied to a version of that repository.

I have a little side-project with 2 other developers and we decided to use Git as our version control system. One of the reasons why we choose Git, was the limitations we saw in our daily work with SVN and the more important reason - isn't it just cool to try something new?

One way to let others participate in your development, is to have a repository on GitHub. Others can come in and get a local copy of your work, contribute to it and merge it back into your original source tree later on. Everything is accessible and essentially open source. However, if you pay GitHub some money, you can have private repositories with contributors - that's what we did.

The move from SVN to Git wasn't easy. We had to adopt our style of working with version control, because we ran into trouble pretty early. I guess we first needed to grok the mindset of branching and merging, before we could really leverage the advantages of distributed version control.

Unfortunately GitHub didn't help getting started. I don't know if it's because of broken tools or if it was GitHub's fault, but we managed to damage one of our branches. When I tried to pull from the branch I got the following error message:

crusty:doublemill dlinsin$ git pull origin master 
error: Could not read 9b82bba67693db3b47189aefea07ec4e1d7be38e 
fatal: bad tree object 9b82bba67693db3b47189aefea07ec4e1d7be38e 
remote: Counting objects: 13, done. remote: Compressing objects: 100% (8/8), done. 
error: waitpid (async) failed 
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side. 
remote: Total 8 (delta 0), reused 0 (delta 0) 
remote: aborting due to possible repository corruption on the remote side. 
Unpacking objects: 100% (8/8), done. 
error: waitpid (async) failed fatal: error in sideband demultiplexer

Since I couldn't find clear information on the problem, I decided to open an issue with GitHub support. Unfortunately after almost a week, I got a reply to my issue which was more than disappointing:

The best thing to do would be to delete the repository and recreate it with a fresh git push.

I mean seriously? Is that the best they can do? Sure, it's the easiest way out for GitHub, but not the most customer friendliest way I can imagine. It's just so disappointing, because I like GitHub and I have no problem to pay for their service. In fact, I guess I would have paid them anyways, because they have a great product and deserve some support. I just don't like this kind of "Have you tried turning it off and on again?" - attitude.

However, even after all the trouble we had, I'm still glad we choose Git. I think distributed source control is the future and I would suggest anybody to have a look at it, before starting the next project with SVN.

More JDK 7 Language Changes

2009-05-28T13:07:00.001+02:00

A couple of month ago, Joseph Darcy announced the first six new language features for JDK 7. Yesterday, he posted another 7 proposals, which Sun will take into further consideration:

1. Byte and Short Integer Literal Suffixes by Bruce Chapman

2. Binary Literals by Derek Foster

3. Underscores in numbers by Derek Foster

4. Language support for JSR 292 by John Rose

5. Indexing access syntax for Lists and Maps by Shams Mahmood Imam

6. Collection Literals by Joshua Bloch

7. Large arrays (revised) by James Lowden

Joseph says:

All the selected proposals were reviewed and judged to have favorable effort to reward ratios and to preserve the essential character of the language.

I think "Collection Literals" and "Indexing access for Lists and Maps" will considerably improve my daily coding life as an average Joe developer. Furthermore, "Underscores in numbers" could really improve working with numeric data. Here are a couple of code snippets from the proposals:

6. Collection Literals:

final List<Integer> piDigits = [3, 1, 4, 1, 5];
final Set<Integer> primes = { 2, 7, 31, 127, 8191};

compare that to the current way of creating a immutable List:

final List<Integer> piDigits = 
Collections.unmodifiableList(Arrays.asList( 3, 1, 4, 1, 5));

I really like this proposal, it'll make life so much easier. I use the notation above almost in every JUnit test to create some sample data in a List or Set. It's so much cleaner and more readable using the proposed syntax.

5. Indexing access for Lists and Maps

List<String> l1 = ["a", "b", "c"];
String firstElement = l1[0];

I like this notation, it's concise and feels very natural. On the other hand, I don't really mind writing List.get(0). Actually, this reminds me of Scala, where you can also say something like:

val l1 = List("a", "b", "c")
val firstElement = l1(0)

3. Underscores in numbers

int phoneNumber = 555_555_1212;

This proposal is supposed to increase readability and everything that accomplishes this should be added to Java. However, I believe, you have to find the middle ground and only apply conciseness, where it makes sense and doesn't hurt readability, but that's another story.

Most of these proposals are only nice additions and are not really essential. However, I think a lot of them are going to make my daily coding life more enjoyable. I'm excited to see them implemented and hope there will be a JSR soon.

Make it Easy to Contribute

2009-05-25T06:03:00.000+02:00

The past couple of weeks, I've been playing a lot with Restlet, a Java based REST framework. I like the it a lot, because it's easy to use and you can get it up and running in no time.

The current version of Restlet is 1.1, but when I compared it to the upcoming version 1.2-M2. it was clear that I would start using that right away. It has built in Google App Engine support and uses an Annotation driven approach, which increases testability and ease of use. This is one of the rare uses cases, where I think Annotations are perfectly suited, but I'm digressing. Overall, it was a natural choice to use the milestone build 1.2 right from the beginning.

After a couple of weeks of coding against 1.2-M2, I started to encounter a couple of weird side effects. After testing the code against the current stable version, it was clear, that it must be a bug in the 1.2 milestone release. So I checked the Restlet site, which nicely describes the process of reporting bugs.

Before entering a new report, you should query the current issue database for similar open issues.

As a decent developer, I followed the link to the issue tracker and saw this:

I was shocked to see this kind of interface! I know I'm a developer and I should love these kind of fine grained and detailed options to query an issues tracker, but that's too much! It's not the first time that I see this interface, Java.net uses it too and I just think it's a PITA to use! Compare it to google's code hosting issue tracker interface:

It's worlds apart in terms of usability and ease of use! And the screenshot above even shows the "advanced" search mode. In most cases, you can find everything with a single search box - google like!

I think, if you want the community to interact and contribute to your project, make it as easy as possible for them. They are trying to help you! We all know the problem of issues reported multiple times or reporters not taking time to correctly file an issue. However, every feedback is valuable and you can always ask for further and more detailed descriptions, if necessary.

Coming back to my bug in Restlet, after I managed to query the issue tracker, I saw that it had already been reported. So I decided to switch back to the current stable version. Unfortunately, I had to jump through a couple of hoops to make it work on the GAE, but that's another story altogether.

Is JavaFX Really the Future?

2009-05-18T06:14:00.000+02:00

A java.net poll, which took votes over the past week, shows that a lot of developers are not quite sure, if JavaFX is the way to go in Java UI space. The "Editor's Daily Blog" tried to blandish the numbers:

The first thing to note is that more than 600 votes were cast. That means that this poll stimulated more community participation than any of the other recent polls. Does this matter? I think so. I think it suggests that, whatever may people think about the future of JavaFX, JavaFX is something that has captured their interest. People are following JavaFX.

To be fair, I voted for "It will endure as a secondary option". I'm not too sure if JavaFX will take off in the future. There was a lot of fuzz about it at last year's Devoxx. I talked to a couple of people back then, but all of them had different opinions. Some of them liked it, other were sceptical. However, the general opinion was "We'll have to wait and see!".

I rarely push out this kind of bash blog posts, but with Sun putting a lot of resources into JavaFX and this significant developer refusal, I think it's worth mentioning it.

Handling Concurrency in Domain Models

2009-05-13T06:00:00.000+02:00

I'm working on a project right now that has a rich domain model, which we plan to use in different environments. One group of consumers are mobile clients, the others are highly concurrent servers. We try to cater to both environments in terms of parallelization, as well as keeping the domain model free of technical details.

When I design a domain model, I tend to keep it as technology independent as possible, that's probably the reason why I'm not the biggest fan of Annotations. You kind of lock yourself into a certain type of technology and you probably introduce dependencies on 3rd party code. Overall I think you are polluting your core classes with details that don't belong there.

One of those technical aspects I'm referring to is concurrency. You can either choose to prepare your domain model for a concurrent environment or leave it to the consumer of the core classes. Take a look at the following class as an example:

public class Foo {
  private Map<Long,Bar> bars;

  public Foo() {
    bars = new HashMap<Long,Bar>;
  }

  public void addBar(Long argId, Bar argBar) {
    bars.put(argId, argBar);
  }

  public Map<Long,Bar> getBars() {
    return bars;
  }
}

Obviously, this class is not meant to be used in multithreaded code. There are a couple of issues, which could lead to an unpredictable state of the Collection bar. Here's another version:

public class Foo {
  private final Map<Long,Bar> bars;

  public Foo() {
    bars = new HashMap<Long,Bar>;
  }

  public void addBar(Long argId, Bar argBar) {
    bars.put(argId, argBar);
  }

  /**
   * @return immutable Map implementation
   */
  public Map<Long,Bar> getBars() {
    return Collections.immutableMap(bars);
  }
}

As you can see there are a few easy things, you can do to prepare this class for usage in a parallelized environment. In fact, I think you should always do them, even if your code won't run in multiple threads. However, this code is not thread-safe either and you need to jump through a couple of more hoops until it is:

public class Foo {
  private final Map<Long,Bar> bars;

  public Foo() {
    bars = new HashMap<Long,Bar>;
  }

  public synchronized void addBar(Long argId, Bar argBar) {
    bars.put(argId, argBar);
  }

  /**
   * @return immutable Map implementation
   */
  public synchronized Map<Long,Bar> getBars() {
    return Collections.unmodifiableMap(bars);
  }
}

I think this version gets pretty close and you could call it thread-safe. I say close, because a) I'm not Brian Goetz and b) we don't know more about Bar. However, we can be sure, that there shouldn't be any problems with the Collection bars. You can add new Bar instances and retrieve them concurrently without affecting the Collection itself in any way.

The price we paid for this is clarity. The code gets a bit more complicated. I know there are other ways to make the Collection bar safely concurrent modifiable, e.g. using a ConcurrentHashMap. The point is, that if you have a complex and fairly large domain class, making it thread-safe would mean littering it with all those technical details, mixing responsibilities and making it way more complicated to maintain.

So where is the right place to handle concurrency?

While researching this topic, I found a great discussion on stackoverflow, where Alex Miller suggests the following:

Start from the data. Decide which data is explicitly shared and protect it. If at all possible, encapsulate the locking with the data. Use pre-existing thread-safe concurrent collections.

Whenever possible, use immutable objects. Make attributes final, set their values in the constructors. If you need to "change" the data consider returning a new instance. Immutable objects don't need locking.

For objects that are not shared or thread-confined, do not spend time making them thread-safe.

This doesn't answer my question directly, but it suggest to handle concurrency on the level of data. That means using the java.util.concurrent classes in your domain model and only for data which is shared between threads.

So what I take away from all of this, is that, it isn't really a question of where to handle concurrency, but rather when. I think if you can minimize the technical pollution of your domain model to the data that needs it, you can contain the damage of clarity. With the java.util.concurrent Collections you have an abstraction that hides the concurrency aspect quite nicely. I guess the combination of both is the way to go: Only optimize data that needs it, with a good abstraction, that hides the technical details.

springOne 2009 recap

2009-05-04T06:00:00.000+02:00

Last week I was at springOne 2009 in Amsterdam, Netherlands. Unfortunately the city left a bigger impression than the conference. There were a lot of people from SpringSource and quite a few interesting sessions, however I didn't get into the spring feeling that I was hoping for.

The most outstanding announcement for me was something called "Spring Roo". According to Ben Alex, it's

...a sophisticated round-tripping code generator that makes it quicker and easier than you've ever imagined to create and evolve Spring applications

You can leverage it to create applications with technologies like Spring, JPA and Spring MVC, using a shell-based approach with tab completion, hints and great default behavior. A big part of the opening keynote was dedicated to Spring Roo, where Ben live coded a simple web-based voting application. You can already download an alpha release and check it out.

Overall the keynotes were the most valuable sessions for me. Most of the others had a rather introductory character and were quite basic, which I think should not be the focus of such a conference. I'm a little disappointed, but nevertheless, I hope next year will be better.

Using Reflection in Unit Tests II

2009-04-27T10:35:00.000+02:00

A couple of days ago, I blogged about the pros and cons of using Reflection in unit tests. Thanks to Samuel, who gave me a pointer to "PowerMock", I don't have to deal with the Reflection API anymore.

PowerMock is a Java framework that allows you to unit test code normally regarded as untestable.

To be more precise, PowerMock takes away the annoyance of dealing with the Reflection API. In case of the example presented in my previous post, instead of this code:

@Test
public void test_Calculate_Quote() throws Exception {
    Contract classUnderTest = new Contract(1L);
    Method calcMethod = getMethodOfClass(Contract.class, "calculateQuote");
    BigDecimal quote = (BigDecimal) calcMethod.invoke(classUnderTest, new DateMidnight(1982, 4, 27));
    assertEquals(new BigDecimal("7.79"), quote.setScale(2, RoundingMode.FLOOR));
}

private Method getMethodOfClass(Class argClass, String argMethodName) {
    Method[] methods = argClass.getDeclaredMethods();
    for (Method method : methods) {
        if (method.getName().equals(argMethodName)) {
            method.setAccessible(true);
            return method;
        }
    }
    throw new NoSuchMethodError("couldn't find " + argMethodName + " on class " + argClass);
}

you simply write this:

@Test
public void test_Calculate_Quote() throws Exception {
    Contract classUnderTest = new Contract(1L);
    BigDecimal quote = (BigDecimal) Whitebox.invokeMethod(classUnderTest, "calculateQuote", new DateMidnight(1982, 4, 27));
    assertEquals(new BigDecimal("7.79"), quote.setScale(2, RoundingMode.FLOOR));
}

I like the approach of hiding the complexity of the Reflection API behind an abstraction and in case of Whitebox it's even named perfectly. But accessing private methods is not the only thing PowerMock lets you do. In addition to much more you can set private fields, invoke hidden constructors and mock static methods. A feature that I really like is mocking final classes or methods, it can be quite helpful, when you are dealing with JDK classes like java.io.File.

I think PowerMock is a great extention to EasyMock and it should go into every developer's tool box. It's definitely going straight into mine.

SpringOne 2009

2009-04-21T17:30:00.000+02:00

Next week, starting on the 27th of April there's gonna be SpringOne 2009. That's 3 days straight and full blown intensive Spring!

Unlike the last 2 years, the conference is not going to be held in Antwerp, Belgium - instead it'll take place in Amsterdam, Netherlands. I think it's a nice change. I've never been to Amsterdam before and I even added a couple of days to my trip to explore the city with my wife.

Looking at the first day, there's a bunch of really interesting sessions like "Performance Tuning for Apache Tomcat", "New Features in Spring 3.0" or "Extreme Productivity in Application Development".

I'm really excited to feel some Spring spirit again...

Using Reflection in Unit Tests

2009-04-19T05:43:00.000+02:00

A couple of days ago I watched a presentation on Neal Ford's book "The Productive Programmer". He talked about 10 ways to improve your code. One thing, which I found quite innovative, was leveraging Java Reflection to test non-accessible code.

With non-accessible code, I mean private, package-private or protected methods and constructors of your domain or service classes. If you are a test addict like me, you've probably made a method public or protected every now and then, even though it shouldn't be, simply so that you could access it from your test code. Using Reflection instead, is a simple and easy solution, I have never given a thought before.

I came up with a little sample, which you can download or check out on github. Take a look at the following class:

public class Contract {
    private static final Double RATE = 0.3;
    private final Long contractId;
    private BigDecimal quote;
    private Customer owner;

    public Contract(Long argContractId) {
        contractId = argContractId;
        quote = BigDecimal.ZERO;
    }

    /** package */void setOwner(Customer argOwner) {
        owner = argOwner;
        quote = calculateQuote(argOwner.getBirthday());
    }

    private BigDecimal calculateQuote(DateMidnight argBirtday) {
        Years ageInYears = Years.yearsBetween(argBirtday, new DateMidnight());
        return new BigDecimal(RATE).multiply(new BigDecimal(ageInYears.getYears()));
    }
    // other stuff omitted
}

In order to test the calculateQuote method in isolation, I would have probably introduced a QuoteCalculator class. It would be in charge of the business logic and used by the Contract class. If you need the logic at multiple places in your code, that's a great solution. If you only need it in Contract, it's quite tedious and I would have probably made calculateQuote accessible from the test class. However, I used Reflection instead to solve the problem and it works quite nicely:

@Test
public void test_Calculate_Quote() throws Exception {
    Contract classUnderTest = new Contract(1L);
    Method calcMethod = getMethodOfClass(Contract.class, "calculateQuote");
    BigDecimal quote = (BigDecimal) calcMethod.invoke(classUnderTest, new DateMidnight(1982, 4, 27));
    assertEquals(new BigDecimal("7.79"), quote.setScale(2, RoundingMode.FLOOR));
}

private Method getMethodOfClass(Class argClass, String argMethodName) {
    Method[] methods = argClass.getDeclaredMethods();
    for (Method method : methods) {
        if (method.getName().equals(argMethodName)) {
            method.setAccessible(true);
            return method;
        }
    }
    throw new NoSuchMethodError("couldn't find " + argMethodName + " on class " + argClass);
}

As you can see the method.setAccessible(true); is doing the trick to enable access from the test to the domain object. Instead of the actual instance of Contract, we use the Method instance to invoke the private call. Everything else is plain test code, as you know it.

Of course, you could argue to make the calculateQuote method package-private or protected and put the test class into the same package. In fact Bill Venners wrote about that in one of is articles, suggesting that testing private methods is bad practice anyways. I tend to agree and I guess the example above is an exception. However, using Reflection is not necessarily limited to testing private methods. You might need access to an object to manipulate it's internal state, in order to test it thoroughly and the best tool for that job is probably Reflection.

I think it's a neat idea to use Reflection in unit tests. Used with caution, it can be really helpful and is definitely better than breaking encapsulation for testing.

More Playing with GAE

2009-04-16T05:33:00.000+02:00

In my previous blog about the Google App Engine (GAE), I wrote about the problems I had encountered using JPA and Maven. In this post I want to share how using Groovy on the GAE worked out and what my impressions are on the scalability of the platform.

Inspired by SpringSource's blog on Groovy with the GAE and after almost a year, I decided to do some Groovy coding. I wrote a small Groovlet, which uses the JPA to fetch entities from persistent storage. Again, I'm quite astonished of how smooth coding can be:

import javax.persistence.*
import java.util.List
import de.linsin.sample.gae.domain.User 
import de.linsin.sample.gae.EMF
 
EntityManager em = EMF.getInstance().createEntityManager()
Query query = em.createQuery("SELECT u FROM " + User.class.getName() + " u")
List<User> users = query.getResultList()

for (User user : users) {
  out.println(user.getName() + " " + user.getLastname() + "<br/>")
}

em.close();

To be fair, I have no Exception handling in this code and there is no finally making sure the EntitManager is closed at the end. Yet, it feels like Java without the clutter.

To get this working on the GAE, all you need to do is drop the groovy-all.jar into the WEB-INF/lib folder of your WAR file and add the GroovyServlet to your web.xml. You add your Groovlet to a groovy folder under WEB-INF and access it like a good old Servlet in your browser e.g. http://dlinsin-area51.appspot.com/HelloWorld.groovy.

Unfortunately there is one major drawback, which makes developing Groovy for GAE a real pain - local deployment of Groovlets is not working right now. It seems like Google has been notified about the issue, but even after a few days the bug is still in status "new", so I don't think there'll be a fix anytime soon. Since daily deployment is limited by a quota, I think this bug is almost a show-stopper and I wouldn't want to develop in Groovy for the GAE right now.

Let's turn our attention to performance and scalability. First off I have a disclaimer: I didn't run any thorough or scientific tests! Although I have some numbers to back up my opinion, you might want to run further tests before you draw a final conclusion.

To get us all on the same page, let's start with a little "theory". When I talk about performance it means something like this:

... performance is characterized by the amount of useful work accomplished by a computer system compared to the time and resources used.

...performance may involve one or more of the following:
Short response time
High throughput

The same goes for scalability, although in general it's more subtle to properly define it:

...scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged.

With that out of the way let's head over to the test setup. It consists of a simple Apache JMeter test script, which puts my poor sample application under load. The script loads the start page http://dlinsin-area51.appspot.com, then inserts the name "JMeter" into the input field and submits the form. The submission results in a redirect to the start page again. I mainly wanted to test "writes" to the persistent storage, because in my experience that's the most hardest part to scale.

I ran the test script with 10 threads (blue shaded) and with 100 threads hitting my sample app. Each thread runs the test procedure 10 times. The results were quite interesting. If you take a closer look at the average response time of both samplers you can see only a small difference between 10 users and 100 users (or threads) hitting the application at the same time. The response time for inserting a row into the persistent storage went up insignificantly, which I think is quite astonishing, considering the increase of load.

However, you should take these results with a grain of salt. They merely exist to give me a hint of what the GAE is capable of. I would be interested in real benchmarks, because I think it's crucial to see how scalable the GAE is under field conditions.

Update: The test results are simply wrong! Thx for pointing it out Bernd, I'm working on it!

Update 2: Here comes the bugfix!

You might ask what happened? Frankly, I mixed up the pictures and didn't double check, before pushing out the post. Sorry about that! I ran the tests with the same specs as mentioned above again and as you can see from the results, this time it looks reasonable.

Based on the new numbers, I have to put my conclusion a little bit into perspective. It still think the GAE scales reasonably well, but the numbers are not that astonishing anymore.

Playing with Google App Engine

2009-04-13T07:45:00.000+02:00

I'm jumping on the hype wagon and checking out the Google App Engine (GAE) for Java. After writing a simple sample application using Servlets, Groovlets and the JPA, I want to share with you the bumpy ride I had.

If you are interested in checking out the sample application you can either download it or check it out on github.

Fankly, I only had a bumpy ride, because I didn't follow Google's suggestion to use the Eclipse IDE plug-in together with a set of ANT tasks, they provide. Instead I wanted to use IntelliJ and Maven. Another suggestions of Google I didn't follow, is to use Java Data Object (JDO) as a persistence API. Yes, that's right, Google suggests JDO as a preferred way to store data. If you are working on a somewhat up to date Java enterprise application, you are probably using the Java Persistence API (JPA) instead. The difference between the two standards, according to wikipedia, are:

... JPA, however, is an Object-relational mapping (ORM) standard, while JDO is an Object-relational mapping standard and a transparent object persistence standard. JDO, from an API point of view, is agnostic to the technology of the underlying datastore, whereas JPA is being oriented totally around RDBMS datastores.

Google's underlying persistence layer is called Bigtable. It's designed to scale across distributed systems, by being non-relation. That means you can dump your data into Bigtable, without brooding over your schema first. On the question why Google favors JDO over JPA, I think it's because you are not dealing with an RDBMS, but Bigtable.

The first thing I did was to write a simple hello world JSP and Servlet and packaged it as a WAR file. Thanks to IntelliJ's built-in enterprise support, I was up and running in no more than 10 minutes. The only difference to a regular enterprise application is the file appengine-web.xml. It contains your application identifier and version. The versioning schema is quite interesting. You can configure which version a user sees and simultaneously deploy a new version for testing.

Google provides a couple of command-line tools, which help you to start a local version of the app engine and upload your application to the cloud. Once you are online, you can access your server logs through a dashboard. Unfortunately I wasn't able to see the logs instantly, after encountering errors. I had to wait for a couple of seconds, which is pretty annoying and makes local testing much more important.

The first hurdle I had to overcome was integrating JPA. Google uses an implementation called DataNucleus, which relies on post-compile bytecode manipulation of your entities. I had the hardest time integrating the bytecode manipulation with my Maven build. Fortunately, the App Engine Google Group was very helpful and the problem was solved quickly. After a couple of hours, I was able to run my first JPA enabled application, without thinking about deployment or database issues. No problems with getting a server to run or twiddling with database settings - the stuff just runs.

As a developer, your probably don't want be bothered with infrastructure, which sometimes looks like black magic. I really like the completely transparent way of developing for the GAE, but I'm skeptical if I'd want to rely my business on this kind of hosting. With Amazon's EC2 you still have the configuration of the system under control and that's probably important, if you want to run a business on it. In terms of pricing, I can't really say much. To me it looks almost the same, except that with GAE you have a quota on everything. There's even a daily quota on datastore API calls, which can't be increased even by paying for it. That's a bit of a bummer! However, I think they chose the quotas reasonably and maybe the are being increased after the public release of the GAE for Java.

In my next blog post, I will cover some more details on how to run Groovlets. I also did some simple load testing with Apache JMeter to get a feeling on how GAE scales.

The State Pattern

2009-04-06T05:53:00.000+02:00

A couple of weeks ago I had to come up with a design for a state machine at work. Even though a colleague mentioned the State Pattern, I thought it was oversized and being the pragmatic programmer I am, I decided to take the easy turn.

I've never really used the State Pattern before and I have to admit, even after glancing at the UML diagram, I couldn't quite figure out how this is gonna help me solve my problem. In case you are like me and need a little recap on the State Pattern, let's look at the wikipedia summary:

The state pattern is a behavioral software design pattern, also known as the objects for states pattern. This pattern is used in computer programming to represent the state of an object. This is a clean way for an object to partially change its type at runtime.
from wikipedia

Starting from this description, it seemed like there is a hammer, which looks for a nail. Having a concrete state class for each state in my design? I'm going to end up with a truckload full of classes and they all need to be carefully designed and tested.

With this mindset, I went down the switch/case-if/else road and designed the state machine in the most straight forward, but most unmaintainable way possible. Here's an imperative style code sample, which points out how not to implement a state machine:

public void insertCoins() {
  if (state == NO_COINS && numberOfCoins >= MIN_COINS) {
    state = COINS_OK;
  } else if (state == NO_COINS && numberOfCoins < MIN_COINS) {
    state = NO_COINS;
    System.out.println("more coins!");
  } else if (state == SOLD_OUT) {
    state = RETURN_COINS;
  }
}
// more transitions like dispenseFood(), printReceipt() and soldOut()

If you are like me and have never used the State Pattern, you probably think "What is wrong with this code?". The answer is nothing! It's just very imperative and highly unmaintainable. Imagine if you have to add a new state, you will need to adopt every if/else blocks in each transition method. In addition to that, you need to update each test case you wrote.

After reading on the State Pattern in Head First Design Patterns, which explains it very visually, I would change my code above into something like this:

public class NoCoins implements State {
  public void insertCoins() {
    if (numberOfCoins >= MIN_COINS) {
      context.setCoinsOk();
    } else {
      System.out.println("more coins!");
    }
  }
  // more methods defined in State, like dispenseFood()...
}

public class SoldOut implements State {
  public void insertCoins() {
    context.returnCoins();
  }
  // more methods defined in State, like dispenseFood()...
}

Each state gets a concrete class and common functionality can be aggregated in an abstract super class (I used an interface here instead). The member context is the representation of the state machine, which is used by the client to transition between states.

The main advantages of the State Pattern, according to Head First Design Patterns, are:

unlike a procedural state machine, it represents state as a full-blown class
the context object gets its behavior by delegating to the current state object
it allows a context to change its behavior as the state of the context changes

My state machine implementation was pretty simple, so I couldn't see any downside using the imperative approach. However, trying to test the beast ended up to be much more complicated than the implementation itself. A colleague pointed out the design smell (thanks Alexander).

With the State Pattern, each state is represented by a class, it can be tested in isolation. I think that is one of the most compelling advantages. It outweighs the argument, that you have much more classes than with an imperative approach.

I really enjoyed reading up on the State Pattern in Head First Design Patterns. Each comes with a visually rich example, giving you everything, needed to use it in your code. It even compares a procedural/imparative implementation of a state machine with the much more improved version using the State Pattern. I find that one of the most effective ways to learn.

JDK 7 Language Changes are Coined

2009-03-27T07:02:00.001+01:00

Joe Darcy has posted a blog post on the status of project coin. According to Joe there are six proposals for small language changes, which are shortlisted by Sun. I put together an overview with some code samples.

1. Strings in switch by Joe Darcy

String s = ...
switch(s) {
  case "foo":
    processFoo(s);
    break;
}

I really have no feelings about this change whatsoever! It's not a pain for me that it doesn't work right now and I think I won't need it if it's gonna be in JDK 7.

2. Improved Exception Handling for Java by Neal Gafter

try {
    doWork(file);
} catch (final IOException|SQLException ex) {
    logger.log(ex);
    throw ex;
}

I wrote about how great it would be to have this feature as part of closures. As we all know, sadly, there won't be any closures in JDK 7, however I'm really glad that this part is considered to be in.

3. Automatic Resource Management by Josh Bloch

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
  return br.readLine();
}

As with catching multiple Exceptions at the same time, this is a language change that I would welcome with open arms! On the mailing-list of project coin this proposal caused the most vibrant discussions. Josh Bloch was very open about any type of feedback, even when someone suggested a modifier for cleaning up resources instead of the try statement. That made following the discussion very interesting.

4. Improved Type Inference for Generic Instance Creation by Jeremy Manson

Map<String, List<String>> anagrams = new HashMap<>();

I asked for this in a blog post almost a year ago and it seems as if I have been finally heard. The first thing you might ask when you see this, is why Jeremy Manson proposes new HashMap<>() instead of new HashMap(). In his very well worked out proposal, he indicates, it's a matter of backward compatibility. However, he also mentions it is not impossible to remove the arrow brackets in future versions.

5. Elvis and Other Null-Safe Operators written by Neal Gafter and submitted by Stephen Colebourne

String s = mayBeNull?.toString() ?: "null";
Integer ival = ...;  // may be null
int i = ival ?: -1;  // no NPE from unboxing

The operator ?: is called Elvis, because the question mark looks like the Elvis smiley, as I've learned from the Java Posse mailing-list yesterday. Jokes apart, I like this proposal the more I look at it. However, I've never had problems with adding null checks to my code and I'm not sure if the NPE problem would be solved better with annotations. JSR 303 - Bean Validation, provides a @NotNull annotation, which can be used to define your intend to prevent Null from being passed to your method. I tend to think the language level approach is not suitable here.

6. Simplified Varargs Method Invocation by Bob Lee

Before:

static <T> List<T> asList(T... elements) { ... }
static List<Callable<String>> stringFactories() {
  Callable<String> a, b, c;
    ...
  *// Warning: **"uses unchecked or unsafe operations"*
  return asList(a, b, c);
}

After:

*// Warning: **"enables unsafe generic array creation"*
static <T> List<T> asList(T... elements) { ... }
static List<Callable<String>> stringFactories() {
  Callable<String> a, b, c;
  ...
  return asList(a, b, c);
}

This proposal simply moves the warnings from the invocation of the generified method to the declaration. I know this warning is annoying and it would reduce the number of warnings in your code base, but for me, this has never been a real pain so far.

The project coin mailing-list was flooded with proposals, so if you wonder why Sun chose the afore mentioned here's why:

Sun believes that the proposals are small enough, have favorable estimated reward to effort ratios, and advance the stated criteria of making things programmers do everyday easier or supporting platform changes in JDK 7.

You can really tell that Sun is on a schedule and that there is not a lot of time to gather more ideas. In fact Joe asks in his blog post to continue work on the before mentioned proposals, in the form of prototypes and refinements, instead of sending in new ones.

I've been on the project coin mailing-list since day one and I have to commend Joe on how he is "handling" the list. No offense, but some of the folks sending in proposals should really try to get some writing lessons. My English is not perfect and trying to communicate something subtle as a language change is really hard, but some folks are just not able to produce proper English sentences. Joe did a pretty good job in keeping people like that on a short leash.

The shortlisted proposals almost match with the winners of the poll I conducted a couple of months ago. I think in general they are gonna be very welcome by a broad range of developers. However, the implementation of those proposals is a whole different story. Next week we will know more.

JUG-Ka Stammtisch 3.0

2009-03-23T07:01:00.000+01:00

Version 3.0 of the Java Users Group Karlsruhe Stammtisch is being release this coming Thursday 26th of March. This time we are going to meet directly in the pub Litfass, which is near Marktplatz, at 20:00 to get a good sip of Java. For further information check out the Google Group or drop me an email.

Final or Not Final?

2009-03-19T06:53:00.000+01:00

I recently implemented an extension to Spring's HsqlSequenceMaxValueIncrementer. When I digged into the Spring source code of HsqlSequenceMaxValueIncrementer and its ancestors, I noticed something astonishing: almost all methods are public or at least protected and there is not one final class or field. Everything is extensible and somewhat accessible.

Let's take a look at AbstractSequenceMaxValueIncrementer, one of the parent classes of HsqlSequenceMaxValueIncrementer:


public abstract class AbstractDataFieldMaxValueIncrementer implements DataFieldMaxValueIncrementer, InitializingBean {
	private DataSource dataSource;
	private String incrementerName;

	public AbstractDataFieldMaxValueIncrementer() {
	}

	public AbstractDataFieldMaxValueIncrementer(DataSource dataSource, String incrementerName) {
		Assert.notNull(dataSource, "DataSource must not be null");
		Assert.notNull(incrementerName, "Incrementer name must not be null");
		this.dataSource = dataSource;
		this.incrementerName = incrementerName;
	}

	public void setDataSource(DataSource dataSource) {
		this.dataSource = dataSource;
	}

	public DataSource getDataSource() {
		return this.dataSource;
	}

	public void setIncrementerName(String incrementerName) {
		this.incrementerName = incrementerName;
	}

	public String getIncrementerName() {
		return this.incrementerName;
	}

	public void afterPropertiesSet() {
		if (this.dataSource == null) {
			throw new IllegalArgumentException("Property 'dataSource' is required");
		}
		if (this.incrementerName == null) {
			throw new IllegalArgumentException("Property 'incrementerName' is required");
		}
	}

	public int nextIntValue() throws DataAccessException {
		return (int) getNextKey();
	}

	public long nextLongValue() throws DataAccessException {
		return getNextKey();
	}

	public String nextStringValue() throws DataAccessException {
		// removed implementation for brevity 
	}

	protected abstract long getNextKey();
}

Since I was extending the framework, the degree of flexibility was great for me. All I had to do was override a few methods to plug in my code and that's it.

If everything is accessible, the way it is in case of AbstractDataFieldMaxValueIncrementer, users can do almost everything they want with the classes you published. They can override all the methods and subclass each and every class. As shown above, that was obviously intended. The class wouldn't be abstract and have public/protected methods if it wasn't intended to be subclassed.

After reading the book Practical API Design, which preaches backward compatibility, I wonder how you would be able to evolve such a class? Let's say you wanted to extend the meaning of the field incrementerName. It should convey more information than simply the name of the sequence. Therefore you'd create a class IncrementerName, which replaced the String field. With this simple change, you'd break all the clients relying on the field incrementerName. I know this example might seem far-fetched, but I think you get the idea.

Another thing that caught my eye, when looking at AbstractDataFieldMaxValueIncrementer, is the field dataSource. It is basically a public field and I'm not quite sure why. Is it really necessary to replace the DataSource after you initialized the bean? Do you really want everyone to screw with the DataSource?

If it was for me, I would have answered those questions with a plain "No!". Why not implement AbstractDataFieldMaxValueIncrementer as follows:


public abstract class AbstractDataFieldMaxValueIncrementer implements DataFieldMaxValueIncrementer {
	private final DataSource dataSource;
	private final String incrementerName;

	public AbstractDataFieldMaxValueIncrementer(DataSource dataSource, String incrementerName) {
		Assert.notNull(dataSource, "DataSource must not be null");
		Assert.notNull(incrementerName, "Incrementer name must not be null");
		this.dataSource = dataSource;
		this.incrementerName = incrementerName;
	}

	protected DataSource getDataSource() {
		return this.dataSource;
	}

	public String getIncrementerName() {
		return this.incrementerName;
	}

	public int nextIntValue() throws DataAccessException {
		return (int) getNextKey();
	}

	public long nextLongValue() throws DataAccessException {
		return getNextKey();
	}

	public String nextStringValue() throws DataAccessException {
		// removed implementation for brevity 
	}

	protected abstract long getNextKey();
}

I think this would not restrict the use of the class, except that you have to use constructor injection, but that's a different story. It would, however, restrict the use of the fields dataSource and incrementerName. I think those fields should be immutable anyways, since I cannot think of a reason why you would want to change them during the life-cycle of the object. I know dataSource isn't truly immutable, but the access is limited to subclasses, which should confine the wrong usage.

That leaves me with the question, why the authors of AbstractDataFieldMaxValueIncrementer didn't go that route? I think it's simply a design decision of Spring authors, to be as open and extensible as possible. They have InitializingBean and @Required to enforce necessary dependencies, which work quite well. I guess they push the responsibility of handling immutables with care to the developer, which is reasonable, but in my opinion rather risky. I think using final in such cases is an easy way to remove unnecessary sources of errors.

I'm not quite sure which approach is the best here. Does it all boil down to "it depends"? Or is all a matter of taste? I don't think so. In my day to day coding, I tend to consciously follow the advices of Effective Java, which favors immutability and limiting accessibility. However, looking at Spring's source code is a truly inspiring. They are doing a phenomenal job of keeping it stable, considering how open and extensible their classes are.

Manifesto for Software Craftmanship

2009-03-16T07:29:00.000+01:00

Go and sign up yourself! Support our craft and help to make better software!

Heiko W. Rupp @ JUG-Ka

2009-03-09T07:14:00.000+01:00

Heiko W. Rupp of Red Hat (author of the first German JBoss book) is going to talk about "System management with RHQ and JBoss ON 2" at the Java Users Group Karlsruhe this coming Wednesday. The JBoss Operations Network (ON) management platform is a centralized system for managing the JBoss middleware.

The talk starts at 7:15pm and takes place at University of Karlsruhe. Get the latest updates of the JUG-Ka at our Google Group or sign up for XING.

Book Review: Practical API Design

2009-03-02T06:14:00.000+01:00

Apress was kind enough to pass me a copy of this book, which I agreed to review in return.

Practical API Design: Confessions of a Java Framework Architect is the book I've always been waiting for. Jaroslav Tulach, the founder and architect of NetBeans, created a highly recommend read for everyone in charge of developing APIs.

But even if it's not your job to define interfaces, you are somewhat alway on the other side consuming them and it's good to know what drives evolution of the APIs you work with.

The book consists of 3 parts:

Part 1 is called "Theory and Justification". It defines the terminology and background which gives you the necessary foundation to explain and justify API design.

Let me give you and example: Have you ever had problems explaining your design to a colleague? You couldn't find the right words to reasonably highlight your decision, but you know it was right? The only justification was your intuition and the feeling that your design was the right choice. Does that sound familiar?

That's where Part 1 of this book comes in and tries to give you a tool to justify and even measure the quality of your design decisions: Selective Cluelessness. It's a principle which is based on the assumption that you can achieve more by knowing less:

"The more good APIs we have, the bigger the systems we'll be able to build without understanding all their details."

"Practical Design" is Part 2 and basically puts the theory highlighted in the first part to practice. Using Java, the author provides a set of what he calls API design patterns. They are design patterns in the traditional sense, but with a focus on evolution. Most of them accompanied by an examples the NetBeans APIs. It doesn't matter if you are not familiar with NetBeans. Due to the author's years of experience with NetBeans, he does a great job explaining the problems it was facing and how they came with a solution, which evolved into an API design pattern.

..., it's slightly more complicated to design a universe than building a house. As a result, we need an enhanced version of the design patters. We need patterns that help us building a "universe".

Part 3 of the book, "Daily Life", is a collection of advices on how to bugfix, evolve and maintain an API. The author points out how important versioning is and how NetBeans solves such a problem. He highlights the importance of compatibility and how to keep the promises to the users of your APIs.

The theory and initial design are just the tip of the iceberg. The rest is the real work.

I'm really glad I read this book, although it took me quite a while. The reason is not the 365 pages. It was all the moments I had during reading it. So many times I was reminded of mistakes I made in APIs I previously designed. I often pondered on whether a solution suggested in the book was better than the one I came up with. I think that's what makes a book interesting, if it makes you think and critically review your own solutions.

I enjoyed taking the journey through the API universe and learning how to design an API in a selective cluelessness way. As for the reasons why you should read this book:

... when you understand the API world, its needs and its laws of evolution, you can shape it into a form containing all that the creators of the oldest and most perfect science always searched for - beauty, truth and elegance. A properly API universe ain't a bad place to be.

JUG-Ka Stammtisch 2.0

2009-02-23T06:12:00.000+01:00

The second Stammtisch of Java Users Group Karlsruhe will be held on Thursday 26th of February. We will meet up at Marktplatz around 8pm to find a suitable location. If you'd like to join the geek chat about Java, check out the Google Group for further details or drop me an email.

NOTE: Over the next few weeks, I'm moving my feed from feedburner back to blogspot so please subscribe to http://dlinsin.blogspot.com/feeds/posts/default/ instead!

An Aspect is Part of Your Implementation

2009-02-18T06:10:00.000+01:00

When implementing parts of your application with AOP, you are magically applying additional behavior to your code. Although technically cool and in terms of reusability great, it might lead to a maintenance nightmare.

Think of an API, let's call it CustomerService. It defines CRUD methods to load and save Customer instances from some backend service. It might define methods like the following:

/**
 * blah
 *
 * @throws CustomerServiceException with following causes:
 *    - IllegalArgumentException if anything is wrong with the passed Customer instance
 *    - NullPointerException if anything is wrong with a collaborator
 *    - FancyPersistenceException if anything is wrong your persistence service
 */
public Customer save(Customer argToSave) throws CustomerServiceException;

Note the standard Javadocs, which define precisely the causes of a CustomerServiceException, which the client of this API can expect. These defined causes as well as the CustomerServiceException are part of the contract defined by the interface. Clients can program against those causes e.g. display different error messages or inform another system.

An implementation of this interface might look as the following:


@Override
public Customer save(Customer argToSave) throws CustomerServiceException {
  try {
    // do some fancy stuff
  } catch (IllegalArgumentException e) {
    
    // do some logging here
    throw new CustomerServiceException(e);  
  
  } catch (NullPointerException e) {
    
    // this is programming error
    throw new CustomerServiceException(e, "Dude where's your head?");  
  
  } catch (FancyPersistenceException e) {
    
    // you might want to do some transaction handling stuff here
    throw new CustomerServiceException(e);  
  
  } catch (Exception e) {
    throw new CustomerServiceException();  
  }
}

This is pretty ugly isn't it? Especially because of the verbose Exception handling. However it's complying with the contract and a valid implementation.

In my current project we followed this pattern in every service class throughout the application. This works fine and provides a lot of consistency for clients of those APIs. However making a commitment like this requires not only a lot of discipline, when implementing those contracts, but also a lot of test code. You have to make sure that each implementation complies with the contracts promised in its interface.

A new member of the team immediately pointed out the drawbacks of our approach: a lot of test code to maintain, a lot of verbose Exception handling polluting the implementation methods and no centralized way to manage the same recurring code. His idea was to use AOP. You can refactor the Exception handling into an Aspect and thus get rid of all the drawbacks mentioned before.

The implementation of the CustomerService interface boils down to the following:


@Override
public Customer save(Customer argToSave) throws CustomerServiceException {
     // do some fancy stuff
}

For a moment this might look like a perfect solution. The ugly technical Exception handling is gone and we are left with the code that actually gets the job done. That makes reading the code so much easier and don't think I'm the only fan of that.

Despite of all the drawbacks we go rid of, we silently introduced new ones. The fact that the implementation doesn't contain any hard reference to those Exceptions we claim to throw in the interface, makes understanding the implementation of the contract a lot harder. Not to mention the code for the Exception handling itself. Another drawback is refactoring the interface. Imagine someone unfamiliar with the code has to change one of the Exception causes. It is merely impossible to understand what's going on.

You have to consider the Aspect containing the logic to handle the Exception as of your implementation. Without it your implementation doesn't comply with the contract.

So what to do now? We have a great solution, which relieves us from all the drawbacks but brings along another bag of drawbacks. Should we gauge which drawbacks are easier to deal with? I remembered a solution I read in Applying UML and Patterns, which suggests a Singleton based centralized error handling. So I came up with the following solution:


public final class ExceptionHandler {
  // private constructor
  public static final <T extends BaseException> transform(Exception argCause, Class<T> argType) {
    try {
      if (argType.isAssignableFrom(argCause.getClass())) {
        return (T) argCause;
      } else if (argCause instanceof NullPointerException) {
        return argType.getConstructor(Throwable.class, String.class).newInstance(argCause,"Dude where's your head?");
      } else if (argCause instanceof FancyPersistenceException) {
        return argType.getConstructor(Throwable.class).newInstance(argCause);
      } else {
        return argType.getConstructor(Throwable.class, String.class).newInstance(argCause,"Unkown!");
      }     
   } catch (Exception e) {/** do some reflection error handling **/}
  }
}

The implementation of the CustomeService interface using the centralized ExceptionHandler looks like this:


@Override
public Customer save(Customer argToSave) throws CustomerServiceException {
  try {
     // do some fancy stuff
  } catch (Exception e) {
    throw ExceptionHandler.transform(e, CustomerServiceException.class);  
  }
}

I believe this is a great trade-off. You have a single point in your code responsible for handling Exceptions. It's easy to test in isolation, which means the test code for your services decrease. The overhead in your service methods is minimal. You have to implement a try-catch block, but I think that's reasonable considering the benefits of this approach.

However, I think the biggest advantage of this solution is the fact that it works without any framework magic whatsoever. It's just plain old Java!

NOTE: Over the next few weeks, I'm moving my feed from feedburner back to blogspot so please subscribe to http://dlinsin.blogspot.com/feeds/posts/default/ instead!

Spring Integration in 10 minutes

2009-02-16T05:16:00.000+01:00

SpringSource's Mark Fisher posted a tutorial on Spring Integration a couple of days ago. I followed the tutorial step-by-step and thought I'd share my IDEA project with you. I also added a maven POM file so you can also import it into Eclipse or use the command line.

NOTE: Over the next few weeks, I'm moving my feed from feedburner back to blogspot so please subscribe to http://dlinsin.blogspot.com/feeds/posts/default/ instead!

Heinz Kabutz @ JUG-Ka

2009-02-10T06:45:00.000+01:00

Im really excited about this Wednesday's meeting of the Java Users Group Karlsruhe. Dr Heinz Kabutz is giving a to talk on "The Secrets of Concurrency".

You might know the The Java(tm) Specialists' Newsletter, which is most famous for a series of laws, explaining how to best write concurrent code in Java. Heinz is the mastermind behind those laws and the newsletter.

The talk takes place at University of Karlsruhe and it starts at 7:15pm. Sign up for our Google Group or join us on XING to get the latest updates on what's happing at the Java Users Group Karlsruhe.

NOTE: Over the next few weeks, I'm moving my feed from feedburner back to blogspot so please subscribe to http://dlinsin.blogspot.com/feeds/posts/default/ instead!

Got Burned, Changing my feed!!

2009-02-09T06:03:00.000+01:00

My current feed is run by FeedBurner. That means most of you are getting this feed from http://feeds.feedburner.com/dlinsin and thanks to FeedBurner you see stuff like "Digg This!" or "Submit to Reddit" at the bottom of each post.

FeedBurner was acquired by Google and is moving all accounts to Google Adsense by the end of this month. Since Google doesn't want me to use Adsense, I can only switch back to my old feed. So if you want to keep reading my stuff, simply switch to http://dlinsin.blogspot.com/feeds/posts/default/. However, the FeedBurner feed will still be alive for the next couple of weeks.

Do You Write Unit Tests For Yourself?

2009-02-02T06:04:00.000+01:00

A couple of days ago I listened to the stackoverflow podcast with Jeff Atwood and Joel Spolsky. They were talking about when it is appropriate to write unit tests for your code.

Joel:

"Changing a parameter in some function call from 37 to a 9 is not really gonna fail or introduce a bug"
"It's great if you use TDD for your encryption library or compiler, but that's a very finite number of apps that are like that"
"For a team of good programmers the prescriptions are probably gonna be different than from a team of mediocre programmers"

Jeff:

"With stackoverflow there are very few cases where I feel like: okay I'm gonna sit down and write a unit test and this is gonna result in a measurably better experience."

Of course I cannot quote the whole discussion here, so this might sound very harsh on testing for you. Jeff kind of put their statements into perspective by saying that he is pro testing, but just doesn't do it on stackoverflow. However, I still have this feeling that they turned their backs on unit testing too easily.

First off, let me tell you that I love unit tests. I write a lot of them and I care about code coverage quite a bit. You might even say that I am a little religious or dogmatic about it. I only have good experience with unit testing, so I tend to believe that I am not that far off. On my current project we are about 8 people working on our code base, so you can imagine there is a lot going on. It's easy to break something and believe me we are breaking stuff all the time. Although each developer has his domain, you are constantly working with code that was not written by yourself.

Fortunately our test coverage is pretty good. In case a test fails and something seems to be broken, you are being notified by the continuous integration server. Personally that gives me the confidence to do refactorings and changes without the fear of introducing major bugs. The biggest downside, which was also mentioned by Joel, is the "bang for the bucks". You need a big investment to get to this degree of test coverage. You really need to gauge, whether it's worth the time invested to write a unit test for a piece of code.

As mentioned before there is a lot of stuff breaking during development of new features. This is mainly due to not knowing all of the code base. However, I think working with other developers, you are bound to have unit tests. At least for the parts of your code that might be extended or maintained by others. It is worth to invest in a unit test, if you want to make life easier for your fellow developers. At least they can change your code with confidence. You are basically giving them a guideline, which helps to get their work done faster and more reliable. In the long run, I think that will increase the quality of your application and hopefully leaves an impression of your code on your fellow team members.

So what if you are working on a small team or almost alone on your project? Do you still need unit tests? That's when I want to come back to the discussion Joel and Jeff had. The stackoverflow team is quite small. I think Jeff probably thinks, that if you are working alone on a project it might not be worth the investment to write unit tests.

I kind of disagree, because I've been there myself. As the only developer of an application and working on various features at the same time, I found myself breaking my own features over and over again. I started writing unit tests and setup a continuous integration server, which helped me automate my builds and improved quality dramatically. By the time a second developer started working on the project the test coverage was reasonable enough, so he could change my code without the fear of breaking anything.

Maybe I'm just not that good of a developer and I need to write unit tests for myself. However, I do think it's worth the investment, because sooner or later another developer will have to work with your code. Go and make his life a little easier and provide some unit tests.

Java 7 Language Changes Poll Results

2009-01-23T06:07:00.000+01:00

Inspired by Stephen Colebourne's whiteboard initiative at Devoxx, I started a similar poll on new Java language feature about a month ago. I sent an invite to the local JUG and posted it on DZone.

I'm really surprised, that over 200 fellow developers participated! Thanks to everyone for voting!

Now let's check out the results. First of all I gave you the choice to let me know how you found this poll.

There were 80 votes submitted through my blog and about 50% of all submissions came through various other channels like DZone or Alex Miller's Java 7 blog. I'm a little disappointed about the participation of our JUG. Only 22 people voted, although there are about 173 members signed up in our Google Group.

Unfortunately about 10% of the votes are invalid. Maybe I should have put the instructions on the blog post directly instead of using Stephen's presentation. However, there are 181 correct votes and those are used in the following charts:

1. Map for-each

2. For-each iteration control

3. List / Map access

4. Infer generics in declarations

5. Multi-catch of Exceptions

6. String Switch

7. String interpolation

8. Multi-line Strings

9. Resource Management

10. Null-handling

It looks like most people wanna see an improved Null handling (change no 10) in the coming Java 7 release. The improved List/Map access (change no 3) on the other hand is something that almost all the correct voters oppose. If you are interested in the cleansed results, I published as a separate website.

I thought a lot about how I should interpret these votes. Frankly, I'm a little surprised about the results. I didn't think that so many fellow developers would like to see an improved Null handling. However, the votes at Devoxx indicated the same and I do admit Null handling can be a huge PITA. What I am kind of shocked about is the huge resistance to closures-related features like resource management (change no 9) or Map for-each (change no 1). Maybe this indicates that a lot of developers are not yet ready for closures in Java. After all, it might have been a reasonable decision of Sun to drop closures - for now.

So, what am I gonna do with those votes? Well, I'll email them to Joe Darcy and hope Sun will include your votes into their decision-making process. I know these votes only speak for a very small fraction of the Java community, but I think every vote counts.

Thanks again everyone for voting!

JUG-Ka Stammtisch(BETA)

2009-01-13T07:06:00.000+01:00

This coming Thursday at 7pm, the Java Users Group Karlsruhe will meet up for beer and chatting about Java at Marktplatz. If you'd like to join, check out the Google Group for further details or drop me an email.