Share Where the User Wants
I’ve been seeing several issues crop up akin to this one,
where developers try to artificially restrict user options to a subset that the developer wants.
In this case, a developer wants to allow a user to send something via ACTION_SEND… but only
via email programs. A worse case is where the developer wants to force users to only send stuff
via Twitter clients.
It is not up to you to dictate terms, but rather to provide opportunities to the user. Just because you only might want to send something via email does not mean that all of your users will agree with you.
Your job is to format data in common formats (plain text, HTML, message/rfc822, etc.) and let
the user share that data how the user wants, via the applications that the user wants.
You may feel that sharing plain text results in too many options. That’s not your problem. If it’s a problem at all, it is the user’s problem with the other applications on the user’s device. If the user feels that the list is too long, the user can uninstall applications that aren’t worth the space they take up on the list.
Admittedly, some devices ship with lots of apps in firmware that can’t be uninstalled, but, again, that’s an issue between the user and the device manufacturer or carrier. If you wish to campaign to get device manufacturers and carriers to limit the number of non-removable apps, by all means do so (and count me in!).
Now, in a few specific cases (email and SMS, notably), you can use ACTION_SENDTO instead of
ACTION_SEND and restrict sharing to particular protocols. Mostly, that should be for cases
where the delivery target is fixed, such as sending an email or SMS to a particular contact that
you pulled up from the contacts content provider.
If you want, format your data in multiple formats and allow sharing of each of them. For example,
your “Share” options menu item could pop up a submenu to allow sharing as plain text and HTML, where
the user’s available applications for sharing will vary by format. In this case, pick formats
that the user will recognize (e.g., not message/rfc822). And, in this case, if you want to blend
in ACTION_SENDTO options (e.g., submenu supports general sharing of text and HTML but also “Via Email”
and “Via SMS”), that’s reasonable. If you think the submenu of options will be too confusing,
use PackageManager and queryIntentActivities() to collect the applications that will support
the various formats and protocols you support, remove any duplicates, and display your own chooser-style
dialog. In fact, this might make a nice reusable component, if anyone else has the itch to scratch.
But, whatever you do, ensure that the user is the one controlling what applications get used for sharing. It’s their device, their information, their bandwidth, their battery, and their chosen applications. Restricting their choices based on your own preconceived notions is no way to win fans.
