State of the State

I just rebooted my DroidX. It had disconnected from the new Pantronics 975 and was refusing to reconnect. Last time this happened, I re-paired the two, but something told me that it was the phone at fault, not the earpiece. I was right.

So it seems that the Android equivalent of Ctrl-Alt-Delete is the remedy to certain problems with your smart phone. [sigh] Why can I not simply tap "connect" and see it talk again to my Bluetooth implant? (It's not really an "implant", but you get the idea.) It's all about state.

Somewhere in the bowels of the phone (whether Android code or Motorola code or Verizon code, who knows?!?) a bit was set that said "we cannot hit that Bluetooth partner, so give up". I say this without rigorous proof for the sake of discussion. It's true that machines have state and that software makes note (and has its own state). So it is reasonable to conclude that the phone software had decided that the earpiece was in "a bad state" and would abandon further attempts to communicate.

The problem is not with state but how state is used and how state info can be corrected. I should not have to reboot my phone (nor even re-pair) for it to use my Plantronics.

This whole concept is rather in-my-face lately because my day job is maintaining a sopisticated program written in assembler. Assembler is cool, though tedious. I love it, but one downside to assembler is that programmers are more tempted to leave "state info" lying around in odd places. In the case of my job, incorrect state info is not as much of a pain as finding where the state info was recorded.

So why blog about it? Easy: it validates one of my opinions. (Why does anyone blog? Okay ... some are honestly observant. But most of us have an opinion and/or agenda.) Higher level languages supposedly free us from state issues. This is true for varying values of "supposedly", and my point is that they don't. As soon as you take things up a level and all state is on the stack (where it can't hurt other functions) you, the programmer, will begin looking for ways to record state info outside the scope of your local function or enclave. (Global variables aside. They are a necessity. It's more about how you use them, or files, or whatever, that needs care and feeding.)

The DroidX is a pathological case. I like the phone, and am mostly content with how it works. But I have resented the bloat of "everything is Java" all along. Layering apps in a JVM is another attempt to protect the state of the machine. Peel back the onion! Sure, it will make you cry, but it will get rid of those dead layers none of us really want.

Back to the bits ... somewhere, my phone had set a global flag or written some config file as it decided the earpiece was gone. There are really two problems: Obviously it got things wrong and that's inexcusable, but significantly in our present world I should not have to unpack so many layers just to reset a bit.

-- R; <><