One of the pesky fragmentation issues Android programmers must worry about is different screen sizes.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 160×160 screen. Later in their life, Sony introduced a 320×320 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 160×160 screen but the OS would convert those and take advantage of the higher-resolution screen to show sharper text and drawn shapes.
This strategy became problematic in PalmOS later, however, when it wanted to ship QVGA [320×240] 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 160×160 an 320×320, giving a scaling factor of 1.5, and here the problems appeared.
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.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 640×480 device than on the 320×480 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.
The Android approach could theoretically handle any pixel-per-inch density. But for convenience, Google set up what Hackborn called “a few major buckets…ldpi (approx 120dpi), mdpi (160 dpi), hdpi (240 dpi), and xhdpi (320 dpi).” To handle the approach, Google exhorts programmers, “Provide resources for different screen densities (DPI) to ensure that your app looks great on any device.”
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, 1280×720 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. Things work very differently in the world of the iPhone, where Apple is in firm control.With iOS, programmers pay more attention to each pixel. When the iPhone 4 arrived, the screen resolution doubled exactly from 480×320 to 960×640, making the pixel-doubling math easy. Many signs point to the next-generation iPad taking the same approach, doubling the first iPads’ 1024×768 resolution to 2,048×1,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.
via Source