http://gotoandlearn.com/play?id=116

While the tutorial itself gives a clearer illustration of the development process, what's more interesting are some of the notable details that clarify or improve upon the MAX announcement back in October.

Perhaps most intriguing is the hardware accelerated demo at the end of the video, which definitely contradicts the relatively poor performance of some of the demo apps already in the app store, and is impressive versus those case studies that Adobe initially revealed.

Even more notably, Adobe has clearly made some substantial headway on the file size bloat issue. 8-9MB base weights were initially stated by Adobe at the MAX announcement, however the test app exported here weighs in at 3.2MB:

It should be noted that this is not a final compile for distribution, which could potentially add more weight (only Adobe knows for sure at this point), but it does appear that Adobe has put some effort into fixing that glaring problem. Bearing in mind that apps over 10MB in size require WiFi to download apps over the air to the iPhone, a high base weight poses a significant barrier to entry for end users to install even the simplest of AS3 based apps.

Also seen in this tutorial is the new  'flash.sensors' package, part of the 10.1 (and likely future Flash Player 11 release) which gives access to device interactions. In this demo, we see an implementation of the accelerometer class on the iPhone, and Lee does note that this will, as expected, be accessible with other 10.1 enabled mobile devices.

Finally, Adobe made it a point at MAX to be very clear about the lengthy compile times for iPhone applications, potentially in the neighborhood of five minutes in length. While this tutorial is for as basic as an app can get, the app demonstrated her takes a mere 38 seconds to compile. Again, this is not a distribution compile, but compile time issues aren't a concern for one-off compiles for distribution. Rather, it's the time suck of test builds that are potential deal breakers. 38 seconds is a promising number, but it remains to be seen what real world app compile times will wind up at when the Flash CS5 beta drops on Adobe Labs, which this tutorial further confirms as on track for the end of this year.

Lee's original post on theflashblog.com can be found here:

http://theflashblog.com/?p=1510

Assuming this event is attached to the object that triggered the rollover popUp, there is an existing method to hide the popup called hidePopUp(),  and a popup named popUp_mc: 

private function eMouseOutHandler(e:MouseEvent):void{
      if(e.relatedObject != popUp_mc) hidePopUp();
}

In this case, if the cursor is over the popup, it will remain visible. If not, we know that the cursor is not over the popup and it should be hidden. Note that you will now need to case for a mouseOut on the popup itself now, since if the user rolls through the pop up and out it will need to know to hide itself. However, the reverse of the code above will need to be implemented for this mouseOut - if the relatedObject property is the object that received the initial rollover, again we should ignore hiding it since cursor would now be over the object that would have shown the popup in the first place.

Adobe Labs - Adobe Flash Professional CS5: Applications for iPhone.

A couple of classes, first one is the manager itself:

package  {

 import flash.display.Sprite;

 public class OverlayManager {
  
  private var objArray:Array;
  
  public function OverlayManager() {
   objArray = [];
  }
  
  public function registerOverlay(obj:Sprite):void {
   objArray.push(obj);
   obj.addEventListener(OverlayEvent.CHANGE, eChangeHandler);
  }
  
  private function eChangeHandler(e:OverlayEvent):void {
   for (var i:uint = 0; i < objArray.length; i++) {
    if (objArray[i] != e.object) objArray[i].close();
   }
  }
  
 }
 
}

Next, our OverlayEvent:

package  {
 
 import flash.display.Sprite;
 import flash.events.Event;

 public class OverlayEvent extends Event {
  
  public static const CHANGE:String = "change";
  
  private var _object:Sprite;
  
  public function OverlayEvent(type:String, $object:Sprite, bubbles:Boolean=false, cancelable:Boolean=false) {
   super(type, bubbles, cancelable);
   _object = $object;
   
  }
  
  public override function clone():Event {
   return new OverlayEvent(type, object, bubbles, cancelable);
  }
  
  public override function toString():String {
   return formatToString("OverlayEvent", "object", "type", "bubbles", "cancelable", "eventPhase");
  }
  
  public function get object():Sprite { return _object; }
  
 }
 
}

And finally, an interface:

package  {

 public interface IOverlayObject {
   
  function close():void;
 }
 
}

