Aral on Flash, SWX, Flex, ActionScript, and life.
Our friends at Mozilla are trying to set a world record today for the most software downloaded in 24 hours to mark the launch of Firefox 3.
To support the effort, we're running a pro bono ad for Firefox Download Day on Pistach.io.
Pistach.io supports open source projects and charity organizations with pro-bono ads. If you would like your organization or project considered, please contact me at aral {at} pistach(.)io.
Go pledge your support for Firefox Download Day 2008 and download Firefox 3.
How cool, I just heard from Brajeshwar on Twitter that The GAE SWF Project is currently the featured application on the Google App Engine Application Gallery.
I released the proof of concept Flex 3 client late last night after the initial Flash 9 client release last week and I'm look forward to writing more about it in a future blog post.
And, far from being a theoretical exercise, the very pragmatic GAE SWF Framework is going evolve and get put through its paces as we use it to build the web application for the Singularity Web Conference. I can't wait!
Exciting times!
Today I'm releasing The GAE SWF Project, a resource of Flash and Flex-related knowledge specifically aimed at getting you up and running quickly with Google App Engine. If you want to skip all the details and start playing with it, skip to the Getting Started section.
Everyone else, read on!
When Google announced Google App Engine last week, I couldn't believe what I was hearing. It was as if someone had said, "Hey, Aral, tell us what your perfect development environment is and we'll build it for you."
In recent weeks, I had started playing with Python and Django and experimenting to see whether I could use it to build the web application for the Singularity web conference that I'm organizing at the end of October. Turns out that I could not have picked a better time to invest in learning Django and brushing up my Python as Google App Engine is heavily influenced by (and supports) Django and is written in Python.
Singularity is shaping up to be a really great conference. I'm honored to have a constantly-expanding stellar line-up of speakers and yet the sessions are just one very important aspect of the conference. I find that you get as much out of your social interactions with speakers and other attendees at conferences as you do from the sessions. And Singularity is no exception.
The Singularity conference application is not something you will login to on October 24th and never visit again beyond October 26th. On the contrary, I plan to launching the application as early as possible and add features as we go so that we can start building the community around the conference. This is essential for the organization of the local conference hubs, for building friendships months in advance of the conference, and so that you can influence what the conference ultimately becomes (you do not have to attend the conference to join the online community.)
When I initially announced the Singularity conference two months ago, I stated in the About page that Singularity would have a "focus on open source, the community, and on giving back."
Today, I'm taking the first step towards delivering on that promise by releasing the initial underpinnings of a framework that will eventually power the Singularity conference web application. I present to you The GAE SWF Project.
The GAE SWF Project (hey, Google chose the name, I only provide the juvenile attempts at humor) is a resource of Flash and Flex-related knowledge specifically aimed at getting you up and running quickly with Google App Engine. The initial release contains a proof-of-concept Flash 9 client showcasing a pre-alpha version of The GAE SWF Framework. The framework is a very light-weight combination of Python and ActionScript 3 that uses some of the best open source components available today on the Flash Platform and Python ecosystem. It is inspired at its core by best practices and a pragmatic approach to application development.
The proof of concept (and, indeed, the whole project) specifically targets Google App Engine. This is by design. The framework is not a generic one (although, by all means, feel free to get inspired and port it if you wish). The dedicated focus is part of the appeal. It means that we can make things simpler.
There will be no abstraction for the sake of abstraction and no premature abstraction; the framework will evolve by encountering real-world problems and solving them.
Finally, keep in mind that you are viewing the fruits of three days of work at the moment (this, in itself, should be testament enough to how easy -- and fun -- Google App Engine makes development). It is early days but I feel that we've made a good start. I hope to hear your thoughts and feedback in the comments.
The proof of concept is built on Google App Engine using Google's webapp framework.
It showcases several fundamental architectural considerations, the most important of which I've outlined for you below.
You use handlers in app.yaml to host a mix of Flash and HTML content, including the Flash Remoting gateway, in a single Google App Engine app.
SWFObject is the way to embed Flash and Flex applications in your HTML. Use it. 'Nuff said.
You implement deep linking using a combination of server-side Python and SWFAddress so that both SWFAddress-style and regular URLs are supported. Regular URLs are translated to SWFAddress-style hash/anchor URLs on the server.
Thus, both of the following URLs are valid ways to reach your profile page on the proof of concept Flash 9 client:
http://gaeswf.appspot.com/examples/initial/profile
http://gaeswf.appspot.com/examples/initial/#/profile
Users with poor eyesight or in environments with reduced-visibility (such as bright sunshine outdoors) may want to increase the size of the text displayed in the browser. By default, Flash and Flex content does not react to these text-size changes. However, it is possible to make Flash content obey browser text-size changes and the proof of concept implements one such method that does not involve any alterations to the Flash app.
(You can read more about similar issues -- and see some juicy Flash myths debunked -- in my review of the talk I gave at Highland Fling this month titled Bare-naked Flash: Dispelling myths and building bridges.)
PyAMF is a Flash Remoting implementation for Python. It has a dedicated and responsive group of passionate developers working on it, led by Thijs Triemstra, Nick Joyce, and Arnar Birgisson. On Tuesday, the team released PyAMF 0.3 with support for Google App Engine.
The GAE SWF Framework uses PyAMF as a core component to communicate with the server and the various Google App Engine APIs. It is currently running PyAMF 0.3.
The PyAMF gateway is setup as a regular mapping, and mapped to /gateway in app.yaml.
You use the Google App Engine Users API to login and out of the Flash application. The current Flash 9 proof of concept implements one of three possible ways of handling logins (see the note in my earlier blog post about the other two ways.)
When you hit a deep link in the application without logging in, you are automatically forwarded to the link after you login. This is a behavior that you are accustomed to seeing (and expect) in HTML-based applications but I have rarely seen it implemented in Flash and Flex applications.
The Google App Engine DataStore is a massively scalable database based on Google's Bigtable (the same distributed database that powers their search and services like Google Earth).
The proof of concept has a profile section where you can fill in your name and a URL (the Users API currently does not provide your GAE app with the user's name, just their email address). This data is saved via PyAMF and the DataStore API.
(All server-side services are in the /services package.)
The Profile Screen shows you how to implement two different types of validation: simple client-side validation and server-side validation.
The Name field performs simple client-side validation that stops the user from submitting the form without entering a name.
The URL field, on the other hand, actually hits the server and asks the DataStore to verify that the URL is valid. When you think about it, it makes sense to use server-side validation code to validate more complex data types using the exact same code that the DataStore API uses.
The user experience is managed via visual cues that are carefully scripted using the excellent KitchenSync AS3 sequencing library by Mims Wright. (Mims just added me as a project member so I can contribute a small update I blogged about earlier.)
(I'm still working on tweaking the timing of the type wait duration for firing the server-side validation code to make it as seamless as possible.)
As the framework develops, I know that the KitchenSync library is going to be an essential, core element, and I look forward to contributing back as much as I can to the project.
The proof of concept also makes use of the Google App Engine Mail API to send email confirmations to your Google Accounts email address after you update your profile.
When initially working with this, I was searching for a simple way to monitor the mail that was being sent from the app. Although the Development Web Server allows you to specify an SMTP server when you start it, I couldn't get it to work with either GMail or my web host's mail server. And setting up sendmail or postfix was a pile of worms I didn't want to sample.
Instead, I found a simple, open source SMTP server written in Python that's perfect when developing locally with the Development Web Server. It's in The GAE SWF Project app that you can download. To start it, simply change to your The GAE SWF Project folder and type:
./monitor_mail
You will see all email sent from your application in the Terminal window. (Note: I run on a Mac and all the commands in this article are meant to be run in Terminal on OS X. You may need to tweak them slightly for your operating system of choice.)
I may introduce myself as a Flash Developer but that doesn't mean that I don't care about the rest of the web. With good friends like Andy Budd, Richard Rutter, Paul Annette, and Jeremy Keith living almost a baseball-bat-wave away from me, I'd be scared silly implementing a new site with anything less than pristine markup. So that's what I've strived for here and I hope I've at least come close. (I did use one <br/> tag, for which I feel very dirty indeed!)
Nearly all of the credit for the CSS goes to the excellent YUI Grids CSS library that Rob Knight clued me into via Twitter last week when I was battling with altering the K2 theme on Singularity to make it into a cross-browser three-column fluid layout.
(The scale9-esque fluid download cell is courtesy of the even more rounded corners with CSS technique.)
The HTML content is structured using several Django templates, which are supported by Google's webapp framework.
Finally, the Flash client uses the TabBar component from the open source Yahoo Astra Flash components and Uza's AS3 Global Object to implement several global convenience properties (like the current SWF's URL).
Getting started with The GAE SWF Project couldn't be easier.
First off, download the Google App Engine SDK (includes the local Development Web Server and webapp framework.)
Next, download the latest release of the The GAE SWF Project and unzip it.
(Or, you can check out the unstable, bleeding-edge version from The GAE SWF Project Subversion repository's trunk on OSFlash.)
Open up Terminal and navigate to the folder you unzipped The GAE SWF Project to. To start the Development Web Server type:
./start
This is a convenience script that I made that starts the Development Web Server and sets the mail server as localhost:5000. You can change these in the script of just use dev_appserver.py . to start it up without mail support.
If you want to monitor the email that gets sent, open up a separate Terminal window and, in The GAE SWF Project folder, type:
./monitor_mail
Now that the app is running, view it in the browser by hitting http://localhost:8080.
You can now open up the source folder and start exploring!
Wow, did I just paraphrase Lionel Richie?
Anyway, I find it useful to tail the Flash trace log (especially to see trace results in the browser and online). Here's how you do it:
Before you start, you need to enable logging by creating a file called mm.cfg in /Library/Application Support/Macromedia.
In it, enter:
ErrorReportingEnable=1 TraceOutputFileEnable=1
You only need to do this once. After that, whenever you want to tail the log, open up a new Terminal window and type the following, replacing USER with your home folder:
tail -f /Users/USER/Library/Preferences/Macromedia/Flash\ Player/Logs/flashlog.txt
As I state on The GAE SWF Project site, I hope that this open source effort will help you to get started quickly with building Flash and Flex application on Google App Engine. In the past few days, I have had more fun developing this than I can remember in a long while. I love Python, I love Django, I love Google App Engine, and I love Flash and Flex. To have them all together... well, that's a dream toolset, right there!
And, there's something to be said about writing your app and then letting Google handle the rest. Personally, I can live with that.
(Oh yes, and I do desperately need to talk to someone at Google about hosting the Singularity conference web application on Google App Engine with regards to the quotas -- if you know whom I should contact, please either let me know directly at aral {at} aralbalkan(.)com or leave a comment below -- thanks!)
The GAE SWF Project is currently a proof-of-concept; it's a three-day old baby that I hope will blossom into a useful resource.
I hope you you enjoy it and I hope that it makes your life a little easier or at least gives you food for thought.
Play with it and let me know what you think in the comments.
As I mentioned previously, I gave a new talk titled Bare-naked Flash: Dispelling myths and building bridges at Highland Fling this week. What follows is a comprehensive live-blog style commentary of the session with slide highlights.
Continue reading 'Bare-naked Flash: Dispelling myths and building bridges'
Do you have a Flash, Flex, or ActionScript job to post? Post it on the OSFlash Job Board.
I've just relaunched the OSFlash Job Board and all jobs listings are 50% off this week if you use the coupon code RELAUNCH. This expires on April 1st, 2008 (no joke!) 
If you want to get notified of new jobs, you can get job alerts by email or subscribe to the RSS feed.
The OSFlash Job Board initially launched last year using the Joard system that my friend and business partner Dave Stone was developing. Dave decided to discontinue Joard at the start of this year so we were left without a job board.
It has taken a little while to get everything set up again but the job board is now back up and running using the excellent JobThread system.
OSFlash gets over 120,000 unique visitors every month. We also have a new job board widget that is featured on the OSFlash.org home page and here on my blog (I get around 70,000 unique visitors a month on this blog). By putting your job listing on the OSFlash Job Board, you'll thus be reaching a very tightly-focussed group of close to 200,000 Flash, Flex, and ActionScript developers, designers, and creatives.
Check out the OSFlash Job Board for Flash jobs, Flex jobs, and ActionScript jobs and don't forget to use the RELAUNCH coupon code to get 50% off your job listing until April 1st, 2008.
If you want to help support OSFlash, tell your friends about the OSFlash Job Board by adding the OSFlash Job Board widget to your site.
<script type="text/javascript"> <!-- var jobthread_jobroll_title = "Jobs"; var jobthread_jobroll_outer_style = "background-color:#dddddd;border:1px solid #999999;width:160px;"; var jobthread_jobroll_inner_style = "background-color:#ffffff;color:#666666;border:1px solid #999999;margin-left:10px;margin-right:10px;padding:10px 10px 2px 8px;font:11px Arial, Helvetica, Sans-serif;line-height:16px;"; var jobthread_jobroll_title_style = "color:#313131;font-weight:bold;"; var jobthread_jobroll_link_style = "color:#0464bb;font-size:11px;font-weight:bold;text-decoration:none;border:none;"; var jobthread_jobroll_featured_style = ""; var jobthread_jobroll_featured_link_style = ""; var jobthread_jobroll_top_style = "padding-top:8px;"; var jobthread_jobroll_bottom_style = "padding-bottom:4px;"; //--> </script> <script type="text/javascript" src="http://jobs.osflash.org/feeds/jobroll/?num_jobs=5&num_featured_jobs=1&display_method=default&version=2.0"></script>
I also made a simple Wordpress Widget that you can use to add the Job Board to your Wordpress blog's sidebar. Download the OSFlash Job Board Wordpress widget.
Once you've downloaded it, simply extract it into your wp-content/plugins folder, activate it, and add it to your sidebar from the Widgets section of the Wordpress administration tool. (Note: The CSS positioning is set for my site, you may need to modify it to make it display correctly for yours.)
Here's the source for the OSFlash Job Board Wordpress plugin. It's released under the open source MIT license, so please feel free to use and adapt it to make your own Wordpress plugins too.
<?php /* Plugin Name: OSFlash Job Board Badge Plugin URI: http://aralbalkan.com Description: Displays the OSFlash Job Board Badge on your Wordpress blog. Released under the MIT License. Copyright (c) 2008 Aral Balkan. http://aralbalkan.com. Author: Aral Balkan Version: 1.0 Author URI: http://aralbalkan.com */ function osflash_job_board_widget_init() { if ( !function_exists('register_sidebar_widget') || !function_exists('register_widget_control') ) return; function osflash_job_board_widget($args) { extract($args); echo $before_widget; ?> <div class="osflashJobBoard"> <script type="text/javascript"> <!-- var jobthread_jobroll_title = "Jobs"; var jobthread_jobroll_outer_style = "background-color:#dddddd;border:1px solid #999999;width:160px;"; var jobthread_jobroll_inner_style = "background-color:#ffffff;color:#666666;border:1px solid #999999;margin-left:10px;margin-right:10px;padding:10px 10px 2px 8px;font:11px Arial, Helvetica, Sans-serif;line-height:16px;"; var jobthread_jobroll_title_style = "color:#313131;font-weight:bold;"; var jobthread_jobroll_link_style = "color:#0464bb;font-size:11px;font-weight:bold;text-decoration:none;border:none;"; var jobthread_jobroll_featured_style = ""; var jobthread_jobroll_featured_link_style = ""; var jobthread_jobroll_top_style = "padding-top:8px;"; var jobthread_jobroll_bottom_style = "padding-bottom:4px;"; //--> </script> <script type="text/javascript" src="http://jobs.osflash.org/feeds/jobroll/?num_jobs=5&num_featured_jobs=1&display_method=default&version=2.0"></script> </div> <?php echo $after_widget; } // Register widget register_sidebar_widget('OSFlash Job Board', 'osflash_job_board_widget'); } function osflash_job_board_style() { ?> <style type="text/css"> .osflashJobBoard { position: absolute; left: 20px; } </style> <? } // Add widget once plugins are loaded. add_action('plugins_loaded', 'osflash_job_board_widget_init'); // Add the badge's CSS to the head. add_action('wp_head', 'osflash_job_board_style'); ?>
Update: There was a small hiccup right after the blog announcement. If you couldn't reach OSFlash.org or jobs.osflash.org, please try again. It's back up and running! Thanks!
The BuddyPress site is currently moving servers but you can still get the open source BuddyPress code from Google Code.
I just had a quick look at the code; the core features (profiles, friends, and messaging) have been implemented and it looks promising.
I'm still debating which (if any) existing platform to base the social networking aspects of Singularity on. The top contender so far is Drupal but, the more I look into existing solutions, the more I feel that a clean, service-oriented custom solution is the best one for the Flex-based Singularity conference application.
Doug McCune is reporting that there is a clause in the Widget Design Challenge 2008 contest being run by eBay that bars entrants from using open source libraries in their entries.
The actual clause follows:
Widget may not incorporate any open source code except for Adobe Flex under the MPL license
This is not good.
I cannot think of any project I've worked on in my career, going as far back as I can remember, that did not use open source code in some capacity. Heck, we owe "Web 2.0" and the web as we know it to open source (can you imagine Google being what it is today while running its huge server farms on Windows Server?) Open source is everywhere, both behind the scenes (powering operating systems, application servers, and databases) and in front (Wordpress, Papervision3D, MediaWiki, etc.) When I was still doing client work, I wouldn't take on any project with a "no open source" clause. Life's too short. And I have much better things to do than reinvent the wheel.
The Flash Platform is blessed when it comes to open source. You can find quite a comprehensive list of open source Flash projects on OSFlash. It makes no sense whatsoever to guarantee a reduction in the quality of entries by disallowing developers access to these amazing tools.
Doug sums up what developers will be missing out nicely in his post:
That means no 3D engines, no physics engines, no custom component libraries. If you wanted 3D you’d have to build your own custom 3D engine. Umm, no thanks. It’s funny because they make the explicit exception for the Flex framework, since if they didn’t do that you wouldn’t be able to make any Flex app at all.
I know this must just be a legal clause that slipped by the Flash team at eBay who are organizing the contest. Now that it has been unearthed, I have no doubt that eBay will swiftly rectify the situation and allow open source libraries and tools to be used in the contest.
As Spock would say, "it's only logical, captain." (Yeah, I gotta lay off the Star Trek books, I know!)
I'm referring to the blog post by David Arno that asks Has Adobe just killed SWX?
David's post refers to the recent opening of the AMF format (good one, Adobe, and about time, I'd say) and the open source release of BlazeDS.
David states:
Flash-based RIA developers wanting to pass data between the client and a back-end server have had to choose between three unappealing technologies: XML/JSON, Adobe’s official remoting technologies and unofficial third party tools based on “hacking” Adobe file formats. The first suffers from serialization/ deserialization and verbose data format overheads. The second is just plain expensive (and only works with Java back-ends). The third is of dubious legality.
It's a good summary. Unfortunately, it's not accurate. Specifically, the bit about SWX being of "dubious legality".
Just to be clear, let me state this for the record: There is no doubt whatsoever about the legality of SWX, SWX RPC, SWX PHP or of any of the other implementations of SWX RPC (SWX Ruby, SWX Java, etc.)
It is actually quite unfortunate that Adobe's previously closed approach to all things Flash, including the "you can't make server products if you read the spec" clause in the Flash 8 spec, casts a shadow of doubt over products like SWX that benefit the Flash Platform instead of celebrating their contribution to the ecosystem. Well, I didn't read the SWF spec to create the AVM1 version of SWX PHP so it is not of "debious legality". Stating that SWX PHP is of "dubious legality" is nothing but FUD.
The same goes for the upcoming AVM2 version of SWX PHP that is based on the Flash 9 spec. The Flash 9 spec does not have the same server product restriction of the previous SWF specs so we are using it to create the AVM2 implementation.
David continues:
Has Adobe just killed SWX? Until today, SWX lacked (as far as I could tell) the ability to pass complex objects back and forth between server and client, but it more than made up for this by the server providing the data as native SWF files.
Unfortunately, again, the information here is just plain wrong.
The whole idea behind SWX is that you can pass complex objects back and forth between the tiers easily -- as they are passed as native data structures. When passing a complex data structure from client to server, SWX RPC encodes it in JSON format. When getting complex (and simple) data types from the server, you receive them as native ActionScript objects within a SWF. In fact, that's what SWX RPC is all about: native data -- both simple and complex.
Finally, David states:
However now that AMFPHP is fully legal and SWX remains in the legal grey zone, to me the choice between AMFPHP and SWX becomes a no-brainer. I can see no reason now to use SWX.
Again, SWX is not in a "legal grey zone" and the reasons for using SWX are the same as they have always been: simplicity.
And, as SWX contains AMFPHP as a library, you are not locked into using SWX RPC in your application. You can start out using the SWX gateway and then switch to using the AMF gateway (or JSON or one of the other gateways provided by AMFPHP) without re-writing your server-side classes. Or use both gateways if you want to: AMF for a web view, for example, and SWX for a mobile view.
And finally, remember that SWX RPC is still the only performant RPC solution for Flash Lite 2+ as remoting is not supported there. As evidenced by the entries in the latest SWX contest (one of the sponsors of which is Adobe), though, I would say that SWX use is far greater on the web than on mobile. This, as I understand from feedback on the Flash Mobile group, is due to the relative lack of Flash Lite 2/3 development in general in the real world currently.
I am personally delighted that Adobe have opened up the AMF protocol and released an open source version of FDS/LiveCycle Data Services. This is something I've been pushing them to do both privately and publicly for the longest time so I couldn't be happier. It's a big win for the Flash Platform.
Also, I'm very happy to see the progress made by Wade on AMFPHP. As I mentioned earlier, SWX PHP actually uses AMFPHP as a library and I have always supported (and continue to support) the AMFPHP project (just take a cursory glance at the web site if you need proof of that!) Heck, we'd all be calling it INFRNO if it wasn't for me!
I see AMFPHP and SWX as complimentary products. I made it a primary design decision of SWX PHP to have it be compatible with AMFPHP. I also urge other implementations of SWX RPC to maintain compatibility with the dominant open source AMF implementation on their respective platforms.
Adobe's latest move, far from killing SWX, will only strengthen the Flash Platform and all products on it, including SWX by winning us more developers.
Bad Behavior has blocked 0 access attempts in the last 7 days.
Recent Comments