Android support small screen

An application «supports» a given screen size if it resizes properly to fill the entire screen. Normal resizing applied by the system works well for most applications and you don’t have to do any extra work to make your application work on screens larger than a handset device. However, it’s often important that you optimize your application’s UI for different screen sizes by providing alternative layout resources. For instance, you might want to modify the layout of an activity when it is on a tablet compared to when running on a handset device.

However, if your application does not work well when resized to fit different screen sizes, you can use the attributes of the element to control whether your application should be distributed to smaller screens or have its UI scaled up («zoomed») to fit larger screens using the system’s screen compatibility mode. When you have not designed for larger screen sizes and the normal resizing does not achieve the appropriate results, screen compatibility mode will scale your UI by emulating a normal size screen and medium density, then zooming in so that it fills the entire screen. Beware that this causes pixelation and blurring of your UI, so it’s better if you optimize your UI for large screens.

Note: Android 3.2 introduces new attributes: android:requiresSmallestWidthDp , android:compatibleWidthLimitDp , and android:largestWidthLimitDp . If you’re developing your application for Android 3.2 and higher, you should use these attributes to declare your screen size support, instead of the attributes based on generalized screen sizes.

For more information about how to properly support different screen sizes so that you can avoid using screen compatibility mode with your application, read Supporting Multiple Screens.

attributes: android:resizeable Indicates whether the application is resizeable for different screen sizes. This attribute is true, by default. If set false, the system will run your application in screen compatibility mode on large screens.

This attribute is deprecated. It was introduced to help applications transition from Android 1.5 to 1.6, when support for multiple screens was first introduced. You should not use it.

android:smallScreens Indicates whether the application supports smaller screen form-factors. A small screen is defined as one with a smaller aspect ratio than the «normal» (traditional HVGA) screen. An application that does not support small screens will not be available for small screen devices from external services (such as Google Play), because there is little the platform can do to make such an application work on a smaller screen. This is «true» by default. android:normalScreens Indicates whether an application supports the «normal» screen form-factors. Traditionally this is an HVGA medium density screen, but WQVGA low density and WVGA high density are also considered to be normal. This attribute is «true» by default. android:largeScreens Indicates whether the application supports larger screen form-factors. A large screen is defined as a screen that is significantly larger than a «normal» handset screen, and thus might require some special care on the application’s part to make good use of it, though it may rely on resizing by the system to fill the screen.

The default value for this actually varies between some versions, so it’s better if you explicitly declare this attribute at all times. Beware that setting it «false» will generally enable screen compatibility mode.

android:xlargeScreens Indicates whether the application supports extra large screen form-factors. An xlarge screen is defined as a screen that is significantly larger than a «large» screen, such as a tablet (or something larger) and may require special care on the application’s part to make good use of it, though it may rely on resizing by the system to fill the screen.

This attribute was introduced in API level 9.

android:anyDensity Indicates whether the application includes resources to accommodate any screen density.

For applications that support Android 1.6 (API level 4) and higher, this is «true» by default and you should not set it «false» unless you’re absolutely certain that it’s necessary for your application to work. The only time it might be necessary to disable this is if your app directly manipulates bitmaps (see the Supporting Multiple Screens document for more information).

android:requiresSmallestWidthDp Specifies the minimum smallestWidth required. The smallestWidth is the shortest dimension of the screen space (in dp units) that must be available to your application UI—that is, the shortest of the available screen’s two dimensions. So, in order for a device to be considered compatible with your application, the device’s smallestWidth must be equal to or greater than this value. (Usually, the value you supply for this is the «smallest width» that your layout supports, regardless of the screen’s current orientation.)

For example, a typical handset screen has a smallestWidth of 320dp, a 7″ tablet has a smallestWidth of 600dp, and a 10″ tablet has a smallestWidth of 720dp. These values are generally the smallestWidth because they are the shortest dimension of the screen’s available space.

