Render IBM i Web Pages to a Smartphone

Article ID: 64668

Posted February 1st, 2010

Application Modernization

Breathe new life into IBM i apps by "mobilizing" them

By:

Do you want to breathe new life into your IBM i applications? If so, then serve them up on a smartphone, such as Apple's iPhone or Research In Motion's (RIM) BlackBerry, via the phone's built-in web browser. We have long been able to render IBM i DB2 data for browser display. Rendering the data to meet a smartphone's form factor makes your applications truly mobile.

Even if you've never written a web application before, by following the simple recipe here you'll be able to build feature-rich mobile applications with compelling visual presentations tailored to smartphone—particularly iPhone—displays. You'll also learn some tricks for maximizing use of a phone's screen space, changing page layout automatically to meet browser requirements, and writing server-side functions specific to mobile computing. Although the supplied examples aim at iPhone web apps, the techniques can be applied to any smartphone web interface.

Optimizing for the iPhone

Just to be clear, there are two types of applications that run on the iPhone: iApps and WebApps. iApps are separately downloaded native applications written in Objective C; WebApps run directly from a web server and are written in a combination of HTML, CSS, and JavaScript. They're displayed in the iPhone's web browser. If the web server is an IBM i, the WebApp can be written in RPG. This article focuses specifically on writing WebApps.

The first thing to know when generating HTML for the iPhone is that it uses Apple's Safari browser. When interpreting HTML, Safari is less forgiving than Internet Explorer (IE) but not as rigorous as Firefox. This means that if a page has a pleasing rendering in Safari on a desktop, it will likely look good in IE and be at least functional in Firefox. However, by sensing the browser type, you can tailor your application to a specific display environment.

The second thing to know is the screen dimensions: 320 pixels wide by 480 pixels high, (320 x 480) in portrait mode. Conversely, the dimensions are 480 x 320 in landscape mode. The viewable portion of a web page is known as the viewport and is generally pegged at 980 pixels for the width of a page, even for the iPhone. If you don't change the default viewport for a page designed to conform to 320 x 480 or 480 x 320, the page will appear in the top left corner of the iPhone screen. To avoid this problem, you need to include <meta> HTML tags to "scale" the viewport to the device width, as follows:

<meta name = "viewport" content = "width = device-width">
<meta name = "viewport" content = "height = device-height">

Including these <meta> tags in the header section of every HTML page causes Safari and most other web browsers to scale the content to fill the screen, whether on a desktop or an iPhone.

In addition to screen form factor, you should consider the unique user navigation capabilities of the iPhone. Users can employ finger gestures—tap, flick, pinch, and stretch—to navigate and resize the content on the display. The conventional wisdom for iPhone web apps is that pages should scale down to 320-pixel width when in portrait mode, rather than being styled with 320-pixel width initially and then having to be stretched to 480-pixel width for landscape mode.

Normally a web browser displays the URL at the top of the page, which consumes some display space, as Figure 1a shows. You can hide the URL to increase display space using a trick called rollup, which auto-scrolls the display to just after the URL section. An onLoad JavaScript event handler in the HTML <body> section lets you do this:

<body onLoad="setTimeout(function() {window.scrollTo(0,1)}, 100);">

Figure 1b illustrates the effect of the rollup code. The user can still manually scroll down to the URL and associated controls if necessary, but the default page presentation now shows significantly more of your application page.

Exploiting Cascading Style Sheets

Cascading Style Sheets (CSS) is an HTML coding technique that lets you separate document content and presentation, to specify HTML-style properties such as colors, fonts, and layout more consistently. (For more information about CSS, see "Use CSS to Give Your Web Pages Style," article ID 62756 at SystemiNetwork.com and "The Basics of Cascading Style Sheets," article ID 20938.) You can exploit CSS with iPhone apps by coding "styling" specifications in a separate file with a .css extension.

By changing which .css file you select based on the requesting browser type, you can apply a completely different set of style attributes to a page, which lets you automatically tailor a web app for the iPhone (or any other browser). You use a <link> tag to reference a specific .css file; the media clause of the statement detects when an iPhone is in use, based on sensed display attributes, selecting the iPhone-specific style sheet when appropriate:

<link href='PCTHRStyle.ccs' type='text/css' rel='stylesheet'>
<!--[if !IE]-->
     <link media="only screen and (max-device-width: 480px)"
          href='iTHRStyle.ccs' type='text/css' rel='stylesheet'>
<!--<![endif]-->

In my opinion this constitutes a "hack" but is nonetheless very effective. By default the style sheet PCTHRStyle.css will be used except when the browser is not IE. In that case, the code tests to see whether the only screen and max-device-width clauses are present, signaling that an iPhone (and Safari) is being used, overriding the style sheet to iTHRStyle.css. Figure 2a illustrates the default page rendering, and Figure 2b shows it rendered using the iPhone-specific style sheet (the iPhone screen must be scrolled via "flicking" to view the entire page). Figure 3 is a side-by-side comparison of the two style sheets.

