0

need help for multiple screen support in android,I have done for 3.2 inch screen completely.and i have added some hard coded values for layouts and items in it.What size should be the size of images in drawable ldpi,mdpi,hdpi?I want to support all screens(only for mobiles), Please help me..

thanks

JCJ
  • 135
  • 2
  • 4
  • 12
  • read this documentation and all your questions will be answered and still if there are any confusion then ask. http://developer.android.com/guide/practices/screens_support.html cause one can tell you image size of Background not all icons and imagebutton used in your app..so please first read this. – MKJParekh Nov 01 '11 at 07:30
  • Check my existing answer: http://stackoverflow.com/questions/7414178/multiple-screen-support-do-we-need-different-layouts-for-each-screen/7414264#7414264 – Paresh Mayani Nov 01 '11 at 07:37

1 Answers1

3

I think by reading this you should be more than prepared to deal with your problem. I could have briefly explained how to do this, but after reading this you should be able to fully understand how this works.

How to Support Multiple Screens

The foundation of Android's support for multiple screens is its ability to manage the rendering of an application's layout and bitmap drawables in an appropriate way for the current screen configuration. The system handles most of the work to render your application properly on each screen configuration by scaling layouts to fit the screen size/density and scaling bitmap drawables for the screen density, as appropriate. To more gracefully handle different screen configurations, however, you should also: •Explicitly declare in the manifest which screen sizes your application supports By declaring which screen sizes your application supports, you can ensure that only devices with the screens you support can download your application. Declaring support for different screen sizes can also affect how the system draws your application on larger screens—specifically, whether your application runs in screen compatibility mode.

To declare the screen sizes your application supports, you should include the element in your manifest file.

•Provide different layouts for different screen sizes By default, Android resizes your application layout to fit the current device screen. In most cases, this works fine. In other cases, your UI might not look as good and might need adjustments for different screen sizes. For example, on a larger screen, you might want to adjust the position and size of some elements to take advantage of the additional screen space, or on a smaller screen, you might need to adjust sizes so that everything can fit on the screen.

The configuration qualifiers you can use to provide size-specific resources are small, normal, large, and xlarge. For example, layouts for an extra large screen should go in layout-xlarge/.

Beginning with Android 3.2 (API level 13), the above size groups are deprecated and you should instead use the swdp configuration qualifier to define the smallest available width required by your layout resources. For example, if your multi-pane tablet layout requires at least 600dp of screen width, you should place it in layout-sw600dp/. Using the new techniques for declaring layout resources is discussed further in the section about Declaring Tablet Layouts for Android 3.2.

•Provide different bitmap drawables for different screen densities By default, Android scales your bitmap drawables (.png, .jpg, and .gif files) and Nine-Patch drawables (.9.png files) so that they render at the appropriate physical size on each device. For example, if your application provides bitmap drawables only for the baseline, medium screen density (mdpi), then the system scales them up when on a high-density screen, and scales them down when on a low-density screen. This scaling can cause artifacts in the bitmaps. To ensure your bitmaps look their best, you should include alternative versions at different resolutions for different screen densities.

The configuration qualifiers you can use for density-specific resources are ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high). For example, bitmaps for high-density screens should go in drawable-hdpi/.

The size and density configuration qualifiers correspond to the generalized sizes and densities described in Range of screens supported, above.

Note: If you're not familiar with configuration qualifiers and how the system uses them to apply alternative resources, read Providing Alternative Resources for more information.

At runtime, the system ensures the best possible display on the current screen with the following procedure for any given resource: 1.The system uses the appropriate alternative resource Based on the size and density of the current screen, the system uses any size- and density-specific resource provided in your application. For example, if the device has a high-density screen and the application requests a drawable resource, the system looks for a drawable resource directory that best matches the device configuration. Depending on the other alternative resources available, a resource directory with the hdpi qualifier (such as drawable-hdpi/) might be the best match, so the system uses the drawable resource from this directory.

2.If no matching resource is available, the system uses the default resource and scales it up or down as needed to match the current screen size and density The "default" resources are those that are not tagged with a configuration qualifier. For example, the resources in drawable/ are the default drawable resources. The system assumes that default resources are designed for the baseline screen size and density, which is a normal screen size and a medium density. As such, the system scales default density resources up for high-density screens and down for low-density screens, as appropriate.

However, when the system is looking for a density-specific resource and does not find it in the density-specific directory, it won't always use the default resources. The system may instead use one of the other density-specific resources in order to provide better results when scaling. For example, when looking for a low-density resource and it is not available, the system prefers to scale-down the high-density version of the resource, because the system can easily scale a high-density resource down to low-density by a factor of 0.5, with fewer artifacts, compared to scaling a medium-density resource by a factor of 0.75.

Fofole
  • 3,398
  • 8
  • 38
  • 59
  • you could have post the link directly..without making efforts to copy..and it would help the other also to view the full content. – MKJParekh Nov 01 '11 at 07:33