Handling Multiple Screen Sizes, Part Five
This is the first part of a several part series on handling multiple screen sizes in your Android projects. This material is adapted from a chapter in The Busy Coder’s Guide to Android Development, Version 3.0.
So far, in the previous posts of this series, we have focused on how you can ensure your layouts look decent on other screen sizes. And, for smaller screens than the norm (e.g., QVGA), that is perhaps all you can ask for.
Once we get into larger screens, though, another possibility emerges: using different layouts designed to take advantage of the extra screen space. This is particularly useful when the physical screen size is larger (e.g., a 5″ LCD like on the ARCHOS 5 Android tablet), rather than simply having more pixels in the same physical space.
Here are some ways you might take advantage of additional space:
Replace Menus with Buttons
An option menu selection requires two physical actions: press the MENU button, then tap on the appropriate menu choice. A context menu selection requires two physical actions as well: long-tap on the widget, then tap on the menu choice. Context menus have the additional problem of being effectively invisible – users may not realize that your ListView, for example, has a context menu.
You might consider augmenting your user interface to provide direct on-screen ways of accomplishing things that might otherwise be hidden away on a menu. Not only does this reduce the number of steps a user needs to take to do things, but it makes those options more obvious.
For example, let us suppose you are creating a media player application, and you want to offer manual playlist management. You have an activity that displays the songs in a playlist in a ListView. On an option menu, you have an “add” choice, to add a new song from the ones on the device to the playlist. On a context menu on the ListView, you have a “remove” choice, plus “move up” and “move down” choices to reorder the songs in the list. On a large screen, though, you might consider adding four ImageButton widgets to your UI for these four options, with the three from the context menu enabled only when a row is selected by the D-pad or trackball. On regular or small screens, you would stick with just using the menus.
Replace Tabs with a Simple Activity
You may have introduced a TabHost into your UI to allow you to display more widgets in the available screen space. So long as the widget space you “save” by moving them to a separate tab is more than the space taken up by the tabs themselves, you win. However, having multiple tabs means more user steps to navigate your UI, particularly if they need to flip back and forth between tabs frequently.
If you only have two tabs, consider changing your UI to offer a large-screen layout that removes the tabs and puts all the widgets on one screen. This puts everything in front of the user, without having to switch tabs all the time.
If you have three or more tabs, you probably will lack screen space to put all those tabs’ contents on one activity. However, you might consider going half-and-half: have popular widgets be on the activity all of the time, leaving your TabHost to handle the rest on (roughly) half of the screen.
Consolidate Multiple Activities
The most powerful technique is to use a larger screen to get rid of activity transitions outright. For example, if you have a ListActivity where clicking on an item brings up that item’s details in a separate activity, consider supporting a large-screen layout where the details are on the same activity as the ListView (e.g., ListView on the left, details on the right, in a landscape layout). This eliminates the user having to constantly press the BACK button to leave one set of details before viewing another.
You can see some of these techniques utilized in the EU4You sample applications, covered in The Busy Coder’s Guide to Android Development, Version 3.0.