If you don't already have a mobile development strategy, you'll need one soon, and one of the first choices you'll need to make is which language to use for development.
Mobile development is the next great wave of development. Like it or not, mobile devices are becoming ubiquitous and your IT strategy is going to have to support them, both for B2C (Business to Consumer) and B2E (Business to Employee) architectures. And the really bad news is that if you're only just now figuring out your browser strategy, you're probably a couple of years and at least one development paradigm behind the curve. This article will try to bring you up to speed really quickly.
Where Are We and How Did We Get Here?
This isn't a tongue-in-cheek question. Taking a step back and looking at the bigger picture is the only way to get a productive sense for the subject, especially if you're currently immersed in the tail end of the last cycle. You need to see the forest instead of the trees. So, what are these cycles of which I speak? Well, they're the larger architectural currents that drive our somewhat more insulated world of business applications. Computer architecture moves in waves. Each wave is distinct, but the waves share similarities as well. For example, when we had this discussion 20 years ago (you remember that, don't you?), we were talking about which languages to use on PCs that would talk to our midrange applications. We argued about devices: IBM PCs or clones? We argued about platforms, Windows or OS/2, and whether to use Basic or C or C++ (or Pascal or Smalltalk). Ten years ago, the discussion was superficially very different because we were talking about browsers and the World Wide Web, but really was it all that unique? We were talking about devices (which browser), platforms (CGI or servlets or IIS) and languages (Java or Visual Basic or Perl or PHP).
It's 10 years later still, and now we're talking about Brand New Challenges (TM, patent pending)! We're talking about devices (desktops, phones, and tablets), platforms (Android and iOS and BlackBerry), and languages (Java or Objective-C or C#)! Which maybe isn't so new after all; in fact, maybe it's exactly what we've been talking about forever. The only difference is that the problem is getting larger, maybe even exponentially larger, as the number of moving pieces skyrockets.
A Quick Look at the Choices
So what are the choices these days? While this article will focus on language, decisions of device, platform, and language are as interconnected as they always have been. If, for example, you somehow manage to choose Objective-C as your primary programming language, you've pretty much narrowed your focus to nothing but Apple products and iOS. But let's see what the options are and where they take you.
And that's when you start delving into the world of native programming, and the language question quickly becomes murkier. Actually, it's not really all that hard to point you at the languages; it's just that there are no one-size-fits-all answers. But at least we can finally get down to the topic of this section and ultimately of the article itself. What are the programming language options for developing mobile application? It depends on the device, and here are your choices:
- Android devices—Pretty much all use Java as their native programming language.
- The Apply family of iThings—These require Objective-C.
- BlackBerries—Older ones use C++; newer ones support Java.
- Windows phones—This is the most quirky environment. Options range from VB.NET to C++ to C#. There's also the ongoing discussion about whether Windows 8 will completely change up the Windows development world as the new Metro UI can be implemented via pure HTML5, a .NET/XAML interface, or the more truly "native" XAML/C++ programming. It's all very confusing.
To Recap the Options
One other issue with native applications: they cannot be delivered via the browser. Native applications generally need to be installed on the device, usually after being downloaded from some sort of store. While Android is developer-friendly in how it handles distribution, Apple really makes you jump through hoops. But however you look at it, when you go native, you'll need a way to deliver your software.
Sorry About That Whole PHP Thing
And for those who have sidetracked down the PHP road, I'm sorry but basically that's a whole lot of wasted time in the mobile world. Any of the server-side scripting languages are next to useless when it comes to mobile devices. Whether it's one of the three Ps (PHP or Perl or Python), or the Microsoft bastion of ASP.NET, or my particular favorite scripting mechanism, JavaServer Pages (JSP), none of these makes sense any more in the brave new world of hybrid applications. Instead, you're going to be designing UIs that live on the mobile device and populate themselves via JSON calls to services on the host. Yes, you can probably write those services in PHP or JSP, but frankly, if you've got the same skill set I do, you're probably better off just doing it in RPG-CGI using something like CGIDEV2 or just writing your own RPG wrappers. Rather than designing and modifying UI scripts on the host, you're just going to parse JSON requests and send JSON data back. You might in rarer circumstances use XML or even SOAP as your transport protocol, but the point is that generating HTML on the server is a thing of the past, so all the scripting languages that support it are also headed out to pasture.
A Road Less Traveled (at Least for Now)
So hopefully I've provided you with a quick look at the landscape. There is no silver bullet; the language is entirely dictated by the device. If you need native access to the device, you need to learn to program it, unless you decide to embrace the hybrid model. Whatever you decide, mobile development is definitely not just an extension of your existing Web applications, even Web 2.0, so you probably want to take some time to assess your strategy before your end users start making your decisions for you.