oftware engineering is all about choices. Choices have to be weighed: performance vs. scalability, complexity vs. flexibility, pros vs. cons, and good vs. poor design. In mobile application development, we have achieved that "many choices" state. In fact, in twenty years of software development, I cannot recall another time when there were so many choices. Before the days of Java vs. .NET, I recall interesting meetings to choose the programming language for a new application. Today's mobile application development environments make some of those choices look like child's play. So the good news is: we have so many choices! The bad news is: we have so many choices and we must choose wisely.
Look up "mobile development" in Wikipedia
, and you will notice the editors of this particular topic have listed 11 different choices for application development on a mobile platform. While the editors have done a good job of listing some of the more popular and widely used programming languages, environments, tools, etc. that same article admits that the listing is not complete. In fact, assembling such a list and keeping it up to date is nearly impossible. For example, just one day before writing this article, Apple released its SDK for the iPhone. New tools and platforms for mobile applications emerge all the time.
If someone else was responsible for choosing the platform for your mobile application development work, that limitsbut does not eliminateother choices. Alternatively, if you are in the position whereby your proposed killer app gets to determine the device platform, the playing field is wide open, and there are many options you need to explore; some have been around for some time, while others are just emerging. How do you choose? What are the factors to explore?
|So the good news is: we have so many choices! The bad news is: we have so many choices and we must choose wisely.|
Do you write a resident application (an application that physically resides and executes on the device) for the device or are thin client applications more appropriate? If you're thinking about thin client applications then what rich internet application technologies are available, and are they advanced enough for mobile devices? If writing a resident application, what technologies are the development option leaders, and what are the technical criteria for evaluating those options? Other articles in this DevX series provide more detail and practical examples to make some of the choices clearer.
Fat vs. Thin
One of software engineering's classic arguments does not go away in mobile application development: should the mobile device serve merely as a thin client tool to access enterprise application and data? Or is an intelligent application required on the device? How does this discussion change when you're dealing with a mobile environment?
Today, most mobile devices come with a browser. These browsers are often called mini or micro-browsers. Given the sophistication and capabilities of today's many devices however, there may be nothing "mini" or "micro" about them. Some browsers on mobile devices offer the same capabilities as a desktop browser. In fact, some believe the death of "native mobile applications" is happening or imminent and that mobile web applications are the future.
A mobile browser (sometimes called a micro-browser) can be used to access both web content and server-side applications, eliminating the need to write and deploy an application to the device. In the mobile development world, these types of devices are sometimes called "mobile internet appliances."
The capabilities of micro-browsers vary greatly. Furthermore, the limited connectivity of any mobile device requires the device to operate, at least on occasion, without connectivity. The very idea of "mobile" user is one that defies having to be tied to any network—even a network without wires. In my area of the country, people like to take long weekends and work from deep in the woods and boundary waters of the Mississippi River. Such cases require an application (and often some data) to be installed on the device. Devices that support locally-run applications are often called "smart devices," or "information appliances," indicating that they have more innate capabilities than those devices that solely offer connectivity. Application development for "smart" devices comes in many shapes and sizes. Some options are targeted toward specific devices while other options support a broader set of devices. Some options have high entry costs, while others are free/open source. You need to weight the features and aspects of all these development options and align the available features against the application requirements.
Thin Client Development
If you are lucky—really lucky, perhaps providing an application and associated data to your customers' mobile devices will be as easy as giving them your "normal" URL.
IDC has reported that it believes 1.3 billion (that's about 1/5 of the world's population) will be connected to the internet via mobile phone in 2008. With that much thin-client capability and connectivity, it's hard to ignore the mobile browser as a very viable means of putting mobile applications in the hands of your customers.
|Figure 1. "Normal" vs. Mini-Browsing: The image on the left shows Intertech.com through a normal browser while the images on the right display the same site through the Opera Mini browser (zoomed out and in).|
However, while accessible, most will find that their "normal" web site, let alone any Web application on that site, will not be usable via a mobile device browser. To give you an example, this URL
provides an online simulation of the Opera Mini browser (commonly found on many mobile devices) that you can use to access any web site. Figure 1
depicts my company's Web site in both a normal browser and through the "eyes" of a mini-browser. Try it out on your own web site.
If you can read the micro-browser version, you either have really good eyes or your web site has already been designed to display better in a micro-browser. Yes, you can "zoom" in and out using the micro-browser's features, but that's not always the most user-friendly of interfaces—especially when you don't know where to zoom in to find what you need. Never mind the fact that manipulating to a particular zoomed area on the screen requires, for some, motor skills akin to those required for playing video games. That's particularly true because mobile device browsers often have limited display space and interactivity (keyboard, pointing device, and so on).
The good news is that thin client development allows many organizations to reuse most, if not all, of the backend of their applications. Getting the apps to the device is also a lot easier. It's the user interface portion of the application that you may need to address to support the micro-browser thin client. Therefore, there are many considerations when writing applications to support the mobile device—even when using the device as a thin client.