The ability to create great mobile applications for the IBM i presents many very exciting opportunities.

It's no secret that mobile computing is hot, hot, hot. But, for you non-believers, consider these numbers:

Figure 1a: Smartphones outsell PCs in 2011 for the first time.

Figure 1b: It's predicted that by 2014 there will be 2 billion Android devices in use. It's also predicted that by 2014 there will be 2 billion PCs in use. That means that Android devices did in six years what it took PCs 32 years to do! (Click here and here.)

Figure 1c: Apple sold 145 million iPhones in four years; it took 28 years to sell 122 million Macs.

As these numbers indicate, mobile is irreversibly and irrefutably here to stay. Many years ago, pundits told us that UNIX/Linux would replace the desktop—but it never did. At least until we could put it in our pocket. With mobile clearly here to stay, let's also be realistic about the future of the desktop—especially in the business world. Mobile devices (especially tablets) may indeed replace a substantial percentage of consumer desktop computers, but in the enterprise there is a still a lot of work we need PCs to do. Despite the recognition that desktop PCs won't be disappearing off of enterprise desks anytime soon, it is important for IBM i businesses to acknowledge and consider the growing importance of mobile devices in the enterprise.

Getting Off of the Dime

It's no secret that decisions in the IBM i midrange enterprise move slowly. In fact, I know of a few IBM i decision-makers who drive to work in cars adorned with "They can have my 5250 Model 11 when they pry it from my cold, dead fingers" bumper stickers.

Despite a general reluctance to embrace new things, from my recent conversations with hundreds of customers (literally), mobile computing is indeed hot in the IBM i arena. And not only is it hot, but the demand for it is becoming more focused. At the last two ASNA developer conferences (in the fall of 2011 and spring of 2012), attendees all agreed that they needed mobile apps, but they couldn't articulate exactly what the business case was for mobile yet; they only knew they were being asked about mobile computing—and the need was coming from the top tier of the organizational chart.

Fast forward to late this summer and this fall, where I've been on the road doing Web and mobile development workshops for customers and prospects. I've noticed a substantial sharpness when attendees address their need for mobile computing. Example applications and use cases roll off the tips of their tongues without much thought. There have clearly been many mobile discussions in the last six months in these customers' and prospects' meeting rooms.

If you're dragging your feet on mobile, give the Google Mobile Playbook a look. Using plain language, it compellingly explains what mobile computing can do for business (the cynical side of me thinks that for Google to tell us that is like your dentist insisting that cotton candy is good for your teeth!).

It's Not Just Emotional This Time

Many of us are veterans from the great GUI wars of the early '90s. Remember those days? Visual Basic was but a baby. The green-screen was frustrating us then (nearly a quarter a century ago!) and perceived as old-fashioned. We all got GUI fever. ISVs could quickly prove the ROI for eliminating the green–screen, but for most vertical application development the GUI had an elusive ROI metric. It was hard to measure the business value of dropdown menus and radio buttons over green-screens. But we couldn't help it; we needed that GUI. Had to have the GUI. For many years, IBM talked up the importance of, among others, C, SmallTalk, Visual Age for RPG, OS/2 and the "polymorphic GUI," Java (remember the ad in NEWS/400 that implied if we RPG programmers didn't learn Java we'd all be flipping hamburgers!), WebFacing, and HATs as avenues with which we could cure our GUI fever. Alas, virtually everyone one of those strategies du jour in the IBM midrange community was stopgap at best, and if not that, an outright failure.

The third-party was there as well. Here at ASNA we sold many copies of our first ASNA Visual RPG (AVR) product; that product focused nearly exclusively on fat Windows front-end client development for what we used to call the AS/400. Visual RPG's early successes proved that, at least in the heyday of the mid-'90s, not every technology needed solid proof of an ROI before its adoption. One of the lessons we learned back then is that rarely is an enterprise technical decision driven purely by technical factors. There are also many social, political, and emotional factors at play. Back in those days, it was often developers, excited about playing with new shiny things, that helped feed the need for a GUI.

The Mobile Push

Fast forward to the debt-ridden, employee-reduced, scratching-for-business early 21^st century. Technical projects are on hold or being doled out slowly. Every project is scrutinized for ROI and a definitive reason to exist. And fewer developers are available to work on whatever projects do get the green light.

But then along comes mobile computing. Mobile applications in the enterprise aren't about the nebulous payback of dropdown menus or radio buttons. Nor are they about replacing the green-screen. They are about empowering a work force in innovating, cost-saving, business-changing ways. Mobile applications present the biggest technical advance we've seen for a long while in the enterprise. These devices defy existing work flows, existing computing models, and existing expectations. It's not overly dramatic to say that mobile computing changes everything. It does.

