ISSUE: Navigation Bar
As I grind out updates to the Navigation-Bar-Fiasco, let's do a postmortem.
For the longest time, Android allowed developers to force full-screen mode with just 2 lines of code, and that system was reliable as heck. Then Google decided to renew this part of the OS into a complex web of frameworks and layers. Both permanent and transient UI elements taking space.
And wouldn't you know it, the first iteration was such a failure that soon, with the next version of Android, there was a rewrite of parts of the new system that was not compatible with the first attempt. As a result, there were three systems: the old, the failed (some sadly stuck on it), and the new elaborate one.
But not to worry, many phone makers obeyed the old declarations, at least initially, so you could get away with just using the old 2-line solution, no problems... Until some devices stopped respecting the old way.
So the code went from two lines to covering all these cases separately with a lot of lines. I was not happy, but, ah, "progress".
But it gets worse: In the new complex system you can set everything as desired, but then some lower-level popup, etc can override some of the values you previously set. Imagine your door opening sometimes when your neighbor opens his door. Unbearable.
Okay, so you have to add rules and triggers to recheck stuff you have already done perfectly whenever the view on the app changes a certain way. Argh, so much needless code, work, and checking values.
But I'm sure you guessed, it gets worse. Some manufacturers then realized they could create their very own, never-before-seen in the history of Android additions with this new complex framework.
And then it gets even worse: they didn't even roll them out to all their devices the same, but scattered and tweaked these unseen mystery changes by their device size category, or whatever their logic was.
It was a tangle in a tangle wrapped in a tangle. Twice I was fooled into thinking: "Oh, I so totally solved this now" because either the fix worked for a little while or only for certain devices. Only to realize mid-rollout that I haven't really done anything at all for the majority of the troubled use cases. Sigh.
And the cherry on top of all of this is this: None of my regular test devices got these unprecedented alterations, which explains my slow reaction to this part of the mess. Everything was fine for most of us, and I knew I had done the code by the specs.
The end result: Over a period of time, I went from two simple lines of code that always worked to over 300 lines of delicate procedures trying to cover every single oddness, runtime tweak, version, and development.
Now the specifications state things like, "Uhm, it could be 50px or 150px, who knows?" Plus, I can't trust the current runtime readout where the bars are located because it might be changed by some random element soon and how do you measure the transient element covering things up.
Okay, so I guess this car you buy will have 3 tires or maybe 7; who knows? You'll know it when we ship the car to you, and occasionally we might sneak into your garage and make it a 6-wheeler.
Lesson learned? If I get more than one report of something odd happening, I can't trust that me following specs is any guarantee that things are working for everybody. That is a depressing realization, because the fact that I have been programming with such a pure basic Java/Android way has protected me from a lot of headaches in the past.
The systems are getting incredibly complex, and worse yet, it's not just one system; it's a several of these over-labyrinthine systems shakingly piled on top of each other in layers.
The vibrate system might be a good example you might have experienced: system-level silence overrides some sounds but not others like priority alerm clocks, but you can also manually block ringtones from certain people while all sounds are ON. When everything can override anything, it is challenging to keep all the ducks in a row.
"Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges, and it causes end-user and administrator frustration."
— Ray Ozzie, former Microsoft Chief Software Architect, Microsoft PDC 2005 Keynote