It wasn’t getting called – a mystery.

I added a background color to its declaration in main.xml and that fixed it.

Grrr.

For example, they discourage getters/setters, preferring public access between classes. This is a big Object Oriented and Java No-No. But it’s the right thing to do where you need it.

I had been wondering where to find stack traces when my code blew out with uncaught exceptions, or failed to start.

Well, I need look no farther. One of the functions of the adb utility is just that:

adb.exe logcat

It does the trick and shows lots of other interesting traces.

And, you can write to it yourself using the Log class in the SDK.

When I tried to run it, it blew up immediately.

I used adb.exe logcat to look at the logs and it was having trouble “inflating” MySurfaceView – couldn’t find the class.

After wasting lots of time, I suspected that the project wasn’t being built correctly. I created a new ASurfaceView class and put all the MySurfaceView stuff in it so it was identical except for the name. I then deleted MySurfaceView.java.

The problems was fixed.

  this.setOnClickListener(
        new OnClickListener() {
            @Override
            public void onClick(View v) {
                 _mainThread.setCenter();
            }
        }
  );

Examining the documentation didn’t show the word “sprite” anywhere. However, it turns out that the Lunar Lander example included with the SDK does sprite graphics (even uses the word) to animate the landing craft.

It’s pretty simple – just draw the object on your view’s graphics object.

Here are a couple of hints:

1. Using the debugger, look at the stack trace. It may have clues in it (or it may not tell you much)
2. Examing the metadata XML files and be sure all references to Java classes are exactly right – package name spelled right, etc

Android provides two things that together make this easy (although I haven’t figured out how to get a snapshot as opposed to a scrolling log):

1. A logging class – in my case, I used:
   

   android.util.Log.d(”ACC”, “dX:” + dampedX + ” LX:” + lastX + ” buf[" + avgOldest + "]=” + avgBufX[avgOldest]);

2. A debug interface for the device or emulator that does lots of cool things, including showing the log in real time. This is called ddms and is found in the SDK tools directory. It is a batch file that fires up a GUI. See this write-up.

;

I had an app which was debugging fine on the emulator, but on the phone, just ran without hitting breakpoints.

It turns out that one needs to add the attribute android:debuggable=”true” to the application XML element.

It would be helpful if the emulator were to raise a question when this element is missing, since this represents a failure to accurately emulate the device.

It turns out the way this is normally done is to create an independent thread with a main loop which calls whatever needs a “tick” periodically.

This is used in the Lunar Lander demo that comes with the SDK.

PROBLEM: this is not very accurate real time. It would be better to have an interval timer that does not depend on the vagaries of running a loop with “sleep” in it. android.os.CountDownTimer may do this, but it does want to stop eventually.

Experimenting…

update…

android.os.CountDownTime does the trick