This chapter is from the book
This chapter is from the book
This chapter is from the book
UIComponent
UIComponent contains the core functionality and properties that a component may need without the necessity of creating it on a per-component basis. Figure 3.2 shows the inheritance chain of UIComponent. Notice how only FlexSprite and UIComponent are part of the Flex framework, whereas the rest of the inheritance chain Sprite and above are actually part of the Flash Player architecture and, as such, are also available to ActionScript 3.0 in the Flash Authoring IDE.
)
Figure 3.2 UIComponent inheritance chain
Although this has little impact on development techniques or performance per se, it is handy to know because it will hopefully help you become accustomed to the class package hierarchy as you move through this book. The main benefit of knowing this is that you can't optimize player-based classes, like Sprite, but you can optimize code that is purely ActionScript, even to the point of ignoring UIComponent and "rolling your own" component framework.
Something for Nothing
I'm not going to sugar coat this: Using the Component framework increases your application's overall file size. After all, there is a lot of functionality to include that you can hook into. Although, now that you can externalize the Flex framework (including the core component framework) from your main application, that hit isn't so bad. Plus, if you were to re-create all this functionality for your own framework, it wouldn't be that much smaller from a file-size perspective. If you want to pare the component framework right back, extending from UIComponent is probably a good place to start because it contains the core functionality that all components harness.
What does UIComponent actually give you, though? Well, it provides the vast majority of the core component functionality, like event management, low-level user interactions via the mouse and keyboard, including tabbing and focus management. It also manages the component life-cycle phases that you have just read about, as well as being responsible for managing style changes within the component framework, while the vast majority of this functionality is provided as stubbed methods and properties that, in some cases, need to be overridden to provide access to the functionality you require. A large proportion of it is based on class composition as opposed to class inheritance. By this, I mean that instances of other classes are accessed as if they are properties and methods of this particular class. Don't worry if this all sounds a bit alien at the moment; a lot of these classes and how to interact with them are covered in later chapters.
Although UIComponent is the basis for all the components within the Flex 4 framework (Halo or Spark), the major difference between the Halo and Spark components is that all the Spark components are actually extended from an additional set of base classes that extend UIComponent. Granted, you could argue that all the Halo components are extended from additional base classes. However, these were created to provide support for the new layout, grouping, and skinning models that the Spark components employ. The reason that Spark has additional classes, as shown in Figure 3.3, has to do with some of the shortcomings of the Halo component framework in these areas.
)
Figure 3.3 Spark UIComponent inheritance chain
I won't go into detail about these new Spark classes, because they are discussed in Chapter 9, "Manipulating Data," and Chapter 10. With that in mind, let's continue.
With all this, understanding which solution you ultimately adopt is up to you, but I recommend starting with either the Halo or Spark component frameworks so that you can see if you need to create your own components from scratch or if you just need to play around with the classes to understand what classes contain the functionality you need and where they are. Remember that nothing is stopping you from extending or creating any class to add in that missing piece of functionality.
UIComponent for MXML
Something that will become clearer as we start to explore the actual makeup of components is that, although you can subclass your ActionScript components from UIComponent, you cannot do the same with MXML. This is partly because a UIComponent has no visual elements and, therefore, is only suitable as a base class. It is also because, although ActionScript does not support the concept of abstract classes,2 UIComponent is designed with that concept in mind, and therefore doesn't implement the vast majority of the properties it provides to its subclasses, making its use as a base for a component defined in MXML pointless. If this has you scratching your head over what sounds like a limitation of MXML for component development over ActionScript, think about how many components you may create that actually need to extend directly from UIComponent. The likelihood is that you will extend your components from one of the more functional subclasses than inherit directly from UIComponent.
That said, there is one problem that you may face while developing MXML components. If you decide to forego the Flex component framework as a basis for your MXML component, you run into issues when you try to initialize your component. This is because you cannot define a constructor for an MXML component. If you do, you will get a compiler error that your component has duplicate constructors. Don't get this confused with an ActionScript component instantiated via MXML, like the simple Login Panel example in the following listing (see Figure 3.4 for a visual representation of what it looks like).
)
Figure 3.4 MXML Login dialog component
<?xml version="1.0" encoding="utf-8"?>
<s:Panel xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
title="Login">
<s:layout>
<s:VerticalLayout horizontalAlign="center" verticalAlign="middle" />
</s:layout>
<mx:Form id="formContainer" visible="true">
<mx:FormItem id="emailLbl" label="Email:" required="true" >
<s:TextInput id="email"/>
</mx:FormItem>
<mx:FormItem label="Password:" required="true" id="formitem1">
<s:TextInput id="password" displayAsPassword="true"/>
</mx:FormItem>
<s:VGroup id="formButtonsContainer" width="100%"
horizontalAlign="right" verticalAlign="middle">
<s:HGroup id="formButtons">
<s:Button id="registerBtn" label="Register"/>
<s:Button id="submitCredentialsBtn" label="Login"/>
</s:HGroup>
<mx:Label id="forgottenLbl" text="Forgotten your Details? Click here."/>
</s:VGroup>
</mx:Form>
</s:Panel>
What I'm specifically referring to is this: If you don't extend your MXML component from a subclass of UIComponent, you will find it difficult to create event listeners for the core component life-cycle events, like preinitialize, initialize, and creationComplete. Fortunately, Flex has a solution for this. It's called IMXMLObject, and it is an interface that you can implement on your MXML component to provide a hook for the compiler.