Hacker News Reader

Comment by nuclear_eclipse | Hacker News Reader

#3 sounds more like complete sarcasm, and just didn't seem to fit with the rest of the article in tone or meaning.

Regarding #8, have you explored the way that "Alternate Resources" [1] allows you to better handle fragmentation issues? I've found it at least to be useful enough to provide a few alternate layouts based on screen orientation, but it would be nice to get further feedback from fulltime Android developers about it. Things like how useful it is in the real world with real, fragmented devire types seems hard to come by...

[1] http://developer.android.com/guide/topics/resources/resource...

View on HN

Thanks for the feedback. #3 was meant to be a more than a little sarcastic, but I guess it didn't mesh well with some of the others.

There are really two types of fragmentation. The first is UI screen size, which isn't too hard to work with. The second, and uglier, is code fragmentation. This is where a piece of code might work totally differently on two separate platforms. Right now Android has a lot of the former, but it's looking like there's a lot of the latter to come.

How could code run differently on one Android 1.6 device from another?

While Android might be internally consistant, the hardware drivers that support it isn't. Everywhere your software interacts with the hardware is suspect for fragmentation. Google will have compliance testing to force OEM's into correctly supporting the Android runtime. However, their only leverage is the inclusion or not of their Google Apps and the "Made with Google" logo for the back of the device.

The handset makers (mostly HTC) have taken to shipping the same kind of "value add" UI changes that they did with Windows Mobile.

What's most unfortunate is that it's not even bullshit -- they are actually adding real value! HTC's on-screen keyboard is better, and they add in some of the multitouch events that Google foolishly left out.

Reply on news.ycombinator.com