<start of rant>

So far I have believed the mantra that Flash Lite works the same way across the devices and that there is no fragmentation in Flash Lite. Well, based on my recent experiences, I need to re-think my stand on this...

I was creating a simple Flash Lite app for a short article. The app would retrieve pictures and some data ovet network. Of course, as I wanted to load pictures, not swf animations, I had to use Flash Lite 2. After some sweating I was able to get my app running on the testing tools of Flash Professional 8. Task completed - I wrote the instructions to recreate the app and was ready to submit the article.

For some reason, I decided to test the app on a real device. Big mistake :-)

First device failed completely (I was using Flash Lite 2 enabled Series 40 device). The second test was with S60 phone with developer version of Flash Lite 2.1 installed (available from Adobe Web site). Now the application started, but still there were some quite sever issues. I was either able to get the image downloaded or then the data, but never the both at the same time. Also the soft key -based navigation required extra work as my initial code did not work. Of course everything worked perfectly in the "phone emulators" on my desktop.

Lessons learned: Always test with a real device and always test with all devices you are targeting.

<end of rant>

I have touched the security settings of operator branded phones on this blog in the past (China Unicom, Sprint, Hucthinson 3G, T-Mobile U.S. and AT&T/Cingular). However I have been pretty light on details about the API access settings on generic (non-branded phones). Time to change that.

Attached is an PDF file (created from an Excel sheet) containing a small sample of API access settings for a number of Nokia phones and the recommended settings from the various JSR specifications (MIDP2, MIDP2.0.1, MIDP2.1, JTWI, MSA). Note that even the recommendations from different MIDP versions are different. And the settings on generic Nokia phones differ from those. And sometimes even the firmware versions seems to affect the available settings. Oh, what a mess.

Yes, I know. This blog is not the optimal place for publishing this kind of info, but I was wondering if people would have some comments on how to present this information so it would be most useful to the developers. One possible, and final resting place for this stuff as well as the operator specific settings information is Forum Nokia Wiki. I was thinking of one page for each different API access settings,  and listing all the devices having those settings. Is this kind of table good, or does someone prefer the tables from JSR specs (which to me look confusing)?

Any other suggestions?

Not having CPU information on Forum Nokia device specification pages has been a source of complaints... well, at least source of frequent queries from developers. This situation is getting corrected as of this writing. S60 3rd Edition Feature Pack 1 devices (like N95 and 6290) already have this information.  Look for the CPU section on the left-hand side column.

Other device specification pages will get this information added during the coming weeks. I hope you will find this information useful.

Of course, there are some non-Nokia sources for the CPU information, like for example this one.

Good and extensive teaching material about mobile programming is always hard to come by and knowing how long it takes to create material only for one lecture, it was nice to find that the course page for Mobile Multimedia Technoogies course, lectured by Vidya Setlur from NRC Palo Alto contains a lot of useful material for mobile Python, Java, and Flash Lite programming.

Does anyone else have any other pointers to useful course materials? (I am guessing that Paul Coulton has something in his sleeves, any others?)

Adobe announced today that the first public alpha release of the Apollo toolkit is now available. I mentioned Apollo briefly in my Adobe MAX wrap-up a few months back.

According to Adobe Labs info page "Apollo is the code name for a cross-operating system runtime being developed by Adobe that allows developers to leverage their existing web development skills (Flash, Flex, HTML, JavaScript, Ajax) to build and deploy rich Internet applications (RIAs) to the desktop."

Definitely Apollo is still long way from final release, but the promise is there. In your spare time, check it out in order to be prepared to work on this platform too when it is getting ready to launch. Some pointers to other blogs entries here, here and here

If you have ever programmed with Flash Lite (or Flash) you are probably familiar with fps speedometer, which measure how many frames per second you device is capable of showing. Of course there is not much movement in the fps speedometer screen itself, so the results might not give you accurate information about the Flash animation capabilities of the device (but then, is there any benchmark application which would give a reliable measurement agreed upon by everybody...)

Recently phirewrkz asked for people to test the speed of their devices with a simple animation of a circle which moves around in circular motion. Quite a few people responded and phirewerkz also published the results in Flash-Lite-Tutorial blog. Knowing that there are more than 300 device models out there with Flash Lite pre-installed, the sample of 15 devices in the experiment is not huge, but it is a good start.

If my memory is not failing me (again), there is not yet a good Flash Lite benchmark available for mobile developers the same way there is for example JBenchmark for Java developers. In the future, as the new Adobe Device Central gets out it should have some tools in place to simulate the performance characteristics the real device (although I am not sure if any benchmarking information is going to be available).

Our Rio de Janeiro TechDay was almost too much of a success. We totally underestimated the number of people showing up. Which lead to very crowded event. Some people were forced to stand for a couple of sessions until we got enough chairs to the room. If anyone in the audience is reading this: Our sincere apologies!

Instead of two days, we packed in things in one day. Some more advanced issues were left uncovered (like signing, platform security, mobile game programming), but we tried to provide a full palette of talks about mobile programming (C++, OpenC, Java ME, Flash Lite, tools, and a number of business related talks, including a presentation by Oi - an operator here in Brazil).

After getting this warm welcome to Rio's mobile developer community, I think we are definitely coming back here.

