Purpose

Writing an appMobi application for multiple devices can prove to be a challenge. The issue is essentially that the devices have different native resolutions. Applications with too small a resolution cause the application will look “blocky” or “fuzzy” when it is scaled up to run on a device with a larger resolution. For example, here are a few popular mobile devices and the native resolution of each:

Device	Platform	Width	Height
iPhone 3 / iPod	iOS	320 pixels	480 pixels
iPad	iOS	768 pixels	1024 pixels
Motorola Incredible	Android	480 pixels	800 pixels
iPhone 4	iOS	640 pixels	960 pixels
Samsung Galaxy	Android	600 pixels	1024 pixels

This article will outline the risks involved and provide solutions to help developers create an application that is as flexible, attractive, and solid as possible.

Developing Applications – Two Options

There are two schools of thought to writing an application that displays appropriately on multiple devices. The first technique is that the developer builds the application UI once and scales it appropriately to all devices. This type of application is built to the width of the largest device supported and uses the AppMobi.display.setViewport command to size the application down to fit on devices with a smaller resolution. The second school of thought assumes that the developer detects the platform as the application starts up and makes appropriate modifications to the UI, essentially repositioning the UI for each supported device. There are benefits and drawbacks to both techniques.

Detecting the platform

AppMobi.device.platform
Getting the inner width & inner height of the document to get the actual dimensions
Using CSS to wrap text

Using the viewport commands

Wait until after the viewport command runs to make the <body> tag visible
Don’t try to do viewport and rotation at the same time

Dealing with device rotation events

appMobi.device.orientation.change
Getting the inner width & inner height of the document to get the actual dimensions

Option One: Build Once

One feature of appMobi applications is that they can be built to scale the screen size from one platform to another. Applications that are built to scroll vertically are particularly good for this option because the HTML elements can be built to “flow” to fit the appropriate size. This feature makes it particularly easy to create an application that looks appropriate on many devices.

Build it big and scale it down

