On the FN discussion boards there has been every now and then questions about Cingular's security domain policy for MIDlets. As many of you know by now they do not follow the recommended security policy for MIDlets.

All developers wanting to know the specifics should check the "Java Signing Requirements" document on Cingular developer Web site. However, 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).

For unsigned MIDlets access to socket connections, PushRegistry, PIM API, SMS/MMS messaging, and Bluetooth (Connector.open()) are not allowed. Socket connections are not allowed for trusted 3rd party applications either, and most of the APIs do not have the option "always allowed" for this domain. You can use Thawte, Verisign or Java Verified signing to get your MIDlet to the trusted 3rd party domain.

There is also an additional semi-trusted "operator" domain, which allows socket connections and also includes blanket permissions for many APIs. You need to sign your MIDlet with Cingular Preferred certificate, in order to place your MIDlet to this "in-between" domain.

Unfortunately I have not yet found a similar document for T-Mobile US (this carrier also has a little modified security domain policy).

Conferences are nice - you meet new people, learn new things, and you also learn what you do not know, as people are asking you questions which require you to follow-up later by email. On the other hand, the days after a conference are problematic, as most of your time is spent in combing through your super-sized mailbox to return it to its former self. I am still in the middle of this process, so if anyone who handed over your business card is listening - replying to you is the next step.

Some odd pointers from Adobe MAX.

The mobility related keynote on the second day brought much more traffic to Nokia booth. However the keynote / general session was built around Verizon Wireless' Flash Lite offerings and did not portray Nokia much.

Even though there are 31 Nokia models with Flash Lite, there are only three Flash Lite enabled/capable Nokia models (6682, E62, and 6133) available currently in U.S. The situation will get better in the months to come, but the adoption curve is not at the same point here as it is in Europe for example.

Adobe Apollo is worth checking out. It is a "cross-OS runtime that allows developers to leverage their existing web development skills (Flash, Flex, HTML, Ajax) to build and deploy desktop RIA’s". I have not yet made up my mind about how great (or not great) Apollo is, but at least the demos were cool :-)

First day and the keynote of Adobe MAX conference are now history. Few comments.

First of all, this is not Flash-only conference (like I described this event in my previous post), but a conference for all users of Adobe products.

I was pleasantly surprised of the discussions I had at the Nokia booth with Flash and Flash Lite developers. Even though basic questions, like "what is Flash Lite" were voiced a few times, I have also had numerous discussions with developers already deeply involved with Flash Lite development or seriously considering in starting mobile development.

Of course the question about Flash Lite markets was asked a number of times. During the keynote Adobe mentioned that Flash Lite is available on over 100 million handsets worldwide. So far Flash Lite is available on 31 Nokia devices (although most of them on other markets than in U.S.).

How to then sell the apps? A number aggregators, like Jamba, Jamster, Handango, and Nokia Software Market distribute Flash applications and the applications can be wrapped with OMA DRM.

In general, much more people are attending this conference than I really expected. An Adobe employee mentioned that about 4,000 people are expected. Many of them attended the keynote this morning, which included a nice intro by Blue Man Group and a couple of announcements. I especially liked the Soundbooth sound editing application for us non-audio professionals (available soon through Adobe Alpha Labs). With that app Adobe seems to have captured the final missing piece of digital media publishing.

"MAX 2006, the annual Adobe user conference, offers the Adobe community an unprecedented opportunity to learn about Adobe software, interact with industry experts, connect with other Adobe software users, and have lots of fun."

Well, the show is starting on Monday here in Las Vegas, so I am guessing the fun part is guaranteed at least for majority of the conference attendees.

Nokia will have a booth at the Expo hall and yours truly will be available for discussion, demos and what say you for half of the Expo floor hours. If you are around, come by and say hello. Especially I am asking for anyone awake on Tuesday morning at 7am to visit the Expo area to keep me awake. I mean whose bright idea was to have the Expo floor open on Tue-Thu at 7 am? Seriously!

The conference contains a track for Flash Lite and I hope to catch at least a couple of the presentations available. At least I have to check out the hands-on lab by our own Forum Nokia Champion Alessandro Pace.

There is a document on Forum Nokia web site describing how to redirect the System.out and System.err on newer S60 phones. I dawned only recently to me that this similar functionality is quite easy to achieve on Series 40 phones.

By "debug" I simply mean here that one can see the System.out stream on a connected PC while running your midlet on Series 40 handset. I have not yet had time find out for sure which handsets support this, but works at least on newest handsets like 5300.

How did I got it working? I first installed PC Suite on my PC (yes, running Windows here). I also created a test midlet printing messages during execution with System.out.println() and installed it on my handset.

Then I connected the phone with a USB cable (selected the mode to be the default) and waited the corresponding drivers to be installed. I went on to check from the PC Device manager what was the com port assigned to my phone.

"Control Panel -> System -> Hardware -> Device Manager -> Ports (COM & LPT). You should see something like: "Nokia GSM Phone USB" there.
Select Properties -> Port Settings -> Advanced. The port should be something between COM1 and COM10 for the Terminal program to be able to access it. Change it if necessary."

If you changed the port it is always a good idea to disconnect the phone and reconnect it, to make sure the port change is updated.

Open a terminal program and connect to that port. HyperTerminal works, but the output gets messy with the linefeeds. Instead you could use some other, more configurable terminal program, like Terminal.

Run your midlet and enjoy the stream of messages displaying on the terminal screen.

The Flash Lite developer community all around the world is growing. But who knows Flash Lite?

Scott Janousek has started a little experiment he announced on the flashmobilegroup emailing list: