Following last week's SATSA API update, I thought an update of the AMMS capabilities of Nokia devices is in order too, as the implementations are not similar on Series 40 and are only partial on S60 devices.

Advanced Multimedia Supplements API (JSR-234) is a new API on Nokia devices. The AMMS API "builds on the framework established in the MMAPI (JSR-135). AMMS API adds many new Controls (in javax.microedition.amms.control and subpackages). Besides new Controls, several new extensions have also been added to the MMAPI framework (in javax.microedition.amms)."

AMMS adds new features to playing audio, camera usage, and image/video effects; as well as introduces a tuner for the Java ME platform. As the "audio enhancement" is a pretty broad definition, here is an excerpt from the AMMS spec to give you some kind of an idea, what is included in the audio part: "The Advanced audio features of the Advanced Multimedia Supplements (AMMS) give the application programmer tools for creating effects such as 3D audio localization, reverb, and equalizer (EQ)."

Now, what Nokia devices have AMMS?

On S60 side, AMMS is partially implemented on S60 3rd Edition Feature Pack 1 (that is the platform for N95). That implementation includes part of the audio controls, but not camera, imageEffect or tuner controls. Check the Java ME developers' guide for Class-level implementation information.

On Series 40 AMMS is introduced along the Series 40 3rd Edition Feature Pack 2 devices and this implementation includes some audio capabilities only (not 3D Audio though). For a list for Series 40 3rd Edition Feature Pack 2 devices see this SATSA post.

On Series 40 devices AMMS is still waiting to be implemented. I should have waited for an additional email, instead of publishing erroneous information...

SATSA API (JSR-177) has four optional packages: APDU, CRYPTO, JCRMI, and PKI. The device manufacturers have so far been able to choose which ones to implement. In the future there is a little less flexibility in here, because Mobile Software Architecture specification (JSR-248, MSA), defines that APDU, CRYPTO, and PKI has to be implemented in MSA-compatible devices. JCRMI is not required for MSA compatibility.

[Side note. APDU stands for Application Protocol Data Unit, and allows you to communicate with applications on a smart card - like SIM card. JCRMI stands for Java Card Remote Method Invocation, and it allows a MIDlet to invoke a method of a remote Java Card object. CRYPTO provides basic cryptographic operations to support message digest, signature verification, encryption, and decryption. And finally, PKI defines an API to support application level digital signature signing (but not verification) and basic user credential management.]

The optionality of these packages has caused some fragmentation. S60 3rd Edition platform includes only CRYPTO and PKI packages. Even though there are some comments floating around in the Internet that the APDU would also available on those devices, that is incorrect. So no Smart Card access on S60 3rd Edition devices. This is true also for the new N95 (S60 3rd Edition Feature Pack 1).

On Series 40 side the first optional package to be implemented is APDU. That is included in the Series 40 3rd Edition Feature Pack 2 devices. I know it is not entire clear from our device specifications, which device belongs to that group, so here is a current list: Nokia 5200, Nokia 5300, Nokia 6085,Nokia 7360, Nokia 7373, Nokia 7390.
There is no PKI nor CRYPTO on Series 40 as of now.

Final word of warning. The SATSA spec defines that there is no Smart Card access for untrusted (unsigned) MIDlets. Additionally, "an exception to this is the permission javax.microedition.apdu.sat, which is not mapped to any function group. Access to (U)SAT is granted to applications only in the operator’s domain."

DEMO and DEMOfall conferences are always interesting events. Never been to one, but I am using the contents of the Web site as an indication...

These conferences have been going of for 16 years now and they are organized by Chris Shipley. In short DEMO conferences are one the the most visible launch venues for a new product. A handpicked crop of start-ups are presenting their products to a audience full of VC's, executives from corporations, and journalists. Examples of past products??? Remember PalmPilot...?

Reading through the presentation abstracts is a lot of fun, and I recommend to check this exhibitor page for this year's event. There seemed to be quite a few mobile related products showcased in the DEMOfall this year (September 25.-27). Here is a sample, but go to the web page for more examples...

• "Qipit is a consumer online service that allows users to capture written and printed information with a camera phone, store and manage it for future use, and share it with friends, colleagues or business associates."
• "...with PixSense, every digital media clip you take with your mobile is automatically uploaded online and can be shared, blogged, pushed to third-party sites and archived, directly from your existing camera phone, over existing mobile networks."
• "PhotoCrank's technology allows mobile subscribers to personalize the photos they take by adding entertaining captions and graphics on the fly!"
• "SCORE provides users with the ability to send real-time, play-by-play video of a specific player directly to the USCORE Website and directly to users' mobile phones as a wireless application."
  

I have always been interested in using technology in advancing well-being, exercising, or coaching in sports. For example some years ago I worked in a project generating a mobile self-help applications for diabetic care - that was really fun!. The project later on was spun out from Nokia as LifeChart (R.I.P). Snif.

In the recent Mobile HCI there was a couple of interesting papers in this wellness area. Buttussi, Chittaro, and Nadalutti described MOPET (Mobile Personal Trainer) in their paper called "Bringing Mobile Guides and Fitness Activities Together: A solution based on an embodied virtual trainer". The Windows Mobile -based trainer monitored user's position during her physical activity in an outdoor fitness trail.

