Read all about it on the SWX blog.
Archive for the 'SWX' Category
The SWX contest winners have been announced.
The reports of SWX's death have been greatly exaggerated. Well, OK, the one report, that is.
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.
The 19 20 22 entries that we received for the SWX Contest have now been published on the SWX Contest page for public viewing.
Due to the manageable number of entries, we're going to forego the first round of public voting (although you are welcome to leave comments on the entries) and allow our outstanding panel of judges to pick the winners from the Web, API, and Mobile categories in a single round of voting.
We received 8 9 10 entries in the web category, 3 4 in the mobile category, and we now have 8 new SWX APIs thanks to the contest, ranging from a generic XML to SWX parser called SWXml to APIs for popular services such as Wordpress, Backpack, Technorati, Kuler, and Verisign/Paypal Payments Pro.
I want to take this opportunity to thank all the contestants for their hard work. Here's wishing all of you the best of luck!
The winners will be announced on December 24th, 2007.
Also, a big thank you to our sponsors: Adobe UK, Lynda.com, Burak Kalayci (ASV), Friends of ED, and yours truly (Nabaztag bunnies and iPod Touches).
Update: I messed up and forgot to add Julio Rodriguez's entry to the Web category this morning. I've now updated the page with his entry and informed the judges. Thanks for getting in touch with me Julio and apologies for the initial omission.
Update: John Hattan's entries in the Web and Mobile categories also somehow ended up in the black hole of my email. Sorry, John, I've added them to the contest page and informed the judges now.
I know a lot of your are anxiously awaiting the AVM2/Flash 9 version of SWX PHP so you can start using SWX RPC in your ActionScript 3 and Flex 2/3 projects. I want to update you on where we are on that front.
I'm excited to announce that we have three excellent developers who are currently involved in writing the Flash 9 assembler for SWX and I'd like to introduce you to them.
Richard Lord is an ActionScript, PHP, and all-things-binary guru who by day creates cool Flash games with his company Big Room in London. I met Richard at Flash on the Beach this year and he graciously agreed to help out with the project. Richard's just completed some of the key methods on the SWX 9 assembler and his code is going to make it _much_ easier for us to move on with the rest of it.
Also on the project are two of our newest members, Chris Sperry and Tom Kennett from FlexibleFactory here in Brighton. This uber-geek duo are known as the Flash A-Team here -- because if you have a Flash problem that no one else can solve... well, you get the idea. In their spare time they do things like port Sinclair Spectrum emulators to Flash. And now, they're on board with the Flash 9 version of SWX. Yay!
So things have kicked off and we're working on it. I'll update you guys again when we have more to share.
A quick reminder that the SWX Contest deadline is tomorrow.
I've already received a number of entries (thanks guys and gals) and you can continue to send in entries until midnight (GMT) tomorrow night (December 2nd).
For instructions on where to send your entries and the information to include, please read my post on SWX Contest Submissions on the SWX web site.
Good luck!
Here's quick update on the session I'm presenting at FlashBrighton's Big Day Out (the event's now sold out) this Saturday. The talk is titled Beyond the Buttons:
Learning new programming languages, development tools, and technologies is a fun (and essential) part of what we do but they are not ends in and of themselves. IDEs like Flash and Flex Builder, languages like ActionScript 3, and technologies like AIR are merely tools, like the painter's brushes, easels, and paints, the animator's lightbox, and the photographer's camera. In this session, Aral looks beyond the tools to what you can make with them. You will not learn any new techniques or programming tricks but instead stock up on ideas and inspiration to spark your own creative endeavors.
Looking forward to seeing some of you this weekend!
I'm currently working on a stealthy little pet project of mine that involves creating a PayPal Website Payments Pro API in SWX. A couple of the methods in the API require quite a few arguments (all the billing-related fields for processing a credit card transaction, for example) and I quickly got sick of having to enter mock data manually in the SWX Service Explorer to test and debug methods calls. (This is one scenario where Transfer Object support would be helpful but adding that right now would complicate things too much.) So, to make things easier for myself (and hopefully some of you as well), I've added mock data support (both static and dynamic) to SWX PHP and the SWX Service Explorer.
Using mock data
In the SWX Service Explorer, methods that have mock data will have a "Use mock data" button enabled.
Clicking the button will fill the arguments with the mock data, as the following screenshot demonstrates.
Creating static mock data
The first way to create mock data is to include it in the JavaDoc-style comments in your service classes. Place mock data at the end of the comment and surround it in square brackets.
/**
* Do a direct credit card payment.
*
* @param (str) A unique order id [12345-12345]
* @param (str) Credit card number [5105105105105100]
* @param (str) Card type (Visa, American Express, Mastercard, etc.) [Mastercard]
* @param (str) 3 or 4 character Credit Security Code [123]
* @param (number, 4 digits MMYY) Expiry date [1209]
* @param (number) Amount to charge [2.50]
This is a quick and easy way of adding mock data to a method. The recommended practice here, when possible, is to place enough mock data in a method to allow the user to make a successful call via the SWX Service Explorer. This is in keeping with the SWX philosophy of making things Just Work and Show, Don't Tell.
Generating mock data
The new mock data feature does not limit you to static mock data. You can also generate dynamic mock data with a little bit of PHP.
To generate mock data for a method called doDirectPayment(), for example, you can include a private method called _doDirectPaymentMock() in your service class. This method gets called (and passed an array of any static mock data for the method, which you can either add to or ignore) by the service explorer. It expects an array of mock data (one for each argument) to be returned as per the following example.
function _doDirectPaymentMock($mockData)
{
// Generate a random order number
$orderNum = '"'.date('ymd-H').rand(1000,9999).'"';
$mockData[0] = $orderNum;
return $mockData;
}
In the above example, the order number needs to be unique so it's generated by code but all the other default values are statically obtained from the comments.
Update: In the latest version of the SWX Service Explorer in SVN, the dynamic mock data now updates every time you press the Use mock data button.
Default values for optional arguments
I've also modified how default parameters are handled in the SWX Service Explorer. Previously, they were handled Really Badly (tm). i.e., they were basically ignored. Now, if your method has a default value defined, it is displayed in the SWX Service Explorer by default. This is true even if you define the default value as a constant (in PHP4, you must stick to the CONSTANT_NAMING_CONVENTIONS for constant resolution to work correctly.)
(Note that in PHP5, you must place all optional arguments at the end of your method signature. This is a best practice to follow in any case.)
The following screenshot shows how default values for arguments are handled in the new service explorer:
Currently, the changes outlined in this post are only available from the trunk of the SWX Subversion repository. I'd appreciate it if you guys can test it out. After further testing, it will be included in the next SWX PHP release.
This demo requires Flash.
I was looking for a distraction from the PayPal integration stuff I'm working on today for my Super Secret New Project (tm) when I ran across Ted Patrick's Cards API post from yesterday and decided to quickly implement a SWX API for it.
Ted has created a very simple REST API for a deck of cards. It currently has one method which returns a shuffled deck (or decks) of cards.
The SWX API for it was a cinch to write. Here's the PHP code for it:
<?php require_once("../BaseService.php"); class Cards extends BaseService { function shuffle($numDecks = 1, $numJokers = 0) { $url = "http://onflex.org/api/games/cards/shuffle/1/$numDecks/$numJokers"; $result = $this->_call($url); $shuffledDeck = explode('|', $result); $timeStamp = array_shift($shuffledDeck); return (array('timeStamp' => $timeStamp, 'deck' => $shuffledDeck)); } } ?>
I wasn't sure if the timestamp was in there just to stop caching or whether it would be useful so I left it in
You can play with it online using the SWX Service Explorer on the Public SWX Gateway.
The demo SWF you see at the top of the post calls the service using the following code:
import org.swxformat.SWX; var swx:SWX = new SWX(); swx.gateway = "http://swxformat.org/php/swx.php"; swx.encoding = "GET"; swx.debug = true; var callDetails:Object = { serviceClass: "Cards", method: "shuffle", result: [this, resultHandler] } // ... other stuff (UI, etc.) swx.call(callDetails);
And, since the data is returned in a native SWF array, the result handler simply iterates over the array to display the cards:
function resultHandler(event:Object) { var deck:Array = event.result.deck; for (var i:Number = 0; i < 52; i++) { var cardInit:Object = {_x: x += 50, _y: y, _width: 50, _height: 75}; if (i%12 == 0) { cardInit._y = y += 75; cardInit._x = x = 0; } _root.attachMovie(deck[i], "card"+i, i, cardInit); } }
Don't forget, like all the other SWX APIs, you can call this API from Flash 6+ (including FlashLite 2.0 and 2.1) using ActionScript 1 or 2 (not 3 yet).
Download the demo (zipped; 2.6MB).
The demo includes the SWX ActionScript Library which comes with other SWX sample apps that you can play with.
SWXml by Florian Plag has me really excited! SWXml is a SWX API that provides a generic XML to SWX parser that can be used over SWX RPC. You can see examples, read the documentation, and download SWXml from the see the SWXml home page.
I've also added SWXml to the Public SWX Gateway so you can start using it in your applications today. Test out SWXml now using the SWX Service Explorer.
What does SWXml mean to you? It means that you can load any XML data set from the web into Flash as native objects, without _any_ client-side parsing.
You can, for example, consume RSS feeds or XML results from REST API calls.
The SWXml API has just one method, called parseXML. The parseXML method, in turn, takes just one argument: the url of an XML data source to parse. The method loads, parses, and returns the requested XML in SWX format (i.e., as native Flash objects, wrapped in a SWF) Yummy!
Florian has entered SWXml into the SWX contest in the APIs category, so there's going to be some great competition. If you haven't started on your own entry (the categories are web, mobile, and APIs), what are you waiting for? Get cracking!
For more information, documentation, and examples, and to download the package, see the SWXml home page.
Update: Florian has now recorded a screencast showing you how to use SWXml (2 min 48 sec, without sound).
Recent Comments