open source cell database

Theres a few 'open' databases out there to find the location of a phone cell. None of them really inspire much confidence. Recently the big players have been showing off their own databases, for example google and yahoo who use cell id for user location services. So its about time that there was one global open database to rench away the money goggled control operators have over their cell data.

I've recently donated some extensive cell data to opencellid and hopefully it can expand as people try and build out location services. Theres also a few clients to download if you want to contribute.

BBC iPlayer moves on to Wii... what next?

Just read that the iPlayer is now moving onto Wii. Its great to see the BBC pushing it so aggressively. I wonder if its using Flash technology? If it is I imagine they'd have to upgrade the Flash Player to support on2, it would certainly make sense if they could because they get good enough DRM

So where will it go next? Having just got back from overtheair its clear the BBC love mobile and want to embrace it, but they have to be conscious of the mass market. Flash Lite 3 would be an easy port as they'd really just have to change the UI of their existing iPlayer, but the penetration is low at the moment. What other options are there that have a rich UI, DRM and a long term roadmap? Will be interesting to see just how far iPlayer penetrates mobile.

Update: I've just read an interesting post by Darren Waters that seems to confirm the iPlayer roadmap with Flash as a technology base and how that crosses over to consoles too. Looks like the Wii will be moving onto Flash 8 soon :)

MAD UK user group night

Tonight I'll be heading down to the Adobe Consulting offices where Mark Doherty will be showing a few of the Adobe hidden mobile gems, namely the European Flash Cast projects and some Flash Lite video.

If you're in London then I thoroughly recommend coming down. This will be a great opportunity to meet some of the EMEA mobile team, see some of the opportunities ahead and meet some of the Flash Lite community.

details are:

Date : 29th Feb, 2008

Time : 7pm - 9pm

Venue : At the Adobe Regents Park office
12 Park Crescent,
London,
W1B 1PH,
United Kingdom

UK MAD

Nokia Flash Lite 3 Memory Bonanza!

As various other people have reported, the latest version of firmware for the N95 8Gb adds support for Flash Lite 3. Its great to see Flash Lite 3 getting out into the wild finally, and perhaps earlier than has been the case with other Flash Lite version changes.

So I have upgraded my N95 8Gb and have been playing around with the implementation of Flash Lite 3. There aren't many changes to the standalone player except for the available memory which has been increased massively!

In previous deployments of Flash Lite the total runtime memory available has ranged from 1024 to 2048 kb. The developer version of Flash Lite 3 released by Adobe for developers to test applications had a default memory allocation of 3296 kb. The in-built Flash Lite 2 player on the N95 has 2297 kb, so it was a nice suprise to see the Nokia implementation of Flash Lite 3 has a jaw dropping 16632 kb of runtime memory!!! Amazing! So now we can load and playback full length mp3 files, for example. Of course, I didn't trust the system reporting of available memory so I checked it quickly by loading and playing a 4mb mp3 file. It worked perfectly - remember this would normally use up 8mb of memory.

Not sure why there is such a difference - maybe its to do with the changes in the way memory is managed in the latest versions of Symbian 9.2?

Flash Lite 3 security

Since the Flash Lite 3 player was made available recently I have noticed developers aren't aware of the new security measures. So heres an attempt at summing them up.

The biggest change apart from FLV support is the new security model. Flash Lite 3 now has crossdomain security AND playback security which makes it the same as Flash Players 8+. There are several confusing aspects to this though because Flash Lite doesn't operate in the same context as a desktop computer.

If you are accessing anything remote from a local file then you will have to do the following:

Put a crossdomain.xml file on any server you are accessing. Or have a proxy script on one server and use that as a gateway to anything you want.

Publish your swf as having 'Network Access Only'. So File > Publish Settings > Local Playback security > change 'Access local files only' to 'Network Access Only'. If you don't do this then your swf won't even trigger the network connection dialog on the device, it will just die silently. Its important to note here that the default is local files only so ANY old content that uses a network connection will not work in Flash Lite 3 until you re-publish it with the correct settings.