Implementing involves a few quick steps for each object (obviously you'll need at least two for this to do anything). First, the object needs to implement the interface (basically requires a public close method on the object). Next, we need to register the object with the manager itself, and finally, whenever the object is shown, we need to dispatch an OverlayEvent.CHANGE event, passing along a reference to the open object. Example:

package {

 import flash.display.Sprite;
 import flash.events.MouseEvent;
 

 public class OverlayObject extends Sprite implements IOverlayObject{
  
  public function OverlayObject() {
  }

  
  public function close():void {
   showObject(false);
  }
  
  public function showObject(show:Boolean):void {
   if (show) dispatchEvent(new OverlayEvent(OverlayEvent.CHANGE, this));
   visible = show ? true:false;
  }
  
 }
 
}

I generally avoid writing editorial articles on my blog, sticking strictly to informational code bits and the like. But as a developer who works closely with designers/devigners, the validity of the Flash timeline in todays development world is a topic I think worth discussing.

Since AS3 first appeared on the scene, the timeline and its ease of use for code have dramatically changed. Granted, most developers (including myself) will say that you should never, ever put code on the timeline, or even worse, after frame one, ever. However, in AS2, you could do it and all would work just fine. Nowadays, timeline code is messy at best, and the undocumented method addFrameScript() is a poor workaround at best. This is largely due to AS3 coming to Flash from Flex first, which is evident looking around the IDE and the language itself, seeing how timeline is really an afterthought in the language.

I'd like to take a second here and point out at this point that I am completely, all for using document classes and not coding in the timeline (or the IDE for that matter) at all, period. It hasn't been a best practice for a long time now and creates headaches that don't need to exist with just a little bit of knowledge about how to properly write a class. I understand the fear of stepping into classes, I've talked to designers who cringe at the thought. But the reality is that a little bit of knowledge will go a long way here.

So my question is this: why, if timeline is an afterthought in the language, is it treated as a top tier item in the IDE? Consider this - you can't create an exclusive Sprite in the IDE (a 1 frame movieclip is technically a sprite, but you can't lock the timeline to only be a sprite by definition). Maybe therein lies the solution I am (and undoubtedly others are) seeking. Really, the timeline could, and should, be a layers panel, just like in photoshop. We don't need additional frames. Why? Because frames are a property of MovieClips. The stage should be a Sprite by default. If you create a MovieClip, the timeline should be an accessible property of the clip within the IDE, with its own interface, building in the power that was added in CS4. But you should not be able to add code to those frames at all. So timelines would strictly be property of the MovieClips themselves within the IDE, just like in the language.

I think the reason we havent seen this yet is twofold: Legacy AS2 users who still use the timeline directly, and the fact that the timeline has become one of the starting points for most users, as well as an identifiable part of the IDE. I see the reasoning, but it weakens the perception of Flash by allowing loopholes for poor practices. This is furthered by the countless tutorials that start with the timeline as step one of using Flash. Take a glance at the newgrounds forums for Flash and you'll see the problem post by post. The language and the IDE need to coexist better as complements to each other, without stepping on each other's toes as much as they do right now.

I think for AS3 projects it's time to lose the timeline rather than force fit it into a language that doesn't really properly support it. There's no reason to. Timeline animations are great, but that's just what they should be - animations. An asset to be referenced and used by code, within AS3 at least. Legacy users are always a consideration, but that doesnt mean you can't force the users of newer technologies to use newer, improved standards. AS3 shouldn't have to support improper code techniques - that's what the support for AS2 in the IDE is for. The addFrameScript() method shouldn't even need to exist in the first place. If Adobe forces everyones hands to fully seperate AS3 code in .as files and animations in the timeline, where they belong, we'll all be better off, and that would be one less knock against Flash as a hack language.

So what do you think? Weigh in in the comments.

Luckily, it isn't as hard as it seems. For developers, one of the best uses for SWC (Flash builds require a matching SWF file as well) files in flash AS3 dev is packing up pre compiled libraries for use at runtime ( you can also package assets, but that isn't what we are here to talk about). It's pretty straightforward using the export SWC option under publish settings. But what if you need to export only a portion of the package as a SWC/SWF library?