Oliver's and Flores-Mangas' "MPTrain: A Mobile Music and Physiology Based Personal Trainer" was similarily a mobile personal trainer, but they were additionally using music to influence the exercise performance.

Of course there were plenty of other interesting papers in the conference (held in the country of my birth - Finland). The full program of the conference can be seen here - at least the novel interactions, and visualization and multimodality tracks seem to have a couple of interesting papers.. but my own interest make my recommendations quite partial, right?.
Even though the papers themselves are not included in the program (they are included in the proceedings) one can find most of the paper already online. Happy reading.

While discussing with SNAP Mobile team members I was told that they have generated a test midlet to evaluate the compatibility of the device/network combo with SNAP Mobile. From the "SNAP Mobile API: Compatibility Test Instructions" document (both are available in the SDK download)

"SNAP Mobile ... is designed to work on all MIDP 2.0 devices. However, there has been some variance among different device types and different manufacturers. In addition, some operators have port and/or APN settings configured to block the SNAP Mobile API, or any other third-party game data packet, from going through a gateway. In order to protect developers from developing SNAP Mobile games on non-compatible devices and networks, Nokia is providing the tool to verify the compatibility."

The doc says that the testing one device takes 15 minutes, and that's about right - unless you need to configure the network settings from the beginning, in which case you need to reserve some more moments.

I spent some time checking a couple devices on Cingular network (E61, 5500, 6131, 6280). I had some problems getting the results on the Series 40 devices - the midlet seemed to fail numerous times and complain about network timeouts (I guess this is because the HTTP test failed on both of the devices), until I finally got the results out:

If you do any SNAP Mobile compatibility testing, please send the results to SNAP Mobile team. Again a snippet from the same doc:

"Nokia also encourages developers who conduct API compatibility tests to submit their test results, comments, and feedback to Nokia. Nokia will compile this information and share it with other SNAP Mobile developers. By doing this, all SNAP Mobile developers benefit collectively from this data, because it helps make the connected games market larger and more robust."

We have some documentation on how to use AT commands on Forum Nokia Web site although I have to admit that the documentation is scarce (see some AT command reference guides here). To be honest, I did not have a clue anyone was using AT commands anymore - especially to connect to mobile phones - until I started monitoring the general activity on FN discussion boards. If someone is as ignorant as I used to be, here is a short overview what the technology is about (blatant copy-paste from a site praised below - thanks traud!):

"Most GSM/UMTS mobile phones include an internal modem. You can do a lot more with the implemented commands than Internet access or Fax sending for example accessing the standard phonebook or sending, modifying and deleting your short messages (SMS) and there is much more – thanks to the 3GPP TS 27.005 and 27.007 specifications."

Apparently (while I was sleeping) many people are connecting to their phones using this commands set and doing amazing things with the technology. Want to learn more? I suggest you visit this excellent site by FN discussion board super contributor traud. The developer community bows to you :-)

Every mobile developer has surely discovered at least one pesky little bug on one device which does not seem to affect any other device. Sometimes the problem can be that some method call does not work. Or the method call produces incorrect result. Or...

Developer's best friends in this situation are known issue documentation packages from the specific manufacturer (in some cases also developer discussion boards can provide some help and guidance... and a place to vent one's frustration :-).
In Nokia's case the known issues are available through Forum Nokia Technical Library (FNTL), which you can also download to your computer.

First of all; FNTL is updated regularly. We have bi-weekly Known Issue board meetings (sounds more formal than what they really are) where each proposed tidbit gets green or red light - or sometimes publishing is postponed until some more details of the issue have been worked out.

The meeting itself is pretty quick, but the background work can be really time consuming. Let's use this reference pixel issue noted by selaoren and ray() as an example. (Of course discussion boards are just one route for adding new issues in the knowledge base. New issues are added based on PRO developer support cases, release notes, error databases, internal developer feedback, and so forth.)

After reading the complaint I needed to test the situation myself. Usually this means coding a midlet from scratch, but in this case ray() provided me with a midlet (thank you!), which I could run on a couple of different devices. Sure, problem seemed to be there on certain Series 40 devices.

At the same time I started looking through the error databases of Series 40 development team. No suitable bug report seemed to be there, although in this case it was not certain if the bug affects also other methods, so I needed to spend some additional time to come up with potential search words.

Next step: Send and email to our internal contact person in the development organization for this specific technology area to find out if this is something he has seen. Maybe unnecessary step, but useful after all, as I ended up using simple copy-paste in submitting an error report in the database.

The short relaxing part (for me) followed, but soon the dev team had confirmed the problem and also found the source for the bug. It turned out that someone else had submitted a related bug report around the same time as me and the source for those reports (even though on the surface they did not look the same) ended up being the same.

Before writing a known issue document one more thing to do is to find the extent of the problem. The dev team deducted certain family of devices to be affected based on the sw build and I ended up testing the issue with as many devices as I was able to get my hands on.

Final step before submitting the issue to the known issue board meeting is to write the known issue definition using a specific template. You should see this issue defined in the FNTL soon :-)

