creacog

Being of a Computer Science background I think it useful if not important that developers have some understanding of what’s going on behind the scenes. It can be a real time saver in choosing the right approach in solving a particular problem. In the Flex framework for example, we have full access to the source code via the open source SDK. However for some decisions it is handy to know the low level implementation. The Flash Player tends to be something a black-box with our knowledge constrained to the documentation which largely covers the ‘what’ is available — but only at a high level ever covers the ‘why’ or ‘how’.

To that end it is especially good to see Tinic Uro finding enough time to blog more frequently recently particularly with the changes for Flash Player 10.1. Tinic’s blog is essential reading for any Flash developer. The two most recent posts:

• Timing it right
• Core Animation

As we look forward to the release of CS5 before long, I had an unusual 5 days producing a new SWF based on a publish-to Flash Player 5 predecessor. So time to put on my Macromedia cap and dig out the old Flash 5 manuals.

This version pre-dates my working with Flash and dates back to when I quite frankly hated Flash. Ironically a number of designer types look on these as the good old days when Flash was very much a designer tool. I have to admit when I first saw Flash V1 further back in 1996 I didn’t rate it. I’d been using programming Director since 1993 and Flash didn’t have Lingo so it had seemed a step backwards to me.

Back to the current project, since most of flash 5 was easily described in two skinny manuals, there wasn’t really that much to have to read up on. The main issues encountered:

• The original designer seemed to have no discernible logic to the placement of graphics and their anchor points.
• Static text didn’t render particularly well — over-anti-aliased.
• Initially had problems with artwork imported from Illustrator

As regards the Illustrator problem, I had imported an .ai document to library and used on stage. Then while publishing I received an error alert :

This movie uses features that are not supported in Flash Player 5. View the Output Panel for details.

In the Output Panel, the message:

Enhanced stroke is not supported in this player

Simply solved by opening the .ai document in Illustrator then exporting a SWF. At which point it is possible to specify the Flash Player version. So saving off a Flash Player 5 SWF and importing that the Flash library rather than the .ai document avoids the problem.

As regards the text problem, this proved to be the motivation enough for the client to agree to updating the target player version from version 5 to version 8 in order to take advantage of ‘anti-alias for readability’.

Sometimes I wish Adobe would obsolete old versions — much like the current pressure to remove support for explorer 6 from the web. On the other hand I have to admire the facilities across Adobe tools that continue support output to legacy flash player versions for when it is impossible to persuade clients to be more current.

So, Flash player 10.1 is available in beta and includes mobile device oriented new features such as multi-touch gestures. Smart! Makes sense with Adobe strategy of delivering to emerging mobile devices. However there are a few million of us already using desktops and laptops with track pads, mouse wheels and mouse trac-balls who are feeling a bit ‘inhibited’. Flash is being used more and more to deliver applications either via browser or the AIR runtime. Such applications immediately feel somewhat inferior when a user cannot scroll or pan a view as they normally would native applications. Arguably ‘Rubbish’ rather than ‘Rich’ RIA in such cases.

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.

The documentation is correct, so i have no excuse, but I didn’t initially read much beyond the signature of the constructor…

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

… at the London Flash Platform User Group… tomorrow (29 Jan 2009).

Really handy! … ActionScript 3, Air and Flex documentaion distributed as an application on iPhone and iPodTouch – by Mike Chambers.

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

(Update: 28/10/2008 here)

Having been chastised for using these ‘unknown acronyms’ in my comment on jd’s weblog, I thought it worth writing a brief entry describing what these acronyms stand for and how they may be of interest for those purchasing or upgrading Adobe software.

• AOO : Adobe Open Options

• TLP : Transaction Licensing Program

Essentially this is all to do with volume licensing as an alternative to purchasing products through the Adobe store or other 3rd party suppliers. Volume licensing sounds like it is aimed at large organisations purchasing site-license. However the Transaction Licensing Programme facilitates as little as a single product license. The way the scheme works is to provide a transaction discount should you purchase multiple products in a single transaction based upon a point value for each product. TLP purchases may be made through 3rd party suppliers, but also through Adobe directly as in my case. There is no published price list so you need to request a quote.

The key point of interest to me was the Upgrade Plan which allows licenses to be purchased over 24 month subscriptions. Essentially this means I effectively have already paid to cover my CS4 upgrade. This is the point I was trying to make on jd’s weblog. He acknowledges that trial versions of CS3 products not being available until mid November is a ‘Pain point’ and he provides some explanation including the phrase “The big shipping versions get released first.”. Well I’m a AOO TLP upgrade licensee who’s just been told I may have to wait until the ‘end of November’ for it to physically ship to me. If it is painful for ‘users’ who haven’t paid for the software yet, imagine the pain for those who have paid for the software, but may have to wait until the end of November.

So while the Upgrade Plan offers some value, fulfilment seems less than ideal especially given this Key benefit documented on the Adobe site: “Get timely notifications of new upgrades, so you can stay on top of new product releases.”.

This is now my latest bug-bear. For Adobe to see how the customer experience could be improved in this regard, they need only look back to the now discontinued Macromedia DEVNET Pro subscription, where serial numbers and downloadable installers were immediately available to subscribers from day one of a new product shipping.

If this was fixed, I could now be blogging about cool new stuff in CS4 rather than  fuming over this and wondering if I would actually be better-off purchasing through conventional means.

UPDATE : 28/10/2008

Received my Adobe License Fulfilment email on 26th. Logged in and was able to request media for the upgrades, but at the time couldn’t see serial numbers or any way of downloading. However just checked again today, and the serials are there and I now have downloads in progress – and at a good bit-rate. So I’m feeling a lot happier now than when this post was originally published. While the process has not been entirely seamless, this time is far better than my previous experience with CS3 where I had to wait for physical media.

Really haven’t spent enough time ‘finenessing’ Flex based UIs recently, so especially looking forward to a something of a fast-track on Flex Effects in Tink’s presentation.

Always good to hear how others work with their clients too in the “ActionScript in Commercial Environment”session.

Full details: London Flash Platform User Group 25th Sept 2008

I’ve just been trying to delete a node and all its descendants from an XML object selected on the value of an attribute. Having read the “ECMAScript for XML (E4X) Specification” (PDF) as linked to from the Flex documentation I expected to be able to write the following…

delete theXMLObject..*.(@id=="theIDtoDelete");

however the above code will generate the following Flash Player runtime error…

TypeError: Error #1119: Delete operator is not supported with operand of type XMLList

The solution is simple if not obvious. The above code should be rewritten to ensure a single node is returned rather than a list…

delete theXMLObject..*.(@id=="theIDtoDelete")[0];

Distilled from this actionscript.org thread.

The authors of SWFObject and UFO have been working hard on a new version released yesterday as SWFObject 2.0. The project is now on googlecode. Geoff’s announcement is here.

As stated in my earlier posts I consider use of SWFObject to be best practice for embedding SWFs in web pages.