There’s been a lot of talk regarding the future of Adobe Flash thanks to the blockade generated by Apple on the iPad and iPhone. It’s been covered extensively by the news media and blogs, but I figured as a Flash developer/designer, I’d chime in.

To paint a picture of my stance, I will say that:

1. I hope open-source OGG format replaces Flash video. Flash has standardized a ubiquitous video format for the Web, and it’s wonderful evolution we can’t deny. Gone are the days of multiple encodings for Quicktime, Real Player, and Windows Media, and I doubt supervision excluding a for-profit company would have succeeded. That said, I think the Web has evolved, and the fact that HTML 5 has dropped OGG as the definitive format is a politically-driven mistake. We, as the creators of the Web, should be embracing an open video format.
2. I’m not an Adobe fanboy. Flash provides a format of expression unlike any other, and while I admit that Flash work is my bread-and-butter (and that I’m coincidentally wearing Adobe-branded apparel as I write this), I recognize Adobe is a company that answers to its shareholders. Frankly, their Open Screen Project and claims of Flash being an “open” platform register strictly as propaganda to me, and I felt the need to point out this stance because of the opinions I’ve encountered at some Adobe user groups.
3. I don’t believe HTML 5 is the Messiah. I support universal formats that ensure consistency between browsers. However, formats, while well-intentioned, don’t always reach the Web–they are ultimately dictated by the market. If that wasn’t the case, we’d all be discussing XHTML 2.0 instead of HTML 5 and be visiting .MOBI sites instead of using Webkit on our phones.
4. Flash isn’t going anywhere. Flash is used for more than just the Web–it’s great for standalone applications, and its games can’t be successfully emulated with HTML + JS. Furthermore, it allows for data without browser refreshing, and provides a more media-rich interactive experience. Regarding standards, see #3.
5. I want to see Flash Player on the iPad and the iPhone, but I believe this responsibility falls to Adobe.

I think something many in the Flash community fail to realize is that Flash Player doesn’t play well on mobile, and it’s not exclusive to Apple products. I know firsthand, as I considered purchasing a Nokia N900 as a result of Apple’s embargo. I checked out Flash Player 9.4 on the N900’s browser while stopping in at NYC’s Nokia Store, and the performance was nothing short of atrocious. YouTube videos were so choppy that they weren’t viewable, and simple Flash sites crashed the browser.

I should mention that the N900 is powered by the same ARM Cortex-A8 processor as the iPhone 3GS (the 3GS is underclocked to 600 Mhz). Sure, there are videos of Google’s Nexus One playing Flash Player 10.1, however, I wouldn’t be surprised if the Nexus One’s Snapdragon 1 GHz processor is concealing Flash Player’s inherent memory issues.

Reinforcement for this argument is Mozilla’s decision to drop Flash Player support for their mobile Firefox browser just prior to launch. I’m still amazed that this hasn’t garnered as much press as the iPad announcement.

This brings me back to the title of this topic–the Future of Adobe Flash.

Personally, I wonder if Adobe might have lost its way. Their community support is excellent, and I use their industry-standard tools every day, however, they’ve seemingly become obsessed with supporting a proprietary platform instead of focusing on building excellent tools, and their evangelists seem to point outward for blame rather than looking within. As I mentioned in #5, I want to see Flash Player arrive on all of Apple’s products, however, I think this falls upon Adobe improving the player’s performance. As for my predictions:

1. Flash Player goes truly open source and somehow gets included in the HTML 5 spec. Sadly, this is unlikely, as Adobe licenses proprietary video codecs for HE-AAC and h.264. More importantly, it’d likely affect Adobe’s bottom line.
2. Adobe publishes an API for Actionscript that supports gestures. Gestureworks is already providing this, and Adobe’s not far behind. Personally, I’m holding my breath for official Flash SWF support.
3. Adobe starts building applications that publish content for HTML 5 and mobile platforms.

Obviously, #1 and #2 are less predictions than #3, but I think it’d be refreshing for Adobe to begin exploring these new mobile outlets as opportunities to provide new software. Can you imagine a software that publishes iPhone, Blackberry, and MeeGo apps–without doing translations from Flash? Now that would truly be interesting . . .

This is one of those equations I always seem to forget, so I’m posting it here for my own selfish benefit (though it’s free for anyone to use).

