search

apache / cordova-plugin-media

Apache Cordova Media Plugin
https://cordova.apache.org/
Apache License 2.0
387 stars 765 forks source link

Feature Request: Specify custom Media ID in the JS API (will send simple PR if approved) #302

Open SmallhillCZ opened 3 years ago

SmallhillCZ commented 3 years ago

Feature Request

Motivation Behind Feature

When webview restarts, e.g. due to battery saving feature when app is in background, it could access previously started sound -and control it.

Also when developing in live reload the link to file is lost.

Feature Description

I play a long MP3, UUID is generated for the MP3 and status update callbacks are connected to the app. I turn off the screen and put my phone away. The sound keeps playing.

After five minutes I unlock the screen, but the webview was killed to save battery and now has reloaded. Unfortunately it can no more acquire the pointer to the MP3 file, thus it cannot control its playing and it plays on its own now and status updates are not transmitted to the app.

If I was able to specify a fixed ID instead of UUID, I could reacquire the handle, because internally existing Media object is returned if exists both for Android and iOS.

The code change would be easy: To allow custom id assignment in this function, e.g. to pass [id,src] instead of src and use that id. Will be happy to send a PR if you agree to implement. https://github.com/apache/cordova-plugin-media/blob/eb99c859ee8f5743c36a4355f4a71d43ce146444/www/Media.js#L42-L53

Alternatives or Workarounds

It would be also interesting to be able to list currently created mediaObject handles (e.g. implement Media.list() in Android in addition to Media.get() and implement it in JS API similarily). Then I could loop through all and search for Media with the same src. Or I could stop all playing playing sounds on e.g. leaving the current page.

ghenry22 commented 3 years ago

You could also enable background operation for the webview as long as media is playing, then let it get killed/suspended by the OS after playback stops.

Your proposed approach would allow the app to kill/resume control of native playback in any edge cases as well which would be useful. I could definitely see this being a useful feature but getting new features into the media plugin seems like a slow process these days.