The pain of Flash Lite 3.0
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.-
May 13th, 2008 at 18:04
Hi Ugur!
I totally agree with you, all the topics you talk about in this post are the biggest problems for flash lite developers today… backward compatibility, some player’s features, distribution and fragmentation.
When you are developing real projects with commercial purposes, all this points are asked by customers, and we are not in the best position to convince them.
The technology should be an aid, not an obstacle.
May 13th, 2008 at 18:28
Hi,
In addition, recently I must code my application for Flash Lite 2.0 because I can’t use SWX on Flash Lite 3.0, and for me it’s another big mistake.
It’s sad that I can’t use FLV and SWX in my applications and for me, one of the big problems in this Flash Lite 3.0 version.
Hope they’ll fix it!!
As Marcos said… The technology should be an aid, not an obstacle.
May 13th, 2008 at 19:27
[...] I want to test N95 Accelerometer and I installed Nokia N95 Accelerometer plugin package and I made a small test with KuneriLite Accelerometer plugin. After a few test I noticed that getting a new axis values takes around one second. Oh it is ok I think but finally I noticed that all redrawing of the UI is hang also for a second. I have installed a new firmware to my N95 with Flash Lite 3.0 Player, which seems to have XML Socket bug and very slow. You can read more here Forum Nokia thread and Kuneri bloggy. [...]
May 13th, 2008 at 19:30
True and sad :-( I have made a few test also, read http://ptm.fi
Pasi
May 13th, 2008 at 19:42
Thanks guys, I see this is not only bothering me.
Raul, what is the problem with SWX? I should check it out as well and add to the list maybe?
May 13th, 2008 at 19:43
Hey Pasi, thanks for the post. It should work on 2.x player well though, is that right?
May 13th, 2008 at 19:53
I completely agree with you Ugur. Sometimes it’s hard to understand Adobe’s decisions…
Leonardo
May 13th, 2008 at 19:59
Hi Ugur,
As long as I know, Flash Lite 3.0 it’s not compatible with SWX because there’s a bug with the POST method, and with the GET method Flash Lite encounters the Security Sandbox (or something like this).
Try it, I made tests and the same file works on Flash Lite 2 but didn’t on Flash Lite 3. So, it seems a bug/problem/limitation/pain.
Regards.
May 13th, 2008 at 20:39
Just a little news/update: today when I tried to install the Flash Lite 2.1 player on my Flash Lite 3 enabled N95-8GB I received the following error:
“Unable to install. Component built-in.”
It seems that on upcoming Flash Lite devices it will be not possible to install other players? :\
Leonardo
May 13th, 2008 at 21:00
Hi Ugur,
Thanks for the detailed break down. Agree with everything.
This could have been simulated a year ago easily. Adobe’s error in introducing something that wasn’t needed on the standalone player and then failing to control its implementation and Nokia’s for not testing the implementation enough and its implications.
And this is just one porting of FL3!!!
Cheers
Nick
May 13th, 2008 at 21:01
I should check SWX problem. We detect problems as we get the use case. Since we use 1.1 most of the time, it’s little slow.
Leonardo: This is another sad thing. You can not install Flash Lite 2.1 player on built-in Flash Lite 3.0 phone, because UIDs are the same (if I am not mistaken). So definitely there is no way, unless a firmware downgrade :)
May 13th, 2008 at 21:05
Indeed Nick! Right now it’s not too late, because there are no S60 3.2 devices in market yet. But once they are out and those issues are not fixed, it will create a chain reaction of fragmentation. I hope Adobe and Nokia are working on that together, to bring a solution.
May 13th, 2008 at 22:12
Thanks Ugur for sharing your thoughts about the problems with FL3. We hear you and the community and are working with Nokia on trying to resolve some of these problems. The continued feedback (both good and bad) about our clients and tools from you the developer community will allow us to be more responsive and ensure that you have a platform you can effectively develop for. If you have any other concerns or just want to chat about things you can always ping me: bperry at adobe dot com
May 13th, 2008 at 22:59
I will forward this to the Flash dev team within nokia
J
May 14th, 2008 at 0:52
Thanks Bill. I am sure you guys are doing your best, and I know that there are many variables in business and it’s not easy to change things fast. I just wanted to raise the flag before it’s too late, because it will be with the first S60 3.2 device shipped without fixing those.
I also want to point out one issue here; although your strategy seems to make Flash Lite player for a better mobile web experience; it’s clear that Standalone Flash Lite is used close to 100%. Insisting on a strategy that is not adapted by community would be an unfortunate move, in my opinion. But I am sure you are already aware of that and taking necessary actions.
May 14th, 2008 at 0:57
[...] KuneriLite Accelerometer plugin. Although it doesn’t work on Flash Lite 3.0 phones (see my post), it should work very well on Flash Lite 2.x and accelerometer enabled devices (i.e N91, N82 [...]
May 14th, 2008 at 2:00
[...] del acelerómetro, que por lo visto le ha dado algunos problemas con Flash Lite 3.0, causado por un bug en el XML Socket del cual ha hablado ampliamente Ugur en su blog (no os perdáis los [...]
May 14th, 2008 at 2:45
[...] The pain of Flash Lite 3.0 [...]
May 14th, 2008 at 4:33
I have used SWX successfully with Flash lite 3 (on the Chumby device). So I am unsure if your issue is specific to Nokia phones.
I know there was a bug for POST requests in FL 2.1, but this was addressed in 3.0 as far as I am aware.
Cheers,
Aran
May 14th, 2008 at 8:37
Ugur,
yes it works much faster in Flash Lite 2.0 in N95. Look more details from my blog at http://ptm.fi
Pasi
May 14th, 2008 at 9:01
Are RTMP connections as slow as XML connections with Flash Lite 3.0?
If RTMP connections work Ok, you may use them to transfer data – that may be a solution.
May 14th, 2008 at 9:35
[...] Lite 3.0 is Community Pain Flash Lite 3.0 Community Pain in his blog and here in flashlitenokiaforum is what Ugur kaner mentioned in his website and imofo [...]
May 14th, 2008 at 9:55
hi.
so your suggestion would be to stick with 2.1 for now?
May 14th, 2008 at 11:30
Haven’t checked RTMP connections. But as far as I got, problem persists on HTTP connections, it’s very slow. We tested it only on XML socket connections.
It’s nothing to do with sticking to a player version. It’s a common problem. People will upgrade their firmware and get 3.0 player anyways, which will break the chain. If problems are solved to next firmware update, things should be fine. Whether you to 1.1, 2.x or 3.x, someone is affected, with hands tied. Only solution can be offered Adobe ‘and’ Nokia (not ‘or’).
May 14th, 2008 at 11:56
Hi,
Is it possible or advisable, especially in regard to xml, to look for a native localhost connection to some flavour of python and leave that to handle the network?
http://wiki.forum.nokia.com/index.php/How_to_use_XML
I see Matt here has a trick that might help things here as well:
http://www.outside-media.co.uk/blog/?page_id=5
hope this helps
Colm
May 14th, 2008 at 12:00
Hi Colm, Do you mean to solve localhost issue? We tried anything; Flash Lite 3.0 will silently ignore and localhost connection outside trusted folders. It even will not check for cross-domain xml.
May 14th, 2008 at 12:09
[...] There’s a developing issue in Flash Lite 3 regarding sandboxing, localhost and network connections, cross domain policy file for Flash Lite. For examination of the issues involved, take a look at http://bloggy.kuneri.net/2008/05/13/the-pain-of-flash-lite-30/#comment-54617 [...]
May 14th, 2008 at 17:32
Hi Ugur,
Like Bill said we hear you loud and clear and we’re trying to find a solution. With regards to the XMLSockets I’ve asked our team to look into it.
Mark
May 14th, 2008 at 17:56
Hi Mark,
Thanks a lot for your support.
Ugur.-
May 14th, 2008 at 19:40
Hi Ugur,
Keep up the good work and keep us posted!
ta
Colm
May 15th, 2008 at 10:59
[...] has an excellent post about problems with Flash Lite 3.0 player. The security sandbox that comes with Flash Lite 3.0 [...]
May 16th, 2008 at 19:23
[...] Ugur started a very good discussion on his blog about current obstacles and bugs in Flash Lite 3 implementation, and how they are effecting developers. [...]
May 16th, 2008 at 19:28
Hi Ugur and fellow FL developers,
I have continued further Ugur’s discussion about FL3 show-stopper issues. Share your thoughts on these issues as well.
http://www.orison.biz/blogs/chall3ng3r/?p=249
// chall3ng3r //
May 19th, 2008 at 22:17
[...] regards to this reported problem we have been listening and working with Nokia and Forum Nokia we have agreed a [...]
May 20th, 2008 at 0:42
[...] The pain of Flash Lite 3.0 [...]
May 20th, 2008 at 13:23
[...] to be in a community where discussions (another one here) turn into actions. Bill and Mark from Adobe gave the good news that Flash Lite [...]
May 20th, 2008 at 13:54
[...] Bill) – After some disappointed views about the security model for Flash Lite 3 applications for Nokia S60 devices, [...]
May 20th, 2008 at 16:20
[...] a nice introduction, with the new player Security settings. About this there are good articles from Ugur and chall3ng3r that point out this has caused problems in having, for example, an application [...]
May 21st, 2008 at 20:00
[...] duda los posts de Ugur y Faisal les han hecho reflexionar sobre cómo estaba el panorama y problemas que ya estaban sobre [...]
June 15th, 2008 at 21:53
Is there any hope in sight to use the missing features in the near furure with Flash Lite 3?
Is there any statement from Nokia or Adobe?
I need to load a XML file from the web in my FL app, but cannot be sure the swf is in the trusted folder – is there a workaround?
June 17th, 2008 at 14:04
Still not heard anything.. As far as I know, it’s not fixed on any device yet.. Hope soon.
Ugur.-
June 24th, 2008 at 15:32
This situation is really bad.
And it looks to be getting worse..
I’ve also been following the thread on forum nokia which now suggests no fix will becoming soon
So i think we should be prepared to see lots of new Fl3 devices hitting the shops in July /August which are essentially broke..
The list seems to include lots of otherwise superb devices
Nokia E71
Nokia E66
Nokia 6600 slide
Nokia 3600 slide
Nokia 6600 fold
Nokia 5320 XpressMusic
Nokia 6300i
Nokia N78
Nokia 6220 classic
Nokia N96
:( :(
July 9th, 2008 at 9:24
Wow. hopefully FL 3.1 that’s been released to OEMs fixes these “security features” and that devices with FL 3.0 can be updated to FL 3.1 through firmware…
-Naz
July 23rd, 2008 at 15:08
So finally I switched to another device: Nokia N78.
And guess what, the problem is not solved yet. :-(
I am desperately trying to get my swx application (twixr) working on my N78, but for now I don’t seem to manage to get the connection work. It asks for access point, but doesn’t get further than that …
July 24th, 2008 at 16:03
Unfortunately, it’s still not fixed :( There is nothing we can do and watch buggy phones keep on entering the market.
May 13th, 2009 at 13:09
[...] mo?na te? zainstalowa? FlashLite 3.1, która rozwi?zuje problem “painboxa“. Ale te? trzeba pami?ta? o utworzeniu pliku crossdomain.xml na [...]
May 25th, 2009 at 8:08
i must say, i’m an experienced actionscriptor making my way into the flashlite world and all these FL3 bugs are really discouraging. If nokia/flashlite/adobe want to solidify their ground in the mobile app world they need to keep on top of this stuff. these bugs should of been called out in the early stages of QA / beta testing on the adobe flash lite team before 3.0 was released. as some have hinted at, it doesn’t take much of a trip up to lose the lead.
ntch ntch.
May 29th, 2009 at 17:12
[...] When testing on a device as a swf, if you find network errors, ensure the swf is placed inside the Flash Lite trusted folder, if available. Location of the trusted folder will vary from device to device, but for Nokia’s N95 its located in C:/Data/Others/Trusted. Note that the Others folder may appear as Other without the s – this is not an issue. If you can’t find the Trusted folder inside Other(s), create it. To access the swf from the device just navigate directly to C:/Other(s), the data folder won’t appear within the phone view. There’s more on this topic on Kuneri Bloggy. [...]