Developing for Symbian and Nokia's Series 60
If you haven't noticed, Nokia's website has been given a refresh since the launch of their new phones the other day. I spent a few hours last night (early this morning actually) going over the site and updating myself on how to develop for Symbian and Nokia's Series 60. I learned quite a lot I want to share here.
Here's a little history about this: I love the idea of developing for wireless devices, either WiFi or Bluetooth or Mobile phones. Last year when I was out of work after I quit Terra, I decided that I was going to learn how to develop for the Symbian OS because it looked promising. So I downloaded the SDKs from Symbian's website and Nokia's Series 60, bought Visual C++ and books on learning C++ and the book on Symbian. After a month or so of not being able to get even "hello world" to come up using C++, I decided to go back to Java. True (if abbreviated) story.
There were several problems that contributed to my ditching development. The most basic is that last year there was only few devices out there that supported the Symbian OS. The Nokia 9200 Communicator cost well over $1000 so there was no way (being out of work) I was going to be able to buy it and play so I lost incentive pretty quickly. Also, learning how to program C++ while targeting such a non standard platform as a mobile phone is ridiculous. It proved impossible for me.
So anyways, last night I went into Series 60 again, which I think is the main version of Symbian that you would want to target as a developer. If you don't understand the difference between Symbian and Series 60 it's like this: Symbian was created as a consortium to provide an OS to mobile phone makers based on Psion's EPOC OS. Because Symbian is trying to please lots of different manufacturers, they've got an "a la carte" system where you can use some or all of the different pieces of the base OS. Nokia has added on their own version of the UI and development stack and called it Series 60. (They also have another version of Symbian for their 9200 phones which have different capabilities including a larger screen, etc. If you haven't seen the 9200 in person, it's more PDA than mobile phone - basically a Psion in a phone casing.)
There's three ways to look at developing for Series 60 devices. The first is as a low-level C++ programmer. If you're interested in developing games or really tweaking the phone's capabilities, this is where you start. A quick look on Handango shows there's already starting to be apps produced this way that provide ways to tweak the OS like making "screen savers" and UI changes. The second way of doing development would be as a Java programmer. A lot more on this in a bit. The final way is as a web developer creating XHTML pages and cool stuff using SMS or Multimedia Messaging (MMS).
Now it would be great if you could download the Series 60 SDK and just start messing around with all this, but you can't because the SDK doesn't provide a real "emulator". I learned about this last year and I'm remembering it now. The idea is that when the Psion guys were first developing the EPOC OS in the late 90s, they didn't have powerful enough machines to emulate the Psion hardware. Because of this, they had to create a work around which was to create a mapping layer between the Epoc API and the Win32 API. This is why Visual C++ is required if you want to do development with either Symbian or Series 60. Last year the Symbian SDK was a nightmare - a mess of APIs and Perl scripts (yes Perl) to do builds, etc. I'm hoping it's been cleaned up and updated. But regardless, this basically means that if you're hoping to start developing for Series 60 on the Mac or Linux, you can't. It also means that that if you're developing for Java or XHTML you'll still have to have a phone in order to test your app, because there's no way to see what the real results are otherwise.
The good thing is that there's now two Nokia phones available with Series 60, the 7650 and the new 3650. They're still a bit expensive, but just looking in the Sunday paper's supplement, I can grab a 7650 for $465 with contract, so this may actually happen. I'm not sure which phone would be better to get, however. Going over the specs last night I noticed that they are both quite different - with the 3650 being new and thus having a lot more features. For example, the 3650 has support for some of the more recent multimedia stuff in Java, Real Video, XHTML (WAP-NG 2.0) and more. Also there's other important hardware differences like the 7650 only has 4 megs of non-expandable memory, but the 3650 (the one with the IMHO ugly round keypad) has 3.2 megs, but with expandable MMC cards accessible in Java. Check out the web page to get a good idea of what the deal is.
By the way, the Nokia Developer's Forum site still isn't wonderful. There's lots of documents that are available in PDF versions only so I can't link directly to them or sections in them. The marketing department needs to get out of the way of the developer area it seems to me.
Now here's where I rant a bit about Java development on these phones. If you go to Symbian's website, download their SDK and read about the OS a bit, you'll find that the original Java stack is in Personal Java - which is a powerful subset of J2SE and a superset of the J2ME specification. The Symbian OS allows that Java be a full-peer in development of applications with access to all the same low-level APIs as in C++. However, Nokia stripped all of that out with Series 60 and instead only supports the less powerful CLDC/MIDP profiles, presumably to make the OS lighter weight for telephones. I assume another reason for this is it also allows Nokia to have a standard Java implementation even for their other non-Symbian phones which still have MIDP support.
It sounds okay, but it isn't. If you don't understand why this sucks, it's because J2ME is a completely lobotomized version of Java. In order to get it to run in ridiculously underpowered environments, the spec strips out just about everything in the Java APIs and has it's own completely underpowered version of the JVM called the KVM. Also, J2ME applications - called Midlets - are simply mobile Applets: They live in a sandbox and have no direct access to any of the underlying hardware - including memory and multimedia. It makes developing in J2ME pretty limited. Sun is developing extensions to the original J2ME spec to fix some of these limitations, but the support is spotty and what's happened is that each manufacturer is coming up with its own workarounds. For example, it seems the Nokia 3250 phones will allow access to their MMC memory cards from Java, but other phones such as the Siemens' don't.
Nokia is actually doing a good job incorporating the new J2ME specs fast - the 3650 for example includes support for MMC access, multimedia, and messaging. And Nokia has provided custom APIs to allow better access to some of the features which would normally be outside the MIDP sandbox: to the Nokia UI widgets and sound for example. However, even with these additions, the J2ME platform still has amazing limitations. Here's a quote from Nokia's own documentation that sum it up best:
2.2.1 MIDlet limitations
This section takes a brief look at the basic limitations on MIDlets.
- MIDlets are unable to access the Series 60 device�s contacts or other native application data, although with networking, contacts could be stored on a server. This limits the range of applications possible.
- It is not possible to extend Java APIs beyond those that come with the device because MIDP has no Java Native Interface (JNI) support.
- Persistent data can be shared between MIDlets within the same suite. MIDlets cannot access the persistent data of MIDlets within other suites. MIDlets should be designed to consider this fact by grouping MIDlets that need to share data in the same suite.
- J2ME is essentially a subset of J2SE, which means that libraries (jar files) are not often easily transferable.
- Due to the limitations of MIDP devices, a good design in J2SE may require simplification for J2ME.
That last line is a massive understatement. Development for the two specs are completely different. J2ME apps have to be as lightweight as possible and very memory conscious. Also, don't expect that your J2ME app will run on anything but one phone at a time. Think the JVMs on popular OSes have anomalies? The KVMs are widely different for each phone and much of the spec is optional, so you never know what support you're going to get on each phone. My point? If you're going to do J2ME development for Nokia's Series 60 phones, it won't be very portable, so don't expect it be.
And that's what bugs me the most. If I'm going to be limited to using a version of J2ME that's only functional under Series 60, I want a more powerful API dammit! Maybe I'm just whinging because I'm such a dope when it comes to developing in C++, but I think it would be to Nokia's advantage to provide more support for Java developers since we outnumber everyone. I think a real plan might be to get a phone and start developing with the stuff I know now (Java and XHTML), and have the opportunity to start learning how to do stuff in C++...
And this is really the idea: What's the plan? What's the next step? I think there's going to be a ton of opportunity for those developers who jump on the bandwagon early. (Or is it too late already?). Developing games in C++ is out of my league, but doing connected J2ME apps and/or highly-available XHTML apps might be a real option to make money. There are going to be millions and millions of Symbian devices out there in the next year or two which do everything that a Palm does, but does it better. Think of all the Palm apps out there and think what you could do if they were all interconnected with full multimedia and imaging and - here in Europe at least - owned by everyone you know. Think about it... Siemens, Panasonic, Samsung and Sendo are all going to launch Series 60 phones in the next year. They're going to be everywhere. It's too big an opportunity to ignore.
-Russ
Links