Hopefully this information is helpful to anyone looking to start Android development.

Getting started

Android is the first mobile platform I've developed for and getting started was a lot easier than I expected it to be. I've been using Ubuntu Linux, running Eclipse with the ADT Plugin and testing on an HTC Evo 4G as well as several emulators.

The Android emulators, in my experience, perform terribly when testing games. Despite this, they are very useful when testing a game for various screen resolutions. A Motorola Xoom emulator helped me fix an issue in one of my games which a Xoom user had notified me of via Twitter.

The online Android documentation is excellent and plenty of tutorials for specific concepts can be found via a quick trip to Google.

Graphics and Audio

As I'd decided to create games, graphical and audio resources were an important part of my applications. To keep production costs down, I created the majority of graphics used in my games myself using the open-source vector editor, Inkscape. I'll never be an artist, but being able to drag together a few coloured shapes in Inkscape was all I really needed.

To support an assortment of devices and screen resolutions, Android is capable of scaling graphic assets used in your application. I was never happy with the results of scaling and I recommend taking the time to create resolution-specific graphics for your applications. This is really well documented.

While I could handle simple graphics, creating audio effects was completely outside of my abilities and so I made the decision to purchase audio from a professional studio. I went with Soundrangers, who are a little more expensive than some other options I'd considered, but have an extensive and well indexed library.

Audio purchases contributed the most to my production costs, as I'll show in the cost / revenue chart.

Installations and Retention

These figures show total installations and the number of users who still have the game installed. I did some research and my retention figures seem to be about average.

Cost and Revenue

This is the amount of money I spent producing each game, and the amount of money each game made. I tried both selling a game, then later releasing free games with advertising by AdMob.

The cost of my first game, Submarine, is only the one-time $25 fee required to create an Android Marketplace account. The rest of the money I spent was only on sound effects for my other games.

Submarine was originally released as a paid application, but was later made free. Radius and Arcade Fishing were released as free applications with advertising. Rock Slots was released for free with no advertising.

Advertisement Stats

These are some more detailed advertisement stats from AdMob, for anyone who might be interested in ad performance.

Being Found in the Android Marketplace

Early in 2011, having an application discovered in the Android Marketplace was fairly easy thanks to the “Just In” list. All new and updated applications would appear in this list for a short time and I consistently saw spikes in installations after every update I released.

Unfortunately, this section of the Marketplace was removed sometime around the middle of the year, almost certainly due to abuse from low quality developers who would release minor updates in order to push their applications to the top of the list.

I can't tell for certain, but I think it's safe to attribute the majority of the installations Arcade Fishing received to the Marketplace search function. Fishing games have proven popular on mobile devices, so it's likely that a steady stream of “fishing” searches delivered users to my game.

Marketplace Users, Ratings and Comments

Once you publish an application in the Android Marketplace, users have the opportunity to rate it and leave reviews for other users to read. This is great for all potential users, especially when paid applications are involved, but the current design of the commenting system leads to my biggest problem with the Marketplace; there is no way to communicate with the users.

In the Marketplace, it is impossible for a developer to see the real identity or contact information for any user who comments on their applications. I agree with Google's decision here, but there's a problem when users are under the impression they can receive support from an application developer by leaving a comment in the Marketplace.

Despite a support email address being provided on an application's page, users often ask questions, ask for help and complain about missing features they simply aren't using correctly in Marketplace comments. Their comments go unanswered and the user assumes they are being ignored.

This isn't the fault of the users. They've learned, through blogs, forums, Facebook and Twitter, that the Internet is a medium for discussion with the people who provide their tools, services and entertainment. I'm sure many users see the Marketplace and an extension of this and, very reasonably, expect it to work the same way.

This is something I really hope Google will address, perhaps by including an "allow this developer to contact me" checkbox to the comment submission form.

That said, there are also some great comments. These are my favourites so far:

"Great Indie game. Wonderful idea" - Jãnis, about Radius.

"SGAce CM7 Great idea really well implemented. Easy to learn and just the right amount of frustration. Would play again." - Richard, about Radius.

It's worth pointing out here that Richard started his review with the make and models of his phone, as well as the custom ROM is he using. "SGAce CM7" tells me he is using a Samsung Galaxy Ace running CyanogenMod 7. There are many variations of Android devices out there, so it's helpful when users report which devices an application either works or doesn't work with.

Future Development

I am not actively developing any Android games at the moment, but I intend to release more at some point in the future. I'd really like to bring an original point-and-click adventure game to Android eventually.

I wanted to do something interesting with the data I had, and generating some kind of image sounded like a fun idea.

I started by writing some PHP code to accept a range of X / Y points and use the GD library to plot them on a blank image. If the same pair of points appeared more than once, the plotted point would increase in size. This way, the size of a point would indicate how much time was spent there.

Once the basic point plotter was working, I wrote some additional code to parse the KML files and interpret the GPS coordinates as points. I fed in the data from Florida and got this image back:

Pretty cool. The large point is the rented accommodation and the pockets of points are theme parks.

I put the code up on GitHub. Feel free to experiment with it.

* Except for when GPSLogger just stopped working for no reason.

Where other services include an address, phone number, map and possibly a few customer reviews, ours would function as a mini-website that could be tailored to any business type.

I spent a couple of weeks looking at existing business directories and websites business owners had set up for themselves to figure out how I would combine the functionality of both into one package.

We spoke to a few business owners as well as some ordinary people who were just frustrated with existing big-name business directories. We received mostly positive responses and that was enough for us to push forward with the project.

After a few weeks of coding, I had a system that functioned like a regular business directory, but with a unique feature. Industry specific components, which I called "modules," could be installed into a business listing to display information specific to that particular industry.