Presentations will be posted again online (many of them were basically same as in Sao Paulo, so the repository might be a common one - I'll let you know the URL after things are in place). Questions were quite similar to Sao Paulo: Linux-tools, Python and the future of PyS60, and so on. Also the state of encryption on Java ME was asked (JSR-177 CRYPTO package on S60 3rd Edition devices, BouncyCastle on others and HTTPS for transport).

Our warm thanks to everyone who showed up!

Two days of technology and business presentations in Sao Paulo is over. On Thursday I will captivate the audience in Rio de Janeiro! (Am I thinking too much of my presentation skills??? Likely yes :-)

About 150 people attended the event (maybe even some more, I am not sure if all the participants on Tuesday were also attending on Monday) and among them were a number of Forum Nokia Champions. It was great to meet everyone!

After the sessions (which covered Symbian C++, Java ME, Flash Lite, OpenC, testing and signing, platform security, business opportunities, and talks by local operator and FN partners) we had panel session for Q&A. The developer tools team was notified that the Linux support for both Symbian C++ and Java ME programming is desirable. MSA presentation prompted a couple of questions about the future developments (JSR-249) and possibility of getting reflection to Java ME (not going to happen on CLDC, CDC is more open). Also the certificate issues caused a couple of queries.

Hopefully the event was rewarding for all participants and gave everyone new information about programming on Nokia devices. The presentations will be likely posted on the net. I'll confirm that from the event organizer, and point to the correct place in my future comment for this blog post.

Thanks also for everyone who filled in the feedback form. Having feedback is important in order to be able to make the future events better!

The Java API access on China Unicom has stirred some discussion on our discussion boards. I have to admit that I am not so familiar with the CDMA operator's behavior around Java API access and security domains, and even less familiar with the operators in Asia region (a lot of the important developer information is in languages I cannot read).

As far as I understand, unsigned (untrusted) MIDlets do not have access to platformRequest, network connectivity (neither HTTP nor Socket), messaging, reading/writing user data (files and PIM), and a couple of UniJa extensions (3D Graphics - com.chinaunicom.m3g - and Standby mode; I am not sure how these work, as I cannot read Chinese...)

China Unicom has some kind of testing certificates available for developers, but I have no information how to apply for one.

I know that writing these piecemeal information droplets about operators' differing Java security domain policies is not optimal way of giving a good overview of the situation (Sebastian has already noted this in his comment to my previous post...,), however I am writing these things as I am learning myself, and I think it is more valuable to get something out than wait forever in preparation for the ultimate security domain info package (which I hope to still compile some day, if all my other duties give me enough time to achieve that...)

While looking for other Sprint (big CDMA operatore in U.S.) related information I found quite a nice information package about Java API security on Sprint devices on their developer web site.

The short summary is that audio/video recording, reading/writing personal data (files & PIM), sending a message, and getting a location from the network all require signing. Otherwise, no access.

The good news is that all Sprint devices have a dormant developer root certificate, which the developer can activate. Then he or she can sign the MIDlets with a Verisign certificate and test the application on a real device (on the activated device only).

For more information, go to this page.

Scott Jenson (lead UI designer at Google) spoke recently at Stanford's Human Computer Interaction group's seminar series about browsing on mobile phones. The archived talk (duration: 1h) is freely available at Stanford Online.

As I have been working in the mobile phone industry for years, there were no huge surprises in his talk. Yes, on many past and current phones the web browsing sucks. Transcoders cripple the content, layout, and UI elements. There are always too many clicks and round-trips to the server to read just one story. And the user is always scrolling. In many cases with mobile browsing it is not clear if the value of the information is greater than the pain felt by the user navigating with small screen, slow bandwidth and crippled content.

Let's face it. UI and controls on mobile devices are different. Lack of mouse means different control mechanisms, and new, improved zooming of Google (mobile) Maps was used as an example (there are other good examples among mobile games for mobile UI/control adaptation). And the small screens continue creating problems (even though the amount of pixels increases, the physical screen sizes are staying about the same or increasing only slightly).

I liked Jenson's idea of using small phone screens as his presentation slides, as it really made the small screen estate problem on mobile devices obvious. Unfortunately this rendered his slides quite unreadable in the archived presentation. 

The talk was part of a weekly seminar series at Stanford's Human Computer Interaction lab, and I have enjoyed quite a few talks in person or though the free online archive. The good part in listening these archived talks is that you can speed-listen them (all the way up to 1.7 times the normal speed, which makes the presenters look and sound like hyperactive coffee junkies) - the bad part is that the audience might not ask the question you would like to ask.

I attended a nice Flash Lite eSeminar organized Adobe, in which Scott Janousek and Richard Leggett demonstrated Flash Lite application development. The online seminar is part of a Flash Lite eSeminar series. Adobe developer services apparently organizes these seminars once a month, towards to the end of the month, so it is worth checking the Adobe's developer website at least in the middle of every month to find out whats coming in the pipeline.

During the webcast Scott described how to develop an interactive screen saver to display the the battery levels, signal strength, charging, (and other system properties) with nice animations. Richard had another walk-through on how to develop a multi-player game based on Sushi server (and utilizing XML sockets). On the live webcast there were major connection problems to the presenter's computer, but these should be corrected for the archived/recorded version.

I also enjoyed very much the Q&A session, there were some excellent questions asked. All in all, a content-rich presentation by two very knowledgeable people (these guys have written a very good Flash Lite book together with Weyert de Boer). The recorded version is worth checking out (I do not know when it is available).