Flex 3 in Action

Advanced reusability in Flex

This chapter covers: ■

Runtime shared libraries

■

Shared reusability

■

The Module API

■

Adding patches

■

Refactoring

So far, you’ve learned the basics of OOP and how to make custom classes. We’ve also looked at how to develop cool components that spit out pieces of functionality. In this chapter, we’ll give you an overview of some of Flex’s advanced reusability features. What is reusability? We use the term loosely to mean ways you can reuse chunks of code either in the same application or across multiple applications. The concept of reusability isn’t unique to Flex; each language provides mechanisms to achieve it. The more you’re able to reuse, the faster you can develop new applications by leveraging existing code. From a maintenance perspective, you can achieve faster turnaround time when implementing changes. With Flex, reusability can also result in improved performance. Previous chapters have covered common reusability techniques, including using custom classes and custom components. One of the advanced reusability features is

380

Licensed to [email protected]

381

CHAPTER 18

Advanced reusability in Flex

the runtime shared library (RSL). By the end of this chapter, you’ll have a strong starting point to understanding what RSLs are as well as Flex’s additional reuse capabilities. A Flex application (which is compiled to a SWF file) can include several kinds of advanced elements: SWC files, RSLs, and modules. Leveraging these pieces will enable your applications to load quickly and will make them easy to maintain in the long run. You’ll learn what each of these elements means for you and how to utilize them in your Flex 3 development. Let’s first explore the primary element: the SWC file.

18.1 SWC files SWC (pronounced “swick”) files aren’t to be confused with SWF (pronounced “swiff”) files. To use a Java analogy, the SWF file is like the .class file (the executable); a SWC is like a .jar file (an archive containing supporting items). SWC files are containers that can house all the classes, assets, and components that you want to put in them and reuse. Most of the third-party components and libraries you’ll use will come in SWC files because they’re much easier to distribute than many .as files. If you open a SWC file with WinZip or any compression program, you’ll see a library.swf file and a catalog.xml file. The SWF file contains all your code/assets, and catalog.xml tells the compiler where to look for a class or asset. Most often, SWC files are used for themes and code you want to share during runtime. Let’s briefly explore the benefits of using a SWC file for theme development. Let’s look at how to use SWC files for runtime shared libraries.

18.2 Runtime shared libraries RSLs are code that is loaded during runtime by multiple applications and domains (for domains, some restrictions apply). Suppose you create a new class that you’ll use in 20 applications. Instead of having this class be compiled in all 20 applications and take up an extra 300 KB, you can trim those 300 KB by having the applications load the class during runtime. This is also a neat way to deploy patches to your application until you release the next major version, as we’ll discuss this later. You’ll see a big performance increase only when you’re developing really large Flex applications, which require the same components and classes. We’ll explore three different types of RSLs: ■ ■ ■

Standard—Cached in the browser and only available to a single domain Cross-domain—Cached by the browser; can be accessed by another domain Framework—Cached by the Flash Player

Learning about RSLs may seem daunting when you’re faced with terms like standard, cross-domain, and framework RSLs, but in reality they’re simple concepts. Let’s start by learning about standard RSLs.

Licensed to [email protected]

382

Runtime shared libraries

18.2.1 Standard RSLs To understand how to use a standard RSL, you’ll create a simple class and make it into an RSL for use in other applications from the same domain. The first step is to create a new Flex library project: 1

2 3

In Flex Builder, create a new Flex library project by choosing File > New > Flex Library Project. Name the project MyRSL. Click Finish.

You now have an empty library project. If you already have classes that you want to convert into a SWC file, all you have to do is drag them into the library folder; Flex Builder will compile them into a SWC file for you. In this case, you’ll create a class to use: 1 2 3

NOTE

Right-click the project folder, and create a new class. Give the class a package of com.gunix.myrsl and a class name of MyClass. Extend the Button class by specifying Button for the superclass. Because you learned about objects and classes previously, you should be fairly comfortable with creating a new class. If you need a refresher, see chapter 16.

In this class, you’ll add a simple label to the button; listing 18.1 shows the full code for the class. Listing 18.1

Simple class to use in an RSL

package com.gunix.myrsl { import mx.controls.Button; public class MyClass extends Button { public function MyClass() { super(); this.label = 'Hey Look, I am Dynamically Loaded'; } }

Creates a new label for the button

}

After you’ve done this, it’s always good practice to clean your project. You do this in Flex Builder via the following steps: 1 2 3

