Flex 4.5 Mobile

A month or so ago the Flex team posted specs on the Adobe Open Source site talking about some of the features that they plan to add in Flex 4.5 specifically for mobile. Specifically these new classes include the MobileApplication, View & ViewNavigator, and the ActionBar. Then last week Adobe posted an updated build of Flex 4.5 to the open source site, but the mobile bits had been removed. Now today an Adobian has posted some video of an application he built using Flex 4.5 Mobile components and running on a Nexus One. In the video he talks a little about some of the changes in Flex for mobile development as well as mentions that the skins are likely to be updated before release.

I have spent some time pouring over the specs trying to make sure I understand them and I plan to do a couple summary posts here in the near future. What I have found is that the idea of how to write an application for mobile is a little different from how we do these things on the desktop with Flex. The main idea is that there is really only one Section or View that is available at any one time. So the MobileApplication class builds on top of the Spark application to facilitate this by providing a ViewNavigator. The ViewNavigator is a new class in Flex 4.5 which appears to behave like the ViewStack of MX. The noticeable difference between ViewStack and ViewNavigator is that ViewStack can only change through content that was predefined, where as you can add new content to be displayed at runtime to the ViewNavigator. In fact with the ViewNavigator you use the views as a sort of stack where you push and pop the views to set what is displayed.

All of this is very interesting and I encourage you to go and read the spec documents on the open source site. There is lots of good information there and you can get a jump start on learning Flex 4.5 by digging into these documents now. Also as we have an Open Iteration meeting coming up if you dig into these docs now, then you might be able to ask questions during that call.

So get on over and checkout the Flex 4.5 mobile specs on the Adobe Open Source site.

The FlexUnit team just put the finishing touches on the first release candidate and posted the files for download.

Unless we get some very scary bugs, these files will be very close to what the final version of 4.1 will include. I think the only known change we have planned is building against the new Hamcrest that Drew tagged this weekend.

The team has already been hard at work prepping fresh features for the 4.2 release which has some new CI functionality as well as a bunch of new tests written with Mockolate. So despite being near a stable release for 4.1 the team is certainly not resting on its laurels.

So do your part to make FlexUnit 4.1 the best product it can be. Download the RC1 builds and give them a test. Let us know if you have any issues.

I am so excited to see that the Flex team had gotten through enough of the hush hush code jam on Flex 4.5 that they are ready to start talking to the community about Flex development again! I have complained lately that I missed these opportunities to talk with the team and help to guide the direction of the SDK.

So you can guess just how excited I was when I noticed an announcement for the next Open Iteration Meeting has been announced on the Adobe open source site.

From the Hero Home Page:

Open Iteration Meetings

We will be having the first Hero Open Iteration Meeting on October 1, 2010. Please join the Hero product team as we cover work that has completed in past Hero iterations and discuss what’s in store for upcoming iterations.

Meeting: Hero Open Iteration Meeting
Date: October 1, 2010
Time: 8 – 9 AM PT (11 am ET, 4pm UK, 5pm CET)
Connect Details: http://my.adobe.acrobat.com/hero-open-source/

So mark that date on your calendar and make time to contribute back the the framework that has made the flash platform available to so many. Be heard and share your feedback with the Flex team.

A little while back we started seeing spec documents appearing on the Adobe open source site talking about new features intended to be delivered in Flex 4.5. Most of these items were concerning the new mobile initiatives for AIR on Android. As these features rely on builds of AIR that were not yet released the code had also not been shared.

However late last night a bunch of new information was posted on the flex wiki regarding the new DataGrid functionality in spark. This caused me to go digging around what else had been posted and I found that the site had been updated ( not sure when) to actually include a build of Hero (code name for Flex 4.5).

This build does not include the mobile items but does include many of the new spark controls that are detailed on the wiki. So if you have just been dieing to play with the new spark controls for Form, Image and DataGrid then hurry over to the Adobe Open source site and get you some Hero.

Hero Home Page
Hero Downloads

Still haven’t bought your ticket to 360Flex in DC? Shame on you! But as usual your procrastination has paid off. Dan Florio (polygeek) has started a contest on his site to give a way a free ticket to 360Flex in DC. By buying your ticket through Dan’s affiliate link you become eligible to win back your fee for buying the ticket. Which is always great.

The really fantastic part of this giveaway is that if Dan gets enough signups he intends to start a scholarship for the next 360 so that someone who would not have previously had the ability to attend such an amazing and empowering conference would be granted the chance.

So again, if you have not bought your ticket to 360Flex in DC, Please do so through Dan Florio’s site.

So I had a client this week that wanted to build a Kiosk application for an upcoming trade show. Of course I told them no problem knowing about the fancy new FULLSCREEN_INTERACTIVE mode of Adobe Air. Well maybe not new but new since the original release :)

So I put in the time and got this thing working great. It fires up and displays a pretty animation as a screen-saver, if you interact with the mouse it loads up the form for people to enter contact data and it was great. With one little exception. If you hit the escape key it took the application out of full screen and it didn’t work very well. Since this application is going to be running during a trade show they want to not make it very easy for the user to get out of the application. I thought this would be simple so I added a key down listener to the application and setup a listener with a break point so I could debug. The problem was unless i was out of full screen I was not hitting the break point. Which really doesn’t do me any good since I wanted to stop it from leaving full screen to begin with.

So I did a little googling and came up with a couple blog posts of people doing exactly what I wanted. The problem was when I ported their code into my application things were not working. You see I had an event handler on my WindowedApplication that called the init() function in response to the creationComplete. But when i got to init() my stage property had not yet been set. So I just used the nativeWindow.stage property thinking that they would end up being the same thing. Well as it turned out I was not catching any events on that stage for key presses.

It wasn’t until I posted on twitter thinking I had found a bug in the new 2.0 air stuff (both examples linked above were for the 1.5.2 release) did things become clear. You see the secret is in the stage. And the fact that I didn’t have a stage for my application should have been the big indicator. In a flex application creationComplete is the event that says all is well and you are ready to get started. However in an AIR application the final event that announces to the world you are ready to be used is the applicationComplete event. Of course the stage was not ready yet, the window had not been constructed at creationComplete.

So if you should come to building your own Kiosk and you need to catch key events when in full screen, remember to add the KeyboardEvent.KEY_DOWN event to your stage in your windowed application. And make sure you wait for applicationComplete to try to set the event listener.

Big props to Nate Beck for reminding me that creationComplete was just not gonna cut it. :)