Setting up Nokia 770 /  maemo (Python) development environment should be a breeze, right? You install scratchbox, maemo bootstrap, and Xephyr and configure them, right?

Well, usually (at least in my case) when I install any new development environment, everything goes wrong. Here is the story, which (as of now) does not yet have a happy ending.

Of course I did not have Linux machine at hand (yes, Windows is no good for this) so I decided to get an old laptop from Nokia IT support guys. The first device I got turned out to be dead / dying, but of course I only tested that at home, so that cost me one evening.

Creating an Ubuntu CD was no walk in the park either. Downloading took more than hour (that was the fastest server I found, others were predicting 20+ hours). After I started burning the ISO image, I realized that the CD burning software on my home computer (Windows) needed the installation CD for that feature. That CD was nowhere to be found (I have to blame myself on this, my wife always puts things in the right places). So quick visit to download.com + downloading and installing a free CD-burner app from there and off we go.

No so fast, buddy. Ubuntu got going on the second laptop - almost. The laptop (IBM Thinkpad T21) seemed to die after a couple of screenfuls of [ok] lines. Knowing that the lunar cycle and possible the position of Jupiter might cause some disruptions in the hitech instruments, I made a couple of additional tries (to no avail of course). Finally I tried on a second laptop (my wife´s, don't tell her), and soon Ubuntu was up and running. At least I now got to see what happened after the stage I reached with the other laptop - the problem had to be in the graphics...

So, a new try with the T21 and this time with safe graphics mode. Yes! Now it was time to install Ubuntu on the hard drive. Surprisingly no incidents there. Of course it took longer than what I expected, but hey, the T21 is well past it's prime...

Even though it was getting past my bed time, I decided to go on with the scratchbox installation as everything (even networking) seemed to be working. I downloaded first the debian installation package for scratchbox core. Well, it requires the libraries to installed first, so... I installed the libraries first. After that the core installation just kept going and going and going... or was it stuck? After waiting 30 minutes, I decided I needed to return on this issue the next evening.

The third evening

I spent a good while trying to continue the installation, but some traces of the aborted installation process seemed to lurk in the system denying any further installations. Thanks to Ubuntu discussion boards I got past that hurdle an got more familiar with "sudo"(Super User Do) than I really planned. After installing all the 5 required packages for scratchbox, something still seemed to be wrong. As did not want to spend too much time debugging the potentially hairy situation, I decided to remove and reinstall the scratchbox altogether. But still I was not able to follow the instructions. It took me a while to realize that the installer had executed some additional commands, which I tried to run manualy (the instructions did not use the installer but extracting archives only).

To make the long story short, I finally made it to the last configuration step of the scratchbox installation (setting up the libfakeroot environment). Of course it failed. At 1 am I decided to call it quits for the day and try again after Labor Day weekend.

If this episode has taught me anything (or more accurately reminded me of something), it is that when one starts to use new tools, one feels lost and makes many easy mistakes in the beginning. For these kinds of issues one needs help, and that help is usually most readily available on various discussion boards by fellow developers. A big Thank You to all of the Nokia developers and Champions who have been, and still are active on Forum Nokia discussion boards helping numerous beginners. The beginners need you!

Yesterday I read through the Mobile Service Architecture (JSR-248 or MSA) specification. Let me tell you, that document is way easier to read than a specification (with same amount of pages) of classes and methods. I mean try to read 100 pages of MIDP 2.0 spec and you fall sleep at least twice.

The MSA specification does a good job of listing the MSA component APIs and MSA Subset component APIs, their inclusion requirements adn additional details. Note that there are APIs, which are mandatory (like MIDP); some APIs, which are conditionally mandatory (like Bluetooth API); and some APIs with optional packages, which (those optional packages I mean) can be mandatory, conditionally mandatory, or even not part of the MSA spec (like SATSA). Conditionally mandatory means that if the device has the required functionality / hardware to support a certain API, that API must be supported. Saying it from another perspective: If a phone does not have Bluetooth, it would be pretty hard to implement Bluetooth API for Java.

As mentioned the specification defines two MSA component API sets: The MSA Subset contains 8 APIs (CLDC, MIDP, WMA 2.0, MMAPI, JSR-75, Bluetooth, M3G, and SVG) and the complete MSA support means that in addition to these 8 APIs, additional 8 APIs are supported - bringing the total amount of APIs in the MSA spec to 16.

There are a number of devices out there on the market, which are pretty close to being MSA Subset compliant. Although in addition to just implementing the APIs, the API implementation has to include support for additional clarifications described in the MSA spec and also the implementation has to pass the compliance test, which of course is not ready yet (it will be available soon, though). After the TCK is ready the spec will go through voting and it will be finalized.

To give you some sort of an idea what does the word "clarification" mean, for CLDC there are things like "the minimum heap size has to 1 megabyte" and that system property string "microedition.msa.version" has to be supported. Other clarifications include additional system property strings for various APIs, minimum number of concurrent threads, MIDlet OTA download size minimums, JAD attribute sizes, etc...

The next step is to go read through the new MIDP 2.1 specification. Now, where's my coffee cup???