Being a good procrastinator, I waited long enough after attending the Flash Lite 1.1 training, so that I had forgotten every bit of advice and exam tip. Completely.

As I still wanted to take the exam before the year ends, last week I ended up scheduling the exam for this Friday (yes, the last work day before Xmas... nice job Hartti, Like you didn't have enough to do work and preparing for the Xmas already). But without deadlines, I would not work as effectively :-)

And like before so many exams before, I ended up scrambling late in to the night the day before to go through the training materials. But when I sat in front of the computer at the certification center, I felt ok. I thought I had mastered the training material, and used the authoring tool long enough to be able to pass the exam.

To my horror the first few questions were totally unfamiliar to me... "If I get this error, what's the problem?" (ehh.. I write always error-free code, so of course this was a new situation to me) "How to solve this situation?" and so on. Apparently the test makers really wanted this to be a "Developer" exam, not just exam to be passed by reading manuals. (Question to myself: Why would I be surprised of this, the exam is after all a Flash Lite 1.1 Mobile Developer Exam....)

After an hour of sweating (umm.. the room was hot, I of course knew well what I was doing...) I ended up passing the exam. I have to admit that the exam was better designed than I initially thought. One needs really hands-on experience of Flash Lite development and deployment to pass this one. Well done, exam designers!

For those who do not know: This certification exam can be taken through VUE or Thomson Prometric.

In early September I wrote about tackling the known issue documentation.  If someone does not remember, the known issue notes and solution documents can be found in the Forum Nokia Technical Library.

Since then there has been a number of conference calls (twice a month - I have not attended all, though) going through one known issue after another known issue. Before the meetings I have spent numerous hours writing myself a number of these documents using discussion boards, internal error databases, and firmware release notes as source material. I have also spent time testing the specific behavior on a number of devices.

Of course, in the process we have found a number of serious issues (like the one about post-dial DTMF tones, mentioned in the blog post linked above), which is a humbling experience. I hope that providing more accurate information about the intricacies of Nokia's devices, you developers have easier time to create successful applications.

During the second half of this year, in my opinion, we have made a good progress on making this part of the documentation offering more complete and more helpful to the developer. But that's only my view. Do you have any feedback or opinions to us on how we have fared?

I thought it would be nice to have some sort of a summary about the different languages which can be used to program mobile phones. I also thought I would be able to come up with a good list in few minutes, but after spending some time trying to come up with a great summary, I realized I need to settle with this half-baked version and hope I can update the list based on comments from you guys... (Thanks Paul for your comments!)

Symbian C++
Market: 100+ million Symbian devices, including S60 from Nokia
Pros: No execution overhead, best access to native capabilities (access to some capabilities requires Symbian signing) before any other development language, free SDKs and tools (to start with), localization framework
Cons: Steep learning curve

Java ME (MIDP2.0/CLDC1.1)
Market: 1+ billion devices (including MIDP 1.0 devices), almost all new phones are Java ME enabled
Pros: Largest market, free tools (a choice of) and SDKs
Cons: Fragmentation (support of APIs, screen sizes, memory, etc.) causes a lot of work in porting, some native access lacking (and no JNI)

Python
Market: Not preinstalled on any devices, on S60 phones only
Pros: Open Source (source available), easy to get started, extensibility (getting better access to native capabilities all the time), excellen prototyping tool
Cons: Work in progress, very limited market - requires users to install Python environment on their phones (although it is possible to create stand-alone Python apps), pain to debug features not supported by the emulator

Flash Lite
Market: 100+ million, preinstalled on newer S60 and Series 40 devices, available for download
Pros: Programming for non-programmers, same great tool as with Flash for desktops, not much fragmentation, very good and upgradeable emulators, player scales the UI (vector graphics)
Cons: Flash Authoring tools is expensive (30-day free trial is available), Flash 1.1 (most of the devices on the market) is very limited in capabilities (for example not Bluetooth support), integration with browsers not available on many devices

A couple of unfinished tools to follow...

Ruby
Market:
Pros:
Cons:

Browser
ECMAScript (Series 40), JavaScript (S60)
Pro:
Cons:

A few months back I compiled a list of mobile developer support sites by carriers and handset manufactures, which seemed to lack a direct pointer to Forum Nokia web site (silly me).

There are however a number of general-purpose Java ME and mobile developer (support) and community sites, which are worth mentioning. In no particular order, alphabetical order is too hard for me :-)

