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:

• stage.width
• stage.height
• stage.stageWidth
• stage.stageHeight
• stage.fullScreenWidth
• stage.fullScreenHeight
• stage.orientation

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>

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:

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.

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.