There’s an apocryphal story about Syd Barrett pranking his band mates by ‘teaching’ them a new song. Every time through the melody he’d change it just a little bit. They thought they were just a little out of practice, or something, they wouldn’t have blamed Syd. After twenty or so slightly – slightly– different repetitions, they wised up. The story says that was the last straw for that incarnation of the band, ’cause no one trusted Syd anymore.

A couple years ago, I wanted a way to close (or open) my garage door via an SMS message. I got the hardware side of things hooked up, using an Internet service that turns SMS messages into webservice calls, and it worked as simple as you please. Text ‘Open door’ to the Internet service, and poof! Up she goes. It even works if you’re two states away.

But I thought it’d be nice to put a simpler face on it, so I built a basic ‘app’ for my Android smartphone. In the background, all the app did was send text messages, but in the foreground:

That’s a picture of the front of the house. Well, actually, it’s three separate pictures: the upper portion (above the doors) is a single image, and then each of the doors down below is its own image. The door images are wired (through the app) so that when you touch one of the doors, it sends the appropriate SMS messsage, and the door on that side should open … or close, depending on where it was when you started. Neat!

I took some severe shortcuts building the app. Normally coders need to account for all kinds of different size screens on phones, so the images they display need to be ‘scalable’ and ‘responsive’ to different screens. Lucky me: Renee’s phone had the same size screen as mine, so a single set of images worked on both fones. The app kept working after we each replaced our phones, because the screens were still the same size!

But around July of this year, the app on Renee’s phone began looking different.

There’s a white margin at the top of the screen, and a white box around the lower images, and it was a lot harder to hit the correct ‘button’ when you wanted a door to move. I thought maybe the app had been corrupted on her phone, so I reloaded it. No difference. Gotta dig deeper. I started up the ‘interactive development environment’ used for building Android smartphone apps, and I had to wade through two dozen “Update available!” messages. At first I tried to ignore the messages, as the previous version of the IDE operated just fine – but a little later I caught the IDE ‘updating’ code anyway. And it wasn’t just updating itself – it was updating the code that I’d written.

The version of the app built with the updated IDE behaved the same on Renee’s phone. More digging, thank Alphabet there’s google. What’s this? Samsung pushed a new version of the Android software to its (well, her) phone in July, and that new version changed the resolution on the screen from ‘quadHD’ to ‘fullHD’. Without asking, even: the manufacturer knows best. So I found the setting and restored the resolution to ‘quadHD’.

Now the app crashes on her phone. The debug messages complain about failing to allocate a huge chunk of memory. Back to the google. What’s this? The Android coding standards say that if you are using images at a fixed resolution, they can’t be stored in the coding project where they used to be. The images must instead be stored over in this other directory.

So I moved ’em, and rebuilt the app. The app works now! (just as it used to).

The pattern for the Android core software and the IDE seems to be: Make slight changes, subtle changes, every single day. For folks who aren’t building apps every single day, there’s no way to keep up. You’re always chasing problems that come out of nowhere. This is the same pattern that Microsoft displayed with successive versions of .NET and the rest of the Windows development stack: change, tweak, change, tweak, change…

When Syd did it, we thought he was malicious.