http://stackoverflow.com/questions/12242111/application-skeleton-to-support-multiple-screen

Application Skeleton to support multiple screen

up vote74down votefavorite 86

As we know Android coming with various device which having different Features, Resolution and Screen-size so while developing an Application which support multiple(small and big) screen there is an obstacle of size and layout. This leads to different combinations of screen sizes, resolutions and DPIs and creates quite a challenge when designing and developing for Android devices. While some other Manufacturer(non Android) have different resolutions and DPI, they share the same screen size and the resolutions follow the same aspect ratio. Therefore, an image can be created to fit the non Android devices. My question is that is there a proper flow or architecture that one should follow to meet the requirement? Remember we do have Tablets of different Size and Resolution. I'm aware that Android Developer contains this information but my view is from implementation. From my knowledge what I understood is that for designing Android graphics even Programmer must know the designing concept. android android-layout design screen shareedit edited Mar 19 '13 at 13:42 asked Sep 3 '12 at 4:48 hotveryspicy 22.7k75376

13   Are you Guys sure this question isn't constructive? –  hotveryspicy Sep 3 '12 at 5:03 6   I think it is very constructive. Would like to know the reasons of the down votes. –  Lazy Ninja Sep 3 '12 at 5:13 11   @MKJParekh take MicroMax Funbook gsmarena.com/micromax_funbook_p300-4701.php 7", 480X800, Ldpi (133 dpi) can you tell me in which category(drawble-large or Ldpi or if Android v3.0 sw-480) it will fall? –  hotveryspicy Sep 3 '12 at 6:55  1   @AZ_ :) We used this res structure in res folder drawable drawable-hdpi drawable-hdpi-v11 drawable-hdpi-v9 drawable-large drawable-large-hdpi drawable-ldpi drawable-mdpi drawable-mdpi-v11 drawable-small drawable-xhdpi drawable-xhdpi-v11 drawable-xxhdpi drawable-xxhdpi-v11 layout layout-small layout-sw530dp layout-sw720dp layout-xlarge values values-sw530dp values-sw720dp values-v14 values-xlarge and used well defined dimensions in xml from values folder. FYKI our application supports more than 5k types of devices. –  MKJParekh Aug 28 '14 at 8:52  1   @MKJParekh bro I have also used the same but I didn't use v9. Still haven't got any complaint from customer :) read this very informative opensignal.com/reports/2014/android-fragmentation –  AZ_ Aug 28 '14 at 9:58 show 2 more comments

2 Answers

activeoldestvotes

up vote117down voteaccepted