If you owned a car dealership, you could install the car dealer module and be displaying your vehicle listings on your listing in minutes. If you had a hotel, there was a module to display available hotel rooms. I also built modules for general retail merchandise, restaurant menus, events, coupons and more. Anything that I had seen business websites displaying online had the potential to become a module in our business directory.

Each module would ask the user to fill in some predetermined fields and that data would be formatted and displayed to anyone visiting their listing in the directory.

While the directory was really cool from a programming perspective, it was, unfortunately, a commercial failure.

After pitching to local businesses, it become obvious that the features I had thought were useful were either too complicated for our target audience or offered more functionality than they needed. Despite the original idea receiving positive feedback, it just didn't work in practice.

Lessons Learned

Don't over-complicate

I got caught up in creating cool features that were a little too complicated for our target audience. Even people I'm related to still don't really know what the business did.

Launch early

I didn't launch the website until it was almost entirely complete. If I had launched earlier with a cut down version, I could have better judged the response and either moved on to another project or taken a different direction. I'm almost certain that launching much earlier would have enabled me to predict the failure of the project.

Do create something just because you think it's cool, but don't try to make a living off it

You definitely shouldn't avoid a programming project simply because you're the only person interested in it. Even if it doesn't become a sustainable business, it'll still be fun and you'll learn something from it.

These are a few tweaks I normally make after setting up a Linux desktop. Gnome ships with a handy configuration editor, which can be accessed via the terminal command gconf-editor.

List-View by Default

Nautilus, Gnome's file manager, displays files as large icons by default. That's difficult to work with, but can be easily changed with the configuration editor.

Applications can be found in the configuration editor's tree-style navigation pane. To tweak the file manager, browse to apps/nautilus/preferences. Find the option named "default_folder_view" [view screenshot] in the key pane and change it's value to "list_view." The file manager will be configured to display a list of files by default.

Editing Executable Files

When you attempt to open an executable file, otherwise known as a script, you'll be asked if you want to edit or execute the script. I spend a lot of time editing scripts, so prefer to have Nautilus open the file in the text editor by default.

This option can be found in the configuration editor under apps/nautilus/preferences. The option is named "executable_text_activation" [view screenshot] and there are three possible values; "launch," "ask," and "display." Enter "display" to have scripts open in the text editor.

Make Gnome Faster

You can speed Gnome up by turning off animations and non-essential display features such as redrawing windows as you drag them around your desktop.

This time you will be editing the window manager, Metacity. Find the configuration options under apps/metacity/general.

To speed up Gnome, just check the "reduced_resources" option [view screenshot].

Fix the Window Button Positions

For years the standard in designing window decoration has been to place the minimize, maximize and close buttons in the same place. It doesn't make sense to group the close button in with minimize and maximize, but there is a very easy way to fix it.

In the configuration editor, under apps/metacity/general, find the option named "button_layout" [view screenshot] and note the option value. It will look something like this:

menu:minimize,maximize,close

Everything on the left of the colon appears on the left of the window decoration, everything on the right appears on the right.

I recommend experimenting to find a configuration that works for you. I prefer this:

close,menu:minimize,maximize

Just for fun I've written a small PHP class to allow PHP applications to interface with the Nabaztag API.

Get the code on GitHub.

The example script demonstrates all the functionality, but for quick reference:

Create a new nabaztag object:
$nab = new Nabaztag($your_serial_number, $your_api_token);

Speak using text-to-speech:
$nab->speak("that rabbit's got a vicious streak a mile wide");

Move ears:
$nab->moveEars($left_ear_position, $right_ear_position);
Provide an integer between 0 and 16 to move the ears through their cycle.

Wake up or put to sleep:
$nab->setWakeStatus($status);
Passing a 1 to this function wakes the Nabaztag, 0 puts it to sleep.

The Nabaztag API will send a response to acknowlege a successful request or point out any errors made. The response is stored in the class and can be accessed via this function:
$nab->getLastApiResponse();

There is another diagnostic function that will list the parameters being send in an API request:
$nab->getApiParams();

Update: The company behind Nabaztag discontinued their website and API support in July of 2011. There is still an active community managing the API at the original domain, but full functionality hasn't yet been restored.

What I found really interesting about Dvorak is the way common keystrokes are designed to flow from the outside to the middle of the keyboard. It allows for a very natural hand movement similar to idly tapping on a table.

I made the change to Dvorak on my laptop because the keyboard I have for my desktop has curved keys that don't lend themselves well to rearrangement. My laptop, an older Toshiba Satellite A135-S2276, has a keyboard that can be easily rearranged to Dvorak. I run Ubuntu Linux and changing the keyboard layout on the software side was no trouble at all. In GNOME, the layout dialog can be found in the System menu, under Preferences and Keyboard. Google will turn up instructions for other operating systems.

I've been touch-typing QWERTY for many years and there was a significant learning curve with Dvorak. After a week, however, I really could see how it would be more comfortable for typing long sentences. Typing emails was fine, but typing PHP code, something I spend most of my time doing, wasn't as easy.

Writing code uses a lot of punctuation symbols and with all the punctuation keys in new positions, the flow I previously had while programming was gone. Mistyping and having to locate keys was damaging my productivity.

I found Dvorak difficult for programming because it was designed to making typing sentences easier. The punctuation keys I need to use often have been pushed off into awkward places to make way for letters, making the chances of reducing my risk of RSI little to none.

I switched back to QWERTY and have been happily touch-typing since. I like the idea of an alternative keyboard, and Dvorak might be an excellent choice for anybody writing a novel, but I've decided against it for programming.