The term "fat" hardly seems fitting, given that many applications that reside on a mobile device measure a few kilobytes in size. However, the term here is used to refer to those applications that are deployed to and execute on a mobile device versus the use of a micro-browser to access data and an application from the server. The term fat-client originated in our desktop world where fat or "thick" clients were larger than the browser application. A term used in some literature that more appropriately suggests the nature and size of these applications is "resident" application.
Building an application to reside and execute on a platform brings a whole other set of considerations and issues versus thin client development. Again, these considerations are neither good nor bad. Considerations are just aspects for your evaluation.
|It's probably more important to assemble a list of application platform options only after first answering a basic question: are you writing to a device or writing to an application platform?.|
Writing to a Device or Writing to a Platform
Unlike thin (browser) client mobile applications, resident applications are going to be more dependent on their device platform. If the device platform has already been selected, this can limit your options considerably. If, however, the platform (device and application platform) is going to be selected on the best technology available to field the needed application, well then, the number of options just got a lot bigger.
Earlier, I referred to the Wikipedia page that listed 11 mobile development platforms. While I applaud those that have tried to collect such a list, you have to look at the list and understand that it's a bit of an apples, oranges, and maybe even grapes (and a few other fruits) comparison. That's because it's a combination of some device platforms, some application development platforms, some RIA technologies and some general programming language alternatives. For example, you can write Java ME applications for Symbian OS and Palm OS devices; all three are listed as mobile development options.
Today, any such list of mobile development platforms is going to run into the same issues. That's why it is probably more important to assemble a list of application platform options only after first answering a basic question: are you writing to a device or writing to an application platform?
I use the term "device platform" here to refer to a mobile hardware device and its operating system and/or its integrated software. The term "application platform" is used here to refer to the combination of programming language, general development API, and the runtime environment for that language on the mobile device. The application platform runs on top of the device platform.
So, when looking at resident application development, start with what might have already been decided—namely the device platform. If the device platform is set, then some—and maybe all—of your application development choices have been decided for you. If the device platform has not been picked, then you have research on application platforms ahead.
Writing to a Device
Has your device and/or the device's operating system already been decided? Now your choices are probably more limited. Since portability (at least broad portability) is probably not as much of a concern, you want to explore and probably even use the SDK, tools and device emulator provided by the device or OS provider. Most of the major device platform vendors provide such tools for their devices. Since you are working with a specific device (or set of devices), many of the other issues that must be considered when working with a vast array of products such as performance and access to the device's features and functionality (phone, camera, GPS, and so on) are probably more straightforward. The table below (Table 4) lists some of these device platforms and what they offer in the way of SDKs, tools, etc.
Table 4. Device Development: When writing an application to a specific device (or set of devices) or device OS, the vendor of that device platform often provides an SDK, emulator, and other tools that can help developers write applications specific to that platform.
Writing to an Application Platform
||Developer Web Site
||C++, Java, Ruby, Python, Perl, OPL, Flash Lite, .NET
||Carbide.c++ IDE (Nokia)-C++ and Java SDKs per device
||Blackberry Java Development Environment, Blackberry plug-in for Visual Studio,Blackberry plug-in for Eclipse
||C, C++, Java
||Palm OS SDK, Java development with IBM Websphere EveryPlace Micro Environment, Also offer Palm Windows Mobile SDK for Palm products on Windows Mobile platform
||Java, Windows Mobile, Linux
||MotoDev IDE (Java Eclipse based), MOTO Q Plug-Ins (for VisualStudio), Many SDKs for various platforms
||Java, C++, Python (S60)
||Carbide IDEs-Number of SDKs for various platforms that integrate with industry IDEs
||Java, Symbian OS, Windows Mobile
||SDK for the Java ME, Mobile JUnit, Eclipse Device Explorer Plugin, additional SDKs and integration plugins for IDEs
Are you a hard-core believer in Java and open source development? Do you anxiously await every MSDN newsletter looking new .NET gems? We all have our beliefs in particular programming languages and development environments. Why? Why do you prefer that development language and application development environment?
Mobile development re-raises this question, and you may have to re-evaluate your answer in light of your mobile application development. Java, .NET (C#, VB), C, C++, Python, and other languages are all options available in mobile development. In some ways, the same criteria used to compare these on a desktop or server can be used to evaluate the languages use for mobile apps. However, mobile development does bring in other considerations which distort the old desktop/server application development environment discussions.
For example, Java's strength has always been portability. Java is a widely available platform on all sorts of mobile devices. Sun touts some 2.1 billion devices with Java as indicated earlier. However, the exact same Java is not on all these devices. In order for Java to fit on so many different styles and shapes of platform, the Java architecture has been broken into a set of configurations and profiles. The configurations and profiles differ according to device and device capabilities. Look, I am a true believer of the Java write once run anywhere philosophy, but to say that Java code is completely write-once-run-anywhere on all devices would be hugely misleading.
Take the .NET platform as example number two. In the classroom, I explain to students that .NET shines in that you can use your choice of programming language (C#, VB, etc.) written to a single platform; that of .NET and the Microsoft operating system. Yes, efforts in projects like Mono attempt to make .NET more cross-platform, but the number of actual platforms and devices using these cross-platform .NET implementations is limited. Microsoft tools (for the most part those in Visual Studio) do a great job of making development to this particular platform very easy. In the mobile platform world, however, Microsoft is not the dominate OS. Thus, writing to this platform may not get you to those customers you want to capture.
So how should you look at the application platforms for mobile devices? The next sections explore three of the more popular application platform choices and look at ways to compare/contrast these platforms. Tutorials and more information on each of these application platforms are available on DevX