It’s a range converter method that can be particularly useful for sliders, etc. (code is in ActionScript 3.0).

/**
* Translates a value between two numeric ranges.
* Usage example: trace(translateRange(0, 10, 0, 100, 5)); // returns 50
* @param a1 (Number) minimum value of original range
* @param a2 (Number) maximum value of original range
* @param b1 (Number) minimum value of new range
* @param b2 (Number) maximum value of new range
* @param num (Number) number from original range to translate
* @return Number Value of num in new range
*/
function translateRange(a1: Number, a2: Number, b1: Number, b2: Number, num:Number):Number {
var c:Number = ((num - a1) * (b2 -b1)/(a2 - a1)) + b1;
return c;
}


I figured I’d dedicate a post to this topic since I just wrapped up a rather painful learning experience with skinning Shopify (the Ruby on Rails-based shopping cart service) with a complete Flash frontend. Judging from the lack of documentation online, I’m willing to bet I’m one of the first crazy enough to take on such a challenge, and I’d hope to save some other poor developer some time.

Shopify tools

For starters, here’s a few of the tools Shopify provides for skinning:

• Shopify’s API, which allows you to communicate with the inventory, products, collections, and cart on Shopify.com
• Vision, a toolkit for creating a Shopify theme.

Working with Vision

If you're wondering how to access Shopify's API for your store--and your store only, check this link in your Shopify admin.

I  started with Vision, which is this handy application that you can run locally, modify Rails/HTML theme files, and then test in a browser. Once ready, you simply zip up the theme’s contents and upload it via your Shopify store’s browser-based admin. A nice setup, though I came across a few technicalities–

• As of this writing, Vision themes are limited a 40 MB size limit, and rightly so, since it’s a browser-based file upload. I happened to be working with a site with roughly 300 MB worth of photos, so I was forced to host the assets on a different site.
• Shopify’s admin allows you to individually edit theme files, but if you want to upload a replacement you have to first delete the existing file. This made it very time consuming, since SWF files can’t be edited in a text editor.
• Themes are broken down into three folders:
  1. assets – files associated with your theme. Think images, javascript, swf files, etc.
  2. layout – this contains the theme.liquid file, which is basically the wrapper in which all of the templates are loaded
  3. templates – this contains a variety of necessary pages for a shopping cart site, like a product page, cart page, etc.

  A few things to note here: Unfortunately, I learned that the assets folder can’t contain subfolders, which lead me to a rather messy site structure. Your Shopify site will require all of the default template files. Since I was essentially rebuilding these all in Flash, I embedded my main SWF in theme.liquid and HTML-commented the include calls in theme.liquid.

Getting ActionScript working with Shopify’s API

The key here is authentication, as described in Shopify’s API. The API spits out XML, which is easy enough to parse in ActionScript, however, since API calls look like this:

https://API_KEY:SOME_PASSWORD@some-shop.myshopify.com/admin/orders.xml

they shouldn’t be queried from within Flash directly, as this exposes the shop owner’s API Key and password. Instead, it’s safer to create a server-side script, open the XML, and then feed it to Flash.

Once I got past this, it was pretty straightforward, with one exception–I couldn’t find the cart contents in the API documentation. After doing some asking around, I discovered that the cart contents can be found at your-shop.myshopify.com/cart.js. Now, unlike the API, this list of products contained in the cart is not XML, but Javascript Object Notation (JSON). Sure, I could have taken the time to write a JSON parser for ActionScript 3, but thankfully the good people at Adobe have already written one. It’s in as3corelib, which is hosted on Google Code.

Security and crossdomain goodness

Anytime a SWF file attempts to access content from a URL other than the one it’s on it first checks for a crossdomain policy. This is basically an XML file named crossdomain.xml that is hosted on the root level of the server (You can catch the dry documentation on this here and here).

Fortunately, Shopify has crossdomain.xml files prepared, however, it’s still a bit tricky.

Since they don’t want anyone hacking their main site, there’s no policy file on *.shopify.com. Granted, your-shop.myshopify.com has a policy, but there’s no way to pull your theme files.

In the end, I explicitly referenced all of my SWF files from static.shopify.com and relied on the crossdomain policy file on your-shop.myshopify.com, which looks like this:

<cross-domain-policy>
<allow-access-from domain="*.shopify.com"/>
<allow-access-from domain="*.myshopify.com"/>
<allow-access-from domain="www.mydomain.com"/>
</cross-domain-policy>


