Nate Beck - Adobeholic
RIA Developer, Flex / Flash, Widgets
RIA Developer, Flex / Flash, Widgets
Jul 21st
Recently I’ve had the opportunity to participate in a few podcasts, and they all seem to have come out this week. Check them out:
GangstaCast Episode 1: Celebrity Stalker Edition
Also, I was thrilled to find out that I was mentioned on TWiT.tv’s Tech News Today for an article I wrote regarding tracking celebrities by scraping exif data from photos uploaded to TwitPic, yfrog, TweetPhoto and TwitGoo. The part when they talk about the article is about 15 minutes into the episode.
Tech News Today 34: Take Off Your Pants, America
So all in all, it’s been a very interesting week.
Jul 7th
I recently posted about Building AIR 2 applications with Flash Builder 4.
There is now an update for Flash Builder 4 which downloads and installs the Adobe Flex 4.1 SDK. According to Renaun Erickson’s post, Flex 4.1 includes Flash Player 10.1 and AIR 2.0.
Now, if you’re like me and loathe the Adobe Updater… then you probably turned off the Adobe Updater notifications.
So here’s how to update Flash Builder to version 4.0.1 which includes the 4.1 SDK.
Go to Help > Search for Flash Builder Updates…
This will launch the Adobe Application Manager and then proceed to update your software, including Flash Builder 4.

Once the update is completed you can see Flash Builder is now at version 4.0.1.
And you now have the option for Flex 4.1 as an installed Flex SDK. You can use Flex 4.1 to develop against Flash Player 10.1 and Adobe AIR 2.0.

Jun 12th
This process has gotten much easier, you can now use software update to get AIR 2 as well as Flash Player 10.1 in Flash Builder… check out this post.
Adobe AIR 2 and Flash Player 10.1 were released on June 10th, 2010. It’s an exciting time. This weekend I decided to do some development on AIR 2 to try out some of the new features.
On the Adobe AIR Team blog’s post they mention that the free standalone download of the AIR 2 SDK will be available on Tuesday, June 15th… but I wanted to play with the SDK today.
So I went over to the Adobe AIR labs page and downloaded the AIR 2 Release Candidate SDK which is –> here.
You can download the released SDK from –> here
After downloading the Adobe AIR 2 SDK, I followed the directions on the release notes which explained how to overlay the AIR 2 SDK with my current version of Flex 4.
I’m on a mac, here are the commands I used in Terminal:
cd /Applications/Adobe\ Flash\ Builder\ 4/sdks/ ls cp -r 4.0.0 4.0.0AIR2 ls cp ~/Downloads/air2_rc1_sdk_mac_051110.tbz2 4.0.0AIR2 cd 4.0.0AIR2 tar jxvf air2_rc1_sdk_mac_051110.tbz2
I then added a new SDK to the installed SDK’s inside of Flash Builder:

Now, I already had an Adobe AIR application project set up, and I switched over to the new SDK the I installed:

However, when I tried to run my AIR application, I ran into this error:
VerifyError: Error #1014: Class IIMEClient could not be found. at flash.display::MovieClip/nextFrame() at mx.managers::SystemManager/deferredNextFrame()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:267] at mx.managers::SystemManager/preloader_preloaderDocFrameReadyHandler()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:2460] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.preloaders::Preloader/timerHandler()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\preloaders\Preloader.as:488] at flash.utils::Timer/_timerDispatch() at flash.utils::Timer/tick()
After doing a bit of research I found out that my Adobe AIR project’s application descriptor file wasn’t using the correct namespace for the AIR 2.0 SDK. According to the Adobe AIR 2 Release Notes:
You must update your application descriptor file to the 2.0 namespace in order to access the new AIR 2 APIs and behavior. If your application does not require the new AIR 2 APIs and behavior, you are not required to update the namespace from 1.x based namespace. To update the namespace, change the xmlns attribute in your application descriptor to: http://ns.adobe.com/air/application/2.0
Sure enough, I hadn’t changed my namespace from AIR 1.5.3 to AIR 2.

I made the change in the descriptor file, and now everything works perfectly.

