A Couple of Hacks for Mobile Flex Development
A Couple of Hacks for Mobile Flex Development
Join the DZone community and get the full member experience.Join For Free
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 comprehensitve tutorial with videos at the end can be found by following that link.
Happy Weekend everyone!
Published at DZone with permission of Duane Nickull . See the original article here.
Opinions expressed by DZone contributors are their own.