Friday, June 19, 2009

MicroFilm wins Flash Lite Developer Challenge Grand Prize



MicroFilm has been outed. We (Paul Wilson and myself) are really happy and honoured that MicroFilm has been given some great public recognition by being awarded the Grand Prize in the Flash Lite Developer Challenge. Many thanks to all those involved.

Now that MicroFilm is out in the public arena I'll try and share some of the thinking and plans behind it over the coming weeks.

Our main goal, from MicroFilm's inception 2 years ago, has always been to get a great mobile video application out into the consumer's hands. That remains the case.

As always with mobile nothing is a s simple as it seems. We do however, have some innovative business models that we’re exploring to support its distribution.

We’re progressing to the next stage of our user testing of MicroFilm and opening it up to a wider audience so send an email to microfilm@ this website if you are interested in helping out!

Friday, June 12, 2009

MicroFilm nominated in the Flash Lite Developer Challenge

Pleased to announce that MicroFilm has been nominated in the category of infotainment for the Flash Lite Developer Challenge

MicroFilm is something that Paul Wilson and myself have actually been working on for sometime. I think the idea was originally forged back in 2007 just after Flash Lite 3.0 was released. Since then we have been slowly modelling and building our take on a dream application for mobile. Imagine you have a nice phone, an unlimited data plan and you love movies - MicroFilm is for you!

Here's a video of the application in action. BTW. This is a real app, not a hacked together prototype, its fed via Adobe Media Server and a fully functional backend providing all the social networking stuff.

MicroFilm Video

Don't forget to vote too if you think MicroFilm is deserving!

Vote Here

Monday, April 20, 2009

Flash at the BBC

The BBC are currently recruiting for contract Flash developers in various departments.

You will need to be a very good developer with great knowledge of AVM1 ;) But don't let that put you off, quite seriously some of the work at the BBC at the moment is in the realms of dream projects. If you fancy playing a part in the future of mainstream entertainment, where the user is not sat in front of a desktop computer then please forward a CV.

What makes a project quite often are the people. The people you'd be working with on a day to day basis are legends in their field so the opportunity is second to none.

All roles are based in the UK, however international applications are not out of the question if your English is near fluent and you don't mind living in the UK for a bit.

Send me an email at flashbbc@gmail.com.

Labels: , ,

Tuesday, March 24, 2009

Why native accessors are really bad in Flash Lite.

At work we were discussing what standards we should use for coding. Things like consistency in formatting, naming and having agreed ways of doing things obviously makes everything easier.

So we entered into the discussion of public variables versus native accessors versus custom functions. Here's what I mean when I refer to the different accessors:


native accessor:
public function get width():Numbe{return _width;};
public function set width(value:Number):Void{_width = value;};

public variable:
public var width:Number;


private variable:
private var width:Number;


custom accessor function:

public function getWidth():Number{return _width;};
public function setWidth(value:Number):Void{_width = value;};


The most compelling argument to use custom accessor functions is that public/private variables, and to a lesser extent native accessors, don't allow you to hide your implementation. This is fine and good, but we are using Flash Lite with a resource limited device. In this scenario best coding practice sometimes has to make way for best performance.

So we decided to do some tests to see what the overhead would be of accessing variables one way or another?



Speed Test results in ms, making 10000 gets and sets:

Custom function 2439
Public variable 2394
Private variable 2395
Native accessor 13450



Memory Test results for creating 10000 instances of each class (kb).


Custom function 6528
Public variable 6528
Private variable 6528
Native accessor 6532


In terms of memory, everything is exactly the same except for native accessors.

For performance, the results show that public/private variables were very slightly faster to access compared to custom functions. However, the massive suprise is that native accessors are more than 5 times slower than public/private variables or custom functions. This is truly shocking, and really could completely slow down your application if you used them extensively.

So in many ways our decision about what approach to take with accessors was made really easy; never, ever, use native accessors! The marginal difference between public/private variables and custom variables was deemed insignificant when compared with the benefits of hiding the implementation.

It is possible to justify the use of public variables in some cases. If you have a value object that is strictly read only and has no functionality, then there is nothing to hide in terms of implementation. The only difficulty here is how do you determine that a value object is read only? How do you guarantee that it will never have any functionality going forward?

Labels: ,

Tuesday, January 20, 2009

XML and Flash Lite..... stuff of nightmares

XML has long plagued Flash Lite developers. It really is the stuff of nightmares, if you use XML you enter a world where nothing is what it seems. Your application lives or dies on the whim of Flash Lite and the XML document itself. If you are not careful you will find that the XML object is not cleared by Garbage Collection, scripts will reach the script timeout limit and stop processing silently, your application will fail.

