Hmm, Yep, on second thoughts, I agree with you. But, as of now, I guess, there is no other way, other than setting priorities to do this.
On Fri, Nov 12, 2010 at 10:56 PM, michael <[email protected]> wrote: > 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]> > <android-developers%[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://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]> > <android-developers%[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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- Kumar Bibek http://techdroid.kbeanie.com http://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
