Dynamic Flash

Confessions of a serial code abuser
  • rss
  • Home
  • MTASC
  • Archives
  • About me
  • Goodies
    • Base64 encoder/decoder class
  • My Bookshelf
  • My Talks

The trouble with Flash and REST

Tuesday, 11 November 2008

I find it shocking that the Flash Player still lacks the ability to properly interact with RESTful web services. I keep running into this issue, and every time I scour the Internet hoping that someone, somewhere has found a solution. Every time I return disappointed, hating the Flash Player just a little bit more.

REST stands for REpresentational State Transfer, and describes a technique to organise a web service into resources that can be uniquely identified by a URI. The actions that can be performed on that resource map directly to the standard HTTP methods: GET, POST, PUT, DELETE, HEAD and OPTIONS. With properly organised resources it’s possible to do virtually everything you can do with an RPC-style web service with REST. The benefit of REST is that it goes with the grain of the web, not against it.

The problem with the Flash Player is that the URLRequest class, which is the basis for all HTTP requests, only supports GET and POST operations1. This is due to a limitation in the NPAPI pseudo-standard used by non-IE browsers that only exposes the ability to make GET and POST requests. Unless NPAPI is updated to allow other HTTP methods, and browser vendors and plugin authors update their implementations to match that new API, we need to find other ways of interacting with RESTful web services.

Now, If you’re lucky, the web service you’re trying to interact with will support some way of overriding the request method, such as a X-HTTP-Method-Override header. If this is the case, you can use the requestHeaders property of your URLRequest object to set the appropriate method:

// Create request object with appropriate resource URL
var req:URLRequest = new URLRequest( 'http://rest.example.com/v1/book/1234' );
 
// Use POST because DELETE is non-idempotent
req.method = URLRequestMethod.POST;
 
// Specify DELETE method in X-HTTP-Method-Override header
req.requestHeaders = [ new URLRequestHeader( 'X-HTTP-Method-Override', 'DELETE') ];

If your web service isn’t quite so forgiving, the only option you have is to use the ExternalInferface class and some JavaScript magic to make requests on behalf of your Flash project and send the response back. It’s an ugly hack, but a developer’s gotta do what a developer’s gotta do. If you’re interested in this workaround, leave a comment and I’ll knock up a simple example.

For what it’s worth, Silverlight fares no better in this regard. This is not surprising since Microsoft are stuck with the same browser plug-in APIs as Adobe, but that doesn’t make it any less annoying for developers on both sides of the fence.


  1. If you’re building Adobe AIR applications, you actually have access to the full gamut of HTTP request methods. See the URLRequestMethod documentation for more information. ↩

Comments
1 Comment »
Categories
Flash
Tags
air, Flash, flex, http, JavaScript, representational state transfer, rest, silverlight
Comments rss Comments rss
Trackback Trackback

<head> over heels

Wednesday, 29 October 2008

So, <head> 2008 is over, and it was nothing short of amazing. Sure, there were a few technical issues, but that’s inevitable when you’re bringing together 70+ speakers and over 2000 attendees from all over the world into one virtual online space for 3 days of fun and learning.

I was fortunate enough to take part in two sessions at the conference. The first was a “State of Flash” conversation live on stage at the London Hub with Carlos Ulloa and Seb Lee-Delisle, and with Aral Balkan guest-starring as moderator. This was my first time on stage at a proper conference, and I think the conversation format and sharing the stage with 3 Flash luminaries, not to mention the large Yahoo contingent in the audience, really helped to ease whatever pre-session nerves I had.

We covered a whole bunch of Flash related topics, from what excites us in the Flash world to discussion of Johnathan Harris’s controversial statements made during the closing keynote at Flash on the Beach ‘08. Based on the questions and feedback afterwards, it seems this session went down pretty well.

Steve Webser, Carlos Ulloa and Seb Lee-Delisle in conversation on stage at head (Photo: bru76)

Steve Webser, Carlos Ulloa and Seb Lee-Delisle at <head> (via bru76)

The second session, entitled Beg, Borrow or Steal: The Art of Flashing Without Flashing, was presented virtually from the comfort of my own living room on Sunday evening. The basic idea was to show that you can steal advanced features from the Flash Player in your standards-based sites and applications that you would otherwise have to wait until HTML5 is fully supported to use. Every time I practiced this before the day the session came in at around the 25 minute mark. Somehow, on the day, I managed to tak up 40 of my allotted 45 minutes with the slides and examples, which only left 5 minutes for Q&A. Oops.

Anyway, the slides and example files from the second session are available to download from the My Talks section of this site. Eventually there will be videos of both sessions available through the <head> website, though for the first 6 months they are exclusive to attendees of the conference. I’ll post a follow-up once the videos are generally available.

A massive thank-you goes out to Aral and the rest of the <head> team for putting together such an awesome and groundbreaking conference. Friday’s sessions and the general geek gathering at the London hub were, in my opinion, worth the admission price alone, and being able to watch the remainder of the conference in my pajamas was quite an experience. One thing’s for sure: <head> ‘09 has a lot to live up to.

Comments
1 Comment »
Categories
General
Tags
ActionScript, Flash, head, head08, head2008, headconference, html5, JavaScript
Comments rss Comments rss
Trackback Trackback

The problem with SproutCore

Monday, 14 July 2008

I’ve been meaning to sit down and this article on SproutCore ever since it shot to fame as the underlying client-side framework used to build Apple’s recently released MobileMe web application. You see, SproutCore seems to have had a falling out with web standards and web development best practices, something that wasn’t getting picked up in all the mainstream coverage it was receiving.

