Difference between Array and ArrayCollection in ActionScript 3.0

Hi All,

Recently I got a query asking the difference between Array and ArrayCollection in ActionScript 3.0.

Let me draw quick comparison between Array and ArrayCollection:

1. The elements of the ArrayCollection can be used in bindings that will be continued to be monitored. This is not the case with the normal Array class, once the element from an array is used in a binding, it is no longer monitored.
2. ArrayCollection provides a rich set of tools for data manipulation

So what does all that mean?

According to the Adobe flex liveDocs

The ArrayCollection class is a wrapper class that exposes an Array as a collection that can be accessed and manipulated using the methods and properties of the ICollectionView or IList interfaces. Operations on a ArrayCollection instance modify the data source; for example, if you use the removeItemAt() method on an ArrayCollection, you remove the item from the underlying Array.

Let me take an example to clear this concept.

Say we receive some data through some webservice. Now if we parse the result set into Array, we have only a few tools to manipulate data namely, push() (for adding an element to the end), pop() (for removing the last element), length (the number of indices), etc.

However, the ArrayCollection class provides a suite of immensely convenient "extra" methods that can act on the Array namely the addItemAt(), removeItemAt(). So using these methods, we can directly access any index value of an array.

Apart from that, we can continuously watch the array for any changes at run time. Say, some user operation deletes a value from my ArrayCollection or Add a new item in my ArratyCollection which I am using as an dataProvider for a data grid. In that case, I can see the node getting disappear or visible at the same time.

This can’t be possible in the case of an Array.

This makes filtering of data as simple as eating a cake :)

HTH

Let me know if you have any doubt.

Thanks,

Shaleen Jain

Item Renderes: Part 1: Introduction

Lets start with the definition of the term item renderers and item editors

According to me:

Item renderes and item editors are set of instruction or a piece of code which customize the appearance and/or behavior of items in list based components.

Sometime people get confused between item renderers and item editors.
So, before going further, Let me draw a comparison between them

Item rendere versus item editors

• Both item renderes and item editors receive data in a data property from a list contol

• The item renderer uses the data for purly for display and can't pass back data to list controls while item editor can pass data back from the controls that then becomes the new value of the edited items

• Visually item renderes and item editors behaves differently and item renders is used all the times while an item editor is used only when item is being edited

Item Renderers and item editors could be of following three types:
1. Drop in
2. Inline
3. Component

Drop in item renederes and item editors
When you specify a control as a value again itemRenderer or itemEditor property of the control it would be called as a drop in item renderer or item editor

Example:
As item renderer

<mx:DataGridColumn dataField="completed"
     headerText="Completed"
     itemRenderer="mx.controls.CheckBox"
     />

As item editor

<mx:DataGridColumn dataField="quantity"
headerText="Quantity"
itemEditor="mx.controls.NumericStepper"
editorDataField="value"/>

Inline item renederes and item editors
when we write item renderes and item editor within a DataGridColumn tag block using
and tag respectively they are known as inline item renderes or editors.
Example

Inline Item Renderes

<mx:datagridcolumn datafield="someData"&gt
<mx:itemrenderer>
    <mx:component>
        <mx:Text selectable="false"
            text="{dataObj.name}"/>
    </mx:Component>
</mx:itemRenderer>
</mx:DataGridColumn>

Inline Item Editor

<mx:datagridcolumn datafield="someData">
<mx:itemeditCoor>
    <mx:component>
        <mx:NumericStepper minimum="0"
            maximum="10"/>
    </mx:Component>
</mx:itemEditor>
</mx:DataGridColumn>

Component Item renderers and item editors
When a inline item renderer get complex, its better to make it in a separate file as an independent component. When we do so, it is know as component item renderer or item editor.
It 0pen almost a new paradigm of opportunities which lets developer ease of resume and provides greater flexibility and functionality.

Example:

Make a separate file say myFirstItemRender.mxml

<mx:DataGridColumn dataField="someData" itemRenderer="myFirstRenderer.mxml"/>