The size against which your value is compared takes into account screen decorations and system UI. For example, if the device has some persistent UI elements on the display, the system declares the device’s smallestWidth as one that is smaller than the actual screen size, accounting for these UI elements because those are screen pixels not available for your UI. Thus, the value you use should be the minimum width required by your layout, regardless of the screen’s current orientation.

If your application properly resizes for smaller screen sizes (down to the small size or a minimum width of 320dp), you do not need to use this attribute. Otherwise, you should use a value for this attribute that matches the smallest value used by your application for the smallest screen width qualifier ( sw dp ).

Caution: The Android system does not pay attention to this attribute, so it does not affect how your application behaves at runtime. Instead, it is used to enable filtering for your application on services such as Google Play. However, Google Play currently does not support this attribute for filtering (on Android 3.2), so you should continue using the other size attributes if your application does not support small screens.

smallScreens , normalScreens , largeScreens , or xlargeScreens attributes are used instead to determine the smallest screen required.

This attribute was introduced in API level 13.

android:compatibleWidthLimitDp This attribute allows you to enable screen compatibility mode as a user-optional feature by specifying the maximum «smallest screen width» for which your application is designed. If the smallest side of a device’s available screen is greater than your value here, users can still install your application, but are offered to run it in screen compatibility mode. By default, screen compatibility mode is disabled and your layout is resized to fit the screen as usual, but a button is available in the system bar that allows the user to toggle screen compatibility mode on and off.

If your application is compatible with all screen sizes and its layout properly resizes, you do not need to use this attribute.

Note: Currently, screen compatibility mode emulates only handset screens with a 320dp width, so screen compatibility mode is not applied if your value for android:compatibleWidthLimitDp is larger than 320.

This attribute was introduced in API level 13.

android:largestWidthLimitDp This attribute allows you to force-enable screen compatibility mode by specifying the maximum «smallest screen width» for which your application is designed. If the smallest side of a device’s available screen is greater than your value here, the application runs in screen compatibility mode with no way for the user to disable it.

If your application is compatible with all screen sizes and its layout properly resizes, you do not need to use this attribute. Otherwise, you should first consider using the android:compatibleWidthLimitDp attribute. You should use the android:largestWidthLimitDp attribute only when your application is functionally broken when resized for larger screens and screen compatibility mode is the only way that users should use your application.

Note: Currently, screen compatibility mode emulates only handset screens with a 320dp width, so screen compatibility mode is not applied if your value for android:largestWidthLimitDp is larger than 320.

This attribute was introduced in API level 13.

Источник

Supporting Different Screen Sizes Andorid

Mobile application run on different devices with different screen sizes and form factors. Android devices come in a variety of screen sizes and resolutions. That’s why handling the multiple screen size in android is most important.

Screen size : Actual physical size, measured as the screen’s diagonal.For simplicity, Android groups has four generalized sizes: small, normal, large, and extra large.

Screen density : The quantity of pixels within a physical area of the screen; usually referred to as dpi (dots per inch).For simplicity, Android groups has four generalized densities: low, medium, high, and extra high.

Orientation : The orientation of the screen from the user’s point of view.In Android, This is either landscape or portrait.

Resolution : The total number of physical pixels on a screen.In Android, we do not work directly with resolution; applications should be concerned only with screen size and density.

How To Support Different Screen’s

Use “wrap_content” and “match_parent”

To ensure that your layout is flexible and adapts to different screen sizes, you should use «wrap_content» and «match_parent» for the width and height of some view components. If you use «wrap_content» , the width or height of the view is set to the minimum size necessary to fit the content within that view, while «match_parent» makes the component expand to match the size of its parent view.

By using the «wrap_content» and «match_parent» size values instead of hard-coded sizes, your views either use only the space required for that view or expand to fill the available space, respectively. For example:

Notice how the sample uses «wrap_content» and «match_parent» for component sizes rather than specific dimensions. This allows the layout to adapt correctly to different screen sizes and orientations.

Use RelativeLayout

