Give us a call 203-379-0773

Flextras has moved Servers

We have just completed a move of this server from our old hosting provider onto an Amazon EC2 server. If you find any problems, please be sure to let us know.

How does one Flex Component talk to another Flex Component?

I think there is one question that has come up hundreds of times on Stack Overflow. The question is "How does one Flex Component call a method in another Flex Component?" or some variation thereof. Sometimes people want to access something in the main application, sometimes they want to access something inside an itemRenderer, other times they want to access another child of a ViewStack. No matter the purpose, I feel it is time I create the most detailed answer to the question I can.

The Setup

First let's pretend you have a setup like this:

Click the image to see a larger version.

Something like this would not be uncommon in an application you were building with Flex. At the root of everything in a Flex Application is your main Application file, usually extending s:Application or mx:Application.

Inside the application contains two main components, ComponentA and ComponentB. These could represent two separate pieces of the app and are never showed together at the same time. Or they could represent two different components that are both shown at the same time and make up a single screen.

Inside Component A, is a ViewStack with three children. ComponentB contains a list class, which could be a List or a DataGrid or something else. The List class uses an itemRenderer. Many beginner developers make the mistake of thinking that the itemRenderer represents a single component; however a new instance of the itemRenderer is created for every item displayed in the list. It is an important distinction that many people do not understand.

The implementation of an application like this could be done across many different files or it could be done in a single MXML file. When creating a single MXML file, the parent child relationship can be hidden from the beginner, because it looks like the main application is the parent of every child. It is important to remember the true component hierarchy when thinking about how components should interact with each other.

Events Communicate Up

Many questions relate to executing a method in their parent from a child. For example, what if you want to change the selectedIndex of the ViewStack from within Child1? Perhaps you're building a multi-step process and the user just clicked a 'next' button. Or perhaps the user was viewing data in a DataGrid and clicked an 'edit' or 'more details' button that is supposed to open up a new screen with additional information. All these are valid use cases. So, how do you do it?

From an encapsulation stand point, a component should never try to execute methods in its parent. Doing so gives the component a dependency upon the parent; thus minimizing reuse. The child component cannot then be used as the child of a component other than the parent

The solution for a component to tell its parent to do something is to use events. An event is dispatched from the component to its parent. The parent will listen to events from its child and execute handler methods to perform some functionality. Flex makes use of this model all over the place such as the click on a button or the input of keystrokes into a TextInput.

The code isn't that difficult. First create an event class:

var myEvent = new Event('myEventType');

And then dispatch the event:

dispatchEvent(myEvent);

If you need to send custom data with your event; you can create your own event class to do so; but I decided to keep such details out of this article. For bonus points you can use metadata to define your event as part of the class. This is primarily used for code hinting within an IDE and does not affect things at runtime. This is sample event metadata:

[Event(name="myEventType", type="flash.events.Event")]

You can put that metdata before the class definition if you have an ActionScript class; or as part of the fx:Metadata tag in an MXML class.

Dispatching the event is only the first step, though. The parent is going to have to add an event listener to it. In MXML this is easy, as the event will show up as if it were a property on the component, like this:

<ns1:Child1 myEventType="myEventHandler(event)" />

If you want the above method to work, you'll need to add in the event metadata. However, if for some reason you don't want to create event metadata, you can also add listeners in ActionScript. You use the addEventLIstener method on the instance of your component. The instance is named by using the id tag in MXML or the variable name in ActionScript:

myChild1.addEventListener('myEventType',myEventHandler);

Either method for adding an event listener will call a method, known as the event handler:

protected function myEventHandler(myEventHandler:Event):void{
// do stuff here
}

Events are the proper way that a component can communicate with its parent. If the component is on the display list; the events can also bubble. Using our example, if myChild1 dispatches the myEventType; first the ViewStack event handlers will execute. If ComponentA added a listener on the ViewStack for the myEventType event; that will execute next. If the main application had an event listener on ComponentA for the myEventType, that event handler will execute next.

