I'd say that for as long as the UI at hand can be expressed as a media element, it can be a plug-in. One example, is an overlay "play" button: this could be thought of as a piece of media that would be playing in parallel of the media element who's playback it'd be controlling.
Can you explain this a bit more indepth?
Are you saying that playbutton overlays should be worked with as parralell media elements that control (how?) the media elements it is parreleled with, or are you just suggesting that this would be a method of making UI elements into a plugin?
Yes, that's sounds good to me.
Serial Media ( pre, mid, postrolls, video.... )
Parallel ads and visual objects showed at the same time like a UI...
But, there's any example somewhere?
Off the top of my head, we don't have an example laying around, but we'll try to whip one up in the next few days. (If we don't, please respond to this thread to apply some pressure. :-)
A minimal and working example with such UI dynamic(that really loaded) plugin is really needed.
How about a little bit of pressure?
I'm developing a dock for a player as a plugin. I think ( reading the osmf docs ) I should create a parallel reference plugin with a view ( the dock ).
I'd appreciate if you could have something soon!
Thanks a lot!!!!
By popular demand, we proudly present you the control-bar-as-a-plugin sample . It consists of two projects: one defines a plug-in, and the other a small test-application that uses it:
I'll start with a helicopter view of what's in both projects:
The plug-in project consists of two AS files:
This class is the plugin SWF's document class. It defines the mandatory pluginInfo getter method that the framework uses to obtain a PluginInfo reference. Furthermore, it defines two callback methods: canHandleResourceCallback, invoked when the framework needs to know if a plug-in can construct a media element for a given resource type, and mediaElementCreationCallback, that is invoked when the framework is requesting the plugin to provide a media element instance. The latter returns a ControlBarElement that is defined in the other class:
Contains the definition of the MediaElement based, control bar displaying object. The object borrows the actual control bar implementation from the ChromeLibrary (http://opensource.adobe.com/svn/opensource/osmf/trunk/libs/ChromeLibrary). It exposes the control bar's Sprite by adding a DisplayObjectTrait to the media element. This is the sole trait that the element implements.
The plug-in test project also holds two files:
This is a utility class that implements much of the boiler plate code that's required on setting up any OSMF application. We're trying it out for size to see if this might be something we could be adding as a utility to the framework itself.
This is the main tester application. Using OSMFConfiguration, a plug-in manager is requisted to load ControlBarPlugin.swf. Meanwhile, a parallel media element is setup that will act as the root of the aggregate media that will be played back. The first child added, is a video that plays an OSMF logo animation. Once the plug-in is loaded, the second element is added: a control bar media element, instantiated by the code on ControlBarPlugin.swf.
That's what the projects do at a high level. There are a number of specifics that require some additional explenation, that are perhaps best addressed by a small Q&A:
Q: This code doesn't seem to actually load a SWF at all!
A: That's correct: the code that's in the repository is set to link the plug-in in statically. This is to make debugging easier (for loading the plug-in from a swf locally in the debugger will fail due to sand-box restrictions). To test the plug-in truely being loaded from its SWF, both projects should be uploaded to a server. When doing this, make sure to uncomment the private static const pluginResource:URLResource.. line that's at the bottom of ControlBarPluginTest.as.
Q: How can the media factory be magically returning the controlbar on just passing it a resource with some metadata?
A: When the plug-in loaded, it registered itself with the media factory. When the factory is asked to create an element for the given resource, it will go over all types and plug-ins that registered with it. Ultimately, this results in the aformentioned canHandleResourceCallback method in ControlBarPlugin.as being invoked. The implementation of that method, returns true if it finds the resource to have a metadata facet that goes by the namespace defined in NS_CONTROL_BAR_SETTINGS. Since the method returned true, the framework will ask the plug-in to instantiate a medial element, next.
Q: How does the control bar know what media element it should operate on?
A: ControlBarElement extends MediaElement, but in addition, it implements the IMediaReferrer interface. Any media element that implements this interface can be informed of existing, and new elements being constructed by the media factory that it created it. To this aims, the element implements the canReferenceMedia, and addReference methods. The first method learns the framework what sort of media elements the element is interested in receiving addReference method calls for. With the sample, canReferenceMedia's implementation will only return true for media elements that have a metadata facet that goes by the namespace defined in NS_CONTROL_BAR_TARGET. In the tester application, this specific tag is being added to the constructed video element. The last step in matching what media element the control bar should control, takes place inside the control bar element's addReference method: as soon as an element comes by that carries the same ID that is set on the element's own ID from NS_CONTROL_BAR_SETTINGS, than the element gets assigned as the control bar's target element.
Hope this will be helpful in getting started on creating UI plug-ins!
We were stucked!
I'm sure you understand the better the documentation the greater the success of the framework.
I'll put my hands on the code right now!
I tried setting up the ControlBarPluginSample Project but it didn't work. I get the following errors:
1046: Type was not found or was not a compile-time constant: IMetadataProvider. ControlBarPluginTest/src ControlBarElement.as line 115 1266433027065 412511046: Type was not found or was not a compile-time constant: PluginManagerEvent. ControlBarPluginTest/src ControlBarPluginTest.as line 47 1266433027010 41249Where are these classes? Why aren't they in the latest SWC?Please halp!
The sample is written agains the OSMF library version that's currently in the trunk. Could it
be that you have downloaded the sample from the trunk, but are linking against the sprint 9 OSMF library? If so, syncing up to the library that's in the trunk should fix the errors.
yes that worked , however, it seems many of the classes in previously supplied sample apps are no longer supported... this makes it extremely difficult to get up to speed on this framework. I think it's a great framework but how can we use it/learn it if the code base changes so drastically? Keep up the good work anyway.
Glad to hear that did the trick!
I understand that it can be cumbersome to see API changes, and having to sync-up. We're doing our best to finalize the APIs as soon as possible. I think that with Sprint 10 the vast majority of APIs will be frozen.
Awesome, I look forward to a more a stable future of OSMF. I do have one question in the meantime. In your control bar example, what is the significance of the
constants? They point to URLs however when I try to navigate to either of them, I get a 404 error.
I also have a question regarding the use of plugins. What is the benefit to using a Plugin implementation as opposed to just building the player using tools provided by the flex framework?