Having been cable-bound for so long to work with our IBM i workstations, the vistas that open up when you consider mobile computing are nearly endless. Supervisors can walk and manage shop floors effortlessly using iPads as 5250 devices; the mobile sales force has information at its fingertips; retail businesses are now able to move the cash register out to where the customer is (I bought produce from a farmers market in the middle of a field the other day, and the vendor's iPhone was his cash register); and dispatchers have instant access to fleet locations and work progress. And these are the obvious things. Clever, business-defining uses of mobile devices in the enterprise are being created every day.

Unlike previous technical revolutions, the mobile revolution is unique in that it's generally driven by a BYOD (bring-your-own-device) mindset. That is, for the first time ever, end-users are bringing their own devices to you and saying, "Hook me up, please." In the old days, we took apps to them and said, "Look what I have for you now." Today users show us their personal smartphones and say, "When can I run your app on this? That's where I really need it." When PCs first appeared, their use in the enterprise was championed from the bottom up by a rogue band of geeky rebels; today the use of mobile computing devices in the enterprise is being championed from the top down by CEOs and executives.

Back in the day of GUI fever, fulfilling our desire for a great UI didn't instantly open the door for new business opportunities, cost-saving work flows, or the ability to create dynamically and profitable new business models. Mobile computing does all that and more. The savvy IBM i decision-maker who ignores mobile computing today is making a huge mistake.

Mobile Imposed Differences

Despite the pressing need for mobile in the enterprise, it's important to remember that to quench the thirst for mobile means understanding its constraints and the differences it imposes on our legacy desktop computing model. For example:

• Mobile devices have a vastly reduced screen size. The common two-finger "pinch" gesture generally always reduces the size display, and you can use your fingertips to scroll to different parts of the smaller display and put them into focus. However, to be truly effective, enterprise apps probably shouldn't work that way. Enterprise apps will generally make users more effective if their displays are tailored for the size of the device being used. This may mean that some apps work better on tablets than on smartphones. It also may imply that the app is responsive enough to change itself and dynamically configure itself to provide the best experience for the mobile device currently being used. Remember, too, that mobile devices also offer the ability to change their display orientation between portrait and landscape.
• Mobile devices don't have a mouse or keyboard. Most of the interaction is through touch and gestures. For greenfield apps, built especially for mobile devices, this is usually an easy constraint to resolve. However, the lack of a keyboard (especially a keyboard without function keys) presents substantial challenges when using an existing IBM i green-screen application on a tablet.
• Mobile devices have limited battery life. This isn't exclusively an enterprise issue; all mobile users are quite familiar with the steps required to keep a mobile device running all day long (why, oh why, are electrical receptacles such a precious resource at airports!). But it is something we must consider as we attempt to resolve enterprise challenges with mobile devices. The more "active" an application is (e.g., constantly polling for a changing GEO-encoded location), the more quickly it sucks life from the mobile device. For many of us, programming for mobile will remind us of the every-byte-counts programming style we used for the S/36!
• Mobile devices are highly dependent on network connectivity. Again, this isn't unique to enterprise uses of mobile, but it is something we need to consider. Mobile applications may need to exploit local storage on mobile devices, and they may need to be more gracious about broken connectivity to be good mobile citizens.

Native or Not?

In addition to the previously mentioned mobile-imposed differences, the model of the mobile application should be considered. The two prevailing models are native and HTML/JavaScript/CSS (which is condensed to just HTML for most of this article).

For native applications, Java is the language generally used for the Android, and Apple's Objective C is the language generally used for the iPhone/iPad. Both of these languages (especially Objective C—it doesn't even have implicit garbage collection in the mobile runtime!) have substantial learning curves. And the integrated development environments also offer their own steep learning curves.

For most enterprise applications, the costs to create device-specific applications are generally beyond the budgets of most businesses. It takes a very large customer base to make most native efforts affordable. Angry Birds amortizes high development costs over millions of users. It is true that going native potentially offers a little closer affinity to the hardware (e.g., access to the accelerometer, the gyro, the camera, and the touch screen), but the HTML model has rapidly matured on the most widely used mobile platforms to recognize hardware APIs. For example, the accelerometer and gyroscope are available to JavaScript on both Android and Apple mobile devices. Touch and many other facilities are also easily available to JavaScript.

Beyond hardware access, the HTML model provides a very strong user experience on mobile devices. One of the things we've learned at ASNA with mobile applications is that they are held to a pretty high "do they look and feel right" standard by users. Savvy mobile users can spot a bogus, off-by-one mobile UI in a heartbeat, so a high affinity for what looks and feels right is very important. And that look and feel can be achieved by the HTML model.

Taxonomy of Mobile Computing for the IBM i Enterprise

Having discounted native development for mobile applications in the IBM i enterprise, let's classify mobile computing for the IBM i. To do so, we need to be specific about where and how mobile will be used, what devices are being used, and what software is needed. At ASNA, we've defined three specific areas of mobile computing and the problems they solve.