You can construct fairly complex layouts using nested instances of LinearLayout and combinations of «wrap_content» and «match_parent» sizes. However, LinearLayout does not allow you to precisely control the spacial relationships of child views; views in a LinearLayout simply line up side-by-side. If you need child views to be oriented in variations other than a straight line, a better solution is often to use a RelativeLayout , which allows you to specify your layout in terms of the spacial relationships between components. For instance, you can align one child view on the left side and another view on the right side of the screen.

Use Size Qualifiers

There’s only so much mileage you can get from a flexible layout or relative layout like the one in the previous sections. While those layouts adapt to different screens by stretching the space within and around components, they may not provide the best user experience for each screen size. Therefore, your application should not only implement flexible layouts, but should also provide several alternative layouts to target different screen configurations. You do so by using configuration qualifiers, which allows the runtime to automatically select the appropriate resource based on the current device’s configuration (such as a different layout design for different screen sizes).

For example, many applications implement the “two pane” pattern for large screens (the app might show a list of items on one pane and the content on another pane). Tablets and TVs are large enough for both panes to fit simultaneously on screen, but phone screens have to show them separately. So, to implement these layouts, you could have the following files:

res/layout/main.xml , single-pane (default) layout:
android:orientation=”vertical”
android:layout_width=”match_parent”
android:layout_height=”match_parent”>
res/layout-large/main.xml , two-pane layout:
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”
android:orientation=”horizontal”>

Notice the large qualifier in the directory name of the second layout. This layout will be selected on devices with screens classified as large (for example, 7″ tablets and above). The other layout (without qualifiers) will be selected for smaller devices.

Use the Smallest-width Qualifier

One of the difficulties developers had in pre-3.2 Android devices was the “large” screen size bin, which encompasses the Dell Streak, the original Galaxy Tab, and 7″ tablets in general. However, many applications may want to show different layouts for different devices in this category (such as for 5″ and 7″ devices), even though they are all considered to be “large” screens. That’s why Android introduced the “Smallest-width” qualifier (amongst others) in Android 3.2.

The Smallest-width qualifier allows you to target screens that have a certain minimum width given in dp. For example, the typical 7″ tablet has a minimum width of 600 dp, so if you want your UI to have two panes on those screens (but a single list on smaller screens), you can use the same two layouts from the previous section for single and two-pane layouts, but instead of the large size qualifier, use sw600dp to indicate the two-pane layout is for screens on which the smallest-width is 600 dp.

Use Layout Aliases

The smallest-width qualifier is available only on Android 3.2 and above. Therefore, you should also still use the abstract size bins (small, normal, large and xlarge) to be compatible with earlier versions. For example, if you want to design your UI so that it shows a single-pane UI on phones but a multi-pane UI on 7″ tablets, TVs and other large devices, you’d have to supply these files:

res/layout/main.xml: single-pane layout
res/layout-large: multi-pane layout
res/layout-sw600dp: multi-pane layout

Use Orientation Qualifiers

Some layouts work well in both landscape and portrait orientations, but most of them can benefit from adjustments. In the News Reader sample app, here is how the layout behaves in each screen size and orientation:

small screen, portrait: single pane, with logo
small screen, landscape: single pane, with logo
7″ tablet, portrait: single pane, with action bar
7″ tablet, landscape: dual pane, wide, with action bar
10″ tablet, portrait: dual pane, narrow, with action bar
10″ tablet, landscape: dual pane, wide, with action bar
TV, landscape: dual pane, wide, with action bar

Use Nine-patch Bitmaps

Supporting different screen sizes usually means that your image resources must also be capable of adapting to different sizes. For example, a button background must fit whichever button shape it is applied to.

If you use simple images on components that can change size, you will quickly notice that the results are somewhat less than impressive, since the runtime will stretch or shrink your images uniformly. The solution is using nine-patch bitmaps, which are specially formatted PNG files that indicate which areas can and cannot be stretched.

Источник