Shoutcasting, event models and AS3 – basics

Posted on February 21, 2009


Today I am redesigning the event structure of my new portfolio site. Instead of sketching things out on paper and have things ending up in some stack of paper I decided to put it in a blog post. This is part 1, explaining the basics ot two principles I use:

  1. Shoutcasting – “I do not know where you are or who you are so I simply shout your name and when you hear me you will respond”
  2. Pointcasting – “I do not know nor care where you are, but I know your name and you are in my list, so I call you directly”

Starting points


In the past year I have done several projects where flash-content was created by others. In contrast to code-driven sites (where all assets are placed on stage- and are stitched together via code) these sites were design driven (where all assets are placed on stage and have to be stitched together via code).


Let’s look at the possible strategies to find and address someone within a venue:

  1. Address the person directly. You do need to know what this person looks like and where he or she is, or cal him or her via their cellphone (which is easier). See “pointcasting” for the implementation of that scenario.
  2. Ask around. You only need to know the persons name, but you are dependent of a chain of people and connections. If your strategy is fuzzy, it might take a lot of asking around. If it is focused it will take less time. You are dependent of a chain of people though. When the chain is broken, you will not reach the person you are looking for.
  3. Shoutcasting via an centralized announcement system. It is a bit crude, but you are not dependent of a chain of people nor do you need to know where the person is within the venue.


  1. There is a Central Handler (named CENTRAL in my code)
  2. This Central Handler is a singleton and provides the shoutcast eventlistener model using “subscribe” and “broadcast” to subscribe to and broadcast the occurrence of an event
  3. There is a Smart MovieClip (Flash / actionscript). This “smart movieclip” carries a toolset of handy things I can use for 96% of all smart objects in my proejcts, including: loading and mappng XML data to elements in a Page/Panel/Button, event handlers and shared objects.
  4. There are Panels/Pages and Buttons
  5. Panels/Pages and Buttons use the Smart MovieClip as their basis via inheritance / extension
  6. The Smart MovieClip imports and instantiates the Central Handler
  7. Via the Central Handler, Smart MovieClips have direct access to the eventlistener


  1. Each panel/page is given an unique name.
  2. Each panel/page/button subscribes to one or more events using the following setup:
    CENTRAL.subscribe(“eventtype_”+myPagePanelName , myOnEventDoAction). myPagePanelName will personalize the “eventtype_” event to a specific page/panel or button.
  3. Via XML definitions, the objects recieve “targets” to shoutcast to. “sources” are passed to child objects (like buttons) via code. For instance:
    <XML><button action=”open_panel3″ src=”mySource.xml”></XML> can be shoutcasted as CENTRAL.broadcast(“open_panel3”)

When the user presses the button, only objects named: “panel3” with the subscription “open_” (“open_panel3”) will respond. The code can look like this:

CENTRAL.subscribe(“open_”, onOpenEvent)
// When whatever component fires a “broadcast” with “open_”+ myPagePanelName the onOpenEvent function will be called.

CENTRAL.subscribe(“hideallpanels”, onHideEvent)
// Since it is not named to a specific panel, all panels will respond and hide when this event occurs.

function onHideEvent(evt)
// Hide this panel (and all other panels: on the general “hideallpanels” event)

function onOpenEvent(evt)
CENTRAL.broadcast(“hideallpanels”) // All panels – including this one – listens to this event and will be set to invisible
this.visible=true; // After every panel is hdden:  show this panel


Since there is no need for objects to be aware of each other, the event model stays resonably simple. With only 6 lines of code you hide all panels and show only the panel whose name was “shoutcasted” with an instruction.


With pointcasting, you only address very specific items. In some cases, when loading data into another object, pointcasting might be preferrable above shoutcasting. Again I used a shortcut, by registering every object of relevance into a list, like a phone directory named: CENTRAL.objects.

When using the example of people, again I want to avoid too many dependencies. I do NOT WANT or NEED to know WHERE this person is or what he or she LOOKS like. Like with my mobile phone: when I dial the number I simply want a response, regardless if this person is at home or on the road somewhere.

To get there I use three steps:

Registering a page/panel
CENTRAL.objects[]=this; // Using the name of the (visual) object to register the object reference to it.

Using XML to tie things together
<button action=”loaddata” target=”myTarget” src=”myXML.xml”>

Calling the target object using the settings in XML

How it works:

  1. Each panel/page registers itself in the objects list, using their unique name.
  2. Via XML I tell objects like my buttons where to pointcast their actions to.
  3. Within the Button-class I simply use the objects list in CENTRAL with the XML definitions bound to the button to perform a specific action
  4. When the target object is there, the XML file will be loaded within that object


Using a loosely based structure like this also carries its risks. “What if there is no panel with the name I called?”. In the sample given above all panels are closed and none will be opened. Also, when multiple elements carry the same name there will be conflicts of references will be overwritten by other references.


Shoutcast and Pointcast as described here are two simple methods to address objects within my Flash projects.