This week, I spent some time on an update to Beat The Joker slots, the first app I developed.  This app has been quite successful, with over 400,000 downloads to date, but it was developed at a time when there was only one version of Android to worry about (1.0) and one device available (the T-Mobile G1 and it’s developer-only variant).  Knowing that, I originally developed an app that depended on having a 480×320 screen.

As more devices popped up, the Android team introduced a scheme for handling different screen sizes and densities in Android 1.6, and they also provided some quick and dirty compatibility scheme to scale apps that weren’t designed with screen adaptability in mind.  Beat The Joker was my first experience with the Android SDK, and the code is pretty ugly, so I used that compatibility scheme for some time rather than diving back into my own mess.  The game has remained playable, but its layout has been less than ideal.

I had several goals for this release.  I wanted to update the Admob library to the latest latest, which will let Admob fill unused space with Adsense ads, hopefully increasing my revenue a little bit.  I wanted to use a more proper layout scheme so that I can make use of wide screens, moving ads out of the playing area and into empty space where possible.  I also wanted to clean up the code a bit in case I decide to integrate this in a future, more-ambitious casino app.

I’ve managed to accomplish these goals, with the help of a few coding rules of thumb:

• Don’t use AbsoluteLayout.  If you must specify pixel-perfect locations, use margins in FrameLayout or RelativeLayout, but still specify elements positions relative to each other as much as possible.
• Use dp (density-independent pixels) instead of px (hardware pixels) in layout files.  Density-independent pixels correspond to 1/160 of an inch.  It’s not exactly that, because devices with slightly different densities are grouped into the same family, but it’s much better than not scaling at all.
• Always try to specify view positions in XML rather than in Java code.  Converting Java values to density-independent pixels uglies up the code, and it’s harder to track down what value changes what position.

Beat The Joker still has a ways to go to be fully modernized.  The biggest issue now is having only one set of  graphics to work with for all screen densities, so the game doesn’t looked as good on high-density screens as it could.  I’ll have to get my designer to create images at different scales in order to address that.