Click the Project menu item on the Flex Builder toolbar. Select the Clean option. Clean recompiles your project and creates a new SWC file in the /bin folder, ready to be deployed.

Licensed to [email protected]

383

CHAPTER 18

Advanced reusability in Flex

There you have it; you’ve created your first SWC file. Next, you’ll learn how you use this file in multiple projects.

18.2.2 Making your Flex application use RSL What we’ve done so far is to create a class and compile it into a SWC file. This now gives us the convenience of being able to access the SWC and the classes inside it from any application we’re building. When working on multiple projects that use shared classes like these, it can be useful to store the SWCs in a centralized folder such as C:\Flex\SWC\. This would include not only SWCs that you’ve made but also others that you’ve downloaded. A SWC is a shared library, and it can be linked either statically or dynamically. In the static approach you’re embedding everything inside the SWC into the final SWF, which from an application development perspective is convenient if you have classes and assets (for example, images) that you use across multiple applications. However, this still results in a large SWF file. Dynamic linkage is what makes a SWC an RSL (and thus the cooler approach) in that it’s loading the classes as needed during runtime. Let’s leave our SWC file where it is and create a project that can make use of it. CREATING A PROJECT TO USE THE RSL

For now, leave the SWC file where it is. You’ll create a Flex project and then configure it to use the RSL. Follow these steps: 1 2 3 4

5

In Flex Builder, create a new project called RSLTest. In the project navigator, right-click the RSLTest project and select Properties. Select Flex Build Path (see figure 18.1). Click the Library Path tab to see the external libraries loaded into the Flex application. One of the first things you should always do when you want to use an RSL is to make the entire Flex framework an RSL. To do this, change the Framework Linkage option in the Properties for RSLTest dialog box to Runtime Shared Library.

Doing so creates a SWZ file and a SWF file containing the Flex framework. A SWZ file is a digitally signed Adobe SWF file that can be Figure 18.1 Select Flex Build Path in the cached into the Flash Player. The next time SWC build dialog box. the end user views your Flex application, the load time will be drastically shorter because Flash Player won’t have to reload the Flex framework.

Licensed to [email protected]

Runtime shared libraries

384

But why does Flex Builder create a SWF file when it already has a SWZ file? Framework caching became available in version r115 of the Flash Player. By the time you read this, r115 will be installed on 90% of computers; but Flex also creates the SWF file so that if the end user doesn’t have r115, the SWF file will be cached in the browser and will act like a standard RSL or a cross-domain RSL. One thing to be aware of is that the browser cache is easily cleared by the user, which would require caching the framework again. Next up is turning the myRSL project into an RSL. CREATING THE RSL

Now that you’ve made your Flex framework an RSL, you have to also make MyRSL an RSL. First, you must import it into the library: 1 2 3

Click Add SWC in the Properties for RSLTest dialog box. Browse to the path of your SWC file. Click OK.

You’ll see the MyRSL SWC file added to the application library. But you still haven’t made it an RSL: if you expand the MyRSL tree node, you’ll see that the link type is merged to code. Merged to code isn’t what you want, because it’s the same thing as having MyRSL compiled in the application (via static linkage). Instead, you want to make the SWC an RSL by dynamically linking to it. To do so, continue from the last step and follow these steps: 1

2

3

4 5

Click the link type, and click Edit (see figure 18.2). In the resulting Edit dialog box, select the Use Same Linkage as Framework check box. This option gives MyRSL the same linkage as the Flex framework, which we’ve made dynamic and thus would make MyRSL dynamic as well and ergo an RSL. The Deployment Path/URL is now Figure 18.2 Select the Link Type option, then click the Edit button to change the linkage of a MyRSL.swf. This is the file that will SWC library. be cached by the browser and will be shared by all applications that use this class. Click OK. Click OK in the Library dialog box. Flex Builder will compile the application with the new properties.

You’ve linked your custom class and made it so that it will be cached by the browser and used in all applications that use this class in your domain.

Licensed to [email protected]

385

CHAPTER 18

Advanced reusability in Flex

You’ll need to perform these steps for every application you want to be able to share this class. But when you upload your application to your domain, you’ll need only: ■ ■ ■

One MyRSL.swf file One Framework.swz file One Framwork.swf file per domain