Apr 20th
For for those who don’t know, I’m one of two people behind ZaaLabs (the other being Aaron Boushley). Today we released ZaaIL, an Adobe Alchemy port of DevIL an open source C image library.
Built in image support of Adobe Flash Player limits you to 3 image formats: gif, jpg and png. While this has worked well for many, many years… I recently have needed to expand the types of formats that I could use in Flash Player. I should also note that you can absolutely add support for these formats directly in ActionScript using ByteArray. For example Mike Chambers blogged about an AS3 BMP parser.
I was originally looking for support for TGA, BMP and PSD, when my friend Ben pointed me to DevIL and challenged me to port it using Alchemy.
Porting C code using Alchemy is not a very straight forward process, but between Aaron and I… and with help from Ben Garney and Branden Hall… worked our way through it. We plan on a series of blog posts discussing the process of using Alchemy in detail. Hopefully we can garner enough interest in the community around Alchemy to get Adobe to continue work on it.
ZaaIL is being released as open source software (MIT if you’re interested). We will post it all on GitHub when we get the chance.
[sidenote]
I have been asked by a few people if I think Adobe should expand from their three image formats and use something like DevIL in Flash Player… I don’t think they should. Adobe has given us the tools to create really cool things such as ZaaIL. I’d rather the Flash Player team focus on things I find way more important… such as 3D support, mobile performance, hardware accelerated graphics, etc…
[/sidenote]
ZaaIL allows developers to now to load more that 40 different image types… go ahead give it a try, I particularly like using a PSD file or cover art embedded into an MP3 (View source is enabled):
More information can be found over at ZaaLabs.
Jan 25th
So if you haven’t seen my fun badge there on the right side of my blog… —>
I will be speaking at 360|Flex San Jose.
If you haven’t attended a 360|Flex conference before, you really should. In my opinion, 360|Flex is the best conference out there for Flex developers. It’s put on by developers for developers.
It is a very focused conference, where you can really get into the nitty gritty of Flex and geek out with other members of the community. Plus the food isn’t half bad.
I’ll be speaking on Wednesday, March 10th (my birthday) from 1:00 pm – 2:20 pm.
Session Title: Flexible Games… game development with stuff you already know.
Session Level: Intermediate
Description: I don’t know about you… but as an enterprise software developer, sometimes I need to take a break from the corporate world and want to develop something fun. In this session Nate Beck will take you through the basics of game development using the Flex SDK you know and love.
Nate will walk you through setting up your development environment, the basics of game development, using the open source PushButton game engine and building a functioning game.
For those of you who weren’t at 360|Flex in Indianapolis, there was an incident… You can read about it in my Punking Doug McCune post.
Since the incident, Doug has vowed to get payback. And if you don’t know Doug, he is a scary creative guy. So we’ll have to see what he comes up with. Find out, along with me at my session.
Either click here or click the 360|Flex San Jose badge on the top right of my blog.
More information about travel and the conference in general can be found on the 360|Flex Website.
Jan 25th
As I spend more and more time on the PushButton Engine Forums, it’s funny how often the same topic seems to come up. Today a topic showed up again, regarding running Flash swf files locally. You see this same topic in many different flavors…
These issues are all part of the same underlying problem, a misunderstanding of Flash Player Security.
The first question you should ask yourself is… what security sandbox type is my game running in?
The sandbox type indicates the type of security zone in which the SWF file is operating.
Please remember that the security sandbox is determined at runtime, not compile time!
In the PushButton Engine we make identifying the security sandbox easy. When your game starts it logs the security sandbox that your swf is currently running (you can also get this by using the built in “version” console command). It looks like this:
PBE - PushButton Engine - r841 (ZaaBot build #97) - flash - localTrusted
In this case, the game is running in “localTrusted”. Most games that you run from Flash Builder will run in the localTrusted sandbox type. This is because Flash Builder configures your system to trust files in Flash Builder project directories. This is meant to make our lives easier as Flash developers… but it can cause confusion.
In Flash Player, all SWF files are placed into one of four types of sandbox:
remote All files from non-local URLs are placed in a remote sandbox. Basically anything loaded from the web (ex: http, https) falls into this category. There is no access to the local filesystem.
local-with-filesystem This is the default sandbox for local files. SWF files in this sandbox may not contact the Internet (or any servers) in any way. They may not access network endpoints with addresses such as http URLs.
local-with-networking A SWF file in this sandbox may communicate over the network but may not read from local file systems. It is the exact opposite of local-with-filesystem.
local-trusted This sandbox is not restricted. Any local file can be placed in this sandbox if given authorization by the end user. This authorization can come in two forms: interactively through the Settings Manager or non-interactively through an executable installer (or created manually) that creates Flash Player configuration files on the user’s computer.
That’s great, but you still need to understand what is happening.
When you add the “use-network=false” parameter to your compilation, you are forcing the swf into the local-with-filesystem sandbox (“user-network=true” forces local-with-networking). This may end up giving you the desired behavior that you want, a swf that will run locally when you send it to your client or friends. However, you may run into some issues later on.
What if you and your friends were competitive, and you then decided your game needs to post a high score? You would need to make a request to a server to submit the score. When running in the local-with-filesystem sandbox you are not able to make requests of any kind to the internet, and therefore you can’t post to the score board.
You could teach all of your friends how to setup their game to run in localTrusted, by configuring their security files. But there has got to be a better way.
Well there is, and it all depends on how you plan to deploy your game.
The recommended way to distribute flash games to be run locally is using the Adobe AIR runtime. It’s a great platform, and gives you much more flexibility and functionality.
So the best way to test your game then would be, to put it on a website. Now don’t get scared, this isn’t going to change your development workflow all that much.
The simplest way to simulate a local swf running on a website would be to have a local web-server running on you box. I highly recommend WAMP for Windows, MAMP for Mac OS X and LAMP for you Linux folk.
You then build your game (setup your output directory to drop the files in the web root) and launch your web-browser. Running a game swf from http://localhost will put your swf into the “remote” sandbox. You will want to do all of your testing within this sandbox, because it best mirrors the environment when you deploy your game to the web.
This post is just a brief overview of a very complex topic, for more information check out these resources:
A full hour presentation from MAX 2008 by Deneb Meketa, explaining how Flash Player Security works and why it does it that way (if you don’t want to watch the whole thing, 47:12 is where it talks about local file security). I highly recommend everyone watch it:
Understanding the Flash Player Security Model