So you really want to be able to phone it in to your IBM i? This article explains the how and how much of mobile IBM i development.

We're in the throes of a revolution, one that I think took many of us by surprise. Yes, people have been using cell phones for a long time, and quite a few have figured out how to use first-generation smart devices such as BlackBerries as true business appliances. But the meteoric rise of the iPhone has fundamentally transformed the Web user interface landscape, making it almost a necessity for companies with a Web presence to have "an app for that." Meanwhile, the perfect storm of the Android operating system and the cost-effectiveness of large-form touchscreen hardware have significantly complicated the decision-making process. Just a few years ago, a thin-client Web application was all that was needed; now you have to decide whether you want to go rich or go native. And if you're going native, exactly which native are you going?

This article provides your initial guideline into that decision making process.

A Very, Very Brief History

The primary reason behind this history is just to make sure we have the terminology correct. Most of us probably agree on what constitutes a "smartphone" today but the reality is that the term is probably older than you might suspect. The original smartphone was an IBM device (surprised?) called Simon, and the first really mainstream smartphone came from Ericsson. And although the former was about as popular as the first IBM PC (not the one you're thinking of; in this case, the P stood for portable, not personal), the latter was actually quite successful. But let's be clear: back then (this was circa 1999), a smartphone was a device that made phone calls and also had email and text messaging in an LCD display with a resolution of somewhere around 100x50 2-color (black and white) pixels. Premium devices such as the Ericsson included some sort of PDA software and bumped the display up to a whopping 360x120.

Figure 1: The Ericsson R380 was the state of the art in smartphones in 1999, according to Popular Science.

I only bring all this up to make sure we move beyond that generation of devices. That first generation of devices can probably be said to end with the Palm and its competitors, such as the original BlackBerry. That's not to say that these companies haven't evolved their product lines; it's just that the bar was pretty much raised forever with the introduction of the iPhone, relegating these older phones to a historical niche equivalent to the old R380. Not that the original iPhone was that much of a revolution; 320x480 (also known as HVGA) isn't exactly burning down the house in the resolution department. But the combination of a solid screen and an excellent touch interface provided a momentum that was only further accelerated with the introduction of the App Store a year later.

And of course, the tipping point came with the mainstreaming of tablet computers, which after nearly a decade of languishing sales, exploded virtually overnight just last year with the introduction first of the iPad and then a torrent of competitive devices. And while some of the tablets (especially the higher end—read "more expensive"—devices) have Windows 7, a plurality of tablets and the overwhelming majority of smartphones use either Apple's iOS or Google's Android. Which brings us to the meat of this article.

Choosing a Mobile Development Model

So which way do you go to create a Web application? A lot depends on the actual business requirement, of course. In fact, for a lot of the more operations-oriented tasks (answer a message, release an output queue, etc.), little more is needed than a standard phone, perhaps with text messaging. Even the lowly Ericsson R380 could handle that. Traveling sales folks can get a lot of what they need via simple email requests: send an email with a specific request in the body, have a batch process monitor the incoming mail, and then send back a formatted PDF with a price sheet or a quote. A BlackBerry with a portable printer (or a nearby FedEx office) can handle that. Heck, today even some of the lower-end phones can handle 5250 emulation (there's an app for that!).

But let's assume that's not what you're after. Instead, what you want is something more interactive. Perhaps it's an executive dashboard: take a look at current sales numbers, see which business unit is down, drill into the backlog, find the hot orders that are holding things up, and then dial the sales manager in charge. This is a little more complex than a standard email message, and it requires a bit more development. Or take advantage of the hardware capabilities of your phone. Say you're on the dock and a delivery comes in with less-than-perfect packaging; you can take a picture with your smartphone, scan the barcode to get the actual shipment information and tag the picture to that shipment, and even get the driver's signature.

How do you do that today?

Well, to start, you have to decide whether you're going to go rich or go native. Going rich generally means using a purely browser-based solution, although considerable range exists within that broad definition. The two primary sub-categories are Rich Internet Applications (RIAs) and JavaScript toolkits.

RIAs are usually characterized by their reliance on a virtual machine of some type; here are some Adobe Flash Player Alternatives, but good old Java (in the form of applets) and Silverlight are also options. Each of these require the virtual machine to be installed, and while these all have relatively high penetration rates on PCs, they are less prevalent and in some cases not even available on various mobile devices. As an example, Apple is notorious for its lack of Flash support.

On the other hand, while JavaScript toolkits do not have as rich a palette of graphics capabilities to draw from, they are much more device-independent and indeed simply require a compatible browser. Dojo, as an example, runs quite nicely on everything from Internet Explorer to Mozilla to Safari to Opera. Your mobile device is almost certain to use one of those browsers, so if you build an application using one of those toolkits, you've got your mobile support automatically. Well, yeah, you have to write your application for the form factor of the device, but the infrastructure is there. Overall, JavaScript toolkits represent a powerful and cost-effective methodology, since a wide range of free tools are available.

The problem with either of these approaches is they have limited or no support for the physical hardware. Browsers tend to operate in a sandbox (for good reason) and typically the operating system won't let browser applications access the hardware. Because of this, it's hard to write a browser application that will, for example, take a picture. So these technologies are not adequate for one entire class of applications that I talked about at the beginning of this article. Note, though, that this isn't cast in stone and some of the tools have more functionality than others. Adobe Flash in particular has at least the hooks to be able to use some hardware, but that depends entirely on whether the mobile device will honor the virtual machine's requests. Such uncertainty doesn't make for a very good foundation on which to build an enterprise application.

On the other hand, if your business requirements skew more toward the dashboard side of the equation, you can still go with either the RIA or the JavaScript toolkit approach. And I would be remiss if I didn't at least mention that if you do decide that the Dojo style of toolkit will meet your business application needs, then you should take a serious look at EGL, which provides an integrated development environment that allows you to design multi-tiered applications that seamlessly combine RPG business logic and leading-edge Web 2.0 technology. I believe there's even a book on the subject!

So You've Decided to Go Native

Let's say you've decided that a browser-based solution doesn't cut it. You need access to hardware that you can't get otherwise, or you want an application with a look and feel that just isn't available from the various toolkits or virtual machines. Now you have to get serious about your decisions. First, you will not be able to create an application that runs on all devices. That's simply not in the cards today, and it's unlikely to be in the future. There is currently no solution like the Java Virtual Machine (JVM) that will allow you to run essentially the same application anywhere. And to be fair, even the JVM is limited in its ability to directly access hardware, which is the primary reason you'd probably choose to go native in the first place.

So one of the things you have to decide is which platform you choose to support.  As I noted at the beginning of this article, three options exist today, and unless you expect to use higher-end tablets, really only two are truly in the running: Android and iOS. Let's compare the development methodologies.

I'll start with the iPhone. I haven't actually done any iOS development. The bulk of my information on iPhone comes from an email exchange with Shannon O'Donnell, who has devoted some serious time to the issue. I then did some research on my own to verify some of the more salient points and give you some links. This isn't a detailed comparison, but the big differences are pretty simple.

First, until just recently your only option for building iPhone and iPad applications was the iOS SDK. Not necessarily a bad thing, but it definitely discouraged people who might want to use other techniques. Just recently Apple announced that it was lifting that particular restriction, although I'm not certain that the announcement does much for business application development; the Unreal Engine is clearly a gaming platform, but I suppose Adobe Creative Suite might allow you to create business applications. It's more of a Web content sort of tool, but in the right hands it could deliver some spiffy applications.

But for the meat and potatoes stuff, you would probably stick with the iOS SDK. The SDK is free, but there are a couple of quirks. First is the language. Apple uses Objective-C, which is going to seem like a pretty quirky syntax unless you're an Apple developer or a reformed Smalltalker. I'll let you follow the link to take a look at the language. The other issue is the licensing. In order to run applications, you have to install a Provisioning Profile. How this all works is about as complex an operation as I have ever seen. I'll let you review a comprehensive discussion of the operation here and let you form your own opinion (and note that this is just for individual developers, not enterprises). In any event, it costs $99 for an individual developer and $299 for an enterprise for the ability to create these Provisioning Profiles. And this is for applications you run internally; not necessarily ones you wish to publish to the "App Store.".

How Does Android Development Stack Up?

Development for the Android is considerably easier. A while back I wrote an article on choosing your Web development language, and in it I described the development process for Android. Basically, you download the SDK and use it to develop your application. The SDK includes a plug-in for Eclipse, which means you can install it into any of your Rational development tools, such as RDP or RDi-SOA, or into a standalone Eclipse workbench. The SDK also includes a powerful emulator.

Figure 2: This is the Android emulator from the SDK. (Click image to enlarge.)

I stole the image from my original article just to give you an idea of what the emulator looks like. I found it very easy to use and at times almost uncanny; clicking on the browser icon caused the emulator to actually invoke the native browser, which I could then use to surf the Web. Very Rube Goldberg, but also pretty impressive.

Furthermore, you use Java to develop Android applications. That was the focus of that previous article, and the basic message bears repeating: if you know Java, you can do a lot more with the IBM i than someone who doesn't. Whether it's taking advantage of the vast library of available Java software, extending tools like IBM's EGL language, or, in this case, creating powerful mobile applications, Java is probably the most important language you can learn after RPG.

More important to me, though, than the tool or the language is the ease of deployment. You use the SDK to generate an Android Package (APK) file. If you've done any Web development, the APK file is similar in concept to a WAR file for Web applications. Next, you install the APK on your phone and you're done. Ah, but how do you install it? Well, you can use a USB connection, and that's usually pretty painless. But I've found an even better solution. There's a utility called Dropbox that provides free cloud file-sharing. You install Dropbox on your workstation and then create a Dropbox account and you now have this virtual folder in the sky. You connect it to a folder on your desktop and whatever you copy into that folder (such as an APK) gets magically transported to the cloud. Then you install the Dropbox Android application and connect to the same virtual folder. You can then install the APK by just clicking on it. It's that easy. So conceivably you could create one (or more) enterprise Dropbox folders and distribute your applications by just dropping them from your workstation to the appropriate Dropbox folder.

I won't go into the security ramifications of these approaches; you'll need to address those within your own organization. Heck, the idea of Web application security is a huge one by itself. Even with browser-based applications you have security intricacies that we never imagined back in the green-screen days; native applications and locally stored data simply compound that issue. But from a pure logistics standpoint, Android's application distribution is unmatched.

So What's It Going to Be?

That's it for this first glimpse into the mobile world. Now you have to start making some decisions. Do you want to go with a browser-based solution, either RIA or JavaScript toolkit? Or do you need the more powerful capabilities of a native application? Each choice leads to other questions. But at least with this article you've gotten a head start into the decision-making process.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale

Also Read

TechTip: A Primer to Bootstrap 4, Part 2

TechTip: A Primer to Bootstrap 4, Part 1

A Hand-Holding App Builder for Handheld Devices