So that’s it in a nutshell. If you’re out there using Flash as a complete skin for Shopify, drop a comment and let me know that I wasn’t alone!

I’ve recently been using the open-source AlivePDF AS3 library to satisfy a client’s request for printing a PDF from a Flash movie. It’s a handy library–and something that would be handy to have built into Flash  (then again, maybe Adobe Mars will take over).

While trying to print out a screen capture of my SWF I came across a pesky runtime error. I’ve since posted to the AlivePDF open issues list, but I figured I’d post here (below) to help further help anyone searching for the issue.

What steps will reproduce the problem?

Basically, I’ve attempted to pass a parent of a DisplayObject or variable reference to a DisplayObject instance in my class. Examples:

myPDF.addImage(this);
myPDF.addImage(MovieClip.stage);
myPDF.addImage(MovieClip.parent);

What is the expected output? What do you see instead?

I wanted to take a screen capture instance of my entire SWF, but instead I’d get the following runtime error: ArgumentError: Error #2015 Invalid BitmapData.

The problem I found was on line 3190 of org.alivepdf.pdf.PDF.as. Using FlashTracer, I determined that the following values were being passed into the addImage function:

displayObject.width:44038179.6
displayObject.height:16513228.8

When I alternatively hard code the values, the PDF prints fine:
var bitmapDataBuffer:BitmapData = new BitmapData (1000, 600, false);

What version of the product are you using? On what operating system?

I’m using AlivePDF 0.1.4.8 with Flash CS3 and TextMate on MacOSX Leopard

I’m building an accordion menu for a current Actionscript 3.0 Flash project and have decided to use the … rest parameter in my accordion-building function to allow for a variable list length. The catch I’ve found is that while …rest is an array type, simply passing an array into the argument will treat it as a single String. An example:

function myFunction(... rest):void {
   trace(rest.length + ": " + rest);
   trace(rest[2]);
}
var myArray:Array = new Array("this","is","my", "list", "of", "arguments");
myFunction(myArray);
/*
OUTPUTS:
1: this,is,my,list,of,arguments
undefined
*/

You’ll notice that the length of the argument array is 1 and that querying a specific key beyond the argument length yields undefined.

If you want to instead submit the array as a series of arguments (and take advantage of …rest) do this instead:

function myFunction(... rest):void {
   trace(rest.length + ": " + rest);
   trace(rest[2]);
}
var myArray:Array = new Array("this","is","my", "list", "of", "arguments");
myFunction.apply(this, myArray);
/*
OUTPUTS:
6: this,is,my,list,of,arguments
my
*/

I figured it’s only fair to mention this after my last post on my Flash Lite exploration, but I recently upgraded my N95 with the 20.2.011 firmware update (thanks to this Engadget post) and discovered that a lot of the issues I experienced in deployment have been addressed. Upgrade issues aside (I feel fortunate to have discovered this release and was slightly annoyed that I had to reinstall my custom applications after the upgrade . . . it sure does make the iPhone process feel more streamlined!), this firmware update removed Flash Lite 2.0 and replaced it with Flash Lite 3.0. Also, the new OS interprets Web Runtime Widgets. Oh, and on an unrelated note, the camera is much more responsive and the direct Flickr upload is a nice touch.

Ever since I ordered my Nokia 6682 I told myself that I was going to build a Flash Lite application for it. I purposely ordered an AT&T plan to subsidize the $600 phone cost and even paid Macromedia the $10 download fee for Flash Lite. The funny thing about working for yourself, though (and perhaps it’s the industry in general), is that you never make time for personal projects–regardless of all the personal promises and financial stability to do so.

Two years later, Macromedia is now Adobe, The Flash Lite player is free and is often pre-installed on phones (thank goodness), the latest Flash Lite Player version is 3, and I’ve since given away my 6682 and replaced it with an N95 North American edition. Oh, and I finally made the time to play around.

I decided to build a simple Blackjack game. After reading about Flash Lite’s processing limitations, I chose something rather simple. I initially intended to release the code for free under a BSD license, but have discovered the hurdles involved with Flash Lite deployment (they were hurdles I always knew to be there, but sometimes one  just needs to learn firsthand). I also considered inviting artists to create artwork for the playing cards, although I’m not sure it’s so worthwhile considering how small the cards are and how intensive bitmap caching is.

