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.
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
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
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online