For iOS, a play during play state would restart the audio at the beginning. I agree we should have a consistent behavior that is documented.
-James Jong On Aug 2, 2013, at 11:33 AM, Lorin Beer <[email protected]> wrote: > I ran into this sometime ago on the android media API. The relevant > conversation is likely deeply buried, and we should consider documenting > the appropriate behavior somewhere permanent. > > My opinion is that appropriate behavior is dependent on the function being > called and the current state. A FSM could capture this. > In terms of <play> during <play> state, I would recommend that the plugin > executes the latest command normally, playing media from a new source or > restarting the currently executing media as if the play command had been > received in the <stopped> state. > > - Lorin > > > On Thu, Aug 1, 2013 at 1:47 PM, Benn Mapes <[email protected]> wrote: > >> Working on https://issues.apache.org/jira/browse/CB-3783, it appears that >> there is no documentation on how the media plugin should handle subsequent >> calls of the same function. >> >> An example would be calling my_media.play() multiple times when the >> my_media is already playing. Should this be swallowed by the plugin and >> ignored? Should we respond with a >> MediaError< >> http://cordova.apache.org/docs/en/3.0.0/cordova_media_media.md.html#MediaError >>> .MEDIA_ERR_ABORTED >> and a message saying the media is already playing? What about subsequent >> calls to my_media.pause() when the media is already paused? >> >> Was just wondering what other platforms have implemented for this and what >> the proper way of handling subsequent calls is. >> >> ~Benn >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