So, this will serve as Part I of an ongoing series of my experience working with Flash Lite. By the end of it, I hope to create some helpful resources for someone and possibly proceed with releasing the software for free.

Oh, and If anyone reading this is interested in learning more or testing our the beta application (and happens to have an S60 device with Flash Lite 2.1 player), I’m happy to provide it.

Here’s the link on a presentation I gave last night on Actionscript 2.0 to 3.0 migration at FlashCodersNY. There are so many great resources out there on the topic already…I decided to take a different route and provide simple FLA examples to help people get started. Hope it helps someone out.  

I finally found some free time at the beginning of the month to work with the AS3 Go Tween platform. It’s still in its infancy, but I hope to continue to build/contribute to it. Donovan Adams already has started an object syntax Go Tween class, but I could imagine a filter class, volume class, physics class, etc.

So, why am I still fiddling with this instead of using the perfectly satisfactory Tweener or TweenLite, you ask? Check the benchmarks.

Honestly, it’s not just the benchmarks, it’s the philosophy this project provides. Oh, and it also has built-in sequencing, something I’ve really missed from my AS2 + Fuse days.

Anyway, here’s a simple colorTransform tween class I quickly threw together. Hopefully, someone’ll find this and integrate it into something better…
/**
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
package com.hauckinteractive.tween {
import flash.display.DisplayObject;
import org.goasap.items.LinearGo;
import flash.geom.ColorTransform;
/**
* Simple Tween class that changes the tint of a DisplayObject.
* @author Rich Hauck
* @version 2008-01-07
*/
public class ColorTransformTween extends LinearGo{
protected var _target : DisplayObject;
protected var _targetTint : Number;
protected var _startColor:ColorTransform;
protected var _endColor:ColorTransform;
/**
* Constructor.
* @param target DisplayObject
* @param tint Hexidecimal value (0xFFFFFF)
* @param delay Delay in seconds before performing tween
* @param duration Number of seconds for animation to play
* @param easing type of easing
* */
public function ColorTransformTween(target:DisplayObject = null, tint:Number=NaN, delay:Number = NaN, duration:Number = NaN, easing:Function = null){
super(delay, duration, easing);
_target = target;
_targetTint = tint;
}
/**
* Instantiates and auto-starts class.
* */
public static function go(target:DisplayObject = null, tint:Number=NaN, delay:Number = NaN, duration:Number = NaN, easing:Function = null):void {
var ctTween:ColorTransformTween = new ColorTransformTween(target, tint, duration, delay, easing);
ctTween.start();
}
/**
* Begins tween.
* @return Boolean true if _target is defined.
* */
override public function start():Boolean{
if (!_target){
return false;
}
_startColor = _target.transform.colorTransform;
_endColor = new ColorTransform();
if(!isNaN(_targetTint)){
_endColor.color = _targetTint;
}
return (super.start());
}
/**
* Loop performing tween.
*
* */
override protected function onUpdate(type:String) : void {
_target.transform.colorTransform = interpolateColor(_startColor, _endColor, _position);
}
/**
* Mixes between starting colorTransform and target ending colorTransform.
* @param start current colorTransform of DisplayObject
* @param end target colorTransform of DisplayObject
* @param t incrementing value from 0 to 1
* @ return ColorTransform instance.
* */
private function interpolateColor(start:ColorTransform, end:ColorTransform, t:Number):ColorTransform {
var result:ColorTransform = new ColorTransform();
result.redMultiplier = start.redMultiplier + (end.redMultiplier - start.redMultiplier)*t;
result.greenMultiplier = start.greenMultiplier + (end.greenMultiplier - start.greenMultiplier)*t;
result.blueMultiplier = start.blueMultiplier + (end.blueMultiplier - start.blueMultiplier)*t;
result.alphaMultiplier = start.alphaMultiplier + (end.alphaMultiplier - start.alphaMultiplier)*t;
result.redOffset = start.redOffset + (end.redOffset - start.redOffset)*t;
result.greenOffset = start.greenOffset + (end.greenOffset - start.greenOffset)*t;
result.blueOffset = start.blueOffset + (end.blueOffset - start.blueOffset)*t;
result.alphaOffset = start.alphaOffset + (end.alphaOffset - start.alphaOffset)*t;
return result;
}
}
}