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 :-)