Support MC Press - Visit Our Sponsors

 

Forums Sponsor

POPULAR FORUMS Rpg sql insert into qtemp table (2021 views) What is better, free code or traditional code ? (1751 views) cant ping workstation from system i (1420 views) was 7 nd server not starting (1251 views) SQL Error 802 Type 6 - Numeric Handling for Joins? (572 views) ODF Release April 28, 2012 (496 views)   Forums

 

 

Search Sponsor

Search

 

 

It seems like new Web language options appear every time you blink. The one you choose can make or break your Web development project, and this article is going to guide you toward the right choice.

Written by Joe Pluta

It's getting difficult out there. We've got more Web languages than we know what to do with, and we've heard no end of the pros and cons of each. People point out the sheer number of programmers for one language or the huge base of applications for the other. Some pundits appeal to purity of architecture; others swear by ease of use. The arguments are endless and opinionated and frankly pretty hard to objectively judge one way or the other. I mean, can you really make an informed decision—one on which you will potentially affect your company for years to come—based on whether or not a language is "dynamically typed"? No, you can't, any more than you can decide whether to buy a new TV based on its predicted contrast ratio. You need to make a business decision, not a technology decision, so in today's article, I'm going to present an argument that, if it applies to you, will be an absolute lead pipe lock.

Which Argument Wins?

How about none of the above? In this article I won't be rehashing any of the old arguments. Instead, I want to present an argument based on an aspect of the Web language decision that you've probably never considered before. The uniqueness of the argument stems at least partly from the newness of this topic. A picture is always worth 1000 words, so without further ado, let me show you a picture.

Figure 1: This is the primary screen of the emulator from the Android SDK. (Click images to enlarge.)

Figure 1 shows the very tech-savvy primary interface for the Android SDK emulator. I'll get into more details shortly, but let me first set up the back story. The Android operating system is Google's answer to handheld operating systems like Palm OS and Windows Mobile and is the framework for devices like the Droid smartphone.

Perhaps more important than what Android is, is what Android is not. Android is not a Web browser. Although Android devices like the Droid support a perfectly serviceable browser (one that even supports Flash!), their strength lies not so much in browser applications as in more fully graphical thick-client applications. Even the most comprehensive JavaScript widget libraries don't come close to the graphical capabilities of a thick client, and Android is no exception. Because it's not a browser, Android can do a lot of things a browser can't do.

Figure 2: This is a simple finger-painting application.

Figure 2 shows the sort of graphical application that you're not going to find in a pure HTML browser interface. On the smartphone, I can simply slide my finger across the screen to draw on the virtual canvas. With the emulator, I use the cursor and mouse as shown. Now, you could do this in Flash. You could probably even do it in JavaScript, although I don't want to even think of the amount of code involved. With Android, it's a couple of hundred lines of code.

A Brief History of Communications

In a way, we've gone full circle with this. First we had thick-client applications that ran on the PC. The problem with these was that they had to be custom built and we had trouble keeping the applications up to date, not to mention issues with different hardware and screen resolutions and so on. The Web browser removed those worries by providing a standard canvas on which to work, at the price of a severely limited pallet to work with. The simplicity of the interface (HTML) gave rise to an explosion of Web development options; scripting languages in particular made broad inroads into the development community because of their ease of use.

However, users quickly became restive with the limitations of the HTML interface. The rise of Flash technology in particular made it more and more difficult to satisfy power users with simple HTML pages, and for a while it looked as though the Web application tool selection would be a war between virtual machines such as Flash and competitors like Silverlight. Meanwhile, though, a different branch of the Web evolutionary tree brought us more and more sophisticated JavaScript widget libraries, in which the browser itself became the virtual machine.

All of these options had one thing in common: they were moving toward increasingly powerful graphics capabilities. And had we stayed with the PC as our primary communication device, we probably would have seen the two evolutionary paths—dedicated graphic VM and JavaScript widget library—continue to dominate the application space, with each having its own specific niche. However, the smartphone and its bigger, badder cousin, the tablet PC, have changed the landscape drastically once again.

The Mobile Business Device

