This is a draft of a post that will be of interest to many. We would appreciate any comments from the community on how to improve it – feel free to send comments directly to us or to discuss on the web board.
In the beginning, when the only device was an iPhone with a 320×480 screen, laying out apps was easy. Today, that’s no longer true. App Studio supports 16 form sizes from 240×320 to 720×1280, along with custom sizes.
How can you design an app that looks good and runs well on all these devices?
Before getting to solutions, let’s mention tablets. The solutions in this tech note will deal with ways to resize your controls to match the screen size. This is usually not the complete solution to tablets. The larger size of the tablet often lets you do things like devote the left third of the screen to a navigation aid. For example, the iOS Mail app uses it to keep a list of messages. Consider redesigning your app for tablets.
Zooming
Zooming sounds like the obvious way to do this. Simply scale the sizes of all the controls to the new size of the screen. Twice as big? Double the width, height, top and left of all controls.
This is a bad user experience. Simply upscaling to the new size will result in buttons and fields being badly sized and positioned. On a larger screen, it might be reasonable to make textboxes larger, but buttons should stay the same size. Images, if scaled to a screen with a different aspect ratio (320×480 to 480×320), would be distorted. TitleBars and FooterBars should keep the same height, but get the new width. Lists should keep the same height per list item, but adjust the number of items shown and width. Text should stay the same size, etc.
If you want to do this, have a look at the Zoom sample on the web board:
<http://tech.groups.yahoo.com/group/nsbasic-app/files/>
Multiple Forms
The second approach is to design different forms for different form factors. For example, you could have a Form1Portrait (320×480) and Form1Landscape (480×320).
To make this work, you’ll need to separate your user interface logic from your processing. Since each control will have two versions (and two names), you’ll want them to save their value in global variables that your processing logic can handle.
The problem with this approach is the proliferation of different screen sizes. It would be a lot of work to maintain forms for all the different screen sizes… and new ones come along constantly.
Set bounds at Runtime
The best practice is to have some code that gets executed when the form shows and on orientation change. It would set the top, left, height and width to reasonable values. For example, the following code will change the form size to match the screen size, and change the TitleBar width to be the full width of the screen:
Form1.width="100%" Form1.height="100%" HeaderBar1.width="100%"
(Note: for Android 2.3 and older, you need to use the following code:
Form1.style.width="100%" Form1.style.height="100%" HeaderBar1.style.width="100%"
)
Here’s some code to reposition a TextArea. It uses the new (2.5.1.1) resize() function to set left, top, width and height in one call:
TextArea1.resize(20,100,Form1.width-40,Form1.height-200)
(Note: For Android 2.3 and older, you need to set the width and height separately.)
This technique can also be a lot of work – you’ll need to think about how every control on every form should be position and test the code.
Where to put the Code
The best place to put the code, whether you want to Zoom or Set Bounds, is in a Form1_onshow() function. It is called automatically for the first form of your project, as well as for any other forms you go to using the ChangeForm() command.
Rotation
Dealing with rotation is more complex than it seems. Different devices handle it in different ways. Here’s a great article on the complexities. This chart certainly shows there is a problem!