The AIR 2 release includes many new features including:

• Native Process API
• Open documents with the user’s default application
• Microphone data access
• Mass storage device detection
• Updated, faster WebKit with enhanced support for HTML5 and CSS3
• Multi-touch
• New networking support including UDP and server sockets
• Screen reader support
• Reduced CPU usage on idle
• Up to 30% reduction in memory usage without recompiling an application
• + more

Links:

• Download AIR 2
• Official AIR 2 blog post by Arno Gourdol
• AIR 2 Release Notes (references the list of new features)

This coincides with the final release of Flash Player 10.1…

• Announcement on the Flash Team Blog
• Get Flash Player

Hello HTC Desire…

It could so easily have been hello iPhone. I do have iPod Touch which I enjoy using. But fundamentally as a Flash/ActionScript/Flex/AIR developer it made no sense at all to get a smartphone on which Flash has been nobbled.

(My own brief comment and observation on the iPhone/Flash debacle : It looks to me that both companies have incompatible business strategies with regard to delivery of RIAs on mobile devices. Discussion outside of the these strategies is in my opinion a deflection. It was disappointing to read Steven Job’s thoughts on Flash, which to my mind are ill-informed and based on half truths – out of character in those regards. It was also disappointing to watch Adobe CEO Shantanu Narayen’s response in interview with the Wall Street Journal where, in my humble opinion, he was far from convincing and by the end was sounding more like a parroting politician. Disappointing too that past quality and performance issues with Flash player gave Apple an easy ammunition to exaggerate and exploit. As an avid Apple Mac and Adobe Creative Suite user I hope the two companies can return to a professional relationship which doesn’t leave customers of both companies, like myself, out in the cold.)

So back to the HTC Desire, some first impressions…

The good

1. It looks good, feels good
2. Nice bright responsive screen
3. Call quality is good
4. Better quality camera than I expected
5. The main reason for getting this device – Flash based apps are allowed!

The not so good (compared with my iPod Touch experience)

1. There are too many buttons. I find myself pressing the wrong one most of the time. Sometimes a button press is required. Sometimes not. The whole thing is less intuitive than the iPod Touch with it’s single button.
2. It seems all too easy to initiate a call at random while scrolling through the contact list.
3. Text selection/cursor positioning is awful
4. There is no out of the box easy way of syncing Address book, Calendar, tunes, photos etc with my Macs. Looks like I need to purchase Missing Sync. That said, I did previously purchase Mobile Me to keep my Mac / Mac Book Pro and iPod Touch all in sync.
5. The Mail application is crap. I use a self-signed SSL certificate on my mail server, so I immediately hit the problem of a silent fail when trying to add connection details to the mail application. The hack in the forum thread worked in fixing it, i.e. turning off my router’s WAN connection, while inputting the connection details. Also it doesn’t list the mail folders on the server – all I get is the inbox. Apple’s Mail app by comparison is a doddle and reflects the structure of my mail account.

Fingers crossed for Android 2.2.

Anyway, looking forward to setting up some kind of tether to share the data connection with my MBP and more importantly getting something running in AIR for Android on there.

For a long time the MOUSE_WHEEL event has been part of the Flash API but only officially supported on the Windows platform (in browser). Original reasoning for not implementing support for the Mac platform can no-longer be argued as all Macs for a number of years have been shipped with the Mighty Mouse (2005) and now Magic Mouse or Trackpads. All of which facilitate mousewheel style interactions. All of which go further and support horizontal as well as vertical scrolling interactions or ‘panning‘. There are JavaScript workarounds for in-browser Flash on a Mac such as this solution on hasseg.org or this SWFObject based pixelbreaker solution. Fortunately Flash applications delivered via the AIR runtime can respond to MOUSE_WHEEL events without any such workarounds. However MOUSE_WHEEL currently only facilitates vertical scrolling in any case.

We need to facilitate horizontal as well as vertical scrolling (panning) of content in response to events from ubiquitous input devices.

A few prominent applications I use often, which suffer:

• TweetDeck : AIR based. High discoverability of lack of horizontal scrolling support
• Adobe online store UK : In browser Flex application – Flash being used in an attempt to emulate HTML – no vertical scroll wheel support for Mac users
• Adobe Flash builder : Design view (Java application with Flash based view)
• Adobe Catalyst : Art-board view (Java application with Flash based view)

