The Flex client works exactly like the Flash 9 client and shares an almost identical codebase. 99% of the framework is the same.
I'm going to document that differences, etc., but it's past 1am at the moment and I need to sleep!
Tag Archive for 'as3'
I just updated The GAE SWF Project to add the proof-of-concept Google App Engine Flex 3 client. The source code download now includes the source code for the Flex project.
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.
A framework for the Singularity Conference
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
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
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.
HTML and Flash in a tree...
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.
Embed Flash content using SWFObject
SWFObject is the way to embed Flash and Flex applications in your HTML. Use it. 'Nuff said.
Deep links
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:
Regular URL:
http://gaeswf.appspot.com/examples/initial/profile
SWFAddress-style URL:
http://gaeswf.appspot.com/examples/initial/#/profile
Flash content that obeys browser text-size changes
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
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.
Users API
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.)
Intelligent forwarding after login
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.
DataStore API
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.)
Client-side and server-side validation
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.
Mail API
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.)
CSS, etc.
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
Getting started with The GAE SWF Project couldn't be easier.
1. Download and unzip
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.)
2. Start the server
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
3. View the app and start hacking!
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!
Trace you, trace me, trace it for always...
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
Play, enjoy, share, have fun!
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.
Update: This post is barely a week old and already outdates. See my updated post and The GAE SWF Project to get started quickly buildingFlash and Flex applications on Google App Engine.
Continue reading 'Building Flash applications with Google App Engine'
Continue reading 'Building Flash applications with Google App Engine'
I just read a blog post and watched a screencast about a new Flash framework called Gaia and I like most of what I saw.
For one thing, it uses SWFObject and SWFAddress and thus forces developers to use good practices when embedding their Flash applications (via progressive enhancement) and makes sure that applications support deep linking (thereby visibly disproving a popular myth that just refuses to die).
Flex Builder and the Flash IDE can learn a lot from Gaia when it comes to supporting good practices. Both Flex Builder and the Flash IDE should use SWFObject and SWFAddress and it baffles me why they do not to this day.
Their site states that the Gaia framework is available in both AS2 and AS3. I did see some timeline code (AS2) in the screencast that made me cringe a little but I haven't had a chance to play with it myself (give a guy a break, it's almost midnight!) I assume that the AS3 version uses the document class and code behind.
From what I've seen, Gaia looks like a very pragmatic front-end framework for Flash developers. I plan on looking at it in more depth when I get a moment and I suggest that you do the same.
This originally started as a response to a recent comment by someone called Pondus on a post on AS2Lib from four years ago but it grew to morph into a post of its own.
In the comment, Pondus states:
I have worked extensively with both AS3 and AS2 and every framework I could get my hands on. as2lib is the best tool I’ve seen so far… by far. But my judgement is perhaps clouded by the fact that my main has been C++, Java, Ruby etc, not Flash until recently.
So with all due respect, it seems that Aral’s take on as2lib represents a misunderstanding of the core problems as2lib [tackles.]
Spend some time working with the very finest frameworks in the java or C# world, like Spring (springframework.org), and then as2lib will make a lot more sense.
OK, to be fair, Aral wrote his post in 2004, when as2lib was not mature, and few people really got Aspect Oriented programming, IoC containers etc.
Simon says “those who like it can use it”. The sad fact is that in the Flash world it’s really more about “those who get it WILL love it”, but few do. The Actionscript culture is dominated by script kiddies, and that’s ok for most projects.
It’s a real shame that as2lib has died. I’ll say it again, it’s BY FAR the best project I have seen in the Actionscript world. Simon his crew are in a league of their own…
I haven't taken a look at AS2Lib in a long time and there's no doubting that Simon is a great programmer. That said, however, my gripe with AS2Lib was that it was too heavy for ActionScript. Unnecessarily so in my opinion. At least that was the case when I looked at it about four years ago and I haven't looked at it since.
In his comment, Pondus states that ActionScript culture is dominated by script kiddies. That's about half right. I'd say that it isn't dominated by but is entirely comprised of script kiddies. You see, it's called ActionScript. And I like to think that we're all kids at heart! 
ActionScript a scripting language. And there's nothing wrong with that (unless you're an elitist stuck-up-your-own-ass Real Programmer (tm) who can only use Real Programming Languages and has Scripting Allergy -- you know, the type that can usually be found creating memory leaks in C++ or adding yet another bloated library to his bloated codebase in Java.)
Personally, I love scripting. It means that I don't have to worry about unnecessary plumbing chores so I can get on with building what I'm actually building.
Unfortunately, the Real Programmers have had quite an impact on the direction that ActionScript has taken.
Specifically, in trying to be make ActionScript more like Java, we have sacrificed some of the simplicity that made ActionScript (and Flash) so accessible in the past. It was telling that the first reaction of one of the top Flash developers (Keith Peters) to ActionScript 3 was to create a Processing-like development environment for it.
I feel that partly this was due to Macromedia's desire to gain enterprise developers for Flex during the early days of Flex. This, in part, led to a sort of awe of Java in the ActionScript community as being the grown-up's programming language. Also, it led to Java developers with no understanding of the Flash Platform migrating to it and expecting it to behave exactly like Java. (And, in a certain dose of arrogance, when discovering that it was actually a different platform, trying to make it behave like Java instead of learning the platform, its character, and discovering its own unique advantages.)
ActionScript is an optionally-typed, dynamic language. In other words, it couldn't be less like Java if it was actually trying to be. Its syntax may look like Java but, if anything, that's a source of confusion as it doesn't behave like Java under the hood.
Personally, I find Java to be the antithesis of succinct, pragmatic, and agile. (To give the Java community credit, in the past few years there has been a concerted effort to make Java lighter.)
IMHO, any development environment or language where you need IDE assistance (instead of having it as a nice to have) in order to develop effectively is demonstrating a certain level of bloat. Features like required imports have made ActionScript a language that you need IDE assistance to code for. And I feel that this is a loss. (Flex Builder is a great tool and I do all my development in it but I would loathe to develop AS3 in an editor without language intelligence).
So, to summarize, this script kiddie thinks that we need solutions that are only as complicated as necessary to solve the problems they are tackling. Additional, artificial complexity may make you feel smarter than thou but, ego issues aside, what is the net gain?
My rule of thumb is that every abstraction, while possibly a factor in easing maintainability and scalability, is also the introduction of a new layer of complexity. What we have to ask ourselves, every time we introduce a new layer of complexity is "does the benefit of this abstraction outweigh the additional complexity?"
Abstraction for the sake of abstraction is nothing but an ego trip for Real Programmers. For everyone else, it's a pain in the ass, lost productivity, and lost time.
Flex comes with a built-in form validation system that unfortunately uses mystery meat tooltips to display component validation errors.
To see what I mean, take a look at the example I wrote a while back in the Validating Data Quick Start.
If you tab around that example, you may notice that you are probably doing something wrong (as indicated by the red borders around the form items that begin to appear) but you have no idea what you're doing wrong. In order to find out, you have to mouse over the form field. Only then does a tooltip appear to tell you what the problem is.
Needless to say, having the user switch input devices and exert additional effort in order to see a form validation error does not make for good ergonomics or usability.
A better alternative is to actually display the error message beside the control.
You can, of course, do this simply by having the error message in a label.
For example:
<mx:FormItem label="Your name">
<mx:HBox>
<mx:TextInput id="yourName" change="validateNotEmptyTextInput(yourName);" focusOut="validateNotEmptyTextInput(yourName);"/>
<mx:Label id="yourNameError" visible="false" text="Your name cannot be empty."/>
</mx:HBox>
</mx:FormItem>
The validateNotEmptyTextInput() method, in this example, is not a Flex Validator (as used in my Validation Quick Start), but a simple method.
For example:
private function validateNotEmptyTextInput(target:TextInput):void { (this[target.name+"Error"] as Label).visible = (target.text == ""); }
In the above example, I'm using a pragmatic naming convention to create a generic validation method that works with TextInput components. Nothing too spectacular visually, but usability-wise already better than the default Flex behavior.
Creating an error Label for each component, though, is not very practical. We can overcome this limitation and add a little visual flare by using the Flex error tooltip instead of a label.
Kyle Quevillon has a post in which he details how to use the Flex Tooltip Manager to create Error Tooltips. Referring to Kyle's post, we can alter the validateNotEmptyTextInput() method as follows:
// If the TextInput is empty, display an error message. if (target.text == "") { // Has the error message ToolTip already been created? // (A reference to created ToolTip instances is saved in a hash called errorMessageToolTips.) var toolTipExists:Boolean = errorMessageToolTips.hasOwnProperty(target.name); if (toolTipExists) { // Error message ToolTip has already been created, just show it. (errorMessages[target.name] as ToolTip).visible = true; } else { // Create the ToolTip instance. var pt:Point = new Point(target.x, target.y); pt = target.contentToGlobal(pt); var errorTip:ToolTip = ToolTipManager.createToolTip(errorMessages[target.name] + " cannot be empty", pt.x + target.width + 5, pt.y) as ToolTip; errorTip.setStyle("styleName", "errorTip"); // Save a reference to the error message ToolTip in a hash for later use. errorMessages[target.name] = errorTip; } } else { // TextInput is valid. Hide the error message if one exists. if (toolTipExists) { (errorMessageToolTips[target.name] as ToolTip).visible = false; } }
Where errorMessages is a hash of personalized messages:
errorMessages = { yourName: "Your name", yourEmail: "Your email", phone: "The phone number" }
Thus, we no longer need the Label component but there is a catch: we still need the HBox (or a container of some sort) if the TextInput is in a FormItem. Otherwise, contentToGlobal() returns an incorrect value when trying to position the error message.
So the new FormItem looks something like this:
<mx:FormItem label="Your name">
<mx:HBox>
<mx:TextInput id="yourName" change="validateNotEmptyTextInput(yourName);" focusOut="validateNotEmptyTextInput(yourName);"/>
</mx:HBox>
</mx:FormItem>
And the resulting validation errors both look nice and are functional.
(In the above example, I modified the errorTip style to make the message boxes slightly shorter than usual by setting the paddingTop and paddingBottom properties to 2.)
To summarize, I'm not a big fan of the mystery meat validation error tooltips in Flex. Displaying validation errors on the form itself leads to better usability as users do not have to exert additional effort to find out what they did incorrectly.
Update: Someone has filed a bug about this very issue in the public Flex Bug and Issue Management System. I've left a comment on the bug and linked it to this post.
If you want to redispatch a ResultEvent when using Danny Patterson's AS3 Lightweight Remoting Framework, you have to modify the ResultEvent class to override the clone() method.
So, if you want to do something like this:
private function resultHandler(event:ResultEvent):void { dispatchEvent(event); }
Just add the following method to com.dannypatterson.remoting.ResultEvent:
public override function clone():Event { return new ResultEvent(type, bubbles, cancelable, result); }
Ditto for the FaultEvent.
Recent Comments