The real impetus behind this revolutionary change is the simple cell phone. While the smartphone is the instrument of the new graphics application, the demand came from the way the cell phone became integrated into the daily business life of everyday people. The phenomenon started simply as text messages and email, which quickly became indispensable as an extension of the workplace terminal. As this integration of mobile access to business became accepted and even commonplace, it lent credibility to the cell phone as a business device and set the stage for the smartphone.

The smartphone is a revolution. Although WiFi-enabled laptops take the workplace out of the office and netbooks make browsers available nearly anywhere, neither one has the same level of personal convenience as the smartphone. And while nobody would argue that a smartphone is a replacement for a PC for, say, writing articles (or programs!), it is perfect for applications that require more graphics and less typing, applications like network monitoring or contact management. Heck, with speech-to-text applications, even the typing aspect becomes less of an issue. I still wouldn't want to write much code using a Droid, but that's why the Android SDK exists, which brings us ever so gracefully to the original question: which language should I use for Web development?

Android, Linux, and Java

I hope it's no surprise to you that the Android operating system is based on the Linux kernel. Linux is wonderfully suited for the smaller footprint of a mobile device. Thus, a good preparation for development of Android applications is a basic understanding of Linux. It's not necessary to be a guru by any means; personally, I know just enough to be dangerous and I do fine. I've only "bricked" my emulator a couple of times (bricking is the act of completely trashing the OS on the device, turning it into an expensive brick).

More important than Linux knowledge, though, is Java expertise. By knowing the Java programming language, you are immediately able to program applications for the Android. Add to that some Eclipse skills, and you can download the Android SDK plug-in and you are off to the races. Add to that the fact that the whole shooting match is open source, and you suddenly have an attractive, cost-effective way to extend your enterprise applications at a reasonable cost. What sort of applications? Well, here's a simple one:

Figure 3: With just a few lines of code, I accessed an RPG-CGI server on my i.

I took a very simple example (that I got from the Internet) and added a few lines of my own code.

   public void onClick(View v) {

      String result =

         com.pbd.test.RestClient.connect(

            "http://" + PbdSystem.iHost + "/cgi-bin/POLLCGI2.PGM");

      mText.append("Result: " + result + "\n");

   }

How did I do this? Well, I know Java, so I was able to intuit that the onClick function is called when the button is clicked. I found an open-source REST client that I was able to modify to my needs, and with my knowledge of Eclipse, I was able to include it in my Android project. After that, it was simply a matter of adding the call to the REST client within the onClick function.

Do you see where I'm going with this? If you want to program the Droid, you need to know Java and Eclipse. With Java skills, the Droid becomes a powerful extension to your enterprise. The example above showed how a few lines of code allowed me to call an RPG program from my phone.

Not the Only Solution

Android is not the only possible solution to the mobile interface question. Some companies have said the heck with it and have focused all their development on HTML-based Web applications. Some have decided to use Flash. Other companies have standardized on the Apple products: the iPhone and the new iPad. Unfortunately, the various approaches tend to be mutually exclusive. Flash, for example, doesn't run on the Apple products, and statements from Apple management indicate no change in that policy for the foreseeable future.

But by learning Java, you can have what might be the best of both worlds. Although I didn't touch on it in this article, Java is a very capable thin-client application-development language. In fact, JavaServer Faces (JSF) is one of the premier frameworks for thin-client development, and the best tools are Eclipse-based. Those skills can then be further leveraged to build Android applications for devices like the Droid. And Android isn't just for smartphones; various companies have introduced or are planning to introduce tablets based on the Android OS. The tablets are priced far below the price of the iPad, and they even run Flash!

But to me the immediate future of business application development centers on the smartphone. There is no one-size-fits-all option. The most common OS is probably Symbian (the foundation of the Nokia line of phones). The primary language for Symbian is C++, but Java is also supported (along with a surprisingly wide variety of other languages). BlackBerry uses Java ME, and Droid uses Java as well. In fact, about the only smartphone that doesn't do Java is the iPhone. And while the iPhone may be the more recognizable name, the language of the iPhone is niche: who do you know that programs in Objective C? Unless you know some Mac programmers, the answer is likely "nobody."

Over the coming weeks, I plan to write some Droid applications that use the i as the host. If you believe, like I do, that smartphones are a key component of your development strategy, then you too should try developing some applications. And once you do, I'm certain you'll find that Java is indeed the best Web language.