Finally created a structure which handle layouts and icon for multiple screen. Android generalises device displays into categories based on two parameters: Screen size, the physical size of the display (measured diagonally) Screen density, the physical pixel density of the display (in pixels-per-inch, or ppi)` To determine screen size & density quickly, please install "What's my Size" app for Android. Screen size Android defines four generalised screen sizes: Qualifier Size small ~3 inches (approx) normal ~4 inches (approx) large Exceeds 4 inches xlarge Exceeds 7 inches Most phones are classified as small or normal (roughly 3 to 4 inches diagonally). But now, there are many phones with large screen such as Galaxy S4, HTC One, Xperia Z A small tablet like the Samsung Galaxy Tab is classified as large (larger than 4 inches) Extra-large applies to large devices, for example large tablets Android defines four generalised screen densities: Qualifier Description Nominal value ldpi low density 120 ppi mdpi medium density 160 ppi hdpi high density 240 ppi xhdpi extra high density 320 ppi Typically: screen size has most impact on your app layouts screen density has most impact on your image and graphic resources It is listed here the percentage difference of device screen Ldpi- 75% Mdpi- 100% (base according to Android developer site) Hdpi- 150% XHdpi- 200% But as we know now most of device coming with 480X800 so I'm consider this as based device, so our new calculation will like this Ldpi- 50% Mdpi- 66.67% Hdpi- 100% XHdpi- 133.33% which means that first icon and design will be created for 480X800 only and then for rest ones(i.e. Ldpi, Mdpi, Xhdpi). There are images which are common for all layout and must uniform in color and shape(no complex shape, no curve) so for this kind of image we are creating 9patch which to be put in “drawable(no-suffix)” folder. To create 9Patch image you can either use DrawNinePatch orBetterNinePatch Now just rename your images based on Android's standards and complete your application with hdpi and then just take drawable-hdpi folder and Open Adode Photoshop(recommended) create Action of multiple size(just change the size according to percentage ratio) once Action created for all size then just do Batch Automate and give source(drawable-hdpi) and destination(drawable-ldpi, drawable-mdpi, drawable-xdpi). The reason I insist you to use Photoshop because it will resize automatically your image with Actions and one more plus point is that you need not to rename the file(it will assign same name as original one). once you completed with creation of all images, refresh your project and test it. Sometimes there may be possibility that the layout which support screen(xhdpi, hdpi, mdpi) may be get cut in small screen(ldpi) so for handling this just create separate Layout folder(layout-small) for it and add ScrollView(mostly). Thats it. Tablet Tablets are categorized into two size. 7"(1024X(600-48(navigation bar))) = 1024X552 (drawable-large) 10"(1280X(800-48(navigation bar))) = 1280X752 (drawable-xlarge) In this we need to create image for both the screen and just put them accordingly So all in all we will have this folder in our application to support multiple screen. drawable drawable-ldpi drawable-mdpi drawable-hdpi drawable-xhdpi drawable-large drawable-xlarge will be more qualifier combination with Screen size and Screen density drawable-large-ldpi drawable-large-mdpi drawable-large-hdpi drawable-large-xhdpi more qualifier with Screen density and Version drawable-ldpi-v11 drawable-mdpi-v11 drawable-hdpi-v11 drawable-xhdpi-v11 and more qualifier with Screen size and Version drawable-large-v11 drawable-xlarge-v11 and more qualifier with Smallest width concept(SW) drawable-sw???dp Further more in Android V3.0 Honeycomb they introduced new concept of SW(smallest width)in which device are categorized into screen width, so if we are creating a folder named drawable-sw360dp then the device with 720dp(either width or height) will use resource from the this folder. for example to find the Samsung Galaxy S3 dp to suffix to drawable-sw?dp With reference of DP Calculation, If you want to support your layout or drawable to S3 then the calculation says px= Device's width = 720 dpi= Device's density= 320 formula given px = dp * (dpi / 160) interchanging formula because we have px's value dp = px / (dpi / 160) now putting value, dp= 720 / (320/160); dp=360. so drawable-sw360dp will do the job Get you Device configuaration from GsmArena Sameway you can also create folder according to Device's Android API version i.e. drawable-hdpi-v11` so the device which is having API11 and it is Hdpi then it will use this resources. Additional Tips: Use relative layouts, dp, sp, and mm dp units - device independent pixels normalised to 1 physical pixel on a 160 ppi screen i.e. medium density. Scaled at runtime. Use for screen element dimensions sp units - scaled pixels, specified as floating point values, based on dp units but additionally scaled for the user's font-size preference setting. Scaled at runtime. Use for font sizes you should always use RelativeLayout for layouts; AbsoluteLayout is deprecated and should not be used. Use appropriate image formats - PNG versus JPEG Android "prefers" PNG for bitmap image files, "accepts" JPEG, and "discourages" GIF. However, PNG and JPEG are not equivalents. They have different quality trade offs, and PNG is not always best: JPEG can offer up to 50% file-size reductions over PNG, which is significant if your app is image-intensive A higher quality "lossy" JPEG may look better than a highly compressed "lossless" PNG, for the same file size Add labels to your images and graphics for debugging Use the supports-screens element Configure your emulators with real device values Conventionally, desktop systems display at 72ppi (Mac), or 96ppi (Windows, Linux). Compared with mobile, desktop displays are always low density. Always configure your Android emulators to mimic real device values, and always set them to scale to emulate device density. In Eclipse, it's easy to create multiple emulators (from the Eclipse menu bar, select Window > AVD Manager > New) configured with values for real devices: Name the emulator for the real device it's emulating Specify Resolution, don't use Built-in generic sizes Set the device density to match the real device (in the Hardware pane set Abstracted LCD Property to the real density, always an integer value) When you launch the device, always select Scale display to real size, and type in the real screen dimension in inches. If you don't set the device density, the emulator defaults to low density, and always loads ldpi-specific resources. Resolution (pixel dimensions) will be correct, but your density-dependent image resources will not display as intended. Of course, nothing you do will reproduce higher density image quality on a lower density desktop display. Here is the Data collected during a 7-day period ending on October 1, 2012. To see the latest statistic about Android platform version, go to here Based on Screen Size Based on Screen Density shareedit edited Oct 16 '13 at 15:48 community wiki 24 revs, 2 users 92%hotveryspicy

2   For samsung galaxy tab 7" we have to keep images under drawable-large-hdpi otherwise image will get stretched or shrinked. –  rajpara Sep 4 '12 at 7:08  @rajpara there are lot of combination and permutation, we will include all such cases later on. – hotveryspicy Sep 4 '12 at 7:10 5   +1 Great work man!! –  Dharmendra Jan 21 '13 at 6:42 1   see @AlexBonel, ya I do agree with you, but my main motto is to make aware how things can be done when it comes to Multi-screen support. One can modify/manipulate this flow/concept because the above is for making clear the initial problem. Additionally I too do modification based on application design. Your post giving me sense that you understood the concept. Hope you got my point. –  hotveryspicy Mar 19 '13 at 13:37  1   good tool here: marcosecchi.github.io/android_resizer_toolkit –  hotveryspicy Jan 27 '14 at 11:02  show 15 more comments