After taking two certification exams (Flash Lite 1.1 and Sun Mobile Application Developer Certification - minus the SCJP prerequisite, which I still need to take to get the SCMAD certification) I am not exactly sure if they are useful or not. On one hand, after preparing for the exams, you do remember quite well the class structures, some syntax details, and also a bunch of more or less useful numbers (minimum requirements and such - which are easy targets for quiz makers).

On the other hand, the current IDEs are all very good in code completion and code tips, so remembering the exact syntax is not so necessary after all. Also the specifications for the APIs are always accessible (either directly in the IDE, or through a browser) so remembering the correct parameters for each method is not necessary either.

Yes, preparing for the exams forces you to read through the specs and that is always good thing (many of the discussion board questions could be solved by reading the proper part of the documentation - the other part seems to be related to the implementations, which is a tougher topic...). You are also much more productive when you have at least an approximate clue on what each of the classes does, what is the proper process&order of using various methods, and where to find more information.

It is important to note that certification exams are not the (only) solution for becoming a better programmer. One needs a lot of experience, coding, and debugging. Also many excellent developers never have taken any certification exams. Maybe the exams are just for the recruiters and for us average coders, who need some assurance that they know something :-)

Continuing the report on Java Security Domain exceptions by operators. I had a little harder time finding out information about the T-Mobile U.S. restrictions as their developer web site is nowhere to be found. Fortunately I was able to dig up a couple of documents providing light on this issue (I have to admit that I have not had a T-Mobile phone at hand to test this, all this is based on the documents I received... however I am planning to visit the T-Mobile store to check this out myself...)

The untrusted 3rd party domain has major restrictions. No access to networking, messaging, local connectivity, PushRegistry, multimedia recording, reading/editing user data, or location API.

The trusted 3rd party domain does not exist.

There are semi-trusted partner and trusted partner domains (operator domains). The semi-trusted partner domain has "ask once per session" settings for all of the APIs I listed above. In the trusted partner domain access to the APIs listed above is set to "always allowed". 

Out of curiosity I skimmed through the few chapters (chapters 6-8; pages 46-81) of the MIDP 3.0 early draft specification concentrating on security domains and MIDlet permissions. In general the overall view is the same as in MIDP2, but there are some changes and additions in the new, proposed spec. One of the biggest one is of course that the security policy has to be broad enough to take into account not only CLDC, but also CDC and JavaSE as well. An additional issue is how LIBlets are treated.

Some general observations:

First of all, it seems that the specification tries to get rid of the recommendation status of the current security policy. In the MIDP 3.0 it is stated (page 77) that:

All implementations of MIDP 3.0, utilizing radio access technologies such as GSM, UMTS, CDMA, WiMAX etc., MUST comply with this chapter. This chapter supersedes The Recommended Security Policy in MIDP 2.1 and MSA (JSR 248).

Interesting to see if this will be the case in the final specification.

Another interesting note is that the implementation of the permission requests is a little different from the current MIDP spec. On page 60 it is stated that the changes include:

• Basing permissions on the class java.security.Permission and subclasses
• Specification of Permission subclasses for each protected API
• Mapping existing boolean permission strings to class based permissions

I need to spend some more time to be able to understand how this exactly is going to work, though....

A notification was sent to the KVM-mailing list that the MIDP 3.0 specification (JSR-271) has reached the stage of early draft preview. It means that the expert group has created a draft specification and now they are asking developers to provide feedback to them. The review period closes on February 5th 2007, so now it is time to read through the spec (all the 700 pages of it :-) and let your voice to be heard.

There seems to be quite a lot of new things in this spec, and as I have not yet even skimmed through the documentation, I cannot really summarize the most important ones... But I here are some highlights (in no particular order...)

• Should run both on top of CLDC (1.1 & 1.0) as well as CDC (1.1)
• Communication between MIDlets + shared libraries (LIBlets) + MIDlet concurrency
• Improvements in the packaging and in the provisioning of MIDlets
• UI and networking improvements

If you have comments on this spec, please send them to comments-jsr271@opensource.motorola.com

