Introduction: an early matter

As you start developing a rich media service, you have to wonder how your service will face 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 (keypdad, joystick, touch screen...)
• Various functional capabilities and limitations (no video, network (2G, 3G...)...)

The objective of this article is to propose a methodology to handle properly the adaptation of your service 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 the service. Indeed it is very difficult to port a service to a new screen size if the screen size porting issue has not been taken into account at the beginning of the project.

The advantage of following a plan is that - if the plan is efficient and correctly 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 one 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 the correct term, we should 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 famillies, which means that each screen size can be equals or close to a familly.

Here are the 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 actually useable canvas is often smaller than the total screen size. This is mostly true for J2ME devices. So the next noticeable point when we look at the screen sizes and the usable screen sizes is that we have screen size families and some slight variations within thosee families:

 A three steps plan

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

• You must grab the static assets of the scene (bitmaps, texts, colors)
• You must layout those assets on the page
• You may adapt the assets (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 (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 define three main phases to be implemented:

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

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

2bis - Eventually adapt the assets (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 the 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 Streamezzo Layouting module will allow you to specify the page layout. The page 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 that.

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 still 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 to 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 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). This way, applying such strategy can lead to 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 easy 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