Daniel Rocha's Forum Nokia Blog

Which technology should I use for development? Round 2: C++

dcrocha — Fri, 30 May 2008 15:39:41 +0000

The Holy Grail, according to Monty Python

So let us talk now about the Holy Grail of mobile development in Nokia platforms: Symbian/S60 C++. It is the language in which the operating system is developed (about 95%), it is the language that allows developing all sorts of applications, from simple expense trackers to VoIP and geotagging and video-sharing applications. It is the language about which odes are written, flowers strewn at is feet, and virgins sacrificed to its altar.

It is also one of the hardest development environments there is to learn: it's not standard C++, you have to instrument a lot of the memory management yourself, the learning curve is very steep, and the amount of code it takes to write even a simple "Hello World" GUI application is larger than any other technology we'll talk about. However, if you have the skills to learn it, the patience to develop apps with it, and want to power your application with the most sophisticated features available, it can be a very rewarding experience using it after all.

Obs.: I know I promised Python this time but I felt like covering the two core technologies first.

First part of this article: Which technology should I use for development? Round 1: Java

Technology: Symbian/S60 C++

Good for:

Games - Full-fledged commercial complex games, such as N-Gage's, as the APIs for direct screen access, 3D graphics, audio and video and camera manipulations are very powerful and enrich and gaming experience.
Multimedia applications - You can write very complex applications which integrate a handful of different powerful features such as: location, geo-tagging, video and audio low-level manipulation, VoIP, camera access and so on. As examples, check Shozu, Fring, Windows Live, Google Search, and many others.
Mapping and location apps - These leverage the powerful Location APIs along with the OS-provided Assisted GPS and the Map and Navigation framework (3.2 only) to give you a very fine-grained control over obtaining the location of your device and integrating it with other features or APIs. For example, Shozu integrates GPS location with EXIF JPEG data manipulation to upload pictures which are geotagged to known services such as Flickr, where they are placed automatically on a map. Very creative. Check also WayFinder, Google Maps, Nokia Maps, Route 66.
VoIP Applications - There are simply too many to list, just check for yourself.
E-mail applications - Your e-mail apps can talk to Microsoft Exchange using ActiveSync protocol, and also be integrated into the standard Messaging application so users can access it without having to go to the menu.
Many others - Enablers, virtual machines, services, device drivers, file managers, are all examples of sophisticated applications which can be written in C++.

Why?

API/functionality availability - Programming with Symbian C++ is almost like programming desktop applications: you will get a stagerring number of APIs, powerful features, sophisticated integration between applications and services; those allow you to do more with your device than any other technology.
Performance - Native C++ applications have the best performance of all analyzed technologies (unless you're a really really bad programmer).
Porting from other platforms - This used to be a nightmare, but with the introduction of Open C and Open C++ porting layers, it became much easier to port from other POSIX platforms.
Tools - Although the building tools themselves are not standard, Carbide.c++ does a fine job of hiding the complexity from you the programmer, allowing for faster application development. Its debugging tools are specially worth mentioning.

Bad for:

Simple applications - If you need to develop an expense or sports tracker, a blogging tool, casual game or such, using C++ is probably an overkill. You can achieve the same in much less time using Java, Flash Lite or Python.
Rapid prototyping - Symbian C++'s complexity will add much more time to your development projects, so it's not well suited for protopying. Do it in Python or Java and if needed, write the final version in C++.
Casual games - That would be another overkill. You will end up writing 7000 lines of code or so per game, and your productivity when compared to your competitors using lighter technologies will suffer. A lot.
Web applications - At risk of souding repetitive, another case where you're better off with technologies whose focus is Web services. I'm talking Widgets, Widsets and Python here.

Why?

Harder to learn than any other technology - Even an experienced programmer, coming from other C/C++ languages, will have a hard time learning Symbian C++, using the non-standard tools and proprietary features, such as resource and registration files. It can take a long time to get a decent working knowledge of how everything works and even then you will find yourself.
Slower development time - Due to the steep learning curver and overall complexity, native development in S60 is generally though to take 3 to 10 times more time than Java or Flash Lite projects.
Portability - First off, there's a binary compatibility break between S60 3rd. Edition and its previous editions. Secondly, even within the same versions there some API incompatibilities/deprecations you'll only find out about when you're deep into development. In this case you'll have to produce a workaround or ask technical support from Forum Nokia to fix you an update, workaround or private API that does the job.
Platform security - Although it's very noble on its purpose (securing users' devices against malware), platform security can be a pain to live with during the development cycle. The whole Symbian Signed environment and platform security API restrictions slow down development time and can increase development costs, because of test fees, certificate purchasing, re-test, etc.

