AIR

Which width? (AIR on devices)

Within the Flash APIs is there there are many similarly named properties which provide subtly different results based on their spec and the state of the application. Width and height are such properties.

Having just read of Mike Jones’ recent article: 10 Tips When Developing For Multiple Devices, and tip #1: Check screen dimension on initialisation, it includes a couple of lines of code to get the landscape height and width of the device screen using a boolean expression to determine the longest dimension. For me this begs the question, why can’t I simply get the right values directly from the API? Especially if my app.xml properties state the app should only display landscape, full screen.

The properties examined here:

Although accurately described in the reference, it isn’t necessarily easy to visualise the differences in behaviour for these properties from the documentation alone. So herewith, a simple HelloWidthHeight app to trace out the values upon initialisation. Included in that app is a class implementing logic based on Mike’s as static methods. The results of debug sessions executed on my HTC Desire are detailed for comparison in the table below.

Key app.xml <initialWindow> properties used were:

  • <visible>true</visible>
  • <aspectRatio>landscape</aspectRatio>
  • <autoOrients>false</autoOrients>
  • <fullScreen>true</fullScreen>
A B C D
stage.orientation default rotatedRight rotatedRight rotatedRight
stage.width 0 0 0 0
stage.height 0 0 0 0
stage.stageWidth 480 800 800 800
stage.stageHeight 800 480 480 480
stage.fullScreenWidth 480 480 800 480
stage.fullScreenHeight 800 800 480 800
Oriented.landscapeScreenWidth 800 800 800 800
Oriented.landscapeScreenHeight 480 480 480 480
Oriented.portraitScreenWidth 480 480 480 480
Oriented.portraitScreenHeight 800 800 800 800
  1. Screen inactive, phone held in any orientation
  2. Screen active, phone lying flat on the desk
  3. Screen active, phone held landscape, mic to the right (this is the intended orientation for the app)
  4. Screen active, phone held portrait, mic to the bottom

In conclusion, unless the application is only ever launched while the screen is active (though that would be the norm), the safe way of determining an oriented width and height is to use a boolean expression along with the fullScreenWidth and fullScreenHeight properties.

UPDATE (20-July-2011): The following table runs the same code in the BlackBerry PlayBook Simulator:

A B
stage.orientation default default
stage.width 0 0
stage.height 0 0
stage.stageWidth 1024 1024
stage.stageHeight 600 600
stage.fullScreenWidth 1024 1024
stage.fullScreenHeight 600 600
Oriented.landscapeScreenWidth 1024 1024
Oriented.landscapeScreenHeight 600 600
Oriented.portraitScreenWidth 600 600
Oriented.portraitScreenHeight 1024 1024
  1. Simulator initially landscape
  2. Simulator initially portrait

Note: Behaviour is slightly different on the PlayBook simulator in that the orientation of the application is set before the initialisation code runs. Therefore unlike on the HTC Desire, fullScreenWidth and fullScreenHeight are correctly returned as the orientation of the application expects.

If anyone else cares to run the code, I’d be interested to hear how variable other devices are in their results, or if this is showing a bug when run on HTC Desire. Running AIR 2.7 here.

Posted by creacog in ActionScript, Adobe, AIR, Flash Builder, HTC Desire, 0 comments

Adobe AIR 2 runtime s for Windows, Mac and Linux publicly available

Spreading the word based on Adobe’s notes…

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:

This coincides with the final release of Flash Player 10.1…

Posted by creacog in Adobe, AIR, Flash Platform, 0 comments

hello desire

So, it’s good-bye to my trusty and slightly crumbling Nokia 3100 (recently a source of amusement and pity amongst my peers)…

Nokia 3100

Hello HTC Desire…

HTC Desire Unboxed

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 Steve 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.

Posted by creacog in Adobe, AIR, Android, Apple, Flash Platform, HTC Desire, 0 comments

flash in the pan

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.

Posted by creacog in Adobe, AIR, Flash Platform, Flex, Mac OS, 0 comments

flash.display.BitmapData gotcha – well gotme for a while

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

Posted by creacog in ActionScript, AIR, Flash Platform, Flex, Flex 3, Mac OS, 0 comments

coach tool in flex / air

Coach Tool snippet Finally got around to adding a case-study to my corporate site including a screen-cast of some of the features of my longest running project, a Flex/AIR application for communicating football moves and plays. Essentially a digital, animated version of a football tactic board.

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

Posted by creacog in ActionScript, AIR, Flex, Projects, 0 comments

ACE

Blowing my own trumpet for a moment… last week I sat and passed as Adobe® Certified Expert in Flex with AIR. Which I hope will help make my case with prospective clients.

Adobe Certified Expert : Flex with AIR

More information on Adobe certification programs.

Posted by creacog in Adobe, AIR, Flex, 0 comments

an AIR pet hate : Forcing Windows UI on users of other platforms

An emerging pet hate of mine: AIR applications that do-away with the system chrome, only to then re-implement parts of it, but ignoring host-system conventions. Note this isn’t anything to do with AIR itself, more to do with designers and/or developers not entirely considering user-experience across all platforms.

window controls

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.

Posted by creacog in Adobe, AIR, Flex, 2 comments

1st debug run following Flex SDK 3.2 update

Will probably yield scary looking error:

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.

Posted by creacog in AIR, Flex, Flex Builder, 0 comments