The first area of mobile IBM i mobile computing is the use of existing IBM i software on mobile devices.

There are many environments, represented notably by manufacturing and healthcare, where users need instant, mobile access to existing IBM i 24x80 or 27x132 applications. These aren't "mobile" applications, mind you; these are simply existing applications that need to be used on mobile devices. The applications are tested, deployed, and connected to substantial back-end workflows and server devices. The business problem they represent is that someone needs to use them from any physical access point. In some ways, this model may be considered less like "mobile computing" and more like offering "mobile workstations." Call it what you want, it's a critical need for many IBM i shops.

In most cases for this model, tablets are the mobile device of choice. Assuming a superb emulator or enhanced display file is available, tablets provide the form factor required to render existing green-screen applications in a rational, usable manner without modification or other preparation. Do note that the quality of the emulator or enhanced display is critical to providing a great user experience on a tablet. ASNA's browser-based emulator and its Wings product are both optimized for use with Apple or Android devices—especially tablets.

The two screens below show how an unmodified green-screen looks using ASNA's browser-based emulator in an iPad. We took great care to make our emulator's "keyboard" feel natural and effortless for users. Function keys must be available, but users don't want them in the way. Figure 2a shows the ASNA emulator in action on an iPad. Figure 2b shows an ASNA Wings-enhanced display file in action on an iPad. This display reacts naturally to touch, and while it doesn't look like it was written from scratch for the iPad, it provides a very good user experience. The Wings mobile user experience is also high value in that it is very economical to produce and use.

ASNA Wings uses IBM's Open Access API, so the underlying RPG that is driving the enhanced Wings displays is essentially unaware that its user interface has been so dramatically enhanced. ASNA Wings provides a seamless way for you to present your existing IBM i applications with very little effort. In fact, although Wings' primary reason for being is to let you create enhanced displays (like the one shown in Figure 2b), with the ASNA emulator (which is included with Wings) it also provides a great no-effort mobile-enabler if all that your users need is a superb tablet-friend emulator.

Figure 2a: A 5250 green-screen running in the ASNA emulator on an iPad.

Figure 2b: A Wings-enhanced display file displayed by an ILE RPG program on an iPad.

The Second and Third Areas of IBM i Mobile Computing

The first area of mobile computing focuses on using existing IBM i applications with mobile applications. Because of their form factor (which enables tablets to display existing applications well without modifying the display file), tablets are generally going to resolve challenges in the first area of mobile computing. The second and third areas of IBM i mobile computing are similar in that both of them address the need to create new IBM i mobile applications. These applications will work with either tablets or smartphones—but anecdotal customer interviews indicate that smartphones are the much bigger target for these new applications.

The result of the second and third areas of mobile computing, at least from the end-user perspective, is very similar, if not identical-looking for the end-user. The end-user has a mobile application, tailored for mobile use, with the appropriate look and feel. However, the two areas diverge substantially in how the new mobile applications are created. Before we discuss these two areas in detail, let's first examine why you might want to write new applications at all for mobile—after all, you have tons of applications on your IBM i—so under what circumstances would you ever need more of them? Aren't IBM i applications like Paul McCartney songs? Do we really need any more of them?

Many (most?) legacy applications are monolithic beasts with nearly every element of the 24x80 screen filled with data. These applications were designed for a back-office, start-'em-and-stay-in-'em work flow. These legacy applications were also written at a time when performance was taken for granted. We didn't spend much time worrying about network throughput when the network was nothing but a 60' twinax cable. The legacy apps opened many (many, many in most cases) files and flowed tons of data between the IBM i's DASD and the 5250 devices.

Mobile applications are the polar opposite of their slothful, monolithic legacy forebears. Where our legacy IBM i applications included everything but the kitchen sink, mobile applications are focused like a laser on delivering very specific chunks of information for very specific tasks. Great care is taken to deliver just the data needed to fulfill a very focused (and small!) display. Performance isn't taken for granted; mobile apps are written to pessimistically assume the data pipeline is slow. The focus, scope, performance, and specificity required to fulfill the demands of mobile computing usually precludes using existing applications for specific mobile tasks.

Beyond the dramatic application model difference, another thing that makes us need new applications for mobile devices is the fact that in many cases mobile computing resolves challenges that green-screen applications never faced. Mobile computing often steps up to fulfill business needs that used to be resolved manually and with batch processing. For example, it was impossible for mobile employees (e.g., truck drivers out on a day-long delivery route) to use 5250 devices to punch in and out for lunch. Therefore, analog work flows were created for these tasks in the old days. With the right software in place, mobile steps up to gracefully resolve these old, antiquated analog work flows.

