The pain of Flash Lite 3.0 • 05.13.08
Usually, when new version of a software is released, we cheer, considering things will get better and easier. As we were expecting things would be easier for developers, we cheered up for Flash Lite 3.0’s features, however that couldn’t be more than wrong and it turned out to be a big pain for us. Moreover, there doesn’t seem to be any short term solution, and no one guarantees there will be one in mid or long term. I would like to write my reasons why I think so, and warn Adobe, Nokia and developers for a potential threat, which will not be long to come.
Security Sandbox Pain (or Security Painbox)
Flash Lite 3.0 came with Flash 8 engine, and together with Security Sandbox ‘feature’. This might make sense for browser plugin, but doesn’t make any sense for standalone player. Nick has a really nice post about this issue, which is almost 1 year old, can give an idea about the past and future of the problem.
Ok, what’s wrong with ‘Security Sandbox’? Isn’t security something good? Well, security is good when it’s used in convenience. If you use security for a case where doesn’t make any sense or bring an added value, you end up making life difficult for developers and users. Problem about this new Security Sandbox is; you either can have a local connection (i.e loading local files), or can a network connection (i.e connect to internet). This ‘feature’ not only brought an unnecessary pain to us (developers), but also broke backwards compatibility. How? Simple: If you have a Flash Lite 1.x or 2.x movie using local and network connections at the same time, it simply won’t work on Flash Lite 3.0 (which means new phones like N95). Wasn’t the biggest problem on mobile world fragmentation?
Problems not only end with those on ‘Security Sandbox’ feature. It’s not possible to do localhost calls, which disables any connection from Flash Lite to outer world. Why is this something bad? Well, there are many 3rd party projects extending Flash Lite via localhost (the only way left to us, because 3rd party application launch is limited by Nokia), such as KuneriLite, Flyer and Janus. These projects help Flash Lite to expand beyond its capabilities and enable people to create richer applications, which can compete with native S60 applications in look and performance.
Luckily, there is a ‘best of worst’ trick that solves those problems. There is a magic folder in ‘C:\data\others\trusted’ (that’s another pain, I will come to that shortly), which disables ‘Security Sandbox’ and enables applications to communicate both with local and network, as well as localhost. Why is this a ‘best of worst’? Simply because whatever you put into this directory is visible under ‘Gallery’ which brings a very bad user experience and many security concenrs within.
This issue will be even more cronic, if Adobe or Nokia doesn’t make any move; because ‘trusted’ folder will not be available anymore for S60 3.2 devices. Which will kill all developer efforts and backwards compatibility forever. We are not sure if Adobe or Nokia will solve this problem, but crossing our fingers hoping someone sees our S.O.S fire.
Trusted Folder Pain
I mentioned Security Sandbox problem and a ‘best of worst’ solution to that above. Now see another pain closely related to this subject.
S60 devices have ‘Phone Memory’ (PM) and ‘Memory Card’ (MC). Users are given the option to install their applications to PM or MC. As you know, to solve Securiy Sandbox problem, we need to install Flash Lite applications to those ‘Trusted’ folders that exist both on PM and MC. So what is the problem? With a clever(!) move, ‘Trusted’ folder is located at different paths on PM and MC. It’s at C:\Data\Others\Trusted\ on PM and E:\Others\Trusted\ on MC. Yeah, but what is the problem? Well simply, it’s not possible to install applications (SIS packages) to different folders on PM and MC, and this breaks Symbian Signed criterias. So, Flash Lite 3.0 applications either will work on PM, or MC. And in that way, you can not get your appliction Symbian Signed.
There is no solution we could find for that yet. If we can not; it will not be possible for anyone to Symbian Sign their Flash Lite applications on Flash Lite 3.0 phones (from my current understanding).
XML Socket Pain
Well, Security Sandbox is not the only problem. There is a serious bug on Flash Lite 3.0 with XML sockets. Simply put, it’s not possible to receive data via XML socket shorter than 1+ seconds, which kills if you need to stream data.
Most clear example for that is using KuneriLite Accelerometer plugin with Flash Lite. Naturally, to use axis values, you need to get those values at least 4-5 times per second; so that you can reflect it to your application. But because of this bug, you can get data only 1 time or less per second, which makes it impossible to use.
See the this Forum Nokia thread for more information on that subject. And as far as we see, there is no solution offered yet.
Conclusion
I tried to state my reasons, why Flash Lite 3.0 is a potential show-stopper for developers, users, enablers and many more on S60 devices. Nokia keeps on spreading this problem via Firmware updates and pushing Flash Lite 3.0 player to earlier phones (i.e Nokia N95 Classic), supporting and triggering fragmentation. With the introduction of S60 3rd edition Feature Pack 2 devices, these problems will be impossible to solve and Flash Lite player will get fragmented at least for couple of years, which will delay market entrance that is already delayed for long time and still immature. What I would like to see is some action from Adobe and Nokia, leaning on this subject and listening to us to avoid a big potential problem awaiting all Flash Lite users and developers in short term.
Please leave me your comments if you have any.
cheers,
Ugur.-
