Flex Builder has been rebranded as Flash Builder in Flex Sdk 4 release

Hi All,

It is one of the most shocking news I came across recently. Yes it is true that Adobe has taken a final decision on rebranding the Flex builder.

Before writing any further, I like to share one email communication which I recently had with Adobe Team.

The content is as follow:

Shaleen Jain wrote:

Hi Adobe Team,

I do not see the decision of rebranding the flex builder to flash builder as a reasonably good decision.
My belief is that, it will discourage new java and flex developer.

Customer is now believing that flex is different from flash in the sense that flex is basically for enterprise application.
Flash is considered considerably at a lower level when comparing with flex.

Client, developing mission critical application will have faith in flex but that can be deteriorate when we start calling flex to flash.

I am working in Flex since 2005. Initially I was not sure what will be the future of flex. Adobe team then clarify that Flex is specially meant for developing RIA which will be run on flash player and it is not flash. I just want to remind Adobe team is that, the decision to make flex and NOT flash is that, Adobe want to attract developer from other technologies(especially Java) because they don't want to be called as designer.

But now when flex is picking up the pace and leading other RIA technologies we are rebrading flex to flash again.

I hope this decision will ruin the image of Flex in the market.

Further to that, developer generally don't prefer to be called a flash developer rather than flex developer ( At least I will never prefer to be called one).

Hope you may want to reconsider the decision to rebrand flex builder to flash builder in the interset of Adobe, their investors and Flex community.

Warm Regards,
Shaleen Jain

Adobe's Reply

Hi Shaleen:
Unfortunately at this time the decision to rebrand has already been made and is final. You can read a good summary of many of the issues you talk about in Lee Brimelow’s blog, at http://theflashblog.com/?p=998

Thanks for your comment!

Mike


I will write more about this very soon.

Thanks,
Shaleen Jain

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

Adobe® Flex™ Builder 3 Pro for Education.

Ad0be is providing free serials for flex builder for educational purpose

To receive the product, you must upload a valid proof of eligibility to get the serial numbers to activate the product. Valid proofs of eligibility are:

   1. a student ID showing current enrollment,
   2. a Faculty ID showing current employment
   3. an employee ID showing current employment, or
   4. a letter on an educational institution letterhead stating that you are either a current student,        a current faculty member or a current employee of the institution.

On the page that opens, accept the terms and click "Student"

On the next page, fill in all fields. There is a special field in this form: Student ID.They ask for a copy of a proof of registration or any document to prove their academic home. 
After uploading the image or PDF, click submit.

Now, Adobe will evaluate and, if approved, will send the serial via email within a maximum of 3 days.

To get the serial, Register with Adobe (the registration is free)

https://freeriatools.adobe.com/flex/

I got this piece of information from flex group and think of just spreading this through my blog so that community can take advantage of this.

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

Adobe AIR passes 100 Million Installs

Adobe has just announced that the AIR platform has passed 100 Million installs. You can read more about this on the Adobe AIR Blog.

In addition, Flash Player 10 has been installed on 55% of computers worldwide.

The article describes how these numbers were determined.

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