Event bubbling is the proper way for a renderer to communicate with the parent of its List. Dispatch an event from the renderer, make sure it bubbles by setting the bubble property of the event's constructor to true, and then listen for the event on the List.

Inside the renderer, you create the event, with the bubble flag to true and dispatch it normally:

var myEvent = new Event('myEventType', true);
dispatchEvent(myEvent);

In ComponentB you can add an event listener to your List class:

List.addEventListener('myEventType', myEventHandler);

You won't be able to add the event listener in MXML unless you extend the list class to include custom metadata as we showed above. But, even without metadata the event will still bubble and the event listeners will still execute.

Methods Communicate Down

Events are how a component should communicate up to its parents. But, how does a parent communicate down to its children? There are two different ways, either by executing a public method on the child or by changing properties on the child. Public methods and properties make up the API which a component expects its parents to use to control its behavior.

Creating a public method is no different than creating an event listener, like we did above. It just uses a different access modifier, specifying public instead of protected:

public function myMethod(argument:ArgumentType):void{
// do stuff here
}

You can specify as many arguments as are needed to perform the method functionality. A good example of this is the addEventListener method. That is a method built into Flash's architecture, but you can write your own methods using the approach above to perform your own functionality. The Flextras Calendar component, for example, has a method to change the view between month, week, and year.

A component would call this method on the instance of the component, specified by the MXML ID. So, if the ViewStack component wanted to call myMethod on the Child2 it would do this:

myChild2Instance.myMethod(myArgument);

Methods can return things by specifying the return type in the method signature. Our example above specifies the return type as void, which means the method doesn't return anything. Here is another method which returns a Boolean value:

public function myMethod(argument:ArgumentType):Boolean{
// do stuff here
// return result
return true;
}

The code you put inside the method, the arguments you choose, and the return value will all depend upon the functionality you want to achieve in the method.

Properties Communicate Down

Changing properties values are the second way that a parent can communicate with its child. As one example, a component's position in the display list is defined with the properties X and Y. The labelField on a list, or the selectedIndex property on a ViewStack are other examples of properties. Properties are implemented as public variables within a component.

They can be implemented with a simple variable definition:

public var myProperty :MyType;

This is the easiest way to create a property on a component. You can also create properties using a special set of methods, named get and set methods. If you want to perform other functionality when setting, or retrieving the value of your variable, then getter and setters are what you need. This is a common implementation:

private var _myProperty :MyType
public function getmyProperty():MyType){
return _myProperty;
}

public function set myProperty(value:MyType):void{
_myProperty = value;
}

The simple public variable becomes private; and the API for setting or retrieving these methods lie within the get and set methods which access the private value. It is very common in the Flex Framework for a set method to be used to dispatch a change event for the component. If you want a property to be read only, you can leave out the set method.

Whether implemented as simple variables, or with get/set methods, properties are accessed identically from the component trying to change the property. For example if ComponentB wants to set the selectedIndex on the List it would do this:

list.selectedIndex = 1;

It doesn't matter how the list has implemented the property for selectedIndex. This is a form of encapsulation I call implementation hiding. One component does not need to know how another is implemented. It should only communicate with it through its public API. The API is defined through documented properties, methods, and events.

Other Thoughts

Components that are on the same level of each other, such as Child1 and Child 2 should not communicate directly with each other. The proper way to have Child1 affect Child2 is to dispatch an event from Child1; have your ViewStack component listen to the event and call a method, or property, on Child 2.

There are other methods for sharing data between components, such as using Dependency Injection to share class instances between components. Another may be to use a Singleton class. Many frameworks exist to help with these things, but it is beyond the scope of this article. Your key takeaway from this article is that the use of events, properties, and methods can help you create robust, reusable components within your application.

Flextras Components Go Open Source

I sent this out to folks on the Flextras Newsletter a bit earlier in the month, but here comes a formal blog announcement.

Flextras Components Go Full Open Source

You can get the most recent source code for all our components, under an Apache License, from the Flextras GitHub account. This includes our Calendar, the Flex AutoComplete component, and the mobile component set. The Mobile Component set includes a Flex mobile DropDownList, a mobile AutoComplete, and a handful of other components.

