The UIQ Evangelist

What does it mean? What does it actually mean? Where should breakage in programs predictably appear? Where do they predictably appear? (And more questions, in the long running series on smartphone OS upgrades).

Part VII, “Backward compatibility”.

With “backward- compatibility”, it’s generally meant something along the lines that the next version of a program won’t break what worked on the previous version. Or that your new gadget will still work with your new state of the art phone with support for a new types of accesssories as well. Even if mostly what we’re really talking about is whether the programming project was planned well. Did someone figure out that a data- field needed another data- type? Did people really need dates farther back than 1971? Did we need a new data- structure on the data- base all of a sudden - were those algoritms unfortunately welded into the program logic? And who needs more than 100 contacts in their phone- book, anyway. That’s usually the problems involved.

But the real question is on what level you’re running into trouble. It is, for example, no problem using abstractions such as a factory pattern for your program, and then fundamentally prevent breakage from version to version from the user’s perspective. Instead dealing with proper backward compatibility issues based on either:

1. changed hardware- configuration or low- level api.
2. new program functionality that was not present before, and cannot be represented with the old data structures.

I.e, instead of having to rewrite your program from the bottom up if you wanted the program to display both jpg and png pictures, you’d instead “upgrade” your fundamental “picture” data collection to deal with more formats, perhaps with hardware acceleration if available, etc. But if you wanted to display something that couldn’t fit in the image- viewer, such as an interactive image- map, then you’d need new functions (although you might keep your fundamental “picture” type anyway, most likely, to avoid actually breaking compatibility backwards).

Still - instead of that, the most common thing to deal with in the computer world is hardcoded algoritms dependent on particular data- stores or particular memory handling. Imagine, for example, the nightmarish scenario of upgrading a server- network where several servers are referenced in permanent addresses in several startup scripts. Not only would you need to manually edit every program every time you need to switch out hardware. Or look out for and slavishly maintain dependencies in the programs that may or may not be handled correctly, dependent on what happens in the new hardware. But you would also have trouble installing new servers and new solutions that should work with this system.

Because that situation simply does not allow for abstraction on any useful level. And you’d be stuck with trying to glue an existing system together, every new piece being a challenge with all kinds of issues ranging from high to low- level programming, hardware and software, choice of standards and so on and so forth.

Another example - why won’t my pictures resize and break properly in wordpress while we’re on the full page? Or why can’t I override styles in the blockquote tags? Because the classes used to format the content on the page use overrides that override the code you put in as a user, because of overly economical use of wrapper classes. That limits you to using the available controls in the panel only, or avoiding the carelessly overridden tags. Brilliant? Not necessarily.

So - obviously abstraction is not only useful, but also critical for choosing a good program solution. Nevertheless, it’s not always used very extensively. So why is that?

There are some good reasons:

1. Efficiency: direct memory- handling for a specialised task might be quicker than a general algoritm. You can save some processing by presuming that the data you have is in the right shape when you access it, for example. Or by explicitly casting your objects to different types before running operations on them. Optimisations like these can often be extremely beneficial - if someone wrote a parsing algoritm that expected a certain length and type of data, sometimes sacrificing the solution you think is most efficient could save running time.

2. Time constraints. It might’ve been best to order a new lookup based on a generic data type, and then transfer the optimisation logic to the chosen data types (if it’s dependent on type), and to the physical lookup routine (if that was where the optimisation was). Perhaps a different solution even would’ve been better. But time constraints typically tend to help you choose one type, one structure, and then - in effect - closing off any future expansion. But it would work.

3. Too much abstraction. You don’t need to pass objects endlessly, either.

Other than that, there are bad reasons:

1. You want to make sure the next product the customer buys require another five months of preparation and planning, and that the smallest upgrade needs an entirely new solution - from hardware, to software and so on. Very pleasing for the marketing people, but not for anyone else.

2. You’d like to offer support- deals that allow you to experiment in live systems. (Allright, that might be a good reason.)

So looking at UIQ devices - what sort of approach did they choose here? UIQ promises to provide a framework that may change in appearance and behaviour, but which will still use the same code- calls for every new version after the current one (at least for UIQ 3.x). And instead they will provide the backward compatibility whenever changes take place in symbian, or if they come up with new ways to represent the UI. New program functionality would have to be added to previous devices, of course - but fundamentally (in theory.. very theory) the same code would run and produce similar results, based on the various objects represented in the wrapper classes. And so providing their customers, phone- manufacturers at the moment, with an easy and portable UI for their devices.

Example: two sheets in an UI could be represented in numerous ways. But if you choose a data structure that deals with an abstraction of “sheet”, you can treat the data and the elements in that construction as you wish on different hardware layouts, etc - without requiring the programmer to directly predict what the layouts would look like. So representing data would be easier, and not dependent on individual program logic.

Imagine if all the parts of the system were treated in this way. And if it wasn’t several years since you could first hear people suggest that - yes, UIQ is in fact several years ahead of it’s time.

next: Part VIII, “The ‘Open platform’ paradigm”.

Categories: Comments, Operating Systems, Symbian
Tags: Development, UIQ