A couple of month's back I wrote about Cingular's approach to MIDP security domain thinking, and stated "as the document has not changed for almost a year now, I think I can summarize the main points of the doc (without needing to update this entry right away)."

Boy, was my timing bad...

Few weeks later Cingular updated the document in question (you need to register to the Cingular developer site to read this document - registration is free). According to this new police the MIDlets in untrusted and trusted 3rd party domain are pretty powerless.

There is no access to socket connections, PIM, file system, SMS messaging, MMS messaging, Bluetooth, or location information from untrusted domain. Also HTTP-access has only "ask always" option available.

But the new policy really cripples the 3rd party trusted domain. There is no access to socket connections, PIM, file system, Bluetooth, or location information from this domain either. Also messaging has only "ask always" option available, and network connectivity has no "blanket" option available.

What comes to the location information, there is no access to that info from the semi-trusted operator domain either (called Cingular preferred).

Yesterday evening I attended the Mobile Monday event here in Silicon Valley and listened to two presentations about how to tackle the issue of fragmented device market while developing applications on mobile devices. There was someone videotaping the presentations, so it is possible that they will be available on the Net at some point.

The first presentation was by Tom Park from Hands-On Mobile and he presented an excellent hands-on (no pun intended) view of the challenges of supporting multiple different handsets using Java ME. If you have chance to see this presentation at some point, please do check it out. Some highlights:

• Creating separate builds for each single device is absolutely the wrong way.
• Abstraction layers (for example for detecting soft keys and such) make sense if that part of the app is not time-critical (helps to cut down the number of builds)
• Group devices in device families (which do not only depend on the device capabilities, but also they are different based on what the applications intends to do)
• Try to find parts of the projects which you can work in parallel (like creating device capability sniffers, etc.) - remember The Mythical Man-Month
• Create the core/full functionality or the app first before starting the porting (less duplicated efforts this way)
• In his experience, defects happen on new devices most often around screen sizes, key mapping and audio.
• His company creates up to 7 builds for high-performance action games, but only one build for simpler, less demanding applications.

The second presentation by Barbara Ballard from Little Springs Design was much more theoretical and abstract. She approached the problem from the view point of user experience and supported the idea of creating re-usable design patterns (stored in corporate design library) for design challenges.

The new version of the Nokia Internet Tablet is here (really, it should be available immediately!). The successor of the Nokia 770 Internet Tablet is called N800. The new device is demoed in the CES conference in Las Vegas. (A couple of phones were introduced at the same time).

Taken from the press release: "Building on the success of the Nokia 770 Internet Tablet, the Nokia N800 introduces faster performance, full screen finger qwerty keyboard, easier continuous connections through Wi-Fi or via Bluetooth phone, integrated web camera as well as a new elegant design. "

There are also a new version of the Maemo development tools available (version 3.0) supporting application development for N800. Note: There is also a developer device program available, through which open source developers can get the device at discount.

Over the New Year's I was celebrating friends' wedding in Yosemite. Yosemite Valley is a gorgeous place (if you have not visited this amazing valley yet, please make sure your future California travel plans include my favorite national park), but cellular network connectivity is really intermittent there. Note: there were more than 3 million visits to Yosemite in 2005 (source), so even crowded vacation places here in U.S. have still spotty cell network...

The lack of cell phone connectivity is not a bad thing, mostly being outside the grid is quite relaxing. However, there is a downside. As no-one had made any plans for the New Year's Eve dinner, we ended up scrambling to find a place to grab a bite and to enjoy the festivities (no fireworks, though :-) As families were hiking and skiing in different places during the day, coordinating a dinner for the same evening turned out to be impossible.

Apparently we have become so accustomed to make last-minute plans and to change them on-the-go with the help of a couple of calls, that no-one really remembered how to coordinate things without being constantly connected (meeting at certain place at time agreed in advance...). It seems like we are not masters of the technology, but a slaves to it.

Sadly, my first reaction to this mess was to start thinking what kind of technological tools would solve this problem. However, I think that the correct solution is to change our own behavior to fit the needs of this kind of a situation.