onDestroy and dealloc ambiguity

[wspresto]

Currently, it is impossible for client code to interpret the state or event in which the underlying native Media object has been destroyed when the OS is terminating the activity / process. This is a short coming of the plugin, because the success callback is called without any indication that the entire activity or process was stopped abruptly. In other worse, the MEDIA_STOPPED state is too ambiguous . I would like to request a solution to resolve this ambiguity.

There is no way for the plugin to indicate to the client code that the underlying OS is terminating the the process. Please provide a way for client code to discern the difference between OS forcefully stopping the media and the media stopping because it has successfully reached the end of playback.

[janpio]

We are always open for Pull Requests improving the plugin.

That being said, I don't really understand what currently doesn't work as documented, intended or wanted. Could you describe a usecase where what you describe matters? What platform are you talking about?

[wspresto]

Sure.
For Android specifically, When the success callback is triggered, there is client JavaScript code that is executed on the WebCore thread. This JS code is unaware of the reason why the success callback was triggered. The reason could be either that the playback has ended because EOF was reached, OR that the underlying Operating System signaled the activity to be "destroyed".

These are 2 distinct reasons that both trigger the success callback equally. I will be submitting a PR shortly in order to suggest a solution, but I wanted to get feedback first.

[janpio]

Ok, now I think I understand - the plugin could report "playback successfully finished" to the web app even though the OS pulled the rug under the plugin, correct?
What could be a reason for Android to do that?

[wspresto]

Correct. That is what was happening in my situation which was causing a bug in my use case.
I personally do not believe the plugin should trigger the success playback if the OS pulls the rugs so to speak. However, the case could be made where someone would want client code to be triggered in response to this event.
Maybe, instead of triggering a state change -> MEDIA_STOPPED during destroy (android) or dealloc events (ios) , the plugin would throw a new type of error. That way, the client code gets a chance to respond to a destroyed event, and any code in the success callback can keep assuming that a successful state change to MEDIA_STOPPED occurred.
Thoughts?

[janpio]

Yes, that sounds very reasonable.
Maybe an additional MediaError?
Is there any handling of such cases in the code base already?

[wspresto]

I have a working example which fixed the issue for me.
https://github.com/wspresto/cordova-plugin-media

If people think this would be good, I can go through the chore of getting an apache license to submit a PR. Otherwise, I will leave as is.

[janpio]

Feel free to just open a PR with your code changes from your fork - we require the ICLA only for the person merging the change into the codebase nowadays.

[wspresto]

Will do.

[wspresto]

#198