So I’ve got a confession to make here, I’ve been working on this bit for the better part of a month now in fits and starts, and having a hard time getting my head around it all. I started out with the notion of a quick primer comparing what it would take to knock out a quick ‘hello world’ on the various native platforms out there if you were to decide to do something other than a web app. As I progressed down that path, I guess I got a little lost along with way, but have finally emerged out the other side, and realized that there’s no way to cover this in a single post, and I was verging on a book if I kept at it. So, I’m going to split this up in the interest of time, and so you don’t forget that I exist… I’m going to start with Brew, Symbian, and RIM, follow with iPhone, Android and WindowsMobile. Thanks for your patience, and I hope that you find this helpful.
In case you’ve been living in a cave you will have noticed that there’s quite a proliferation of platforms in the mobile space for which you, Joe Developer, can go out and build an application. Some of these the platforms offer both naitve development interfaces usually in some flavor of C, and most also offer some a sandboxed and interpreted option. (Java, Flash). Recent activity in the mobile space may make these ‘native’ platforms an attractive target for you, but I’d like to stop, step back a few paces, and take a look at what you’re getting yourself into before you go down that road. Maybe you’ll take another look at web based apps, maybe not. Either way, it’s worth thinking about
I’ve said it before, and I’m sure I’ll say it again, but when you start building applications for mobile devices, you must, must, must think about who your audience is and what features you need to reach them effectively from your application. There are instances where it really does make sense to build a ‘native’ application. These include the need for rapid response and key stroke interpretation (like in a game), access to potentially private data (like GPS location), or the need for persistent storage (like for photo uploading/sharing). However, if you’re providing an information based application that may even need access to some on device features (like the address book or the dialer) you may be better off with a web based application.
I’m going to take a quick look at the barrier to entry of building an application for the ‘native’ environments and what it’s going to take, starting with the basic building block of every programming exercise: ‘Hello World.’ Clearly, if you’re going to build a native application, you’re going to want it to do much more than display simple text, and there are compelling features and reasons to go native, but I just want to set expectations appropriately before you (or your minions) go down that route.
Here we go!
Symbian
As a platform, Symbian has the broadest reach of any ‘SmartPhone’ OS out there. By sheer force of Nokia you can find the environment across the globe. However, be aware that it’s had several different iterations, and there are a number of different UI layers on top of the underlying OS. The most prevalent, and the most relevant and lively today, would be the Series 60 UI layer (which is now in it’s 5th edition). Actually, since I spent so long working on this article, it’s now the only UI Layer as the folks up in at UIQ (adopted by SonyEricsson and Motorola) have thown in the towel and filed bankruptcy. To be fair, you don’t have to write directly to the Symbian/S60 layer if you don’t want to. Our friends at Nokia provide access via Java, FlashLite, and Python in addition to their C/C++ API’s but since we’re talking about going native, let’s look at developing for the C++ interface.
The first thing that you’re going to need is the Carbide.C++ IDE that you can find under the ‘Devices, Docs & Tools’ tab on Forum Nokia. To move forward with development for real devices, you’ll also want to get the ‘platform sdk’ that matches the devices you’re targeting. Despite the fact that the newer touch screen devices, such as the Nokia 5800 are running S60 5th Edition, the most wide spread implementation is 3rd Edition FP1. Once you pull down Carbide and the Platform SDK, you’re also going to need the right version of Perl (5.6) from ActiveState in order for the build chain to work properly. This means that you may have to un-install a newer release that you may be using for other purposes on your system.
Once you’ve got all the tools set up, you’re ready to roll. Thankfully, the IDE (built on top of Eclipse) has a tremendous set of wizards to get your started, as an application as silly as ‘Hello World’ get built from 5 C++ files (along with a number of includes…) and the core code which generates the UI to display the text string is 209 lines long. Now don’t get me wrong here, C++ is a pretty freekin powerful language, and is clearly way over kill for our stupid little app, but it’s also worth noting that it’s not for the faint of heart. Also keep in mind that as I noted above, C++ is by far not the only option for you, and that the tools and environments provided are intended to be used up and down the Nokia device developer ecosystem, from those building end user games and applications to those creating low level device customizations.
When you’re done running in the device emulator, you can switch your target to the appropriate device from the Platfom SDK which you’ve downloaded and build a .sis file for deployment. However, remember that starting with the 9.x version of Symbian, you need to sign your applications before deployment. For testing and development purposes, you can use the Open Signed program which will sign your app for a specific device (based on IMEI) and then you can transfer it via Nokia PC Suite (via Bluetooth/IR/USB Cable) so you can do on device testing. Once you’re ready to distribute your application in any sort of volume, even to internal users, you’re either going to have to self sign and deploy your root cert to all of your users, or go through the full Symbian Signed process.
Brew
From our friends at Qualcomm, BREW provides a robust and powerful C based environment for building pretty much anything that you can imagine. Much like Symbian, it can be used for creating the lowest of level applications for the device, including the dialer and messaging clients as well as games, entertainment, and media based applications. Also, like Symbian, the steps to getting off the ground require a significant investment on your end.
You’re going to need a C/C++ IDE and tool chain that will enable you to build .dll files to test in the simulator environment, and you’re also going to need an ARM tool chain if you want to build for actual devicesd. The folks at Qualcomm recommend your favorite incarnation of Visual Studio as your IDE. Once you’ve got that beast up and running and configured, you can pull down and install the BREW SDK and tools , which integrate into the IDE and include the emulators and utilities which allow create the full panoply of files need to actually build and deploy a Brew app. Like Symbian, there are several versions of the BREW platform out in the marketplace, so be sure that you know your target devices as you progress in your development. Qualcomm provides a series of ‘device packs’ to more accurately simulate real devices in the marketplace along with a ‘device configurator’ if you’re so inclined to build your own.
When your tool chain configured and running got those running, you can start building up the simple application. Using the wizards included in the BREW SDK you can get the basic building blocks of the application running, but in addition to the C source file, you’ll need to use the BREW tools to create a some peripheral files which are required to actually run the app itself, the MIF (descriptor file) and BAR (resource file) that will go along with the binary. Here’s where things get a little wacky (or not). The Brew SDK in conjunction with your IDE will churn out a DLL that will run in the emulator. However, when it comes time to get your app on to a real device, you’re either going to need to license the RealView Compilation Tools (RVCT) from ARM or get your environment set up with gcc compilers for ARM so that you can generate the MOD file (which is the executable target for the device). Also note that you’re going to have to have a signature file that goes along with your MOD file, and all of this so that you can side load your app on to a device in your immediate possession for test/debug purposes. In the event that you actually want to take your app to market, you’re going to have to go through certification, and get it loaded into the BDS for distribution and the whim and will of the BREW operators around the globe.
Blackberry
Our friends up at Research In Motion made an interesting decision when it came to the ‘native’ environment to expose on the Blackberry platform. Instead of going straight with C/C++ they have chosen instead to leverage Java. Basically, building ‘native’ applications for a Blackberry is like building a J2ME application on steroids. They platform related features are all exposed either through JSRs or custom RIM classes, all of which are provided through the net.rim.* packages which are part of either the custom RIM JDE or an Eclipse Plugin. The RIM SDK and simulator tools require version 3.4 of Eclipse, so if you’re behind the times, you will need to update. The good news here though is that if you’re a J2ME developer already, building for Blackberry is going to be very straight forward for you. Your run of the mill ‘Hello World’ is accomplishable in < 30 lines of code. Lucky you.
Building and running the emulator provided by RIM is completely straightforward: if you use the RIM JDE or configure the Eclipse plugin, you’ll automatically test into the simulator, and when you target a release build, you’ll get all the files you need for deployment on a real device (test or otherwise). For testing purposes, the shortest path to success is going to be to use the commandline javaloader tool which will push your app to a device tethered via USB, clean and simple (or quick and dirty depending on your point of view). For actual delivery of content to real users, you can use the Web Loader that’s provided by RIM. However, if you’re of the enterprise variety of developer, you can also use the Blackberry Enterprise Server to distribute your wares. If you’re going to leverage the platform specific features of the Blackberry and do something more interesting than just ‘Hello World,’ like with the other platforms, you’re going to need to get your application signed so that it has the appropriate set of rights to do what you want it to. App signing can be done by you, all you have to do is cough up $100 to RIM to get the keys to unlock the classes, and you’re on your way.
Note that RIM also provides a container based application development environment for Rapid Application Development they call MDS. The MDS Runtime is first deployed to the device, and then apps on top of it can be built. They provide both a version that integrates into Visual Studio as well an Eclipse Plugin which gives you a drag and drop set of GUI tools to build apps, insulating your from the underlying J2ME development environment (if you so desire).
That’s about all I can tolerate for now. I’ll chat with you soon about building for iPhone, Android, and windows mobile, and then follow up with a quick comparison and touch on go to market as well. Thanks for your patience.
You can also find more specifics and thorough instructions in the following places:
- Symbian Developer Booklets:
http://developer.symbian.com/main/documentation/booklets/booklets_using.jsp - Brew Programming Primer:
https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/ad/do/programming_primer - Blackberrry Developer Documentation:
http://na.blackberry.com/eng/support/docs/developers/?userType=21
