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 http://technoracle.blogspot.com/2010/12/mobile-slashdot-rss-reader-tutorial.html. 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 slashdot.org. 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!
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.
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.
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 http://technoracle.blogspot.com/2010/12/mobile-slashdot-rss-reader-tutorial.html. 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 slashdot.org. 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().
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.
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.
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".
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.
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!