wireless.java.sun.com

ericgiguere.com

http://www.java-tips.org/java-me-tips/ (Thanks Shylle!)

j2medeveloper.com

j2mepolish.org

meapplicationdevelopers.dev.java.net

mobiquil.com

javaverified.com

j2me-device-db.sourceforge.net/pmwiki/

www.microjava.com/

phoneme.dev.java.net/

www.developer.com/java/j2me/

Most likely there are many more relevant sites for mobile developers out there, so if you know a good one, please do not hesitate to point that out to me.

I do not usually have much time to rate these sites, hence also recommendations of the best ones are welcome!

Adobe has posted Flash Lite 2.1 player for S60 3rd Edition devices for free download. I quickly tested installing the player on N93. It works and plays Flash content! Enjoy!

Oh, yes. Of course also earlier editions of S60 platform are supported (2nd Edition FP2 & FP3 devices).

For those, who do not have a clue what I am talking about:

Adobe® Flash® Lite™ 2.1 for Symbian allows mobile developers to create Flash Lite applications and content for supported Nokia Symbian S60 devices. Mobile developers can now benefit from cross-platform development since Flash Lite 2.1 is also available for BREW and Windows Mobile 5.0 devices. This allows repurposing of content and applications with minimal changes for another platform.

This standalone version of the Flash Lite 2.1 player for Symbian devices is free and allows developers to test their Flash Lite applications and content before actual handsets start shipping with Flash Lite 2.1 pre-installed. This version is also available to end users who want to play back Flash Lite content and applications on Symbian devices.

The MIDP specification allows quite a lot of variance in the installation procedure of MIDlets. The spec basically only states what the AMS (Application Management System) needs to take care of but not how it should be taken care of.  So it is no wonder that installing MIDlets on Series 40 is different from installation on S60 phones.

First of all, when you transfer MIDlets to Series 40 phones, they will get installed "on the background". The user does not need to start the installation procedure and walk through the installation - after the user navigates to the Application menu, the MIDlets is already there. On S60 phones the user has click through an installation before the MIDlet is installed on the phone. If the MIDlet was downloaded using the browser that process starts automatically. In other cases the user has to go to inbox and start the installation by clicking the JAR or JAD file. On Series 60 phones the destination of the MIDlet varies across the board. On some devices the MIDlets are installed in "My Own" folder, or in "Installations", or...

On Series 40 phones the destination of the MIDlets has changed a little through the different models, but mainly the MIDlets can be found in the "Games" subfolder.

One might ask how Series 40 phone user knows which of his/her MIDlets are untrusted and which are signed as no installation notifications are displayed to the user. The answer is that the user has to select the MIDlet in question and check the MIDlet settings using the Options menu.

One thing to remember on Series 40 phones is that when upgrading a MIDlet, JAD files need to be used. If one intends to upgrade an existing MIDlet using JAR file only, the MIDlet does not get replaced but the new MIDlet gets installed next to he old existing version.  

And lastly a reference to information on JAD and manifest files...

Got is interesting piece of news through POLITECH (Politech is the oldest Internet resource devoted to politics and technology):

FBI taps cell phone mic as eavesdropping tool
December 1, 2006, 2:20 PM PST

The FBI appears to have begun using a novel form of electronic
surveillance in criminal investigations: remotely activating a mobile
phone's microphone and using it to eavesdrop on nearby conversations.

The technique is called a "roving bug," and was approved by top U.S.
Department of Justice officials for use against members of a New York
organized crime family who were wary of conventional surveillance
techniques such as tailing a suspect or wiretapping him.

Nextel cell phones owned by two alleged mobsters, John Ardito and his
attorney Peter Peluso, were used by the FBI to listen in on nearby
conversations. The FBI views Ardito as one of the most powerful men in
the Genovese family, a major part of the national Mafia.

...

Nextel and Samsung handsets and the Motorola Razr are especially vulnerable to software downloads that activate their microphones, said James Atkinson, a counter-surveillance consultant who has worked closely with government agencies. "They can be remotely accessed and made to transmit room audio all the time," he said. "You can do that without having physical access to the phone."

Now, call me stupid, but I do not exactly know how this would be technically possible on for example on Nokia phones (although Nokia is mentioned in the article quoted), as the phone UI would reveal an active connection to the user. And if a separate application would be used, the user needs to install it first (or did they also replace the phone with a new, bugged phone at some point). Anyone care to enlighten me?