Watching Notch Code away for Ludum Dare

This Saturday, I ran across a link on Hacker News mentioning the Minecraft creator Notch was writing a game from scratch for the Ludum Dare competition, and he was streaming his whole experience live. So I decided to take a peek at what he was doing, and wound up burning the better part of the weekend watching him code away.
It was really interesting watching how he builds up a pretty impressive game out of nothing in only the span of a few days. Even more so coming from someone with very little game programming experience.
It just goes to show you, practice does indeed make perfect. Very good inspiration for anyone looking to become a better game developer or really better developer in general.
After the competition (still going for another hour or two), the source code will be available to anyone who wants to take a peek, and you could even watch Notch write all the code on his page to follow his thought process a bit (see the link at the top).

Dealing with Java’s Input Streams

 

Always check your byte count when using Java Input Streams.

Why do you ask, Mr. intelligent internet reader?

Well, the other day I ran across a strange response with some of our client code. In some rare instances, maybe 1 in 500 requests, the HTTP response we received from our server would come back as a bunch of unreadable mess.

When looking into the problem closer, we found out that in a small subset of requests, the server was indeed sending a response back, but the response was completely unreadable.

Tracking down these kinds of problems are really painful. First we had to figure out if the problem was somehow with our decoding techniques. Nope, that checked out all right. Then we looked into the possibility of the server sending back bad info in some situations. Nope. After 1000s of attempts, everything checked out fine.

So I went back to check out the client code. I then looked toward what was happening before the response was decoded. Even there , everything looked fine. X amount of bytes were received from the server via simple Java Input Stream. But wait, the number of bytes were a bit low, about 5 bytes short. This was happening in every response. Only sometimes it would cause the response to be unreadable. What would cause that?

After a few hours of working with the code, it turns out that a simple Java byte array does not correctly convert over to a standard byte array. Instead of using the standard byte array, the ByteArrayInput Stream needs to be used to convert to a byte array. After we added this simple one line fix, everything checked out!

So the bottom line is really…

Never assume your response from a server is completely correct until you know the byte count is spot on. And always be weary of Java Input Streams.

How to Tell if Your Android Application is in the Background

Figuring out if your Application has entered the background is a fairly annoying task in Android. You would think there would be a simple callback like “isInBackground()” that would simply notify the application, but sadly there isn’t.

This means you have to figure out a way on your own to determine the background state. From what I have seen, there's really only one option, and that option involves actually counting live Activities by using the lifecycle methods in each Activity.

To do this efficiently as possible, you need to have a “base” Activity class that all of your real classes inherent from. In this base Activity class, you need to override two methods: onResume and onPause. You would also need a counter variable in the base Activity (or wherever you would like to store it). As you would expect, the onResume method needs to increment the counter, and the onPause method needs to decrement the counter.

Also, the onPause needs to check the counter variable to see if it’s zero. If the counter is zero, then you know your Application is in the background and is not being currently seen by the user. This is because the last Activity started has been paused and no other Activity of your Application has been resumed yet.

New and Improved

The above solution will work on any version of Android. However, on Ice Cream Sandwich (4.0 and API level 14), there is a cleaner solution.

In the Application class, Android now has a new method called unregisterActivityLifecycleCallbacks. This method allows the developer to have one callback that is notified anytime a Activity Lifecycle method is called (onCreate, onResume, etc…). By using this callback, the above counter could be implemented exactly the same, except now, no base Activity class is needed. We simply call this method in the Application class of the Android application and keep track of the currently running Activities there. Now this code doesn’t need to touch every Activity that is created. If only it was back-ported!

Know of any other ways to determine if an Android application has moved into the background?