Make sure the path of the RSL is the same throughout your applications, so the Flash Player knows where to check whether the file is cached in order to load it. You’ll see a significant difference in application load times, because the Flash Player won’t have to load the 200–300 KB Flex framework or your custom classes each time you view the application. In the next section, you’ll learn about the next element of making a good SWF file: the module.

18.3 Modular Flex application development One of the neat new features in Flex 3 is that you can develop Flex applications using modules. By using modules, you encapsulate the different parts of your application. A key benefit is modules being independent of one another. If the application has a bug, it’s much easier to locate and fix. The primary difference in using modular programming rather than componentdriven programming is that modules are loaded and unloaded at runtime rather than being compiled in the SWF file. This means your SWF file size is greatly decreased, your Flex application is structured much better, and you can reuse the modules in other applications if you wish.

18.3.1 Components vs. modules As we stated earlier, the main difference between components and modules is the fact that components are compiled in the Flex application and modules aren’t. But you can still do the same things with modules that you’re able to do with components. They consist of essentially the same code, except that a module starts with the tag and a component starts with a tag of the class it’s extending. Following the tag, you’re free to copy and paste your component code, making the module behave exactly like your component. Modules are loaded when the Flex display list sees that the module needs to be shown. For example, if your module is on a different view state (see chapter 13), it isn’t loaded from an external SWF file until the view state is shown. On the other hand, if you’re using a component, it’s embedded in the Flex application. Regardless of whether or not it’s shown, it takes up space in the SWF file.

18.3.2 Creating a simple module Let’s create a simple module that holds a button. Create a new Flex application project, or use the one you previously created, and follow these steps:

Licensed to [email protected]

Modular Flex application development 1

2

386

On the Flex Builder menu bar, choose File > New > MXML Module to open the dialog box shown in figure 18.3. Type the name of the module you’re creating, and specify whether you want to be able to use this module in other applications. If you indicate that you want to use this module only for this Flex application, Flex removes unnecessary classes from the module and optimizes it by making it smaller in size and faster to load. If you specify that Figure 18.3 Creating a new MXML module you want to be able to use the module in other applications, Flex gives the module the functionality of being independent of the application; you’ll be able to use it in other projects. For this example, select the Optimize for Application option.

3

Click Finish.

After you’ve created your module, you’re free to add things like buttons, panels, and canvases—anything you need to create the features or user interface you want. You may wonder how you’ll access data from the module in your application. Flex has a solution called the Module API.

18.3.3 Loading modules the MXML way with the Module API Now that you’ve created your module, how do you use it in your Flex application? Your first instinct might be to go to the component library in Flex Builder, find your module in the Custom folder, and add it. That approach will work. But doing so is the same as using components and doesn’t have any impact on your application load times or size. So how do you load a module in Flex? You can do so two ways. The easier one uses the tag and passes the url parameter the path of your module:

This creates a new instance of the MyModule.swf module and loads it in Flex when the tag is called. This is a good solution for beginners who are just scratching the power of modules, but if you want greater control and the ability to unload modules when you don’t need them, you’re going to get your hands wet in ActionScript.

Licensed to [email protected]

387

CHAPTER 18

Advanced reusability in Flex

18.3.4 Loading and unloading modules with ActionScript Before you learn how to load and unload modules using ActionScript, you need to learn how the Module API works. It’s located in the mx.modules package, and it has one interface and four classes. You don’t have to know the ins and outs of the classes and interfaces, but table 18.1 covers them briefly. Table 18.1

The Module API package

Name

Type

Description

IModuleInfo

Interface

Handler for the module being used

Module

Class

Base class for an MXML module

ModuleBase

Class

Base class for an ActionScript 3 module

ModuleLoader

Class

Similar to SWFLoader but can interact with the module

ModuleManager

Class

Manages the loading and unloading of modules in the Flex application

To load and unload modules, you use the ModuleManager class to manage the ModuleLoader tag. First, create a new ModuleLoader tag in your Flex application and give its id property the value MyModule (see listing 18.2). Listing 18.2

New module using MXML



Run the application, and make sure the module is being loaded; you may see a one-second delay in loading the module, depending on how big it is and what its contents are. Next, create a new button named unloadBtn, and title it appropriately using the label property, as shown in listing 18.3. Listing 18.3

Unloading a module using MXML





Now, create a tag in which to put your ActionScript, and create a function called unloadMyModule().

Licensed to [email protected]

388

Modular Flex application development

