Best practices for targetting a wide range of devices and screen sizes.

Question

As you know android today is many versions many constructors, many screen sizes,...

it's quite difficult for developers today to write programs that targets a big part of devices.

What would be THE developer must-know practices for this ?

• tips for fluid layouts.
• "standards" for developing on any android version.
• ...

Any other ideas ?

Answer 1

I tend to use a mobile stylesheet that is only included when the app is accessed from a mobile device. This stylesheet generally applies a min-width (depending on user and device requirements), and fills the content up to 100% of the screen width.

Other suggestions:

• mobile-specific landing page, taken up entirely by a menu and a search box
• evaluate what content is actually important to a mobile user and focus on that
• No dead ends - even if a search returns zero results, make it easy to continue on (new search, page suggestions)
• geolocation if applicable (ie a
  google map showing store locations
  nearby)
• test on a variety of devices if possible (ie blackberry's native browser tends
  to have difficulty with jquery)

Answer 2

I agree with Johnny, use a mobile stylesheet. For example:

<link rel="stylesheet" href="screen.css" media="screen"/>
<link rel="stylesheet" href="handheld.css" media="handheld"/>

However whatever you do at the bottom of the page allow the user to interchange between the two. For example many 'mobile' sites include a link at the bottom to view the 'full' site. This way the user makes the concious decision over the capabilities of their device.

Answer 3

The only things I've found so far:

1. Develop to the lowest SDK version you can. I target 2.2, but only use APIs from 1.6 and so far (touch wood) that's worked out well. You can still support things like backup and move app to SD card thanks to these being driven by the Manifest.
2. For really small screens you will probably need a separate layout. Using the emulator I've found that just reducing the size of the graphics doesn't make the layout usable - you need to re-arrange and strip out some elements.
3. Sometimes you need a separate layout for portrait versus landscape mode - but often the portrait works fine in landscape.

It'll be interesting to see what other have to say - particularly around providing multiple drawable resources for different densities. I've not been able to isolate why it's sometimes required to use -hdpi and sometimes not to get good results on a hdpi screen.

Answer 4

For Layouts

First, you should start off by reading the official Supporting Multiple Screens Best Practices. There are a lot of good tips there, as well as a general idea on what you need to be looking for in terms of compatibility.

One thing I've found to be very helpful, which seems quite obvious, is to actually test your layout in various sized emulators. How does your layout look when expanded to 1024x768 (even though no device will have such a res)? How about when it's super tiny and square? Seeing how your layout stretches/contracts will help you tweak it to better fit all screens.

layout_weight

In layouts, android:layout_weight is a powerful, but under-documented attribute. Using it, you can create layouts where components are sized in percentages to each other.

For example:

<LinearLayout android:orientation="horizontal"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">

    <EditText android:layout_weight="80" 
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />
    <Button android:layout_weight="20"
        android:text="Button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content />
</LinearLayout>

In this layout, the <EditText/> will take up 80% of the available width, while the <Button/> will take up 20% of the available width. Obviously, this should be used carefully so that all items can still be usable even if they are small.

<include />

Another helpful layout practice is to bundle up common bits of your layout into separate files and include them using <include layout="@layout/smaller_section" />. That way, you can shuffle around other parts of the layout (say, for landscape), without having to keep entire parallel versions of the layout.