7. Form factors

Tame that fragmentation beast.

J2ME was touted as Java in every handset - and that's pretty much what it became in the end. To achieve this across such a diverse range of devices, compromises had to be made. Most now accept those compromises were too limiting, meaning you had built a car with 1 gear, only available in black with 1 seat which could onlfy travel on the freeway. Manufacturers wanted to sell more handsets ;-) They "enhanced" the standard J2ME with their own extensions, which was great for them but very, very bad for the ecosystem as a whole. Apps which used proprietary extensions were not compatible, resulting in its ultimate demise.

Android is so much richer than J2ME it's off the scale, but those pesky manufacturers will insist on trying to differentiate their products. There's a risk that this fragmentation could happen again, and we could end up in the nightmare situation of having to develop and market apps for each Android device. To be fair, the closed guys have their faults but this isn't one of them. Heres Googles take on the issue:

So what can Android developers do about it? As it happens, it's nothing like as bad as J2ME. When you think of different form factors you have the obvious one, with or without a keyboard, and then the usual culprits such as screen pixel density, memory capability, cpu power, sensor support and so on. There are some obvious pitfalls to avoid, like hardcoding absolute values in your XML layouts, and some rules to stick by such as always using density-independent pixels ("dip" or "dp") and scale-independent values ("sip" or "sp").

There are really only 3 screen size to sizes to target, and support is built in as explained here. Basically, your code can interrogate its environment at start-up to detect the presence/absence of essential hardware features, so your GPS app should fail gracefully with an error message if location isn't supported, and that's all done in one app.