From the dark widget ages it was theorised; in the widget revolution it was proved possible; but now moving into the next widget era, it is practical. What am I talking about?
Widget communication.
A Communication History
The first Infosemantics widget to use a form of communication was the Event Handler widget. Initially only one Event Handler widget could pick up a right mouse click at any time. So it was built in that if any Event Handler widget detected a right click, they’d notify all other Event Handler widgets.
The next widget to use communication was the Interactive Drag and Drop widget. This was the project saw the development WidgetFactory communication architecture. To date I’d say the D&D widget is still the best example of widget communication out there. In fact check out our recent eSeminar on the Interactive Drag and Drop widget, in there are a number of good examples of using multiple D&D widgets to make powerful interactions. None of that would be possible without Widget Communication.
So how does it work?
Widget Communication Explained
The Widget Communication architecture is made up of three parties.
- The Widgets
- The Rooms
- The Agent
Let’s meet them.
The Widgets
Meet WidgetBill and WidgetJo
WidgetBill and WidgetJo are best friends. They like to talk very loud, which unfortunately disturbs their neighbours. So they decide to start their own exclusive club, where they, and any other like minded individuals, can ‘dude’ all they want.
First of all, they’ll need a room for their club to meet.
The Room
So Bill and Jo go ahead and design their club’s board room.
It may not come as a surprise to you that neither WidgetBill nor WidgetJo possess the craftsmanship skills to build their own room. So they search for an Agent.
The Agent
WidgetBill and WidgetJo manage to find an agent willing to take on building their room.
So the Agent goes away and does the following.
- First of all, he checks there are no similar clubs in the district that WidgetBill and WidgetJo could join instead. If there are none, he builds their room to spec.
- The agent inducts WidgetBill and WidgetJo into the room’s member list (which all rooms have by default).
- He gives WidgetBill and WidgetJo directions to their new room.
And finally WidgetBill and WidgetJo have their own private room to communicate about anything they want.
The End!
Wha-?
Okay, dudeish metaphors aside, what’s really going on?
The ‘widgets’ we’re talking about are different widget instances in the exported Captivate runtime. They need to be able to communicate with each other without disturbing other widgets, so they create what’s called a Widget Room.
There are two types of rooms: Regular Rooms and Slide Rooms. Regular rooms can be joined by widgets anywhere in the Captivate Movie. Slide Rooms can be joined only by widgets on the same slide as the room’s attached to.
Now widgets can’t build the room themselves, because the two widget would end up creating two separate rooms that only they could join. So they pass the job of building the room off to the ‘agent’.
The agent takes information about the room and uses it to check if another room already exists with the same details. If there is no room, then the agent will create one. If there is a room, then it most likely exists because previously another widget asked the agent to create the room and that widget is now eagerly awaiting the arrival of the other widget. Now that the agent is in possession of a room (pre-created or otherwise) it adds the widget to the room’s member list, then passes back to the widget a reference to the room.
At the end of the day, the whole process is just a safe way of ensuring the two (or more) widgets have a reference to the same room object.
So on a conceptual level that’s how Widget Rooms work.
In the next post I’ll show you how to code your widgets in such a way as to create and join a room.
If you can’t wait till then, I suggest you check out the WidgetFactory documentation and look at the classes under the widgetfactory.communication package.
Until then, PARTY ON DUDES!