WarCry’s exclusive PlayXPert developer journal series continues this week with a look at the widget feature system. SDK Manager Eric Cox gives would-be developers a great look at the broad functionality of the PlayXPert system. Keep reading!
Continuing our discussion of specific features that the PlayXpert platform makes available to widget developers, this month I highlight the “Feature System.” PlayXpert’s Feature System fulfills another part of PlayXpert’s basic internal design philosophy: modularity. You already know that the PlayXpert platform is built around being modular – each widget is a separate module, with separate functions. The Feature System takes this one step further, allowing widgets to make their services and interfaces available to other Widgets. Internally, we think of this as “Inter-widget Communication.”
What if you have a widget that interfaces with an external component and that component’s services might be useful to other widgets in the system? PlayXpert makes it possible for one widget to make this component’s services available to other widgets via the Feature System. A concrete example of this is the Tunes Widget. Recently, one of our community developers was invited to update the basic Tunes Widget to allow it to control other Widgets, to allow the Tunes widget to control different music players through a common user interface. Widgets that implement the “MusicPlayer” Feature can automatically be controlled through the Tunes Widget UI. This allows other community developers to implement music player widgets for other players (I hear that widgets for fubar2000 and others are in the works), all of which can use the Tunes user interface to control them.
In short:
- Widgets tell the PlayXpert core that they implement a certain Feature (“I implement a music player”).
- Other widgets broadcast that they wish to consume, or interact with, a certain Feature (“Does anyone here implement a music player?”).
- The core also allows widgets to register to be notified when a widget that implements a desired Feature is loaded (“Can you call me when there is a music player available?”).
In one of the previous articles, I briefly showed how the core queries a widget for its list of features when it loads a widget. By returning a “MusicPlayer” Feature in that query, a widget tells the core that it implements a music player – essentially it’s telling the Tunes Widget, through the core, that it has the ability to interface with some software that plays music (e.g., Winamp, iTunes, etc.). This happens when the core calls the IWidget method, GetFeatures().
When the Tunes Widget loads, it will register a new “Feature Loader” that will listen for any widgets that are loaded that implement an “IMusicPlayer” interface. A Feature Loader acts almost as a callback – it gets called whenever the specified Feature is loaded. When a new widget is loaded, the core checks the new Widget to see if any existing Widgets are waiting for any of its Features. If so, the Feature Loaders for that Feature are furnished with the IMusicPlayer interface contained within the newly loaded widget.
This method of making data and events available across all widgets opens up a whole spectrum of possibilities. For example, our Twitter widget sends Tweets about game play based on information from our Arcade Widget. In another example, our Arcade widget scans the servers for a particular game by sending ping packets out to each of the servers. The Feature System allows developers to create “headless” widgets that contain code to implement new protocols to scan servers in support of Arcade.
PlayXpert makes it easy to produce and consume services that are made available by other widgets. For more detailed documentation on the Feature System and all of the services that PlayXpert offers widget developers, please visit our website at http://www.playxpert.com
Thanks to the PXP development team for continuing insight into this innovative program.
