Introduction: an early matter

As you start developing a rich media application, you have to wonder how your application will react when facing devices diversity. The technical points that will have an impact for you regarding devices diversity will usually be:

• Screen size
• Operating System
• Man/Machine Interface (keypad, joystick, touch screen...)
• Various functional capabilities and limitations (video, network (2G, 3G...)...)

The objective of this article is to propose a methodology to handle properly the adaptation of your application to different screen sizes. We focus on this item because it is actually the one that has the most significant impact on the global design of a mobile applicable. Indeed it is very difficult to port an application to a new screen size if the screen size porting issue has not been taken into account from the beginning of the project.

The advantage of following the plan is that - if the plan is efficient and properly followed - future porting and adaptation will mainly rely on automatic adaptation. Even the manual part of the adaptation - when necessary - should be reduced to one simple and localized task instead of a bunch of code.

Whatever the initial scope of the project, one should always apply this adaptation plan so that future porting can be made easier. Projects often start with one demo on a single device but once the demo is approved you would better be prepared to fast and efficient porting...

One more thing: the term "screen size" is not really accurate, we should indeed use “screen resolution” but we chose to use "screen size" anyway in this article since it is the most commonly used expression.

Screen size families

We usually sort various screen sizes into families, which means that each screen size can either strictly match or be close to a defined family.

Here are the usual families that we have identified:

• "Portrait" families
  • 480x640, 240x320, 176x220, 176x208
• "Landscape" families
  • 320x240, 640x480, 480x320
• "Slim" families
  • 240x400, 320x480, 360x640
• "Square" families
  • 240x260, 320x320

Device screen size VS useable screen size

Among these families it is important to understand that the useable canvas is often smaller than the total screen size of the mobile devices. This is mostly applicable to J2ME devices. So the next noticeable point when we look at the screen sizes and the useable screen sizes is that we have screen size families and some slight variations within thosee families:

A 3-steps plan

Let's sum up the actions you have to perform in order to display a scene adapted to the current device screen:

• You must grab the static assets of the scene (bitmaps, texts, colors)
• You must layout those assets on the canvas
• You may adapt the assets (i.e. resize a bitmap for instance)
• You may add a few devices specific tricks (specific font adaptations, specific text spacing, etc...)

So this means that you need to be able to:

• Describe and organize your assets and eventually specify several sets of assets (per screen size family)
• Adapt & Layout in a generic way those assets (i.e. no magic number in the RSP code)
• Set some device specific properties also without having to modify deeply the RSP code

The screen size adaptation plan we propose intends to provide a step-by-step methodology and the tools you will need to achieve these.
We can identify 3 main phases to be implemented:

1 - Define a Skin and use it in your application code to reference the static assets

2 - Define the Layout and describe it independently from the scene description code itself

2bis - Eventually adapt the assets (either server side or client side) to fit the layout when needed

3 -Define the device specific properties and use the device database to handle device-specific cases

The tools to achieve it

Skin management

A Skin references all the static assets of the application: bitmaps, text, colors, and shapes.

A Skin is defined for a given screen size and is localized (i.e. can vary upon languages).

The purpose of the Skin API is to provide a generic interface to retrieve those assets. From your RSP code you will retrieve skin items thanks to key strings. This way the scene description code does not depend on the screen size.

Layouting & Adaptation

The Layouting module will allow you to specify the canvas layout. The canvas layout is a set of containers; each container has a logical ID and its own adaptation rules.

The actual size of the containers is computed at request processing and then, instead of having size computations in the RSP code, you can refer to containers size and positions.

Once the containers size and position are resolved, you can decide to adapt some graphical assets. You can use server side image transcoding & resizing capabilities to achieve this.

Device fine tuning

Once your page is fully set up to adapt itself as well as possible, 90% of the job is done. Now we all know that still there are some specific device adaptation that may be required.

Device fine tuning is this last (optional) step when you adapt some identified variables of your page for one specific device. Most of the time those parameters are related to text fonts.

The idea here is to make this phase as easy as possible and to avoid having to modify the RSP code on a device by device basis.

The implementation we propose is to externalize those properties in some properties files. One can define one property file per device. The role of the DeviceProperties module is to fetch the property file for the currently requesting User-Agent, depending on the device name, brand or model.

The DeviceProperties module also provides an API to access device specific information related to the Streamezzo Device Database. So one can retireve and test the current deviec information such as "is it touchscreen or not", "does it support feature XXX", etc...

Conclusion: towards a zero-cost porting

The objective of the strategy we propose here is to have - once applied - at least 90% for the screen size adaptation job done automatically. The only manual part of the adaptation that may still be done is to test on device and adjust some specific device properties (like font size) in a dedicated properties file. This way, applying such strategy can decrease dramatically the porting cost of applications.

There is even more to gain in applying those mechanisms, such as better code readability, design/logic separation which induces better application architecture and easier maintenance.

This article intends to give you an overview of the tools and practices to be used. You can find more in-depth information in other dedicated articles, in the products documentation and tutorials.

More on Adaptation Framework...

Adaptation Framework – Hands on
Adaptation Framework – Guideline: the "one size fits all" strategy