Thursday, December 23, 2010

A Couple of Hacks for Mobile Flex Development

The new Flex Hero 4.5 SDK has great features and the architecture for mobile applications is very cool.  Working with it over the last few months has also taught me a couple of coding hacks to share.  First let's look at how it works.

A Flex Mobile application is composed of a minimum of three files.  The first is the main entry point into the application, which has two main content areas.  The top content area (shown below in green) may contain three content areas.  These are Navigation content, Title content, and Action content. Note that these are optional and some applications might use different navigation schemes such as creating a Vector of Spark Navigators.

The gray area below the title is the main content area of an application.  This is controlled by the navigator(s).

When you set up a new Mobile application, the minimum three files are the main entry point, the first default Home or First View, and the Application Descriptor. The descriptor file has the same basic purpose as in previous versions of AIR except it has been extended to declare Android manifests and other items.  The graphic below depicts a larger project and shows some of the main components of a mobile application.

When you launch a mobile Flex application, the first view may be declared within the entry point to the application.  In the example above, MobileFileBrowser.mxml has a single declaration that points to MobileFlexBrowserHome.mxml.   This is declared in line 5 of Code Sample 1 below.

Code Sample 1

Line 6 shows a great trick.  Mobile applications may take a while to initialize and providing user feedback during that time is sometimes useful.  The splashScreenImage shows up when the application launches to let the user know the app is initializing.

Now let's take a deeper look at how the navigation works.  Below is a screenshot of the Mobile Slashdot RSS reader I am working on.  The first half of the tutorial to build it and the source code are available at Note that the current code base has some need for optimization.

The Home view in this case contains a list and has a service call linked to it to reach out and grab an RSS feed from  The service call (getData()) is initiated on an event called "viewActivate", which is fired when as the view becomes active.  When a user gets this view, they may select an item from the list and the view navigator will then pass the data object to a new view and instantiate the new view.  In this example, the RSS item is passed and details are shown in the new view.  If the user wishes to navigate backwards, they simply use the back button.  The code for this is written as pushView(View, Data) and popView().  

Here is an important tip! Consider what happens in a mobile scenario when the user examines several different RSS items and navigates backwards to the main list.  When the new view is active, the old view does not persist by default so a new service call must be performed every time the list view is shown.  If you link your service call up to the viewActive event as shown below on line 5 of Code Sample 2, your application will make the service call each time the view becomes active.

Code Sample 2

Needless to state, in many situations, this is architecturally really bad as it will eat up both bandwidth and battery/CPU life.  Luckily, this problem can be rectified with a single declaration.  The better way is to not call the service based on a viewActivate event and instead allow the user to trigger it with a button or use the applicationInitialize event.  Once you do this, you can simply add the declaration that the destructionPolicy is none as shown below in line 7 of the code snippet. If you download the current source code from part one of this tutorial, note that this has not yet been done and is being slated for part 2.

Code Sample 3

Now let's consider another way you can allow users to navigate through your application.  The Slashdot RSS reader application has an information view.  To access the information view, the call is made directly from the action content area.

When the user clicks the information icon, a call is made through the navigator.activeView object as shown in code samples 4 (below) and 2 above.

Code Sample 4

Note that on line 29 of code sample 4, the call is made to the public function on line 19 of code sample 2.  This function only requests that the navigator push the information view, in this case with no accompanying data.  Since the information view will also have the info icon in the parent container, it too must contain the showInfo() function or an error will be thrown.   If you wrote the function exactly the same as in the other views, it could lead to a recursive problem.  If the user keeps hitting the information icon, new info views get created and activated.  If the user hits the icon 25 times, they would have to hit the back button 25 times to return.

There are two ways to keep the view from being pushed more than once.  On line 10 of the code sample below is the function that gets called when a user clicks on the information icon.  Line 12 sets up a regular expression that will detect if the current view is the "InfoView".

Code Sample 5

Note that there is a "\d*" within the regular expression.  If you add a line of code to trace the name of the currently active view,  the console will show that the runtime appends some numbers to the end of the name as shown below.

Essentially the regular expression can detect if the activeView is already the InfoView and prevent it from creating another instance of itself.

The problem with this approach is that over time it becomes unmanageable.  A far better way to prevent this is to simply make the showInfo() function in the information view do nothing as shown on lines 8-11 of Code Sample 6 below.  Note that if you do not have the showInfo function in the info view, an error will be thrown when the user hits the icon.

Code Sample 6

This is a far better way to handle the problem.

Well, that is all for now.    A video tutorial will be out shortly to summarize some of these lessons and the source code for the RSS Reader will also be released.

Happy Holidays everyone!

Tuesday, December 21, 2010

My favorite 5 Slashdot Comments of 2010

I post a lot of stuff on  Here are some of my favorites:


I guess people are worried that our state of the art igloo geometric designs, dogsled aerodymanics and maple syrup chemistry are in danger if poltical decisions are made without the benefit of science. Luckily there are only 78 of us in the whole country. We can probably sort it out in about a fortnight over a few Molson's beers while watching ice hockey. duane "Who won the damn gold medals at the last Olympics anyways?"
"Question everything, including this!" -


Because there are lots of us who work at Adobe who have been very vocal internally about ensuring that Linux is a first class O/S and released at the same time as the other O/S's. That is why Linux is getting the 64 bit Flash Player. More and more of us are using Ubuntu and RHEL on the server (our enterprise ESB uses RHEL/(WebSphere || Weblogic || JBoss) as a reference implementation!). Now if we could only talk our bosses into CS5 for Linux.....


On Flash and having a Choice:

You could say you are also forced to use a browser then. You have a choice. If you want to see certain sites in their entirety, you can choose flash. If you want to experience only the text, use wget. If you want to see something in between, use a browser. your choice. There are still some old guys who don't even like to load images and only read the alt text. Can't make everyone happy so giving people choice is the only path we can take.


130 mb of ram while sitting idle? Then it's perfect for windoze and osx.... So what are the alternatives for *nix users now? dn grep this: s/$your_beliefs/$common_sense/i;


you are right. The way Flash (the swf format only, not the whole platform) was written circa 2003, it wasn't optimized to go to mobile devices. There were some issues and technical hurdles to get around. Some of them were simple (like stopping FP instances that are not in the visible part of the screen) or simply reducing the frame rates of flash applications that are using battery power when they are not in focus). Some required much more thinking such as form fields receiving focus when the tab is hit from an HTML form element above a flash form element). To scale to mobile was a challenge which has been met with the Flash PLayer 10.1. The Google Nexus 1 phone (which I own) does a great job of running the full version of Flash (not Flash Lite). The FP 10.1 has *huge* technical improvements from previous versions Adobe is full on excited about HTML 5 too. There are some really cool possibilities about using HTML 5 features side by side with Flash. Serge Jespers did a great job of showing this on his blog late last week: [] The fact is that HTML being updated is not something everyone asked for, but in it's execution, there are some obvious features that I am glad to see such as the Video element. I do share some concerns about how more advanced API's get implemented (such as the document.evaluate(); API) for complex XSLT processing but hope the industry will figure it out. DN

"Any technology can be used for good or for evil. The only question is how you decide to use your coding time in between "
- Gandalf