Nearly 2 years to the day after I submitted this issue with the ‘draw9patch’ tool in the Android SDK to Google, the issue is still open.

I only mention this because it seems the owner of the ticket has changed today.

Way to go, Google.

So my friend Don has been learning iPhone/iPad programming lately, and he decided to implement a pong game to learn how to do game and graphics programming. He’d done this before, years ago in DOS, which makes it a good task to learn the new API.

He kept showing me code… and of course that got me thinking.

So I put together a quick pong demo for Android using AndEngine and the box2d physics engine.

You may now be saying, “But wait! Pong doesn’t need a physics engine!” Yes, yes, you’re right. The world doesn’t need yet another pong game either. But I did want to learn to use box2d anyway, so I’d call this a success.

I just whipped up a little multitouch bug tester program for Android. As noted in my previous post, lots of Android phones running 2.3.7 and earlier have buggy multitouch. In this example, I show the pointers (up to 5) with pointer numbers. You should be able to see at least two, and if the bug is not present, they should work properly. If you have the bug, you’ll notice 1 and 2 swapping back and forth as you touch 1, touch 2, lift 1, then tap 1.

Enjoy. multitouchbugtest.apk

This blog is really starting to seem like a rant about bugs. Today’s is dealing with multitouch on Android. My conclusions:

• Android 3.0+ handles multitouch almost perfectly, and supports multiple pointers. All devices I’ve tested have handled 4 pointers.
• Android 2.x (I’m testing with 2.3.5 and 2.3.7) sometimes works and sometimes doesn’t, it seems to depend on hardware.

I have a Motorola Droid2, some friends have T-Mobile G2’s, and another friend has a HTC Evo something-or-rather. The G2 works fine, but the Droid2 and Evo don’t.

I wrote a test program that tracks two simultaneous touches, and the location of them. In these logs, the pointer number should be the index number of the touch event, where “touch event” is defined as from the time you touch until you release all touches. In Android 3+, it correctly keeps track of up to 4 pointers (on my hardware anyway) correctly, such that the ids of the touches don’t change. These logs are from my Droid2. “left” and “right” are as reported by the X coordinate of the touch event. The boolean is my attempt to detect when we’re in “stupid mode” as I’ve been calling it.

1. I touch left, then tap right on and off:

D/GameView(29118): pointer 0 down false left
D/GameView(29118): pointer 1 down false right
D/GameView(29118): pointer 1 up false right
D/GameView(29118): pointer 1 down false right
D/GameView(29118): pointer 1 up false right
D/GameView(29118): all up false

2. I touch left, touch right, then release and tap the left pointer:

D/GameView(29772): pointer 0 down false left
D/GameView(29772): pointer 1 down false right
D/GameView(29772): pointer 0 up false left
D/GameView(29772): stupid mode enabled
D/GameView(29772): pointer 0 down true right
D/GameView(29772): pointer 1 up true left
D/GameView(29772): pointer 1 down true right
D/GameView(29772): pointer 0 up true left
D/GameView(29772): pointer 0 down true right
D/GameView(29772): pointer 1 up true left
D/GameView(29772): pointer 1 down true right
D/GameView(29772): pointer 0 up true left
D/GameView(29772): all up false

You will notice in #2 there that it gets confused as to which number pointer I’ve been tapping, and it even reports the coordinates of the other pointer in the ‘down’ event. This is “stupid mode” :) Since there are still so many 2.x devices, I now have to work around this somehow. Fun!

I’ve been working on an Android program which uses 2D graphics over the past few days, and since it’s always nice to have sample code to start from, I dug up my old Android starfield simulation.

I wrote this thing back in 2008, not that long after Android first came out, as an introduction to doing 2D graphics. I’ve written starfields before, first in C (and modeX) back in 1996, then in Flash’s ActionScript around 2002.

I just compiled the Android version, and discovered that nothing has changed in the API since 2008 - a very good thing. I did speed up the animation a little and add more stars, since modern phones are a lot faster, and there were odd gaps in the animation.

You can find all of these versions, with source code, right over here. Naturally, all source is copyright (c) me, and released under the Creative Commons by-nc-sa license.

I was reading an article today, a comparison of application life-cycles in Windows Phone 7 and Android, and while the article is for the most part correct, many of the statements are made in a slightly misleading manner. After a bit of pondering, I realized why this is.

Imagine that we have two children, Alice and Bob, who have a bag of 100 LEGO blocks. They’re building small houses.

Logical process

Initially, Alice and Bob each take half of the blocks and build a house. A bit later, Alice decides to rebuild her house with half as many, so now she has 25 blocks in her house, and in a spare pile. No problems so far.

Bob discovers he needs a bit more blocks, so he asks mom to help him out. Mom notices that Alice has 25 spare blocks, so she puts them back into the group pool. Bob then takes another 10 blocks and finishes his house.

A Windows user’s perspective

Okay, let’s restart. Alice and Bob build houses of 50 blocks each, then Bob takes his apart, and rebuilds with 25. He now has 25 in his spare pile.

This is where a Windows user would say to Bob, “Hey! You aren’t using those! Put them back!” Have you noticed this happen? Even though Bob wasn’t using the blocks, they’re still in his pool. But this isn’t a problem, since so far, nobody else has asked for more blocks.

The average Windows user immediately complains when they don’t have “free memory.” But if you think about this, “free memory” is really just “wasted memory” because it’s not in use. Why did you pay for that extra gigabyte anyway?

Android

A common “complaint” about Android, usually from users of other phones is that you can’t close applications in Android. For the most part, this is correct, there’s no simple way to “close” an application - but why did you want to? Unless the application is specifically written to run things in the background, once it’s no longer the foreground application, it’s not running. “But wait!” you say. “It’s still using up memory!” Yes, yes it is - but until you need that memory, why do you care what else is using it? Android will happily shoot that other app in the head and steal its memory for you - but only if you actually need it. But if you don’t, and you want to switch back to that previous application, you don’t have to restart it from the beginning, it’ll just pick up where it left off. This is GOOD, it’s an advantage.

I finally quit being lazy and updated my first Android app, calCOOLator. It was semi-broken because it was using standard java.lang.Double numbers, now I’m using java.math.BigDecimal and dealing with precision much better. Maintaining old applications, especially when it’s been years since you even looked at the code, is a little annoying.

I’m sure I’ll still get comments about how it doesn’t handle percentages correctly. “50 + 10% = 55” - wtf kind of math is that?