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?
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.
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.
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?
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1