"With great power, comes great responsibility", once said Spider-Man's uncle. In this case, however, with great power you'll get great complexity. If after careful evaluation of requirements you decide you should go with C++, commit yourself and your development team to learn the plaform right, and well. Otherwise it will cost you time and money. We know that time = money, so it will end up costing you money².

Symbian/S60 C++ offers you the opportunity of leveraging as much functionality as the device can provide. This can be a real differentiation factor for your applications and can result in more users, thus more money. Just make sure it's the right technology for you before you start up your project.

OK, now I'm not lying: next round will be about Python.

See you!

Which technology should I use for development? Round 1: Java

dcrocha — Tue, 27 May 2008 18:29:05 +0000

If I had just made a dollar each time I heard this question... *sigh*.

With the availability of so many different development technologies in Nokia's platforms today, sometimes is hard to decide which of them we should use to build our application, isn't it? There's Java, Symbian C++, Open C, Flash Lite, WidSets, WRT Widgets, Python, and the list is still growing.

This is good news for developers, since not everybody has the same technical background nor is developing the same kinds of applications; this means at least one of the technologies will fit our experience and purpose like a glove, and we are going to use it. On the other side, this may confuse newcomers to the wonderful but fragmented mobile software world. Usually it goes like this:

Question: "I want to write an application that opens a file and sends it out to a web server. What should I use to create it?"
Answer 1: "Java ME, FileConnection API"
Answer 2: "Don't bother, use C++ or you will get a lot of security prompts."
Answer 3: "Why use C++ when you can do the same with Python? C++ is way too hard!"
Answer 4: "Python does not run on S40, use Java."
Answer 5: "Do you really need all that jazz? Why don't you go with Flash Lite and use server-based persistence? Your application will look great!"
Answer 6: "Flash Lite is too fragmented. Use Java, but beware of the MIDlet signing issues or your app's user experience will be crap!"

Go check the Discussion Boards. It is crowded with examples of conversations like the one above. Having answered this question so many times before, I decided to summarize my answers in this blog, in the hopes of helping developers decide what use from the growing technology options pool offered in mobile devices these days. Please keep in mind that the following are my opinions on the subject; yours may differ and even prove mine wrong, but that's the beauty of interacting with people within a community. As the number of technologies it too big for a single post, I will continue my analysis in the upcoming posts. I will start off with the most popular mobile developmentp platform, Java ME.

Technology: Java

Good for:

Productivity applications - Examples: sports trackers, expense control apps, Personal Information Management (calendar, phonebook, etc.).
Games - Both casual and complex.
Enterprise applications - These don't require fancy user interfaces. Using LCDUI and the standard packages can go a long way pretty fast.
Rapid prototyping and proof-of-concept applications.
Network applications - RSS readers, weather services, blogging applications, mobile versions of Web applications.
Creating truly portable apps

Why?

Java and its mobile version are very simple to use and learn - An experienced programmer, even coming from other C/C++-based languages, can get a pretty good working knowledge of how everything works in a matter of weeks and start producing applications quickly. This leads to faster time-to-market for Java ME apps.
Applications are generally portable between S60 and S40 platforms - Although there are some differences in implementation, supported packages, audio/video formats and so on, those are few in number and thus easier to work around. You don't need to entirely rewrite your application so it will run on N95 instead of 6131: a few runtime checks and versioning tools will be enough.
Game API combined with optional packages makes it a killer for game development
Straightforward network API makes it easy to communicate with web services - The GCF (Generic Connection Framework) is a simple and unified way of using the network on Java ME applications. Once you learn how to do one kind of connection, you will have learned them all.

Bad for:

Accessing device resources - Examples: SMS Inbox, file system, gallery, hardware.
Multimedia applications - Examples: Video streaming players, audio and video recorders, camera applications.
Performance-intensive applications - Scientific computing, image processors, video decoders, sound processors.

Why?