The reality is, for most IBM i businesses needing mobile applications today, unlike Paul McCartney songs that we just don't need any more of, we are probably going to need a new family of IBM i applications targeted specifically for mobile users. Having established that we probably need some new applications to fulfill our mobile demands for the IBM i, how do we get them? That brings us to the definition of the second and third areas of mobile computing for the IBM i. Remember that as far as the end-user is concerned, assuming well-crafted development tools are used, the result of these two areas is for all intents and purposes indistinguishable. Under the covers, though, two very distinct programming paths are taken to arrive at the result.

The second area of mobile IBM i mobile computing is the creation of new software for mobile use with traditional RPG III or IV programming experience.

Although we've heard a lot lately about the demise of the RPG programmer, and it is true that some are rapidly reaching retirement age, there are still thousands of RPG programmers with great programming skills in IBM i shops today. Given the right mobile-enabled tools, these programmers could easily develop the next generation of mobile applications for the IBM i. The key, though, is "given the right mobile-enabled tools."

These RPG coders need a programming model that bridges their traditional RPG programming expertise with the ability to create, and connect to, a great mobile user experience. In Q1 2013, ASNA will release ASNA Mobile RPG (MR) to solve this challenge. MR empowers RPG programmers to create superb mobile applications. The displays in Figures 3a, 3b, and 3c show an example of the type of mobile user experience you can expect with Mobile RPG. You can read more about ASNA Mobile RPG at http://asna.com/us/mobilerpg.

MR provides a Windows-based designer used to create mobile displays with a point-and-click model. Once created, the MR Mobile Display File is compiled on the IBM i as a display file object. An RPG programmer then writes an RPG program using this display file. At runtime, the RPG program thinks it is communicating with the traditional display file, when in fact it is communicating with the MR Mobile Display File—which is displaying on a smartphone or tablet.

MR was specifically designed to put mobile development in the hands of traditional RPG programmers who do don't know, or have the time to learn, HTML, JavaScript, CSS3, Java, or Objective C. The MR Mobile Display File designer hides away those details and simply lets RPG programmers be productive quickly with their existing skills.

In 1994, ASNA introduced ASNA Visual RPG, and that product revolutionized IBM i application development for thousands of customers around the world. ASNA Mobile RPG will do the same thing for IBM i mobile application development for the traditional RPG programmer! Stay tuned!

Figure 3a: A mobile application driven by either ASNA Mobile RPG or by ASNA Visual RPG. This screen lets a user select the first letter of a customer's name.

Figure 3b: After tapping a letter on the screen shown in Figure 3a, the user can scroll down the necessary customer, or the customer can be searched the search box at the top of the list.

Figure 3c: After tapping the correct customer on the screen in Figure 3b, this screen is displayed to show customer sales detail.

The third area of mobile IBM i mobile computing is the creation of new software for mobile use by PC-centric developers.

Just as many IBM i businesses have traditional RPG programmers available to create mobile applications (again, given effective tools!), there are also a great number of IBM i businesses that have VB, C#, or ASNA Visual RPG programmers who also want to create great IBM i applications.

While there are many approaches to building this type of application with these languages, a very popular model has emerged called a "single page" application, where the HTML, the JavaScript, and the CSS are delivered to the mobile device with one payload. A single-page app is created with two primary components: a server-side component that provides data to the mobile presentation layer and an HTML5 presentation layer. The data is provided with Web services serving up JSON data to the mobile client (and conversely, receiving it back from the mobile client).

Because ASNA Visual RPG has such a great affinity for the IBM i database, it makes a great language with which to write these JSON-providing services. These programs are hosted on a Windows Web server and read IBM i data and translate it to and from JSON for consumption by the HTML5 presentation layer. There are a great many open-source libraries (such as jQuery, jQuery Mobile, Dojo, and Knockout.js) that facilitate the creation of the mobile user interface. ASNA Visual RPG works very well with single-page mobile apps and with these open-source libraries. In the case of having VB or C# programmers, they can use ASNA Visual RPG to focus on the data services and then scaffold the rest of the application with the language of their choice for the rest of the back-end.

Creating mobile applications like this generally requires a team atmosphere; there are, to be clear, several critical skills required to stitch this type of application together. But there are many IBM i programming team members who either already have many of these skills or are ready and willing to learn them. If your team has programmers like this, the third area of mobile is a great way to fulfill your IBM i mobile needs.

The Mobile Challenge Awaits!

The ability to create great mobile applications for the IBM i presents many very exciting opportunities. These applications have the potential to be a generation of business-changing, workflow-defining applications. They will keep your business competitive, relevant, and vibrant. And for many shops, resolving the mobile challenge will revitalize its programmers with new and exciting applications to create.

As you can see, there are several great ways to use mobile computing with your IBM i. Regardless of how you need implement mobile computing on your IBM i, ASNA is there to help!