In this function, call MyModule’s unloadModule() function (which is a function of ModuleLoader). See listing 18.4. Listing 18.4

Unloading a module using ActionScript


]]>



When you call the unloadModule() function, it tells the Flex display list to remove the module from the Flash Player render list and to remove it completely from memory. Loading the module again is easy: you call MyModule.loadModule(), and Flex loads the module for you. Modules are the most effective way to develop large-scale and small-scale applications. They’re effective in the long run when you need to add new features or remove features because they aren’t dependent on the code in the application and won’t cause bugs.

18.3.5 Pros and cons of modules Modules sound almost too good to be true. Unfortunately, like anything in life, modules have their pros and cons. Figure 18.4 shows some of them and which ones have more impact. As you can see, the benefits of using modules greatly outnumber the consequences of using them. In the next section, we’ll explore how to use the ideas you’ve learned and make patches for your application. Figure 18.4

Pros and cons of a module

Licensed to [email protected]

389

CHAPTER 18

Advanced reusability in Flex

18.4 Adding patches in your Flex application lifecycle As a programmer developing large-scale applications, sometimes you’ll have to patch your application before the next major release. Instead of compiling the application and redeploying the entire application onto your servers, a quick and easy way to apply patches is to leverage the power of RSLs. Recall that an RSL is loaded during runtime in the form of a SWF, cached into the browser, and cached again only if the browser cache was cleared or the file was updated. You can use this to your advantage and have a SWC file called patches that the application checks for updates during runtime. But when you patch something, it usually replaces or updates a class, which isn’t an explicit capability of using SWCs, but there is a neat trick to effectively get the same end result, which we’ll explain next.

18.4.1 Using a SWC to update and replace a class One of the neat features of the Flex compiler is that it will prioritize RSLs to load from top to bottom. Say you have a class in your application that has two functions, and you want to add a third function while updating the other two to take advantage of the new function. You can copy and paste the class in your Flex library project, modify it to meet your needs, and have it create a patches.swc file. Then you can go to your application, pull up the Properties window, and edit the Flex Build Path dialog box (see figure 18.5) to add the patches.swc file. Now you move this file to the top of the list and build your application. By moving it to the top, you make the Flex compiler load the classes in patches.swc and drop any duplicate classes it finds later. This is a good way to get those temporary fixes out before your next major release. During your development process, you’ll sometimes encounter situations where you’ll want to rename parts of your code. In the Figure 18.5 Adding a patches.swc RSL to next section, you’ll learn how to do this with- the Flex Build Path out copying and pasting or rewriting.

18.5 Refactoring Refactoring was a major feature added to the new Flex Builder version 3. It’s a good way to reuse code throughout your applications. It happens to all of us: you start with a small proof of concept, or what was initially scoped as a quick-’n’-dirty application that over time exploded in scope. It results in functions that were named poorly, or that have changed in purpose, and now you want to clean it up.

Licensed to [email protected]

Summary

390

You could hunt down every instance and fix it, which would be time-consuming and inefficient. A global search and replace may work, but that approach isn’t bulletproof and may cause you more grief than it cures. The solution? Refactor! Let Flex Builder do the work: it will rename everything for you, and all will be well. Consider the poorly named function in listing 18.5. Listing 18.5

Bad method name

package com.a.b.c { public class Alphabet { public function Alphabet() {} public function badMethodName():void {} } }

The function is called more than 100 times throughout the application. If this were Flex Builder 2, you’d have to go through your code and rename badMethodName() to goodMethodName() for each occurrence. But by using the power of refactoring, you can do the following: 1 2 3

4

Highlight the function, right-click it, and choose Refactor. Flex Builder displays a refactor prompt. Type a new name for the function. Click Preview. Flex Builder scans your code and shows you all the references it will update, so you can make sure Flex Builder will do the job correctly. Click OK. Flex Builder looks through your code and renames the function and the calls being made to it.

If you’ve never heard the term refactoring before, it may sound amorphous and complicated. The reality is that there’s not much to it; it’s one of the easiest tools you can use in Flex.

18.6 Summary When you’re developing large-scale applications, the size of your SWF file can quickly go from a few hundred KB to one or two MB. You can reduce the size of your SWF file and make your code much more reusable in other applications by using techniques like RSL and modules. You’ve learned how to reuse your code and make your application perform at its best. But even with increased speed, you’ll also want to make your application look good. The next chapter will teach you how to make your application look sexy.

Licensed to [email protected]