CSS is just one tool in your HTML arsenal for tailoring web app appearance. Sometimes you need more than just a style sheet change. In those cases, it may be best to provide completely customized HTML as separate web pages. You can do that by using HTTP redirection.

Device Detection and Redirection

If you're coding HTML for multiple mobile platforms, sometimes the style changes are too radical for a simple CSS makeover (see the sidebar "A Word About BlackBerry Smartphones," below, for some considerations when coding for browsers on BlackBerry mobile devices). HTTP servers supply environment variables in the initial HTTP response that contain information such as the IP address of the requester, the referring HTML page, and the browser being used. One such environment variable is userAgent, which identifies the browser device (as opposed to browser software) being used. The variable hails from the days when Netscape Navigator reigned supreme, and it is used today with that legacy attached.

The following JavaScript snippet uses the userAgent environment variable to "navigate" to a different HTML page depending on the device being used.

<script>
if (navigator.userAgent.match("BlackBerry") != null) {
          window.location="Blackberry.html"
     }
else {
     if (navigator.userAgent.match("iPhone") != null) {
          window.location="iPhone.html"
     }
     else  {
          window.location="Laptop.html"
           }	
     }
</script>

Screen Orientation and Beyond

Another useful environment variable window.orientation, which contains a value expressed in degrees giving the current orientation of the device:

0 = portrait mode
90 = landscape left
-90 = landscape right

There is also an event window.onorientationchange that detects a change in the device and to which a function call is attached. The function could change the positioning of some browser elements to accommodate the new orientation. For example, three elements may be stacked into one column and three rows in portrait mode but as one row and three columns in either of the landscape modes (via conditional coding similar to the conditional CCS example discussed earlier).

Conditional CSS and redirection can be combined to render reports for the iPhone, which often benefit from landscape orientation. Figure 4 illustrates a report in landscape mode. One technique to simply and quickly convert program-described RPG report programs to HTML is replacing the PRINTER file with a SPECIAL file and having the associated exit-point program be an RPG CGI program rendering output to the browser. The only other program change needed is to remove print skip and space values, since they apply only to printer files. A single exit-point program could be used in all program-described RPG report programs in your application.

You can extend information rendering further by exploiting web-based services such as Google Charts to do graphics processing that yields pie charts, dashboard gauges, bar graphs, and the like. (See "Better User Interfaces for Your Web Apps," article ID 57095 and "Application Webfacing Solutions Product Roundup," article ID 63075 for more information about services and products that you can use to customize information rendering.) Figure 5 is a gallery of the types of displays you can generate for both the iPhone and other smartphone platforms.

Mobilize Your i Apps

Breaking the shackles of the printed report and 5250 display by shifting to a mobile browser brings you a whole new world of information-presentation options. By mobilizing your apps, you'll let your users be effective from more locations, making them more responsive to changing business conditions. What are you waiting for? Mobilize today!

Trevor Seeney is an experienced software developer and technology consultant with Sentinex. Recently, Trevor has developed web-facing applications in RPG and PHP. His current focus is rendering System i data and metrics onto smartphones with emphasis on the iPhone.

A Word About BlackBerry Smartphones

Canalys, a company that provides expert analysis for the high-tech industry, reports that the RIM BlackBerry enjoys a 20.9 percent share of the smartphone market, compared to the iPhone at 13.7 percent. (Nokia leads with 44.3 percent). For the second quarter of 2009, however, Canalys also reports mobile browsing by platform, as Figure A shows.

To me these figures are shocking. Although BlackBerry sales dominate the market, hardly anybody uses the browser on it. Two out of three people accessing the Internet from a smartphone use an iPhone. The BlackBerry achieved corporate acceptance long before the iPhone came into existence, and even today some consider its phone and email features stronger than the iPhone's. Plus the BlackBerry is more tightly integrated into corporate technology infrastructures. But my own experience confirms that the BlackBerry browser is difficult to use and provides inconsistent renderings of web pages, some to the point where they are virtually unreadable.

Is this a harbinger for the future? Will Blackberry improve its browser before the iPhone gains corporate acceptance, or will its corporate market share diminish? Many people I know favor the BlackBerry because they've had bad experiences with AT&T. The BlackBerry is offered by a number of carriers, whereas the iPhone is currently limited to AT&T. There might well be a jump in iPhone sales from Q4 2009 to 2010 with the expiration of the exclusive AT&T deal.

What is the smartphone developer to do? In my opinion, you should redirect BlackBerry web users to a separate HTML document, but use conditional CSS to vary the renderings for iPhone and desktops, as needed.

—T.S.

Bookmark/Search this post with: