Screen Density Issues
One of the main tasks for supporting different hardware is providing resources for the appropriate screen types. Although we're talking about three different 7-inch tabs here, their screen stats are sufficiently different enough that it's important for developers to take note.
- The Kindle Fire has a 1024x600 pixel screen at 7 inches across. Quick, what's that in DPI? And in Android abstracted DPI? Easy: 170 DPI physical resolution and 160 DPI abstract (MDPI).
- The Galaxy Tab has a 1024x600 pixel screen at 7 inches across. The physical DPI has to be the same. So, isn't the abstract DPI the same? Nope! Samsung chose to report it as an HDPI screen in order for the OS to pick higher resolution resources. Turns out, this worked well. But now we have two devices with similar screens and two different DPIs.
- The Nexus 7 has a 1280x800 pixel screen at 7+ inches. The physical DPI is, therefore, about 216 DPI. So, that must be an abstracted DPI of 240, or HDPI, right? Nope! It is, in fact, TVDPI.
What's TVDPI, you ask? The Android developer documentation covers it well:
Resources for screens somewhere between mdpi and hdpi; approximately 213dpi. This is not considered a "primary" density group. It is mostly intended for televisions and most apps shouldn't need it—providing mdpi and hdpi resources is sufficient for most apps and the system will scale them as appropriate. If you find it necessary to provide tvdpi resources, you should size them at a factor of 1.33*mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi.
In fact, Dianne Hackborn (an Android Framework Engineer at Google), in a Google+ post, explained it even better with respect specifically to the Nexus 7. It is useful to note that the Jelly Bean platform only has a single image resource specifically pre-scaled to TVDPI. The rest of the resources come, presumably, from HDPI and are scaled appropriately. We know designers hate system scaling, but the density of the displays is really getting to the point where most users won't notice scaling artifacts.
Due to a variety of factors, the software experience on the Nexus 7 may not be what developers and knowledgeable users expect. With the density settings not matching either the Kindle Fire or the Galaxy Tab, the layouts may not be identical across all the devices, depending on how the developer organizes their project resources.
For example, the Amazon Kindle app, which is available on all three devices, has a different experience on each. Despite the similarity in screen stats, the layout and fonts aren't identical across each. The border sizes don't quite match. There isn’t the same number of selectable font sizes. Even the screen color isn't quite the same, though that has nothing to do with the application and, instead, is a function of the physical screen and video hardware calibration. If a user only has experience with one, they'll never know better. But, as a developer, you'll want to make sure that what the user is experiencing is what you expect.
While the Nexus 7 may not be a new form factor for tablets, the entire hardware and software package and pure Google experience are not something developers (and other manufacturers) can ignore. The brand-new smooth Jelly Bean platform combined with high-end hardware is sure to delight users. Developers should take care to not let their application perform in a way that doesn't blend nicely with the overall system experience.