waffle

n8 explains why Android’s network policy is going to suck by edict.

As with many programming gotchas, it has to do with the ghost of Javas past and is exacerbated by the special “modern API” brand of xenophobia that seems to naturally occur in spades within the confines of the Java platform design meetings, a veritable Ytterby of people who were scarred for life by event loops and established programming practice in general. (These people also seem to ship without a sense of humor in their classpath, so I’m spelling it out: just kidding. Mostly. By now this group is essentially self-selecting; anyone with any demands of their JVM programming language other than “in perpetuity essentially the same as what was available to me in 2002″ has already fled to hipper alternatives.)

And it does explain it, even if it doesn’t excuse it.

Android developer advice:

The network is especially slow and inconsistent, so you should never do network requests on your main thread. In fact, in the upcoming Honeycomb release we’ve made network requests on the main thread a fatal error, unless your app is targeting an API version before Honeycomb. So if you want to get ready for the Honeycomb SDK, make sure you’re never doing network requests on your UI thread.

Network requests can (should!) be handled with asynchrony, and asynchrony can (should?) be handled without introducing threads (event/message loops). What they’re saying is that it’s not just okay to sit around spinning for network, you actually have to involve a new thread, on a device with scarce resources, just to do that, even if you’re just doing it asynchronously. That’s conceptual and actual overhead.

As long as you start the request asynchronously, it doesn’t really matter what happens. Even if network requests did involve the CPU sitting around spinning, the system should be able to do that in a special thread for you. With the way it actually works, the CPU sets off the request and the networking interface and the network does most of the busywork until you start to get stuff back and the buffers fill. You yield immediately for other stuff, and the asynchronous operation picks up when it’s done.

I’d like to hear from any Android developers whether there’s any architectural reason to actually do a new thread. Conventional wisdom and past experience, including several operating systems with millions of users, says you don’t have to do it. Are there any constraints I’m missing, or is it that the APIs (or Java itself) are so inept that most people can’t bother getting asynchrony right anyway?

I wanted to have an outlet dedicated solely to writing about programming. Presenting: stmts.

There’s already a few posts, but I recommend starting from the beginning.

I’ve been having this idea for some time, and I decided to toss a few things together in a more expedient fashion to get the ball rolling sooner rather than later. (Yes, that is a stock theme, and no, that WordPress install didn’t exist three hours ago.) That’s not how I normally operate, but let’s see how this goes.

I got through the first few levels, then I turned off the Wii and now the Wii is broken. I think it got upset with the slippery steering, apparently honoring the recent trend of real-world physics adherence ahead of actually being in control.

If you take away the Wii quirks (you can shake the controller, therefore you must juice the ability to shake the controller even if we’ve begrudgingly agreed that pointing at the screen isn’t good) and the physics, it sounded like, looked like and played like Donkey Kong Country, and better yet, like the first Donkey Kong Country, not the sequels.