After years of suffering here a few short notes on successful use of XML.

1. IdMap locks an XML object in memory. This is a bug. Here's the issue, with some XML files it is impossible to delete the XML object from memory because somehow the idMap holds a reference to the XML object itself. So before deleting an XML object you must first delete the XML.idMap property.

2. If you want to avoid the potential pitfalls of creating and then deleting XML objects, try just reusing the same XML object to process all your files.

3. Never do too much in a loop, this can cause the FL player to freak out and stop processing the loop, leaving you with an unfinished set of data. The timeout for loops on desktop is 15 seconds, on mobile this seems to be a lot less. This could be because OEMs have set it lower or it could just be because of poor implementations - who knows!

4. Don't forget the UI. Flash is single threaded so when you are executing code Flash must finish before it can render. This means your UI won't respond if actionscript is busy parsing an XML file.

5. onData() and onLoad() happen in the same frame. This means when an XML file is loaded it first creates the XML object via parseXML() then it calls onLoad() where you can walk through the DOM and access the nodes. The implication of this is that Flash has 2 heavy bits of processing to do in one frame, increasing the likelihood of a timeout. If timeouts are an issue you can overwrite the onData() event, call parseXML() and then call onLoad() in the next frame.

6. If you control the data you use then process it into something other than XML on the server or locally. XML objects occupy a lot of memory, name value pairs are much more efficient and you wont need to process them at all.

7. Test your XML loading needs at super speed in device central. So take your basic requirements for XML processing, create a new fla and set the FPS to 120. Do your loading operation 1000s of times and look at the memory. You'll get a good idea how good your memory handling is.

Thursday, October 09, 2008

Nokia Sports Tracker, Unicef and lots of running

Just over a year ago I started my own get fit program by going to the gym on a regular basis. At the same time I discovered Nokia Sports Tracker and for the first time in my life I actually started running! Of course I used to play football lots and that involved running after a ball but this was running for the sake of running - something I'd always viewed as a masocistic activity. Nokia Sports Tracker actually gave me a geek reason to start running and from there I've actually started enjoying it.

So this weekend everything culminates in me running a half marathon for Unicef in the Royal Parks Half which plots a 20k route around the central London parks. Its nice to see Nokia are one of the key sponsors, although its a shame they don't seem to be tying Nokia Sports Tracker into the event more. It would be good to see them push Sports Tracker a little more as its a great tool and has been around for well over a year now. Although I have a few gripes with the current version, the core functionality of being able to track progress via GPS and then share this with a google maps mashup is great.

The Royal Parks Half starts this sunday at 10 am. If anyone wants to sponsor me and help out Unicef that would be great and really appreciated: http://www.justgiving.com/nickgerig

I'll be using Sports Tracker to track my progress live on race day - so you should be able to go here and see live tracking data.

Sunday, July 06, 2008

the mobile soup

There's some great commentary on the mex blog about the state of operator and manufacturer consumer stances. You can read it here http://www.mobileuserexperience.com/?p=574

My take on this is that its all just part of the increasingly rapid shift in roles that is inevitable when a market is structured ineffectively. The whole web, mobile and other convergence is picking up pace. Operators and manufacturers have held all the cards for years and have failed spectacularly to produce any real consumer services.

Of course there are regional differences, Operators in Japan have taken full advantage of their position and turned themselves into real service facilitators, so the consumer is happy - they don't buy just a handset they buy a specific service laden handset targeted at all their needs. In Europe and the US service standards are so low that operators have to rely upon manufacturer provided USPs to create some kind of crap marketing campaign. It can only become increasingly easy for manufacturers and software service providers to take over.

Recently we've seen 02 and Orange suddenly become broadband and portal providers. This is really reminicent of the early internet days where models like MSN, AOL, Lycos etc were the norm. This is almost like a last desperate act of saying look we really are service providers honest, look we do email, news, broadband,etc. I'd be really suprised if any of them pull this off in the longrun. Even if they do, I think they miss the point - all anyone ever wanted was to have great services on mobile phones.

So I understand its a strategic move to counter the invasion of the internet services provided by the Googles and Yahoos, and you can't just have a mobile presence thats true. But that's just delaying the inevitable, they cannot compete at this level and their history proves that. The real battle will be between the handset manufacturers and the internet giants. We've already seen Nokia in particular start to move into multiplatform software, creating the potential to compete with the likes of Google, Apple, etc.

I think the interesting move will be when an operator makes the move to being just a facilitator and helps consumers get the services they want. That's when we'll see some really great things happening on mobile - ultimately the consumer doesn't care who dominates as long as the end result is good, something we are still far from with mobile. When will Google buy a controlling stake in an operator I wonder? :)