One thing I noticed -- the current implementation of the default CHOOSER activity does not quite work the same as when you get when using Menu.addIntentOptions() -- it will show all of the activities that match the intent, however it does not take care of filling in the intent action field if one wasn't already specified. :(
Unfortunately we'll have to live with this for 1.0. It means you can't correctly use it for the case where you create an intent with no action, that is want to let the user pick all of the actions for a particular URI. So as an example, you'll need to use it in the cases we have been, where the original Intent is full specified, such as GET_CONTENT with some MIME type. On Sep 4, 6:12 pm, Mark Murphy <[EMAIL PROTECTED]> wrote: > hackbod wrote: > > Actually I don't think I would structure the example that way -- it > > isn't really the kind of UI flow you would do, so this isn't how the > > action is intended to be used. What it is mainly used for is when you > > want to pop up a list of things for the user to choose from to fill in > > a field. For example, if you were going to write a shortcut manager, > > you could use ACTION_PICK_ACTIVITY to have the user pick an activity > > to assign to a shortcut. If the Intent extra you give it is > > action=MAIN category=LAUNCHER they will be picking from all of the > > "applications" they have installed. > > Oh. > > > For the case of picking a contact and then do something with it, > > probably what you want to use is a chooser -- see > > http://code.google.com/android/reference/android/content/Intent.html#... > > Oh! > > > This presents to the user a list of activities that match the given > > intent (if there is more than one) and upon selecting one of them > > executes that activity on the caller's behalf. This is intended for > > things like having the user add an attachment to an e-mail message > > (where you want to present a list of things that can supply > > attachments), so I think it better follows the example you want, and > > should be used far more than the PICK_ACTIVITY action. > > OH!!! > > So, I had the right concept, but the wrong action name. That beats most > of the alternatives. > > > Instead of queryIntentActivityOptions(), I would suggest using the > > higher-level menu apis: > >http://code.google.com/android/reference/android/view/Menu.html#addIn...[],%20android.content.Intent,%20int,%20android.view.MenuItem[]) > > Yeah, I already have that one written up from before. > > > To be honest, though, for our current UI we have pretty much backed > > away from the menu approach, and I think all of the regular apps are > > now using ACTION_CHOOSER for places where their actions can be > > extended. The chooser approach seems to work a bit better for > > scalability in the places we have been using it. > > I can imagine the options menu may get kinda crowded. > > This is just what I needed to know. Many thanks! > > -- > Mark Murphy (a Commons Guy)http://commonsware.com > _The Busy Coder's Guide to Android Development_ Version 1.1 Published! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new Android 0.9 SDK beta! http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
