April 5th, 2009
I recently worked on a project where the client was providing designs for image manipulations which were being done with a ColorTransform in flash. After a couple of bits of feedback along the lines of “…can the blues have more yellows in them at times…” I decided there must be a better way.
So I built the client a tool which allowed them to fiddle with parameters to ColorTransform and send me the numbers. It’s in the same vein as the Flex style explorer but much simpler. So simple in fact that it is hardly worth posting but I was surprised that I couldn’t find something similar on google so I thought I would save someone else the half hour it took to put together…
Click on the picture below to try it out or you can download the source here.
April 4th, 2009
Last weekend I joined in on the first ever Flex Bug Quash. What is a bug quash?
An event where the community comes together with one goal in mind… To quash as many bugs in one day as humanly possible. Don’t just complain, do something about it.
The idea was to allow the commuity to get involved and contribute bug fixes for the Flex framework back to Adobe. This is open source in action! As someone who has spent a fair amount of time cursing the Flex framework and it’s bugs I thought that I should get involved. It also seemed like a good opportunity to network with other Flex developers – although this aspect would have definitely been better if I was close enough to attend in person in Seattle (or one of the other hubs). At least I was in the correct timezone – some developers in Europe, Asia and Australia worked through the night!
After checking out a working copy of the entire 3.x branch of the Flex SDK from the repository I could work on getting my environment set up. The SDK has Flex Builder library projects for the framework.swc, airframework.swc and rpc.swc set up. So I set up a “BugQuash” project and linked it into the framework library project. This means I was basically monkey patching the framework.swc with the latest sourcecode from svn – including any changes I made. This allowed me to easily tackle bugs.
There was a list of bugs on the Adobe bug tracker which were marked as “SDK Community Bug Fix Candidates” – these were bugs which were considered good candidates for the community to tackle. I think this meant that they hadn’t been judged important enough to be placed on an Adobe engineer’s workload and they weren’t considered too hard or dangerous for the community to have a go at. I had a quick flick through the issues on this list and picked the first one which looked like a nice quick and simple fix.
My first bug took a little longer than I expected to fix. While it was quite simple I wanted to make sure that I was doing things correctly and putting my code in the correct places. It’s harder than simply writing code as you have to make sure you think about how any other developer might use (or abuse) the code you write. Once my code was done I generated a patch file – this was easily done with Tortoise SVN. Having signed the relevant legal documents I could then simply attach the patch to the relevant ticket in the bug tracking system.
Once the patch was on the system it needed to be reviewed by a member of the community. Chris Hill kindly volunterred and checked my code and added some extra test cases. Once this was done the bug went into a queue waiting for official Adobe code review. And once that was done my patch was given the go-ahead and committed back to the framework repository. It was very satisfying when my bug was approved and my patch was checked into SVN. I’m genuinely proud that some of my code is in the Flex framework and that I’ve added some useful functionality. And I’m fairly certain that this bug fix will save some cursing for developers when the next point release of the framework comes out!
I then picked up another bug to look at and also successfully submitted a patch for it. As a prize (along with having hopefully helped to make Flex a better place for developers) I get to display this little badge:
Overall I found the event to be very rewarding. More important than the bugs I fixed on the day is the fact that I now feel that I can contribute to the Flex framework. I’m not using Flex too much at the moment but I know that when I was using it day in, day out I would often come up against bugs. And often the fix was simple to implement. But if the fix required monkey patching or otherwise modifying the framework it wouldn’t be allowed in the project (as the project needs to build with a default Flex framework) and I’d end up using an ugly workaround instead.
Now that I know I can submit patches to Adobe and that those patches can be accepted into the framework (obviously dependant on their quality and any side effects) I am much more likely to do so. And if there are a number of similarily empowered developers using Flex day in, day out then we should see a vast reduction in the number of bugs in the Flex framework. So I think that the inaugural flex bug quash was a great success and I look forward to using a more reliable flex framework in the future.
May 14th, 2007
I decided it was about time that I learnt how to use Flex. The best way to learn is always by building something so I decided that I’d build a little app to connect to the Slim Timer API and make it easy to keep track of your time. It seemed like something that was perfectly suited to Flex – built from UI components and connecting to an XML webservice.
So here it is: Slimmer Timer. You can download Mac and PC versions as well as seeing a screenshow on the project page at that link.
Although building the app was relatively straightforward, there are some gotchas that I ran into which I thought I would expand on a little here… All of these issues are as I experienced them in the standalone debug player – they may happen differently in the browser plugin.
- Setting contentType and a custom “Accept” header on a HTTPService only works when the method is POST. If you change the method to GET then these extra headers aren’t sent along with the request.
- The HTTPService.method documentation is very misleading… GET and POST are the only valid values unless you are using FDS as a proxy. More info on that on this post on FlexCoders
The solution to these problems was to wrap my generated swf in a Screenweaver Hx program. This makes it easy to write a little bit of haXe code which can intercept network calls from the flash and act on them. The haXe wrapper adds the required HTTP headers to my GET calls and also allows Flash to make PUT requests.
To support HTTP PUT requests I appended a “put=true” onto the URL requested by Flash which the haXe wrapper detects and then changes the HTTP request type. haXe’s HTTP class doesn’t support methods other than GET and POST but because it is open source I could easily extend this class to suit my needs. The haXe files I wrote can be seen here if you are interested…
As well allowing me to tweak the network behaviour and therefore make my app work, Screenweaver allowed me to remove the chrome from the app window and make the app slightly transparent. These extras help it to live up to it’s name of “Slimmer Timer” :)
As SlimmerTimer was my first foray into the world of Flex it’s not as well coded as it could be. I’m currently rewriting it using the Cairngorm framework so there may be a better version out some time soon but for now I think it’s quite useful as what it is – a simple little app for keeping track of your time.