Hmm... I don't quite agree with the above statements for different reasons:
1) The user usually has one single intention when hitting a media button. I've in fact already written an application that "misused" the media buttons for voting, but even for this application, I would expect to place a vote when hitting the button, and nothing else. I don't want to place a vote and have music started at the same time. I have a hard time to think about a use case in which a user wants two applications to react on a single button click... 2) Music players (and, more generally, media players) typically run in a service. Several services from different music players can run at the same time. The media button receiver is typically used to control such a service (i.e. registered with the service). So, no matter whether the broadcast is registered in the manifest or (only) in the service, two (or more) music players can be registered. If the user presses the play button, s/he definitely wants to have some (for the user well defined) music started. If the first player to start the music aborts the broadcast (yes, that works), that's (almost) fine, the music starts, and nothing else happens. However, the user has no control as to which player (service) will react to the button event (basically the priority of the registered receiver defines the order, as it seems). Thus, the "wrong" song (i.e. not the one intended by the user) might start playing. If the first player that starts music does not abort the broadcast, a second player might start music (=> definitely not the desired behavior). 3) I've quickly checked the manifest files of some of the major music players in the market. All of them (including the stock player) register the media button intent in the manifest, with different priorities: - TuneWiki (priority 2) - Meridian (priority 12700) - Cubed (priority 3) - Museek (priority 12800) - MixZing (priority 999) - StockPlayer (no particular priority is set) So, the reality is, that people are using the headset buttons to launch music (applications). Moreover, there is a race for ever higher priorities. The observed race for priorities was surely not the intention of the OS designers... Except of the Stock Player, all of the above players offer a setting to switch of headset controls (which kind of looks like a fix to the mentioned problem). So that's probably the way to go for the time being (register to the button events with high priority but offer a setting to ignore the events). Still, I think a (OS based) possibility for the user to define which of the registered applications should react to the intent in which order would be a cleaner solution. After all, it's a pain if I have to uninstall an otherwise useful application that happens to have registered the media buttons with high priority but does not offer a way to ignore the events. So, that's my thoughts about the topic... Any comments are welcome... Thanks, Michael On Nov 11, 6:54 pm, Kumar Bibek <[email protected]> wrote: > Well, I guess, the behaviour of the ACTION_MEDIA_BUTTON is not to only start > or stop playing music. > > Different apps might want to handle and do different stuff when the media > button is pressed, and thus, every app registered for the broadcast should > receive it silently, without prompting the user, since, different apps might > do different things. > > I think, registering for this broadcast should be done within one of your > activities or services where you want to listen to this broadcast and also > unregister it when you are done, instead of putting this in your manifest. > > > > On Thu, Nov 11, 2010 at 11:14 PM, michael <[email protected]> wrote: > > Thanks for the reply. So I guess Android is missing a clean concept > > here...? > > > The problem is that if a user has installed several media (e.g. music) > > players, it is not clear which player will be started. Most likely, > > all of them are registered for the ACTION_MEDIA_BUTTON intent, and > > hence all of them might start playing music... If the players abort > > the broadcast once received, I guess the other players won't receive > > it anymore... But still, there is no possibility for the user to > > choose which player should take control. I've noticed that some > > players just set an extremely high priority value for the intent (and > > thus basically try to make themselves the default player). This is > > definitely not the intended way of handling the issue, because in the > > end, only the user can decide which of two installed players should be > > launched (i.e. which one s/he wants to be his/her default player, and > > which one might be used for special cases only). > > > Any thoughts on that? > > > On Nov 11, 4:14 pm, Mark Murphy <[email protected]> wrote: > > > The media button is a broadcast Intent, not an activity Intent. Hence, > > > it doesn't go through the normal chooser-style stuff like you see with > > > activity Intents (e.g., default browser). > > > > You can listen for the ACTION_MEDIA_BUTTON broadcast. The > > > documentation does not say it is an ordered broadcast, so I assume all > > > applications that have registered for it will receive it. > > > > On Thu, Nov 11, 2010 at 10:06 AM, michael <[email protected]> wrote: > > > > Hi, > > > > > I wonder whether there is a concept in Android that allows a user to > > > > define which application should be launched if a headset media button > > > > is pressed..? > > > > > This would be something similar as the concept of a "default browser" > > > > or "default e-mail application" that is launched when a website should > > > > be opened or a mail needs to be sent. As far as I know such a concept > > > > at least exists for a browser on Android. > > > > > Is there something like a "default media player" that is started when > > > > the user hits the headset's play button? If so, how could my > > > > application inform the system that it is a potential candidate for the > > > > "default media player" application? > > > > > Thanks, > > > > > Michael > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Android Developers" group. > > > > To post to this group, send email to > > [email protected] > > > > To unsubscribe from this group, send email to > > > > [email protected]<android-developers%[email protected]> > > > > For more options, visit this group at > > > >http://groups.google.com/group/android-developers?hl=en > > > > -- > > > Mark Murphy (a Commons Guy)http://commonsware.com| > >http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy<http://github.com/commonsguyhttp://commonsware.com/blog%7Chttp://twit...> > > > > Android App Developer Books:http://commonsware.com/books > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%[email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Kumar Bibekhttp://techdroid.kbeanie.comhttp://www.kbeanie.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