Don't forget to mention the folder if of you component file if their is any. Say you saved all your renderes or editor files under renderers folder then you should include it like this:

<mx:DataGridColumn dataField="someData" itemRenderer="renderers.myFirstRenderer.mxml"/>

We will discuss about these various types of item renderers and item editors with a lot of other things in detail with coming series of articles on this topic.

Hope you enjoyed reading this article.
I would be interested in your feedback about this article.

Thanks,
Shaleen Jain

Item Renderes & Item Editors

Hello Friends,

Today I decided to write an article on item renderers & item editors.

When I started writing, I felt it is not possible for me to write everything in on go.
So, I decided to write a series of articles on item renderes & item editors.

Stay tuned to watch out the series.

Also if you show your interest by commenting on the topic, that would boost my interest in continuing this series.

Thanks,
Shaleen Jain

Efficient Component Layout

I recently worked on a project where there were problems getting the components to fit properly, align, and stretch were necessary. Here are some tips to making it easier to layout your application.

First, diagram what you what. Here is a layout that could be more optimized:

<mx:Application>
 <mx:VBox>
  <mx:HBox>
   <custom component 1>
  </mx:HBox>
  <mx:HBox>

   <custom component 2>
   <mx:VBox>
    <mx:ViewStack>
     .. stack children ..
    </mx:ViewStack>
   </mx:VBox>
   <custom component 3>

 </mx:VBox>
 <mx:HBox>
  <custom component 4>
  <custom component 5 >
  <custom component 6>
 </mx:HBox>

</mx:Application>

This layout can be made more efficient in a couple of ways. First, remember that <mx:Application> lays its children out vertically, so using a VBox inside of it is redudant. The same holds true for <mx:Panel> and <mx:TitleWindow>.

Second, any container with one child is unnecessary. All that you are doing is causing the Flex LayoutManager to do more work.

Here is the same application with a more efficient layout:

<mx:Application>
 <custom component 1>
 <mx:HBox>
  <custom component 2>
  <mx:ViewStack>

   .. stack children ..
  </mx:ViewStack>
  <custom component 3>
 </mx:HBox>
 <mx:HBox>
  <custom component 4>
  <custom component 5>

  <custom component 6>
 </mx:HBox>
</mx:Application>

The first <mx:VBox> was eliminated because it was redudant. The first <mx:HBox> was eliminated because it was unnecessary (it had only 1 child). The same is true for the inner <mx:VBox> that contained the <mx:ViewStack>.

Another layout concern is when and where to place width= and height= specifications. As a rule of thumb, I do not place those values in the component definition. For example, in the definition for CustomComponent.mxml:

<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="100%">
 .. contents ..
</mx:VBox>

Placing the width= and height= parameters here means that this component will always try to take up all of the space in whatever container it is occupying. My rule is to let the parent component decide how its children should be positioned and sized:

<mx:HBox width="500" height="400">
 <CustomComponent width="100%" height="50%" />
 <OtherComponent width="100%" height="50%" />
</mx:HBox>

Placing the size attributes in the parent lets you easily reuse the component.

Another problem I see is when to use the width= and height= attributes. Take this MXML snippet:

<mx:HBox>
 <CustomComponent width="100%" />
 <OtherComponent width="100%" />
</mx:HBox>

This will have a layout problem because the <mx:HBox> has been given no size. You may think that the <mx:HBox> will take its size from its children, but that is not always the case. You may see scrollbars appearing where you don't want them or components not occupying all of the space.

Suppose the <mx:HBox> above were meant to fill the remaining space of its parent? Without specify width= and height= attributes on the <mx:HBox>, you will get unexpected results.

This is better:

<mx:HBox width="100%" height="100%">
 <CustomComponent width="100%" height="100%" />

 <OtherComponent width="100%" height="100%" />
</mx:HBox>

My other rule of thumb is to always specify width= and height= attributes. This helps the Flex LayoutManager be more efficient and it gives you more control.

