Sure, Good questions. I'll give it a shot. The MediaPlayer is the faceless (i.e. doesn't inherit from a DisplayObject) controller for media compositions. The MediaPlayer takes all of the Trait APIs, such as playable, pausable, and seekable, and makes them easy to use, in a central class. It also adds looping, autorewind, stop, and a few other convinient methods.
The MediaPlayerSprite is basicly a DisplayObject for a MediaElement, with a MediaPlayer attached. The MediaPlayerSprite lays out the media, and allows it to be added to the stage quickly and easily.
The MediaElementSprite is just like MediaPlayerSprite - except it doesn't automatically come with a media player. It's use case is media that needs a DisplayObject, but no media player controller.
One more class I should mention - we have yet another UI class RegionGateway, which was made to integrate into the layout system. The MediaPlayerSprite and MediaElementSprite may be merged into the RegionGateway, to make a consoldated UIComponent. This work hasn't taken place yet, but will happen in the next few sprints.
My recommendation for the present is to use the RegionGateway, since it is the newest component, and written by the author of the layout system (Edwin). I usually pair it with a MediaPlayer object for my demo players.
What is an example use case of the MediaElementSprite, and how does it differ from a MediaEelement?
Would MediaElementSprites be used as assets within a slideshow?
The main use case for MediaElementSprite is when you have multiple MediaElements being displayed at once, but their playback is controlled by a single MediaPlayer. For example, you might have a video playing in parallel with various banner images or overlay SWFs. The video might be placed in a MediaPlayerSprite, whereas each image/SWF would be placed in a MediaElementSprite.
That being said, we'll soon be revisiting the current design to clarify (as Ryan mentioned above) the overlap between these two classes and RegionGateway.
Thank you for that explanation.
I wonder if the documentation could explain useCase expectations during these sprints.