WAI
Status Update
Comments
am...@google.com <am...@google.com> #2
Thanks for the feedback. We'll pass this feature request to our product and engineering teams for possible consideration.
am...@google.com <am...@google.com> #3
The mentioned use case can be solved by creating a share target activity (using intent-filter ACTION_SEND). Direct share are intended to be used for sharing with person(s) and they should generally have a direct entry-point as well.
We can reconsider this restriction in future, if there are use-cases which fit the above description.
We can reconsider this restriction in future, if there are use-cases which fit the above description.
jo...@gmail.com <jo...@gmail.com> #4
Share Target activities cannot be created dynamically, so unfortunately that won't solve it.
Let me share an example for one of my apps:
- My app doesn't have a default share target by default
- Users can create a share target with their own custom icon and label
- Clicking this target will trigger a task that can do whatever the uses wants to
- User can create also dynamically create launcher shortcuts for other purposes
So, lets say the user wants to create a share target that says the shared text out loud:
- user creates share target with i.e. a microphone icon and "Speak" label
- user creates task that takes the shared text and speaks it out loud
In this use case the user has no use for the launcher shortcut. It wouldn't be able to do anything logical because there would be no shared text.
So, to make it clear, my initial suggestion would benefit situations where share targets are created dynamically and not statically.
Hope this makes sense. Let me know if you need more specifics for this use case.
Let me share an example for one of my apps:
- My app doesn't have a default share target by default
- Users can create a share target with their own custom icon and label
- Clicking this target will trigger a task that can do whatever the uses wants to
- User can create also dynamically create launcher shortcuts for other purposes
So, lets say the user wants to create a share target that says the shared text out loud:
- user creates share target with i.e. a microphone icon and "Speak" label
- user creates task that takes the shared text and speaks it out loud
In this use case the user has no use for the launcher shortcut. It wouldn't be able to do anything logical because there would be no shared text.
So, to make it clear, my initial suggestion would benefit situations where share targets are created dynamically and not statically.
Hope this makes sense. Let me know if you need more specifics for this use case.
mm...@commonsware.com <mm...@commonsware.com> #5
> The mentioned use case can be solved by creating a share target activity (using intent-filter ACTION_SEND).
No, the share targets still show up as dynamic shortcuts. You can see this by running the official sample (https://github.com/googlesamples/android-SharingShortcuts ), once you get past the compile bug. It has a share target activity, which is where the actual share sheet sends users. However, the launcher icon still has dynamic shortcuts, for whatever Intent you put in the ShortcutInfoCompat.Builder.
The net effect, AFAICT, is that if you use share targets, you cannot use other shortcuts. *And*, your share targets have to make sense as dynamic shortcuts, which will not be the case all the time (as the preceding comment illustrates).
I can see why you want to reuse some of the shortcut plumbing for share targets. However, it is fairly important that the developer be able to tell the system which shortcuts are actual shortcuts for use as shortcuts, and which shortcuts are merely there to be able to provide share targets.
No, the share targets still show up as dynamic shortcuts. You can see this by running the official sample (
The net effect, AFAICT, is that if you use share targets, you cannot use other shortcuts. *And*, your share targets have to make sense as dynamic shortcuts, which will not be the case all the time (as the preceding comment illustrates).
I can see why you want to reuse some of the shortcut plumbing for share targets. However, it is fairly important that the developer be able to tell the system which shortcuts are actual shortcuts for use as shortcuts, and which shortcuts are merely there to be able to provide share targets.
Description
This may not always be wanted. For example, I may want to have a share target that speaks the shared text out loud, but it doesn't make sense at all to have that appear as a launcher shortcut. There's no logical action for that share target when there is no shared text.
Making this mandatory will use precious launcher shortcut slots with unwanted share targets.
Thank you in advance.