For the uninitiated, SproutCore is a JavaScript framework developed by SproutIt. It was initially developed to enable them to build their Mailroom application, which according to their website is a hosted help desk service for consumer-oriented businesses . So far, so good. The description given on the SproutCore website makes it sound like the framework is similar to other JavaScript libraries like YUI and JQuery, only a little more focussed on the application as a whole:

SproutCore is a framework for building applications in JavaScript with remarkably little amounts of code. It can help you build full “thick” client applications in the web browser that can create and modify data, often completely independent of your web server, communicating with your server via Ajax only when they need to save or load data.

What the above paragraph only hints at, though, is that SproutCore doesn’t just ignore progressive enhancement — it hacks it into tiny little pieces, urinates all over them and then mails them back to you one by one:

After lots of testing, we have found that the most efficient way to server a SproutCore application is as a … static web page! Once a SproutCore application is loaded into your web browser, it communicates with your backend server using Ajax.

Can you guess what an application looks like with JavaScript disabled? If you said “a blank page”, you can give yourself half a gold star. The unfortunate truth is that what you get is even worse than a blank page - you get a page devoid of any content but with UI controls that do absolutely bugger all. Don’t just take my word for it; check out the check out the SproutCore Photos example and then turn JavaScript off and hit refresh.

I thought we’d moved past this whole progressive enhancement issue back when Jeremy Keith was banging on about it to anyone who stood still for long enough. Alas, it seems there are still some poor unfortunately souls who have yet to benefit from Jeremy’s wisdom.

The total disregard for progressive enhancement is not the only thing wrong with SproutCore. Almost every UI widget and container in the framework is represented by nested <div> elements, differentiated only by their combination of class names. Where semantic elements are used they are used incorrectly (i.e. using <label> for headings). There is no sign of tab-enabling them or WAI-ARIA support, and all of this means that SproutCore applications are likely to be totally inaccessible out of the box.

OK, so SproutCore is bad, but what does all this have to do with Flash? That’s a fair question, given that the main focus of this blog has been Flash / Flex / AIR for the past 3 years. The answer is that the About SproutCore page takes a fundamentally misinformed swipe at Flash, and I’m calling them on it:

Why should I use SproutCore instead of a plugin like Flash or Silverlight?

Nobody likes using software running in a sandbox and no one likes to download plugins before they can use your software. If you want to create an application on the web that is fast, fluid, and native, and usable by everyone, use the only technologies that come built right into every browser: HTML and JavaScript. SproutCore makes it easy to do just that.

It seems that the SproutCore developers may have forgotten that JavaScript also runs in a sandbox, and it’s a great deal more restrictive than the Flash Player. Just try making a cross domain request using JavaScript, or setting up a permanent connection to a socket server, or (as is available in Flash Player 10) run-time access to local files.

They also seem to have missed the fact that the percentage of users unable to see Flash content is significantly lower than those fumbling around the Internet without JavaScript disabled. According to Adobe’s statistics content published for Flash Player 9 is viewable by an average of 97.4% of web users across all markets. That compares very favourably with the 95% of users who have JavaScript enabled according to w3schools.

Oh, and there’s nothing special about SproutCore’s fast, fluid and native controls - they are no more or less fast, fluid or native than Flash or Flex components. You can make either one look like native operating system controls but that doesn’t mean you should, and speed of execution and layout is down the to the implementation. On the speed front, it’s interesting to note that Mozilla are busy integrating Tamarin (the ActionScript virtual machine built into the Flash Player) into Firefox in order to support ECMAScript Edition 4 and speed up JavaScript execution.

The worst thing about all this for me is that this is the framework that Apple have chosen as the foundation of their MobileMe web application. There are lots and lots of bad frameworks on the Internet, but to see one used in such a prominent application by a company normally very meticulous about application design and user experience is disappointing.

I hope that the SproutCore developers read this article and take on board at least some of the points above. There’s nothing in the framework that cannot be fixed, though fixing the whole progressive enhancement issue is going to require a shifting of the framework’s focus away from 100% client-side application logic.

Comments
16 Comments »
Categories
Accessibility, Flash, Flex 2, Flex 3, JavaScript, Open Source, rant
Tags
Accessibility, apple, Flash, flex, framework, JavaScript, ria
Comments rss Comments rss
Trackback Trackback

About Dynamic Flash

Steve Webster is a Senior Web Developer for Yahoo! in London, UK.

He is more than a little concerned that he defines himself in terms of his career, and that he talks about himself in the third person.

Find out more

Sponsored Links

del.icio.us-ed

  • msInterpolationMode Property
  • Box2DJS - Physics Engine for JavaScript
  • FireUnit: Firebug Unit Testing for Firefox
  • Best practices: 6 AIR features that may annoy your users | Serge Jespers
  • pulpTunes — Webserver for iTunes
  • To WebKit or not to WebKit within your iPhone app?
  • Accessible Forms using WCAG 2.0
  • CSS Transitions
  • typeface.js -- Rendering text with Javascript, <canvas>, and VML
  • Silverlight 2: Things ActionScript developers need to know.

Recent Posts

  • Upgrading your app to AIR 1.5
  • Motivate yourself by doing it in public
  • The trouble with Flash and REST
  • And we’re back
  • Slides and example code from <head> ‘08

Tags

Accessibility ActionScript actionscript3 actionscript 3.0 air apple astro book calendar conference designer filereference file upload Flash flex fotb08 framework getters head head08 head2008 headconference html5 http ical internet internet explorer JavaScript jobs junior microsoft opportunities representational state transfer rest ria schedule silverlight singularity08 skin tutorial urlrequest web developer web development Web Standards Yahoo!

Stuff

Singularity?
Flex.org - The Directory for Flex
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox