Note: This post has been getting a fair amount of traffic. I originally posted this directly after launch, and subsequently it contained outdated information from what is now known from the final release of OS 3.2. I originally had left the original post info for the sake of blogging/ journalistic integrity, however after three revisions because of newer info, I decided to strip the clutter of invalid content. Having said my disclaimer, below is the revised new post, and here is the release version of the iPad UA string as of 4/6/10, pulled directly from my 32GB wifi model:

Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) version/4.0.4 Mobile/7B367 Safari/531.21.10

more after the break.

The iPad represents itself in line with how the iPhone and iPod Touch differentiate themselves by specifying different device strings, but still contains the word 'mobile' - so Apple is currently explicitly classing this device as a mobile browser. But we now have a new class of devices to case for, segmented somewhere between mobile and non-mobile. While Apple has taken the first real swing at a tablet user agent, it's up in the air whether other tablet browsers will fall in line with this or do their own thing. Consistency is critical for proper detection without necessitating device specific casing.

This is intriguing and presents an interesting new issue for web developers. In their marketing materials, Apple has classified the iPad as designed for a full web experience (barring Flash of course), but they themselves are saying to the developers that this is a mobile device, right in the UA string. Moreover, technically the UA string classification is correct - this is a mobile browser. This isn't the desktop version of Safari. While they are both webkit based, it is inevitable that considerations will want to be made for the glorified Safari mobile browser in the iPad, and using the user agent string to identify that and case for it is problematic unless Apple modifies the UA string. My guess is at some point they will, possibly as soon as 4.0 hits.

It's not so much that this matters for development now as much as that it sets a precedent for future slate browsers. Apple has said here that slate browsers, even if they are larger versions of existing mobile browsers, should identify as a mobile browser, but clearly full sites should, and will be ultimately presented to iPad users in many cases. Even if the UA string wasn't an issue, there's still the question of how to architect a full site for both tablets and desktop viewing (primarily casing for browsers that do and don't have Flash). Proper implementation of progressive enhancement techniques is a great solution (see my related post on this topic here).

Maybe this whole UA string mess will all be a moot point when we see the 4.0 beta. As with all things Apple launch related, time will tell. One thing you can count on is that if the iPad succeeds, the precedent will be set. We'll see who follows.

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

trace(TimeFormat.formatTime(200, TimeFormat.SECONDS));

outputs "0:03:20". Full class after the break.

package {

public class TimeFormat{

public static const HOURS:uint = 2;

public static const MINUTES:uint = 1;

public static const SECONDS:uint = 0;

public function TimeFormat() {
}

public static function formatTime(time:Number, detailLevel:uint = 2):String {
var intTime:uint = Math.floor(time);
var hours:uint = Math.floor(intTime/ 3600);
var minutes:uint = (intTime - (hours*3600))/60;
var seconds:uint = intTime -  (hours*3600) - (minutes * 60);
var hourString:String = detailLevel == HOURS ? hours + ":":"";
var minuteString:String = detailLevel >= MINUTES ? ((detailLevel == HOURS && minutes <10 ? "0":"") + minutes + ":"):"";
var secondString:String = ((seconds < 10 && (detailLevel >= MINUTES)) ? "0":"") + seconds;
return hourString + minuteString + secondString;
}

}

}

doucmentation: http://www.jeffdepascale.com/documentation/tabulate

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;
  }
  
 }
 
}

http://code.google.com/p/gmaps-samples/source/browse/trunk/basic_wcircle/basicw_circle.htm

The problem is that when crossing the date line or the poles, the polygon draws incorrectly. the following code builds on the method drawCircle in google's implementation. This one is designed to return the points in an array for a specified radius around a LatLng position. Polygons will cross the date line, and if the poly reaches a pole it will draw a hard line across the top of the map instead of breaking into the gray outside the map. Verified working in 1.16 of the API.

 private function getPoints(latLng:LatLng, radius:uint):Array {
   var circleLatLngs:Array = [];
   var circleLat:Number = radius * 0.014483;
   var circleLng:Number = circleLat / Math.cos(latLng.lat() * Math.PI / 180);
   var numPoints = 100;
   var maxLatitude:uint = 85; //equates to the latitude edge in google maps (not 90)
   for (var i = 0; i < numPoints + 1; i++) {
    var theta:Number = Math.PI * (i / (numPoints / 2));
    var vertexLat:Number = latLng.lat() + (circleLat * Math.sin(theta));
    var vertexLng:Number = latLng.lng() + (circleLng * Math.cos(theta));
    //if the latitude value is outside the maxLatitude value for either hemisphere, lock it to that value.
    if (vertexLat > maxLatitude) vertexLat = maxLatitude;
    if (vertexLat < -maxLatitude) vertexLat = -maxLatitude;
    var vertextLatLng:LatLng = new LatLng(vertexLat, vertexLng, true); //setting true allows values outside 180 degrees, which fixes issues crossing the date line
    circleLatLngs.push(vertextLatLng);
   }
   return circleLatLngs;
  }

Hopefully that saves some headaches!

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.