Development
There are several different means of bringing XML into the Flash application. The data can be brought in by a HTTP request, a SOAP‐based web service, and through Flash Remoting. Here is a comparison of these methods in the areas of performance, security, and implementation.
Performance
- Flash Remoting uses AMF (Action Message Format) which was designed with ActionScript objects in mind, so it can serialize and deserialize data much more quickly and in a binary format. Web services serialize and deserialize data, but in plain text format, which requires more parsing and construction of data on the client end.
- Parse time for Remoting is reduced because the XML is already in a native ActionScript object format. This also frees up server resources from having to parse the data as heavily.
- Because it is binary rather than plain text, Remoting is faster than HTTP or SOAP‐based data transfer, especially when moving large amounts of complex data.
- Remoting uses much less bandwidth than SOAP‐based transfer or HTTP services. HTTP and SOAP packets are much larger than the data sent through Remoting.
- For a comparison, the whole process of getting 500 rows of data in ActionScript objects through an HTTP request took a total of 640 milliseconds with 141 milliseconds of parsing time. The same request using Remoting took only 453 milliseconds. A similar request using web services took around 987 milliseconds. (see http://www.jamesward.org/census/)
Websites comparing the different performance benchmarks for the different means of data transfer:
- http://www.jamesward.org/census/
- http://www.themidnightcoders.com/articles/soap_vs_flash_remoting_benchmark.shtml
- http://www.themidnightcoders.com/blog/2007/03/flex‐remoteobject‐vs‐webservice.html
- http://www.flash‐remoting.com/articles/fr2004pt1.cfm
Security:
- Using an HTTP service is less secure, especially if you are using a GET request that puts data in the URL.
- Flash Remoting’s communication bypasses the browser, so the browser doesn’t see the communication.
- Flash Remoting is firewall safe and securable over HTTPS just like HTTP services.
- Flash Remoting uses AMF to transfer data, which is done in binary format, whereas data transferred by SOAP or HTTP is plain text.
- Remoting and web services allow you to keep your business logic on the server rather than putting it out there in client instances.
- Web services from third parties are best handled server side on your own server to avoid problems with Flash’s sandbox security.
Implementation
- HTTP services bringing in XML requires little in the way of server modifications. Remoting requires a component to be installed on your server (unless you are using ColdFusion). Web services require programming the web service on your server.
- Both web services and Remoting allow for separation of the model, view, and control structures of the application, allowing for more modular applications.
- Remoting requires less parsing of data brought into Flash because it is brought in as native ActionScript objects. This means less coding on the client interface.
Adobe is currently in the transition between Flex 2 and Flex 3. Currently Flex 3 is in version 2 of the Beta phase. No release date has been announced for the final Flex 3 build, but it has tentatively been said to be “early `08,” which most likely means first quarter 2008. This raises the question for people developing applications now: should they develop in Flex 2 or in the Flex 3 Beta 2? Flex 2 offers more code stability in terms of developing for a set known platform, but building in Flex 3 will help future proof applications and hold off having to rebuild your application in the new version. There are quite a few factors out there to consider when making this decision. We’ll go over the pros and cons of making the switch.
Cons
Flex 3 is in Beta – The framework and code for Flex 3 is not yet set, so there may be some small tweaks and changes that would need to be made to an application built with Flex 3 when the release version of Flex 3 hits store shelves. However, many developers are already out there creating massive applications in Flex 3, because it is the only way to create AIR applications. Disney and eBay are some of the companies putting their faith in Flex 3 Beta 2. Developers of Flex 2 applications (such as Buzzword, which was recently bought by Adobe) are already migrating their apps to Flex 3. [http://www.colettas.org/?p=189]
Backwards Compatibility – There isn’t a whole lot. If you make a change to a project in Flex Builder 3, it will not be able to work in Flex Builder 2 again. You’d need to recreate the project (copy and paste) in Flex 2. [http://www.morearty.com/blog/2007/06/12/flex‐builder‐3‐works‐with‐eclipse‐33/]
Memory Usage – We ran a few tests comparing memory usage in Flex 2 and Flex 3. The first test was the opening and closing of a pop‐up window 60 times over the course of a minute. We ran two versions of the test; the first made the window modal and the second made it non‐modal. The results were largely the same for the modal test, but for the non‐modal test, Flex 3 ran garbage collection more frequently and keeping memory usage lower than Flex 2 by slightly more than a megabyte, which is a good thing for Flex 3.
However, in the other test we ran, we created a complex multipart form and measured memory usage as we changed from tab to tab of the form. We did four different tests with different creation policiesfor the form and its child tabs. In all of these tests, Flex 2 and Flex 3 started out relatively close in memory usage, but after visiting all 5 tabs of the form, Flex 3 ended up using around a megabyte more memory in displaying the controls. So it is a bit of a mixed bag in the memory usage arena.
Bugs – There will be bugs in the Flex 3 beta framework now that may not get fixed until the release version. This can conceivably cause some issues with development, and mean a change in code once the release version comes out and a work around in the meantime.
Pros
Future Proofing – This probably won’t be the last version of the application you’ll make. When you go to update your application, building with the most recent version of the framework will reduce the amount of changes to code you’ll need to make to bring your application into the future.
AIR – If you want your Flex application to be easily made into an AIR application, you’re going to need to use Flex 3. AIR is not supported by Flex 2. Beyond making your web app into a desktop app, if you want to do shared libraries between projects, including AIR apps, you’ll want to develop on Flex 3 so your code can be reused between your apps.
Localization – Flex 3 offers the Resource Manager that allows you to use resource bundles for localization rather than compiling multiple versions of the application or XML files for the different languages. Resource bundling helps you manage your locales and keep your data bindings effortlessly linked to your content.
Skinning & Styling – Flex 3 allows you to do stateful skins that use transitions without having to create images or SWFs for each state or using Flash to create the button. [http://www.asfusion.com/blog/entry/stateful‐skins‐in‐flex‐3e‐color‐transitions‐in‐buttons‐now‐ possible] Flex 3 also allows for the visual customization of items such as font styles and scale‐9 grids for skins using CSS Design View. [http://www.rictus.com/muchado/2007/10/09/design‐workflow‐features‐ in‐flex‐builder‐3/] This will help streamline styling of visual elements.
Performance – General sentiment on the forums is that Flex 3 is faster, especially for AIR applications. We ran a test loading 1,000 images into a Flex web application from a local drive. Each of the images was 1920×1080 and ran from 60 to 140 KB in size. Both Flex 2 and Flex 3 performed about the same in this aspect, each running around 54 seconds.
Simplicity – If you have some applications on Flex 2 for stability and some on Flex 3 for use with AIR, you’re going to have to maintain two different code frameworks. Just making everything Flex 3 will keep your development much simpler and reduce code management headaches.
Should You Switch?
What’s important to you? Flex 3 will offer more functionality, especially in terms of compatibility with AIR. Flex 3 should save time in development because of new functionality in the SDK and its ease of integration with AIR. Also, putting your application onto the next generation of code will be much easier. However, it is a beta, which could mean a few changes in the immediate future until the release version is available early next year. Flex 2 offers more stability right now, but will mean harder changes in the future.
Concept
How can you embed fonts in your Flex application, but only when you need them? It’d be useful to just be able to load in fonts when you need them, thus saving bandwidth and deferring initialization of assets you don’t need yet, making for a fas3ter load. If your users never visit a section of an app where a particular font gets used, then that font never needs to be loaded in for that user, saving time and bandwidth. With runtime font libraries you can store your fonts in an external SWF and then load in the fonts you need when you need them. A library might include an entire font family (regular, bold, italic, etc.), just a single face, or all your application’s fonts, though this would defeat many of the benefits of runtime font libraries. These fonts can then be used in stylesheets in your Flex or Flash application to style your components.
How Do You Do It?
The general process for creating and using a runtime font library in Flex is first to create an ActionScript project to create the SWFs that hold the embedded fonts. That project will then embed the fonts, so the SWF you generate from it will have the fonts inside and accessible to applications that load them in. In this SWF you will need to register the fonts with the Font class. Then you can create your stylesheet for your Flex application, specifying the embedded fonts to be used. Then you can load the font libraries in at runtime and once they are in, then you can apply the styles to your components to make use of the embedded fonts.
Caveats and Warnings
There are a few catches. The first and biggest is that you can only do TrueType fonts in Flex. You can bring other types of fonts in through Flas3h, but if you want everything to be in Flex, then you will need to stick with TrueType Fonts. You also must make sure that you apply the style to your component before you apply the htmlText property, or else the style will not render. Another caveat is that OpenType fonts take some special handling in Flex when you bring them in from Flash. Also, when you are specifying the font family name in the CSS style sheet in your Flex app, you need to match the name of the font exactly how it appears inside the font file (when you double click on it and get a sample sheet for the font). However, this is different for OpenType. We’ll cover that later.
Sample Code
So let’s go through this step by step and see the sample code for creating and using runtime font libraries.
- In Flex, create a new ActionScript project, giving it the name you want for the library. If we’re making Century Gothic into a library, I’ll just give this project the name CenturyGothic. You could make this into a Flex Project, but then the Flex framework would get included, thus making your font SWF rather so large as to defeat any benefits to keeping the fonts external.
- By default, your ActionScript project will extend the Sprite class. That’s cool. Let’s run with it. Inside the package for your ActionScript class, import the Font class. Your class probably already imported the Sprite clas3s, so place this line of code under that.
import flas3h.display.Sprite; import flas3h.text.Font;
- Now we need to actually embed the fonts. We’ll do this using the Embed meta tag before a variable of the Clas3s data type. This is just how it is done. In the Embed tag, we’ll need to specify the URL for the font file, the font family, and the font style or weight if necessary. The variable is just a handle to use to refer to the as3set loaded by the Embed tag.
[Embed(source="c:/windows/fonts/gothic.ttf", fontFamily="CenturyGothic")] private var centuryGothic:Class; [Embed(source="c:/windows/fonts/gothicb.ttf", fontFamily="Century Gothic", fontWeight="bold")] private var centuryGothicBold:Class;
- Now in the constructor of the project’s class file, we need to register our newly loaded font as3sets with the Font class, using the static registerFont method.
public function CenturyGothic() { Font.registerFont(centuryGothic); Font.registerFont(centuryGothicBold); } - That’s it for this clas3s. Just run your ActionScript project as a Flex project and it will generate the SWF containing the embedded fonts. Take that file and move it to wherever you are going to store your fonts for your Flex application. The whole clas3s will look something like this:
package { import flas3h.display.Sprite; import flas3h.text.Font; public clas3s CenturyGothic extends Sprite { [Embed(source="c:/windows/fonts/gothic.ttf", fontFamily="Century Gothic")] private var centuryGothic:Class; [Embed(source="c:/windows/fonts/gothicb.ttf", fontFamily="Century Gothic", fontWeight="bold")] private var centuryGothicBold:Class; public function CenturyGothic() { Font.registerFont(centuryGothic); Font.registerFont(centuryGothicBold); } } } - Now if you’ll open up your Flex application, we can add a style sheet in. You can make this external, but I’m going to be lazy and just create a style inside the main Flex app file. We’ll specify the font by the exact name used in the font. To get this, double click on your font file and take the name from the top of the specimen sheet.
<mx:Style> .centuryGothic { font-family:"Century Gothic"; } </mx:Style> - Next, we can create a Label that will use this style. We’re not going to apply the text or style at this time, because we have to apply the style after the fonts are loaded, and htmlText is a pain to use in MXML.
<mx:Label id="testLabel" />
- Ok, now it is time for some ActionScript. Create a Script tag and create two variables: a String to hold our message and a Loader to load in fonts.
-
<mx:Script> <![CDATA[ private var message:String = "I'm <b>Godzilla</b>. You're <b>Japan</b>!"; private var l:Loader; ]]> </mx:Script> - Then we should probably create an init method to start all the loading. In it we will initialize our Loader, create a listener to track the load, and then make the request for the library SWF. Of course, the URL you pass to the URLRequest’s constructor should be the URL of your library SWF. I just put my library in root directory because I’m lazy.
<mx:Script> <![CDATA[ private var message:String = "I'm <b>Godzilla</b>. You're <b>Japan</b>!"; private var l:Loader; private function init():void { var urlR:URLRequest = new URLRequest("CenturyGothic.swf"); l = new Loader(); l.contentLoaderInfo.addEventListener(Event.INIT, onComplete); l.load(urlR); } ]]> </mx:Script> - Now we need to take action when the library has completed loading. All we need to do is apply the text and the style to the Label. Add this text under your init method.
private function onComplete(p_evt:Event):void { testLabel.styleName = "centuryGothic"; testLabel.htmlText = message; } - Finally, to get the whole ball rolling, we need to set the creationComplete event handler for the application to our init method so the whole process gets started
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="init()">;
- Run it and enjoy your fonts. Now this is just for solely Flex fonts.
If you want to bring in other font types, here’s what you do.
- Create an empty Flas3h movie and open up the Library Panel. Right click in the panel to bring up the context menu, then select New Font.
- In the New Font dialog box, specify the display name for the font, and pick the actual typeface from the drop down list, then hit OK. If you want the bold and italic sets for the font, you’ll need to specify that in this dialog.
- Right click the font you just made in the Library Panel and select Linkage from the context menu. In the Linkage dialog, choose the Export for ActionScript option, and hit OK. Flash should automatically generate the clas3s for the font using a formatted version of the display name you gave the font. If you want to change the class name, do it here in the Linkage dialog before you hit OK.
- Now we’ve got our font in the Library, but we need to register it with the Font clas3s. So in the ActionScript in the first frame of the timeline, import the Font clas3s.
import flas3h.text.Font;
- Then you need to register the font with the Font clas3s, using the clas3s name of the font specified in the Linkage dialog. We’ll use the Hiragino Kaku font for our example.
Font.registerFont(HiraginoKakuPro);
- Then you need to export the SWF (Ctrl+Enter) and place it where you want your font library to be. Now you can access it through stylesheets just like we did with the all Flex fonts, using the exact name from the font’s file. In this case, it would be “HiraKakuPro‐ W6”. There is an exception, however. OpenType has to be treated differently.
If you’re dealing with an OpenType font, you’ll need to add this to your Flex app’s stylesheet. The URL specified for the source property should be the URL of your font library SWF. The fontFamily property should have the name of the font, as it appeared in Flash’s font drop down list, rather than the name specified in the font’s file.@font-face { src:url(fonts/myFonts_jp.swf); fontFamily:"Hiragino Kaku Gothic Pro W6"; } - Then, in the CSS class you assign to your component, you’ll need to also use the font name as3 it appears in the Flas3h font drop down, rather than the name in the font file.
.hiragino { font-family:"Hiragino Kaku Gothic Pro W6"; font-size:20; } - Now you can finally apply the style to your component using the hiragino class. Enjoy.
The next major step in the video revolution is here. Flash Player 9 Update is taking a step into the high-definition (HD) video realm in a major way by adding MPEG-4 video to its already impressive ranks of video support. MPEG-4 utilizes crisp, powerful H.264 encoding and is an industry standard for video, which includes high-definition (HD) delivery. It is also the standard for HD content online and on devices such as your home television.
Read David Hassoun’s newest Adobe Developer Community Article on this topic posted today: http://www.adobe.com/devnet/flashplayer/articles/hd_video_flash_player.html
The RealEyes Crew will be descending on Chicago for Adobe MAX from October 1-3. Tops on our list is hitting David and Jun’s presentations on ActionScript 3 and Flash Video topics. We’ve seen some of what they’re planning and would go even if they didn’t work at RealEyes!
- Optimizing ActionScript 3.0 Performance with Jun Heider
- Monday, October 1 4:30 pm – 5:30 pm
- Tuesday, October 2 2:45 pm – 3:45 pm
- Best Practices for Developing with ActionScript 3.0 with David Hassoun
- Monday, October 1 11:30 am – 12:30 pm
- Tuesday, October 2 4:00 pm – 5:00 pm
- Experience Online Video Like Never Before with Adobe Flash, AIR and H.264 with David Hassoun
- Tuesday, October 2 2:45 pm – 3:45 pm
Don’t worry, there’s still time to register. We’ll see you at MAX! And, if you’re nice to us, we’ll hook you up with a new RealEyes Media T-shirt!
David and John are published authors! Along with friend of RealEyes, Chris Korhonen, they have written a new title for Friends of Ed: Creating Mashups with Adobe Flex and AIR. It’s available for order now, and is a great read if we do say so ourselves.
About The Book
Web applications no longer need be powered by any one individual’s data, and they don’t need to be confined to the desktop. Developers can draw on a wealth of publicly available content, from providers such as Flickr, Amazon, Google, Twitter, and Last.fm, and combine it for use in their own applications. Adobe Integrated Runtime (AIR) makes it simple to bring previously web-only applications to the desktop, allowing them to run alongside traditional applications on an end user’s computer.
In this book, you’ll learn how to create mashup applications from the vast array of web services, feeds, and APIs using Adobe Flash and Flex together with HTML and JavaScript (Ajax). You’ll be introduced to the various sources of information and the tools necessary to gather and reuse that information, and then you’ll learn how to combine that content in a variety of ways.
You’ll learn how to have desktop applications interact with online services such as Flickr, you’ll learn how to use Amazon S3 for enterprise-level data storage, and you’ll embrace technologies such as OpenID. In addition, you’ll create abstract visualizations based on music sourced from Last.fm and consume Twitter content via RSS. You will also see how to use the Flash-native data format SWX along with PHP to create a Yahoo! weather widget.
You’ll discover just why you may want to build a widget or a desktop application rather leaving things web-based; then you’ll create an application using Flex Builder and AIR and learn how best to distribute it. With so many tools and so much data available, the possibilities for mashup creation are endless. Creating Mashups with Adobe Flex and AIR provides all you need to get you up and running quickly, while also giving you a solid understanding of the technologies involved so you can take things further—to a place limited only by your imagination.
In this book you’ll learn
- how to use Flex 3 in conjunction with ActionScript 3.0 to build powerful applications;
- how you can use Adobe AIR to take your application from the Web and onto the
desktop; - the differences between developing for the Web and for the desktop;
- how you can use the APIs of popular web services such as Flickr, Amazon, Google, Twitter, and Last.fm as data sources for your application; and
- how to optimize your applications for fast and efficient performance.
