Phones come in many sizes, and Android (on the two Nexus models here) is designed to span the range.
(Credit:
phone-size.com)
With resolution changing from one phone to another, programmers have to figure out exactly how much room they can devote to icons, photos, video game backgrounds, dialog boxes. But, Google argues, paying the price upfront pays programmers back in the long run--and helps them avoid the fixed-resolution difficulties that afflicted Palm.
Indeed, even before the first Android phone hit the market, Google had set on an approach designed to accommodate not just different pixel resolutions, but also pixel densities--the number of pixels per inch. Android framework engineer Diane Hackborn described the company's philosophy in a Google+ post yesterday:
Much of the motivation for this came from experience at Palm/PalmSource. Palm devices traditionally had a 160x160 screen. Later in their life, Sony introduced a 320x320 screen; this worked pretty well by just doubling the coordinates supplied by the application so (unless using new APIs) it still thought it was drawing on a 160x160 screen but the OS would convert those and take advantage of the higher-resolution screen to show sharper text and drawn shapes.Scaling up object dimensions by a 1.5x meant, for example, that "your nice solid lines now get various gray smudges on them depending on how they align with the real screen pixels," she said.
This strategy became problematic in PalmOS later, however, when it wanted to ship QVGA [320x240] screens. These were cheaper to produce since they were used in many other devices; by putting the handwriting area at the bottom of the screen you could still have the expected square area for the app. However their density was halfway between 160x160 an 320x320, giving a scaling factor of 1.5, and here the problems appeared.
To address Android's challenges with screen sizes and resolution, the operating system uses an idea called the density-independent pixel, variously abbreviated dp or dip.
Android's approach to screen resolution can be baffling, and Android comes with a variety of layout tools. Once you master them, "it's zero-effort-easy to make layouts that automatically resize for portrait/landscape device orientations and varying screen sizes," said Meridian Apps programmer Nick Farina in a blog post.
"If you specify, in your application, a button with a width of 100 pixels, it will look at lot smaller on the 640x480 device than on the 320x480 device. Now, if you specify the width of the button to be 100 dip [density-independent pixels], the button will appear to have exactly the same size on the two devices," said Android engineer Romain Guy in a mailing list post.
Pixel-per-inch densities vary, so Android programmers need to include graphic elements in multiple sizes.
(Credit:
Google)
So there's upfront work for coders and graphic designers. But the result, she said, is that software adapted reasonably well to the arrival of the Galaxy Nexus and its 316dpi, 1280x720 screen.
"Android and its applications were able to pretty much run on it as-is," Hackborn said.
So yes, the Android approach is flexible. It had to be, of course: from the start, Google envisioned Android as an operating system for many manufacturers.
Android is vibrant, but it's messy, too.
(Credit:
Stephen Shankland/CNET)
With iOS, programmers pay more attention to each pixel. When the iPhone 4 arrived, the screen resolution doubled exactly from 480x320 to 960x640, making the pixel-doubling math easy. Many signs point to the next-generation iPad taking the same approach, doubling the first iPads' 1024x768 resolution to 2,048x1,536 pixels.
Apple's approach surprised Tim Bray, an Android developer evangelist for Google, when he realized how it worked from Farina's explanation.
"I initially shook my head in disbelief at all the little bits of hard-coded arithmetic, like y += 7 and MARGIN - 30. Clearly this logic is not resilient in the face of a different-shaped screen. But I bet it's fast," Bray said. He added:
It's plausible, as Nick Farina implies, that iOS' fixed-dimensions screen model is partly responsible for the astonishingly-fast performance Apple wrings out of the underlying hardware.
And I'm not even saying that Apple's choice here is wrong. The trade-off, if I understand it correctly, is form-factor flexibility for performance and simplicity, and so far that's been working out pretty well for them.
This is dummy text. It is not meant to be read. Accordingly, it is difficult to figure out when to end it. But then, this is dummy text. It is not meant to be read. Period.
ConversionConversion EmoticonEmoticon