Always specify sizes, even for GridItem and GridRow tags.

You can also use <mx:Spacer> to help you out. On the project I mentioned above, the <mx:Grid> was used to create a control bar. There were two parts: a right side and a left side. So the developer used a <mx:Grid> with a single <mx:GridRow> which contained two items: one aligned left and the other aligned right. This worked, but the <mx:Grid> is pretty ineffcient. A better way to lay this out is:

<mx:HBox width="100%" height="26" horizontalGap="2" marginLeft="3">
 <control 1>
 <control 2>
 <mx:Spacer width="100%" />
 <control 3>
 <control 4>

</mx:HBox>

This uses an <mx:HBox> and a <mx:Spacer> in the middle taking up the remaining amount of space. So the Flex Layout Manager places the first two controls in the HBox on the left, then places the other two controls on the right, and fills the remaining space with the spacer.

I threw in some other attributes on the <mx:HBox> in case you weren't aware you could use them. The horizontalGap= attribute will make sure there are only 2 pixels between the items and the marginLeft attribute makes sure the first control is 3 pixels from the edge on the left.

From a performance perspective, it is best to use absolute pixel sizes and positions. But this isn't always possible and certainly, it doesn't make applications resizable. So compromises can be made. If for example, you know that a text field will be 200 pixels wide and 26 pixels height, specify that. If want the text field to occupy the width of its container, then use 100%.

In conclusion, when you are creating a component or application, follow these rules:

First, diagram your layout.

Second, remove controls that are redudant, especially <mx:VBox> containers as immediate children of <mx:Application>, <mx:Panel>, and <mx:TitleWindow> as they place their children vertically by default.

Third, identify containers holding only a single child. All Flex components can be sized and most have the same attributes. Do not think you need a container just to a particular attribute, especially when the child of the container is itself extending a container.Than

Finally, make sure you specify width= and height= attributes on all components. Use pixel sizes if possible. And use the <mx:Spacer> to take up room between components rather than introducing extra containers.


Thanks,
Shaleen Jain

What is mx_internal?

Here, I am going to tell you about the mx_internal namespace. You often come acrosss this work when you open any flex component.  I have used mx_internal namespace a couple of times, but I swear to god I have never understood what it means or why it is used. So I decided to plunge in a little bit and make some sense out of it.
So I decided to plunge in a little bit and make some sense out of it.

Before I get to that, it makes sense to discuss a little bit about namespaces. Namespaces are essentially used to limit the scope of methods, classes, variables or constants. One could say that they are used to avoid potential naming conflicts that may arise with other components having the same names. Namespaces are associated with a Uniform Resource Identifier that identifies the namespace. You can find more information on namespaces here.

Now, mx_internal is one such namespace that the Flex SDK uses to handle internal data. Just like all other namespaces, mx_internal contains a lot of variables which we can use in our code. To know which variables belong to mx_internal, dig into the Flex SDK code and you can find them. An example of the use of mx_internal can be found in the TextInput.as class of the Flex SDK. Some commonly used mx_internal variables/methods of this class are:

/**
* The internal subcontrol that draws the border and background.
*/
mx_internal var border:IFlexDisplayObject;

————————————————————————————–

mx_internal function get selectable():Boolean
{
return _selectable;
}

To you the mx_internal namespace, just import it and let Actionscript know you are using it.

import mx.core.mx_internal;

use namespace mx_internal;

You are then ready to use the variables of mx_internal.

Of course there are some issues with using this namespace. First there is no code hinting in Flex Builder when using this namespace. That means you have to dig yourself to know which variables are present in the namespace. Second, Adobe has mentioned this warning with using the namespace.

“This namespace is used for undocumented APIs — usually implementation details — which can’t be private because they need to visible to other classes. APIs in this namespace are completely unsupported and are likely to change in future versions of Flex.”

That means that the next time Flex updates happen and your code doesn’t work as it is supposed to, don’t blame Adobe.

Thanks,
Shaleen Jain