Java's functionalities depend on Java Community Process process: if there's no official, industry-standard API for what you want to do, you are out of luck. Example: accessing SMS inbox.
Mobile Media API implementation is (too) highly modular, a lot of runtime checks are needed. Also, most functionality is implemented on the native side and then made available to Java's virtual machine, such as the camera access. This may have a serious impact on performance.
Fine-grained control over video, audio and camera is generally not available. Although JSR 234 (Advanced Multimedia Supplements) tackles some of these issues, it still can't be compared to what's available on other technologies, and its device availability is still low.
Access to the file system is provided by FileConnection API, but it's somewhat restricted and requires the midlet to be signed, otherwise multiple security prompts will be displayed, taking your user to tears (believe me). The signing process itself costs money and has some bureaucracy, so be prepared.

As I said before, these are my opinions on the technologies. It does not mean that X is better than Z, and Z should be thrown into the dirt and kicked in the head, like XML in the funny The Parable of the Languages. If you get your requirements right, it's very likely that your question of "what to use" will answer itself. Need to access the Inbox? Down with Java. Need portability? Down with Python and C++. Fancy UI? Flash. Requirements management is a science, not an art, so when you get it right from the start, the development technology to use will pop up naturally.

Next time I will cover the darling of all Internet programmers, now getting much of the attention on S60 platform: Python.

See you!

Make your widgets and Flash Lite applications fly!

dcrocha — Mon, 24 Mar 2008 19:09:47 -0100

As I mentioned in my last post, I have been thinking a lot lately about how to extend applications that run on sandboxed environments, such as Java ME, Flash Lite and Widgets, using some powerful native technologies such as C++, Python and Mobile Web Server.

I did my research and turns out some people have already been thinking (and doing) this for a while now, so I wanted to share this with you, for a reason I will explain later:

- Our very own Sr. Technology Expert Petro Soininen has created a widget that's able to send text messages and read the SMS inbox of an S60 device, using a creative combination of Widgets, Python, PHP and the Mobile Web Server. Here's the link for the article with complete source code: http://wiki.forum.nokia.com/index.php/How_to_utilize_device_resources_from_a_WRT_widget

- Forum Nokia Champion Felipe Andrade and his company have been working for quite some time in the Flyer Framework, a server application written in Python for S60 whose goal is to provide enhanced native functions to Flash Lite applications. It looks pretty mature, and I wonder if it could be used with Widgets as well with some adjusts in connectivity (full HTTP vs XML sockets).

I mentioned these two ways of extending widgets and Flash Lite apps because of the Global Code Camp Contest. I figured that an application/widget with enhanced functionality has more room for being innovative and delight users in many different ways.

As nothing was mentioned in the contest rules, I asked the Forum Nokia team responsible for the competition whether applications produced with these extension methods would be valid or not. An the answer is that these turbo web widgets and Flash apps are allowed, so you have a lot more options to introduce cool features in your apps via sweet Python and PHP scripts.

So take a look at them both and make your widgets and Flash apps fly higher than ever!

Hurrah! Widgets! - and more

dcrocha — Thu, 20 Mar 2008 17:43:40 -0100

If you have been reading Forum Nokia web site regularly, you've probably noticed the big Win 15k Euros! posted on the main page since March 18th. If you click the link, you'll be redirected to the Forum Nokia Code Camp Competion we're hosting. It's all about you developing a winning Web Run-Time (WRT) or Flash Lite application and raking in a lot of nice prizes from Forum Nokia.

Registration has already begun, so come up with your bright idea for either platform and enter the competition!

If you have a concept but don't have a command in any of these technologies, a good idea would be to register for one of the Forum Nokia Regional Code Camps happening worldwide and get started with both WRT and Flash in nice hands-on workshops.

Yours truly will be probaly hosting a Flash Lite somewhere in April, stay tuned.

If you're more into widgets, you can also get started by checking out this article I wrote back in November 07. It covers everything you need to know to develop your first widget, including SDK and live testing with our Remote Device Access service:

Widgets on S60: Web Runtime

* * *

I have been thinking a lot about Python for S60, Mobile Web Server and how to extend Flash and Java applications using the former technologies. I wonder if it would be possible to extend Widgets as well, having a C++ or Python light web server running on the phone while a widget makes local XMLHttpRequest connections to this service, thus getting more native-related functionality. Mobile Web Server seems like a good candidate for this type of experimentation. I may give it a try soon. (evil laugh)