To build an application for this case, scale the application for the biggest screens and then allow the hardware to display at the specified width using the AppMobi.display.setViewport command. Just like the Mike Teevee’s chocolate bar in “Willy Wonka” ( http://en.wikipedia.org/wiki/Charlie_and_the_Chocolate_Factory#The_Television_Room ), we’ll build the application for the biggest screens and then use the device’s browser software to shrink the page to fit. While scaling an application up creates “fuzziness” or “pixilation”, scaling an application down to a smaller resolution just sacrifices some of the small detail that would be visible on larger devices.

For example, suppose the customer requires an application that displays properly on both the iPad and the iPhone. The iPad has a native resolution of 1024x768 pixels, but the older iPhone has a resolution of 320x480. In order to build an application that would look appropriate on both devices, the application should be built with an HTML component that was fixed at 768 pixels wide (assuming the application runs in portrait orientation).

When the application starts up, the appMobi Javascript library will throw the appMobi.device.ready event to indicate that it has loaded. At that point, the application can successfully use the AppMobi.display.setViewport command to set the “virtual resolution” of the application.


document.addEventListener("appMobi.device.ready",onDeviceReady,false);

/* This code runs as soon as appMobi activates */
function onDeviceReady() 
{
	//set Viewport
	AppMobi.display.useViewport(768,1024);
}

document.addEventListener("appMobi.device.ready",onDeviceReady,false);

/* This code runs as soon as appMobi activates */

function onDeviceReady()

{

//set Viewport

AppMobi.display.useViewport(768,1024);

}

“Dead Space” Issues

There is a trade-off to building the application at maximum size and sizing appropriately. Unfortunately, this technique forces developers to give up valuable screen space on certain devices. Because the screen ratio of these devices vary from device to device, creating an application using this “build once” method will result in some “dead space” in the application on some platforms. Take a look at the diagram below.

Description: portrait

When an application runs on a device other than the iPad in portrait orientation, there will be some unused space visible at the bottom of the screen. Developers must fill this space with non-essential elements just to reduce users’ confusion.

Description: landscape In Landscape mode, the opposite of the portrait “dead space” problem is evident. Since handheld devices are longer and skinnier, when the viewport sizes the application down there will be space on the iPad that is simply not visible on Android or iPhone handheld devices.

Orientation Issues

Because sized applications suffer from two very different forms of “dead space” issues between landscape and portrait orientation, building an application using this technique makes it very challenging to also build in the ability to handle orientation changes. Developers can turn off orientation changes by calling the AppMobi.device.setAutoRotate command, and then set the default orientation for the device using the AppMobi.device.setRotateOrientation command. Call those two commands as soon as the appMobi.device.ready command is available along with the AppMobi.display.useViewPort command.


document.addEventListener("appMobi.device.ready",onDeviceReady,false);
/* This code runs as soon as appMobi activates */
function onDeviceReady()
{
//set Viewport
AppMobi.display.useViewport(768,1024);

//lock orientation
AppMobi.device.setRotateOrientation("portrait");
AppMobi.device.setAutoRotate(false);
}

User Interface Sizing Issues

Another issue that makes a “build once” application problematic is that UI elements must be built with the smallest screens in mind. Although the iPad can easily support a screen with five or six icons wide, an iPhone or Android handset device will require an icon that is at least 120 pixels square to look appropriate after being sized down for smaller devices. Before deciding which of these two methods of multiple resolution design concepts to use, make sure that the application audience is fine with a particularly large-looking user interface on devices with a larger resolution.

Option Two: Sense and Modify for Each Platform

On the other hand, applications can be built to sense what type of device it is running on and adjust the user interface accordingly. This option is best for applications that don’t scroll and aim to provide an experience closest to a true native application.

This option will make the application faster to load as well since the device’s processor won’t have to work on the task of scaling all the UI elements for the application whenever something must be shown on the screen.

Sense the Device

Using the Javascript navigator.userAgent command, a developer is able to detect which platform the application is running on. Call it once the appMobi.device.ready event is fired to make sure that appMobi is available first.


document.addEventListener("appMobi.device.ready",onDeviceReady,false);
/* This code runs as soon as appMobi activates */
function onDeviceReady()
{
	if (navigator.userAgent.toUpperCase().indexOf("IPHONE")!=-1 ||
	navigator.userAgent.toUpperCase().indexOf("IPOD")!=-1)
	{
	//size for the iPhone
	}

	else if (navigator.userAgent.toUpperCase().indexOf("IPAD")!=-1)
	{
	//size for the iPad
	}

	else if (navigator.userAgent.toUpperCase().indexOf("ANDROID")!=-1)
	{
	//size for an Android handset device
	}
}

Sense the Screen Dimensions

Further, applications can detect the screen dimensions using the Javascript screen.width and screen.height parameters. Based on that data, a developer could have the application react by loading alternate CSS3 documents and Javascript libraries. These alternate files would then alter the UI elements size and position accordingly. Use the CSS3 rules below to build application stylesheets:

Rule	Use	Example Rule
position	Use the position rule to place UI elements by pixel coordinate in an application. This rule must be set in order to take advantage of the top, left, bottom, and right rules.	position:absolute;
top/bottom	Use one of these rules to position UI elements vertically. The top rule positions the element from the top of the parent element, while bottom positions the element up from the bottom of the parent element.	top:30px; bottom:25px;
left/right	Use one of these rules to position UI elements horizontally. The left rule positions the element in from the left side of the parent element, while the right rule positions the element in from the right side of the parent element.	left:25px; right 100px;
width	Use this rule to scale the width of a UI element .	width:250px;
height	Use this rule to scale the height of a UI element.	height:120px;
display	Use this rule to turn on and turn off UI elements in the application.	display:none;

For more information on CSS rules, check out w3Schools’ CSS tutorial online here:

http://www.w3schools.com/css/default.asp

To include external CSS3 documents, add a style element referencing the filename to the head element of the application’s HTML document.


<link href="CSSFILENAME.css" rel="stylesheet" type="text/css" />

Effort Issues

Unfortunately, sizing for each device comes with a cost. The user interface for the application must be designed for every device it supports. Once the application is finished, testing on multiple devices must be done to make sure that the application performs correctly.

Conclusion

Consider creating applications using the “build once” approach for applications that don’t require orientation changes and are able to “flow” using customary CSS positioning rules. Developers building an application that is meant to feel more like a native application should eschew some of the conventions of the web consider sticking with a more specialized approach of sensing each platform and modifying the user interface appropriately.