0

I'm implementing an app for Android(API 10). I have few designs for tablet(supposedly) and for mobile phone. Regarding the previous sentence it might sound a bit stupid: in my opinion layouts should be picked according to device's physical size - not resolution, otherwise there might be a phone with high resolution that renders, say, a grid of 5x5, in rather confusing, inadequately small-sized way. In order to provide division by physical size I gotta use /res/layout-* folders. Agreed ?

Also: I'm a bit confused about multiple-screens guide's definition on physical size. Would you mind explaining what physical size is in terms of Android mean, what it's measured in? Is there any correlation with dpi?

Thanks.

Shine
  • 3,788
  • 1
  • 36
  • 59

4 Answers4

1

A workaround for api level 10 could be something like this:

  1. use the compat lib from the SDK so that you can design with fragments.

  2. Assume everything before android 3 is a phone. For example use your layout files in layout/* for this (and the rest will be based it on unless overriden). This assumption is basically only wrong for the original Samsung Galaxy Tab 7" from 2009.

  3. Assume everything on android 3.x is a tablet (they are), so do some tablet specific layout if you want and have them under layout-v11 (and maybe also layout-v12 if there is anything specific to android 3.1). Tablet specific layout could mean that you arrange your fragments differently and/or show multiple fragments at the same time.

  4. Everything newer (android 3.2+) you can use the new stuff from api level 13. Such as layout-sw600dp/ for some layouts etc etc. http://developer.android.com/guide/practices/screens_support.html#DeclaringTabletLayouts

Mattias Isegran Bergander
  • 11,811
  • 2
  • 41
  • 49
  • (Copied from another thread): Good idea, but does it mean creating two applications at a time. In specification actually it is said that app should handle following resolutions, including 1280x800, yet why you think there's no possibility to handle that sort of thing in 10th API ? For instance here developer.android.com/guide/practices/screens_support.html layout-xlarge it is supposed to handle "Extra Large screen" devices(at the bottom). "Extra Large screen" means tablet as well - isn't it ? –  May 02 '12 at 19:30
  • 1
    Well depends a bit but generally yes. Go ahead, the emulator can show you how it works in practice. But remember we now have 1280x720 resolution on phones as well. The graphic here with both dpi and screen sizes can perhaps help you visualise it: http://developer.android.com/guide/practices/screens_support.html#range But you could use layout-xlarge-land as well, had forgotten about landscape mode too, you could/(should probably) design differently for that as well. – Mattias Isegran Bergander May 02 '12 at 19:41
  • Thank you for suggestions, I'll continue researching this issue. But one more question, if you don't mind. In "multiple screens" article it is that if one would like to create a custom avd he can do so. One thing I can't figure out is setting physical size. AFAIK physical sizes are measured in inches and in case of predefined emulators QWGA,HVGA size is somehow defined automatically. But how do I specify physical size when I build a custom AVD ? –  May 02 '12 at 19:53
  • Indirectly. You specify resolution and you specify dpi (dots per inch, or sometimes called ppi, pixels per inch), that gives you the physical size. Screen sizes are usually measured as the diagnoal though so you need help from our old greek friend Pythagoras as well. – Mattias Isegran Bergander May 03 '12 at 06:59
0

Physical size is usually measured in inches, it simply tells you the real device's screen size (usually 3-4" inches for phones and 8-11" for tablets).

dpi, is NOT correlated with it. Dpi expresses screen density, how many pixels are shown in a given area (usually a square inch). It could be considered as a measure of screen quality.

Resolution is given by the product of the two; it expresses the total number of physical pixels on a screen.

Going back to your first question, you should be density independent as much as possible; your app should "look the same" on devices with different densities. The /res/layout-* folders are designed to provide this feature, the system scales drawable resources to the appropriate size and you could then declare in your manifest that your app supports any density:

android:anyDensity="true"

On page http://developer.android.com/guide/topics/resources/providing-resources.html#BestMatch you can learn how Android choose the best matching resource.

Shine
  • 3,788
  • 1
  • 36
  • 59
  • I need to get use of two layouts. They have different design. One is more tablet oriented. So my guess is that I should decide which to use regarding physical size and I can't quite understand this "the system scales drawable resources" /res/layout/ doesn't contain drawable. Secondly, what's the difference between "physical pixels" in your resolution description and "how many pixels" in dpi ? –  May 02 '12 at 13:57
  • a pixel is alway referred to as a physical dot. But resolution is an "absolute" quantity, it expresses the TOTAL number of pixels on your screen. On the other hand, dpi is a "relative" quantity, because it is expressed on a square-area basis (how many pixels in a given area). Different screens with EXACTLY the same size may have different dpi, hence different resolutions. – Shine May 02 '12 at 14:13
  • maybe the page http://developer.android.com/guide/practices/screens_support.html#DeclaringTabletLayouts could be helpful to design a tablet specific layout. Basically, I guess you should use "size" Screen characteristic, not "density" – Shine May 02 '12 at 14:16
  • I'm building against 10th API. –  May 02 '12 at 14:25
0

With Android API 10 the best option for targeting tablets is probably just distinguishing the actual size of the screen in the code using something like: https://stackoverflow.com/a/5789916/1319155 and then just load a different drawable if the size value returned was greater than 6 (or whatever size you want to declare as a "tablet").

The reason you can't really just use the size folders (i.e. layout/large) is because the folders don't distinguish between phones and tablets very well. A kindle fire and galaxy nexus may both be considered "large" devices.

The reason you can't really use dpi is because that is not a good reflection on what type of device it is, just how "dense" the pixels are on a screen. Most new phones are much denser (having more pixels per inch) than tablets anyway.

Community
  • 1
  • 1
user1319155
  • 149
  • 8
  • agreed, that's why I want to distinguish according to size. I don't like the idea of "just distinguishing the actual size" because there going to be quite a few "if" statements in activities, I guess. Since I only have a single src folder, I need to somehow extract the differences between both layouts and retain my activities simple. Idea that want to try includes use of fragments - this way I'll be able to describe specific parts in layouts(large or normal). –  May 02 '12 at 15:26
  • Does that answer your question or are you looking for more? Without Android 3.2 or higher you cannot simply use folders to specify a minimum size, you only have the large/normal layout folders. That is why Android released the new size qualifiers in 3.2 (when they realized the sizing issue). See: [Declaring Tablet Layouts for Android 3.2](http://developer.android.com/guide/practices/screens_support.html#DeclaringTabletLayouts). Otherwise there is no way to extract the differences within Gingerbread and to create something guaranteed separate for all tablets and phones just by using folders. – user1319155 May 02 '12 at 15:56
0

There are two ways of doing this. From Android 1.6 (API 4) on, there are four layouts that describe the physical size of the display: small, normal, large, and xlarge. As described on http://developer.android.com/guide/practices/screens_support.html , these correspond to:

  • xlarge screens are at least 960dp x 720dp
  • large screens are at least 640dp x 480dp
  • normal screens are at least 470dp x 320dp
  • small screens are at least 426dp x 320dp

Note that these are measured in DP, not DPI. DPI is Dots Per Inch, and specifies screen density. DP, also written DIP, are Density-Independent Pixels. Again from the guide:

Density-independent pixel (dp)

A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way. The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.

In other words, 160 DP = 1". Applying this standard, we see:

  • xlarge screens are at least 6" x 4.5" (7.5" diagonal)
  • large screens are at least 4" x 3" (5" diagonal)
  • normal screens are at least 2.9" x 2" (3.5" diagonal)
  • small screens are at least 2.6" x 2" (3.3" diagonal)

(Not sure why the selection is so odd, but that's what they defined.)

From Android 3.2 on (API 13), there are more options, as described here: http://developer.android.com/guide/practices/screens_support.html#DeclaringTabletLayouts

Here you can use "smallest screen width," "available width," or "available height" options to define your own categories; again, the unit in question is DP, which is 1/160". Note that these specify the smaller of the two dimensions on the device--e.g., for a 7" tablet they recommend specifying layout-sw600dp, that is, "smallest width 3.75 inches," which would be intermediate between the "large" and "xlarge" sizes defined in API 4. They have a number of specific comments about this topic, including notes about how the widths are measured (it may exclude things like the notification bar), so it's worth taking a look at the documentation.