If you don't want to build the source yourself, binary builds are still available for download the Flextras web site, along with our documentation and samples.

What about Flextras Customers?

If you're already a Flextras customer, you'll still be eligible for complimentary support, as we have always provided. If you're not a Flextras customer yet, we will be more than happy to provide you with support at a cost. This can be done on an hourly basis, or through extended consulting engagements depending on your need.

Final Thoughts

I've spent the past five years of my time devoted to Flextras and being part of the Flex Development Community. It would be fantastic to see lots of people do great things with my component legacy.

If you want to say thanks, or if you need help, be sure to contact us. We'd love to hear from you and will be here when you need us.

Kickstarter Plans for Flextras AutoComplete - 12/7/2012 - Episode 150 - Flextras Friday Lunch

I took last week's Flextras Friday Lunch session, to talk about the changes I Want to make to our AutoComplete as part of our Kickstarter, if the Kickstarter project gets funded. There are only a few more days left and a long way to go, so if you're interested in this project, we're running out of time to fund.

Flextras Friday Lunch is a short demo followed by open Q&A that occur the first and third Friday of every month at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

A look at our AutoComplete Code - 11/21/2012 - Episode 150 - Flextras Friday Lunch

This wasn't quite a Flextras Friday Lunch, since I held it on Wednesday. But, I used the same infrastructure. This time I demonstrated our AutoComplete component, and took a look at the code that lies behind the component. Since I did have the recording, I thought I'd post it here.

Flextras Friday Lunch is a short demo followed by open Q&A that occur the first and third Friday of every month at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Check out the Flextras AutoComplete KickStarter

Did you ever wish that the Flex Framework had a native Autocomplete Component? Do you wish you had easier access to the source of the Flextras AutoComplete? Do you want to help make those things happen?

Now you have a chance to answer all three questions as a yes.

We have launched a KickStarter campaign to do just that. If funded, we are going to expand the API of our Spark AutoComplete and donate all the code to Apache Flex.

This is an experimental approach to funding our love for creating Flex components. If you like the idea, then go check out the Kickstarter and let's make this happen.

Flextras Friday Lunch – Hiatus

It is said that all good things must come to an end, and I have decided to discontinue the Flextras Friday Lunch sessions for the time being. The Flextras Friday Lunch ran for 150 episodes over the course of four years.

I used the live screencast medium to demonstrate many samples related to Flex and mobile development. The short demo sessions were followed up by Q&A and we talked about everything from Flex development, to business models, and to the mobile device revolution.

These sessions took time to prepare, and were mentally exhausting to do; I blocked out all of Friday morning to prepare and usually took it easy for the rest of the day. If you go "by the business" then I'm pretty sure that blog posts brought a lot more traffic--and registrations--to the site than these sessions. But, I greatly enjoyed doing them, which is why I kept them up.

Now I plan to reclaim my time to focus on other pursuits. As I know more, you can expect to hear more about them in this blog as such endeavors come to a point where there is something worth sharing.

Thanks to everyone who participated in, or watched a recording of, a Flextras Friday Lunch live session. I hope you enjoyed them as much as I did.

Using SQLLite with AIR - 9/14/2012 - Episode 150 - Flextras Friday Lunch

In this session, I talked about using SQLLite with AIR and some techniques to make that work. We also talk about language choice and approaches to updating data.

Flextras Friday Lunch is a short demo followed by open Q&A that occur the first and third Friday of every month at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Flash Builder 4.7 First Look - 8/31/2012 - Episode 149 - Flextras Friday Lunch

This week I share some of my first thoughts about Flash Builder 4.7.

Flextras Friday Lunch is a short demo followed by open Q&A that occur the first and third Friday of every month at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Spark DataGrid - 8/24/2012 - Episode 148 - Flextras Friday Lunch

This week I demo the Spark DataGrid.

Flextras Friday Lunch is a short demo followed by open Q&A that occur the first and third Friday of every month at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

More Entries

garcinia cambogia reviews

payday loans online

seo services