[AC-1196] Ti.Media.AudioPlayer undefined
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | n/a |
| Status | Closed |
| Resolution | Invalid |
| Resolution Date | 2014-11-18T09:19:54.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Titanium SDK & CLI |
| Labels | audio, audioPlayerAPIs, audioplayer |
| Reporter | Jason Priebe |
| Assignee | Shuo Liang |
| Created | 2014-11-07T16:31:13.000+0000 |
| Updated | 2017-05-08T14:39:07.000+0000 |
Description
When I add an event listener to an AudioPlayer's 'change' event, I try to test e.state against the various constants, like Ti.Media.AudioPlayer.STATE_BUFFERING. When I do, I get an error because Ti.Media.AudioPlayer is undefined.
I can work around the problem by referencing the constants from my AudioPlayer instance variable.
var _player = Ti.Media.createAudioPlayer ();
_player.addEventListener ('change', function (e) {
switch (e.state)
{
case Ti.Media.AudioPlayer.STATE_BUFFERING: // crash and burn
break;
case _player.STATE_BUFFERING: // this is OK
break;
}
});
Hi, Based on your code, you have to write code like "_player.STATE_BUFFERING". As Ti.Media.AudioPlayer is just class name, not the exact Object. And the State_buffering is a property for that Object. Like can add event listener to _player not Ti.Media.AudioPlayer.
I completely disagree with this being marked "invalid". How is Ti.Media.AudioPlayer.STATE_BUFFERING any different from Ti.UI.SIZE? Or Ti.UI.PORTRAIT, Ti.UI.LANDSCAPE_LEFT, etc.? Inconsistencies like this in the semantics of the library are one of the biggest obstacles to new user adoption of the Titanium platform. Many users would have given up when Ti.Media.AudioPlayer.STATE_BUFFERING threw errors. How many would bother to try checking for an *instance constant*??? I've been developing software for over 20 years, and I've never found an API that uses *instance constants*. Class constants, yes. Not instance constants. At least fix the documentation so that users understand that these are not class constants.
I agree. Documentation for the 'change' event on AudioPlayer references these constants as though they were on the AudioPlayer object rather than its prototype--which is what makes it accessible only through an instance. There's no reason to put the constants in an instance: they don't change across instantiations and shouldn't ever be changed anyway.