Adobe actively invite comment and suggestions on their products. More widely/easily through the Feature request/bug report form. They have opened up the bug tracking system for a number of products. Flash player being one of them. There is an active bug report with regard to this issue and I would encourage anyone with an opinion to contribute to the discussion and/or add weight by voting. Just sign up and access FP-1262. There is an active drive from within Adobe to help from the community to improve the quality of Flash Player and AIR.

As for the solution I think I’d like to see something along the lines of… Extending the flash.display.InteractiveObject with a ‘panEnabled‘ boolean property defaulted to false which, when true, allows the object’s Panning behaviour/event broadcasting (akin to doubleClickEnabled mechanism). So, when panEnabled is true, if the mouse pointer is over the InteractiveObject, and the user makes a ‘pan’ gesture, the frontmost panEnabled InteractiveObject broadcasts flash.events.MouseEvent.MOUSE_PAN events containing with the additional properties : offsetX and offsetY. Text based InteractiveObjects should default to panEnabled = true. Further, I’d quite like to see mechanisms to facilitate behaviours of nested pan-able objects. E.g. on a Mac, the front-most display object gets scrolled until it can scroll no further, then if the user continues the scroll input, the containing display object then scrolls.

In rounding up, the best place to contribute your opinions on this subject and have them heard by Adobe is here : FP-1262.

public function BitmapData(width:int, height:int, transparent:Boolean = true, fillColor:uint = 0xFFFFFFFF)

I needed a transparent bitmap. Reading the default “transparent:Boolean = true”, I assumed by simply supplying width and height, a transparent bitmap is what I would get. Not so! I got a white rectangle. The reason being, that the default fill colour is 100% white. (The first pair of FFs representing the alpha in ARGB).

At first it would seem slightly unintuitive for the second default to conflict with the first, until one realises that the ‘transparent’ flag is there to indicate whether the object will support transparency or not. Not to state that it should be initially created transparent. Supporting transparency increases data size from 24 bits per pixel to 32 bits per pixel.

So what i should have done :

bmd = new BitmapData( width, height, true, 0 );

More details and the screen-cast are on the creative-cognition case-study page.

More information on Adobe certification programs.

Downloaded it, had a play, simple and effective. A ‘back’ button would be nice though in future versions

The example above taken from Tour de Flex.

Personally for this app I see no reason not to have used the host system’s chrome. Doing so would have entirely avoided this issue. But to re-implement fundamental controls such as those pictured using positioning and icons based on only one operating system in an app which is cross-platform undermines the user-experience for users of other systems. In the example, a Windows arrangement and appearance is used which feels wrong on a Macintosh system, where the arrangement should be reversed and in the left rather than the right corner of the window. That it is Adobe setting this presedent in a number of their AIR applications is disapointing. I hope it is a convention other AIR developers will not follow. I certainly wont.

Process terminated without establishing connection to debugger.
Command:
“/Applications/Adobe Flex Builder 3/sdks/3.2.0/bin/adl” -runtime “/Applications/Adobe Flex Builder 3/sdks/3.2.0/runtimes/air/mac” /PathToProject/bin-debug/Project-app.xml /PathToProject/bin-debug
Output from command:
error while loading initial content

So, basically by setting the project to compile against the SDK 3.2 you are implicitly changing the version of AIR you are building against from earlier versions to 1.5. To fix you need to open file :

/PathToProject/Project-app.xml

and change the namespace to “http://ns.adobe.com/air/application/1.5″

This has already been logged as a bug (FB-15687) in the bugbase against Gumbo, by the release of which, hopefully it will be intercepted to present a more meaningful message.

Point the configurationFile property to the location of that file: as in the following ActionScript:
appUpdater.configurationFile = new File("cfg/updateConfig.xml");

If you are familiar with the File class, you will see that this is likely to generate a run-time-error, especially when testing in adl…

ArgumentError: Error #2004: One of the parameters is invalid.
at Error$/throwError()
at flash.filesystem::File/set nativePath()
at flash.filesystem::File()

If you are like me, you’ll probably want to place the updateConfig.xml file within the application directory next to the *-app.xml file. If so, the line of code you need can be written:

appUpdater.configurationFile = new File( File.applicationDirectory.resolvePath( "updateConfig.xml" ).nativePath );

or more compactly, using the “app:/” url scheme:

appUpdater.configurationFile = new File( "app:/updateConfig.xml" );