Be aware that neither Device Central or the Flash IDE enforce the new security measures, so you won't realise any issues until you test on the device.

So now that the basic rules are there heres my take on how the desktop player settings transform themselves into a very different mobile context.

1. On the desktop you can launch a local swf in the browser and a user is given a warning so that they can 'trust' the file to connect remotely. In Flash Lite 3 the user will never get this prompt it will just die silently. This is probably a good thing.

2. On the desktop you can open a projector to playback a swf and this will automatically be 'trusted' and therefore have no local playback security restrictions, you can load local and remote data at the same time. On mobile its a bit different.

The Flash Lite standalone player on s60 is actually treated like a 'local' web browser on the desktop. On s60 the nearest equivalent to a desktop projector file is actually a Symbian application that launches a swf. So, you ask, how can a developer make an application that accesses local and remote data?

We don't know at the moment. But the OEM's should implement the ability to have swf files marked as 'trusted' in someway, maybe during an installation process. This would be similar to the way desktop Flash works in that if they are opened via a projector they are automatically trusted.

3. Shared Objects are not classed as local access. So you can at least save small amounts of data locally and access remote services (same as desktop I think).

4. If you really have to have local and remote access you could easily just have a local proxy program that dealt with all your network requests through it's local connection. This would be easy for data but perhaps a little more tricky media assets.


So there you have it. The new security settings are there to make the Flash Lite player as close as possible security wise to the desktop versions of Flash. The net result of the new security measures will mean more hoops to jump through for mobile developers. How much depends on how well the OEMs implement the Flash Lite 3 player.

My opinion here is that mobile is a controlled enough platform to not need the same security measures as desktop. The issue here is not with crossdomain but local playback security. Bringing Flash Lite closer to the desktop player is in itself pointless. There has to be some recognition of a 'projector' style application for Flash Lite 3 applications for this to work. The new local playback security settings make this now even more of a need.

I suppose one other scenario is that OEMs could also completely ignore the Flash Lite 3 security measures...... now there's an idea :)

realtime mobile ads

Just read a post from Bill about global mobile phone subscribers and the numbers are astounding. It reminded me of this admob application that shows realtime ad views from their worldwide network. Equally impressive stats but more interesting is just seeing the different locations and phones that people have. Also remember that these are people actually browsing - active users!

dealing with fscommand launch

If you've ever wanted to use Flash Lite to communicate with C++ then fscommand("Launch",application) is a very useful feature. Its purpose is to allow you to launch an application on the phone and pass in addional command line parameters if necessary. So you could for example launch the browser and pass in a web address. Thats a basic example and there are other ways of doing that with getURL(). The real value in the launch fscommand is that it allows you to launch your own C++ application in the background to support your Flash Lite application.

In a recent Flash Lite project where we needed to use fscommand("Launch",app)
we came up against a few issues when it came to s60 3rd edition phones. So heres a summary of things to consider when using fscommand("launch").

You will probably have to call fscommand("launch") from a button press as it needs to be a user initiated action.

For 3rd Edition phones, because of the way applications are accessed you do not give an actual path to the application. So if I wanted to open the browser I would just do the following:

fscommand("Launch", "browser.exe");


For 2nd Edition phones you have to give the full path to the executable file. So for example:

fscommand("launch", "z:\\system\\apps\\browser\\browser.app");


Passing in arguments works the same across s60 3rd and 2nd edtion devices by putting the arguments after the application. eg.


For 2nd edition: fscommand("launch", "z:\\system\\apps\\browser\\browser.app,http://bbc.co.uk");


For 3rd edition: fscommand("launch", "browser.exe,http://bbc.co.uk");


However we were unable to read the arguments for our custom application. So it maybe that because of the security of the 3rd edition only the native applications such as browser can accept incoming arguments?


When it comes 2 way communication between Flash Lite and other applications the more effective way to do this is by running a local server on the device and then using loadVariables or even XMLsocket to talk to the native app. Although theres no point having a local server listen out for FL calls if FL isn't even running. So fscommand is again crucial here as a the starting point of communication.