Skip navigation

Tag Archives: adobe

As someone who has worked with Flash since FutureSplash was acquired by Macromedia, and as someone with both a design / animation and programming background, I agree with Adobe’s decision to go with a more structured implementation of ActionScript in Flash with AS3. I believe it is a strategic move to position Flash as a viable platform for true RIA development.

There’s no reason that a toolkit couldn’t be written that abstracts the API to provide some of the functionality mentioned in the article. It would streamline development for designers / animators, yet maintain the architectural integrity of AS3.

It’s undeniable that the new VM is harder, better, faster, stronger. The level of complexity of the API needed to increase to provide access to the host of new features–not only for the contemporary version of Flash, but also to elegantly scale for the future.

Consider even the nomenclature of the AS2 display object hierarchy. “MovieClip”? Think about how someone from a development background (not Flash) would approach the idea of an interface comprised of “MovieClips.” They’re not interested in frame-based animation. They don’t want to play a movie. They want to draw vector graphics on the screen. So they create a “MovieClip”? I think Adobe has done a fantastic job of maintaining cohesiveness between a logically engineered AS3 API and the legacy AS2 API that anyone who has evolved as a designer / developer with Flash would be familiar with.

I believe that AS3 allows a developer to logically approach Flash as a UI platform with some amazing capabilities. I think AS3 alone may prove to be a challenge to a designer without any programming background, but this is not unmitigable with a well-written toolkit for designers. Maybe that’s the core of what I’m saying–that you can go one way but not the other. You can abstract an API to make it easier for a designer to use, but you can’t go the other way and take an abstracted API and make it more powerful for developers.

Specifically related to Charge #6–that’s definitely biting the hand that feeds you. SOME errors are better than NO errors. I think it was incredibly cumbersome to code to AS2 for the example that was cited in the article. I agree with the verdict NOT GUILTY.

I would also like to say that I concur with the other, arguably non-AS3, issues mentioned in the article, specifically “Failure to Unload,” which has caused me much grief in the past.

My intent is not to come off as a pretentious “real Flash developer” to all you “plebeian designers” or something, nor is it to slam Colin, whom I hold in very high regard, but I hope that this provides some counter-rationale.

Ok, I re-read the article, and I have to concede that perhaps my previous comment was slightly a knee-jerk reaction. As a Flash platform evangelist, I really appreciated the architectural changes in AS3 vs AS2. By the time I got to the bottom and read the previous comments, I forgot that Colin’s “What Should ___ Do?” commentary was really well thought through and addressed both the concerns of the designer and developer.

“But despite all the talk of GPU blitting, pixel shading, and ligatures, a non-negligible percentage of the Flash community is rightfully asking: is Adobe still committed to the simple, agile authoring practices on which Flash was founded? It’s a rational enough concern. After all, Flash built its success on ‘ease of use.'”

I think it is a valid concern, but “ease of use” is relative versus the audience, purpose, and power of what is being evaluated. I agree that Flash should be easy to use, but that does not mean what it did 10 years ago.

“Or maybe the time has come for someone to make an entirely new application for building simple Flash websites and animations. Such a tool could even be written in ActionScript, and deployed as an AIR app.”

I wonder when the convergence between Desktop, AIR (runtimes), Browser, Flash Player will happen. I feel like the industry is so confused with levels of abstraction, we’re writing browsers for various OS’s, that render HTML documents, which contain Flash players, that render RIA’s, or animations or whatever, which can also be deployed in an AIR runtime, which can contain a browser, etc… Forgive my rant, but I just don’t see things working like this sustainably for very long. Ultimately, it will come down to a contiguous platform that will allow left-to-right-brained people to interact and produce content in a continuum of connected devices. The moment we have immediate high-bandwidth connectivity everywhere is the moment the game entirely changes, and it’s almost here. But I digress…

Adobe has enhanced the security policy in Flash Player 9.0.115 and 9.0.124 that may cause some issues if you’re interacting with Web Services. Typically when I start a Flex project, I just throw a simple, open crossdomain.xml file on the root of the service site (or elsewhere) and go to town (which is poor practice to leave when you deploy). 

The “come and get it” policy file typically looks like this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*" />
</cross-domain-policy>

 

However, we noticed that an intranet project we’ve deployed stopped working on certain computers, throwing the following error:

[RPC Fault faultString="Security error accessing url" faultCode="Channel.Security.Error" 
faultDetail="Unable to load WSDL. If currently online, please verify the URI and/or format
of the WSDL (***YOUR WSDL ENDPOINT HERE***)"]
      at mx.rpc.wsdl::WSDLLoader/mx.rpc.wsdl:WSDLLoader::faultHandler()
      at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
      at flash.events::EventDispatcher/dispatchEvent()
      at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::dispatchRpcEvent()
      at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::faultHandler()
      at mx.rpc::Responder/fault()
      at mx.rpc::AsyncRequest/fault()
      at ::DirectHTTPMessageResponder/securityErrorHandler()
      at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
      at flash.events::EventDispatcher/dispatchEvent()
      at flash.net::URLLoader/flash.net:URLLoader::redirectEvent()

 

When you check out the XSD for policy files, you’ll notice that (among other things) they’ve added a “allow-http-request-headers-from” element. So the new “come and get it” policy file looks like this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*" to-ports="*" />
    <allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>

 

This should allow you to consume your services from basically anywhere. Remember to lock your stuff down when you deploy.

This works (outputs ID’s):

new Array();
var attributes:XMLList = _data.Attributes..AttributeDescriptor;
for each(var attribute:XML in attributes)
{
	trace(attribute.@ID);
}

This doesn’t (outputs nulls):

			
var attributes:XMLList = _data.Attributes..AttributeDescriptor;
for each(var attribute:XML in attributes)
{
	trace(attribute.@ID);
}

Any questions?

Update: Kudos to Larry (developmentastic.com) for beating his head against this brick wall on the Winestore project.

Follow

Get every new post delivered to your Inbox.