I did some searching, and the few topics I found that mentioned this had replies that questioned the merits of the idea instead of proposing how to go about it. In my case, for Fosfr, I was looking to produce an external library file, but needed to include about 13kb of the entire 50kb package in the core SWF file to properly launch the loading process of the framework, which would then go and get the rest of the library before running any code that needed the full framework library. So there are legitimate cases where you may want to do this. And actually, it can be done.

So, how to go about it? The problem lies in that generating SWC files pulls all classes referenced from your chosen classes along with them into the SWC. so, say you are using TweenLite in your package that you wish to turn into a SWC. Check the SWC afterwards and you'll see that the TweenLite package got sucked in there too. So how can this be avoided? To do it you'll need to use one of the powers of SWC's themselves -compile time class referencing - and one of their usage nuisances - priority of classpaths over SWCs in Flash.

Here's the steps to generate a partial package SWC:

1 - Create an FLA to make a SWC and generate a full SWC of the entire package you wish to generate as a SWC. Dont worry about file size or excess files, this file is for reference.

2 - Take the SWC and place it next to that same FLA (CS3) or in publish setting specify the SWC as an external library (CS4). Now, go back to your class package. Save a backup copy first, then in the package folder, erase all of the classes you'd like to EXCLUDE from the SWC library.

3 - Generate another SWC (give it a different name). If you did this right, this new SWC will only contain the classes you have left in the package folder. Since the Flash compiler prioritizes classpaths over SWC files, the compiler found the source for those files in the right place, so it placed them in the new SWC. When it got to one it couldnt find, it then searched your external library SWC's, in this case the one holding the whole package and said 'yes, here it is, it compiles and I'm cool with it'. Since it is an external library though, it doesn't pull the class into the new SWC. The result? a partial package SWC and SWF library, containing only the .as files you explicitly wanted contained inside.

This leaves two open ends.

First, you must be positive that you aren't referencing any of the classes you left out before you load in the full library for use (remember proper loader context, ApplicationDomain.currentDomain, to access those classes at runtime).

Second, what about that full library? now you have a full library that has files you've since duplicated in the new smaller SWC. Well, you can, if you wish, reverse the process and go back and use this new smaller SWC as an external lib and remove the classes contained inside from your package, and recompile. What you'll wind up with is a full package split cleanly between two SWC files. Pretty nifty. It's a fair amount of work, and it should be easier, and maybe it is - if someone has a better solution, please share!

a parent SWF

a child SWF, dispatches a custom event

another child swf, nested in either the parent or the other child, listens for that custom event.

The error you'll receive is a type coercion error that looks like a mistake - can't convert [custom event name] to [custom event name]. So what gives? They're the same class, both SWF files have imported the event class correctly, yet they are colliding through the event dispatch. Well, it turns out it is a security violation due to the way in which the SWF was loaded. Change your loader context to new LoaderContext(false, ApplicationDomain.currentDomain) when loading in those child SWFs and suddenly they can talk to each other more openly than before and type checking  correctly returns that all important 'true' - in other words, no coercion error. All of those imported classes match up - and you can even instantiate objects of a type defined in the other child SWF without importing it into your class. To get Flash to export it without referencing it though requires a SWC file for the SWF to reference the classes from (CS4 modified this process a bit with the ability to specify external libs, and Flex has had the same functionality for a while i believe). Colin Moock's Essential Actionscript has a chapter on doing just that, right at the end of the book. If you're interested in that process, he says it better than i ever could.

FYI - the fix mentioned in my previous post on the subject is still valid if you can't/don't want to change the application domain for the loader. Adding the reference to the document class of the top level parent SWF still rectifies the issue.

Lots of additional features planned here, including incorporation into Fosfr after the 1.0 release of that. Currently Tabulate is a 1.0 alpha with no docs since it is all likely to change.

http://tabulate.googlecode.com

This is still problematic, no doubt. going about this method of ensuring you are in a buffering state means you absolutely have to catch all occurences of pauses, whether triggered by the FLVPlayback package or by the user,and flag them, to make sure you have isolated buffering related pauses only. Whats more, this renders the bufferingBar property useless, which is designed to connect a Sprite to buffering events, displaying a custom graphic when buffering. I don't recommend using this anyway as doing so removes the ability to control how and when that visual is displayed, but if you DID decide to use it, the use case discussed above is definitely not caught by the class itself - it simply pauses.

If someone is aware of a simpler and/or more conclusively effective workaround, please drop a comment!