An interface and android service for sharing.

An interface and android service for sharing.

This has been derived from https://codereview.chromium.org/1229083003/ .

R=etiennej@chromium.org, etiennej@google.com, pylaligand@google.com

Committed: https://chromium.googlesource.com/external/mojo/+/01c387c25c0a89bacf29b43421d0ba0aa8243f7b

[alhaad1, 2015-08-17 17:01:21]

alhaad@google.com changed reviewers:
+ ppi@google.com

[etiennej, 2015-08-18 15:15:14]

etiennej@chromium.org changed reviewers:
+ etiennej@chromium.org
- etiennej@google.com

[etiennej, 2015-08-18 15:15:15]

One possible extension of this is to allow apps to register for incoming
intents. It should probably wait for another CL though.

https://codereview.chromium.org/1287003010/diff/1/mojo/services/sharing/publi...
File mojo/services/sharing/public/interfaces/sharing.mojom (right):

https://codereview.chromium.org/1287003010/diff/1/mojo/services/sharing/publi...
mojo/services/sharing/public/interfaces/sharing.mojom:9: ShareText(string text);
I think you should define a struct here. Something along the lines of:

enum MessageType {
   TEXT;
   IMAGE;  // maybe?
}

struct Message {
  string? data;
  MessageType mimetype;
}

interface SharingService {
  Share(Message message);
}

This way, it is easier to extend in the future if we need it.

[alhaad1, 2015-08-18 15:53:10]

alhaad@google.com changed reviewers:
+ alhaad@google.com

[alhaad1, 2015-08-18 15:53:11]

https://codereview.chromium.org/1287003010/diff/1/mojo/services/sharing/publi...
File mojo/services/sharing/public/interfaces/sharing.mojom (right):

https://codereview.chromium.org/1287003010/diff/1/mojo/services/sharing/publi...
mojo/services/sharing/public/interfaces/sharing.mojom:9: ShareText(string text);
On 2015/08/18 15:15:15, etiennej wrote:
> I think you should define a struct here. Something along the lines of:
> 
> enum MessageType {
>    TEXT;
>    IMAGE;  // maybe?
> }
> 
> struct Message {
>   string? data;
>   MessageType mimetype;
> }
> 
> interface SharingService {
>   Share(Message message);
> }
> 
> This way, it is easier to extend in the future if we need it.

I am trying to understand the difference between what you suggested vs something
like:
interface SharingService {
  ShareText(string text);
  ShareImage(handle<data_pipe_consumer> image);
}

To me the second seems cleaner. WDYT?
That way the interface can be updated as needed.

[etiennej, 2015-08-19 11:54:37]

On 2015/08/18 15:53:11, alhaad1 wrote:
>
https://codereview.chromium.org/1287003010/diff/1/mojo/services/sharing/publi...
> File mojo/services/sharing/public/interfaces/sharing.mojom (right):
> 
>
https://codereview.chromium.org/1287003010/diff/1/mojo/services/sharing/publi...
> mojo/services/sharing/public/interfaces/sharing.mojom:9: ShareText(string
text);
> On 2015/08/18 15:15:15, etiennej wrote:
> > I think you should define a struct here. Something along the lines of:
> > 
> > enum MessageType {
> >    TEXT;
> >    IMAGE;  // maybe?
> > }
> > 
> > struct Message {
> >   string? data;
> >   MessageType mimetype;
> > }
> > 
> > interface SharingService {
> >   Share(Message message);
> > }
> > 
> > This way, it is easier to extend in the future if we need it.
> 
> I am trying to understand the difference between what you suggested vs
something
> like:
> interface SharingService {
>   ShareText(string text);
>   ShareImage(handle<data_pipe_consumer> image);
> }
> 
> To me the second seems cleaner. WDYT?
> That way the interface can be updated as needed.

Actually, here is the scenario I had in mind: say the user is in a chat app (or
SMS app, or G+-like app, ...), and we have a feature to share a chat message
outside the app. Now, these messages may be anything: pure text, URL, sound,
video, image, maybe even another app. In that case, the "natural" way to design
this is to have each chat message object have a method to create a
SharingMessage struct that would be passed to a common method; this way, you can
decouple the code that decides what is shared to the code that connects to the
sharing app.

I feel that your proposal is somewhat cleaner/easier if the app requesting the
sharing is always sharing the same type of object, as you pass directly the data
you want to send. However, for more complex cases, you would get a long list of
methods where code would be mostly duplicated (ShareText, ShareURL, ShareVCard,
Share...).

Another way to maybe address both our concerns would be to have:
> interface SharingService {
>   ShareText(string text, string mime);
> }

So that, at least we can share anything which is not a binary stream. 

However, I do not have the strongest of opinions on the subject, so lgtm. Do as
you wish :)

[alhaad1, 2015-08-20 00:12:17]

I gave it a thought. Going with this implementation for now.

[alhaad, 2015-08-20 00:14:30]

Committed patchset #1 (id:1) manually as
01c387c25c0a89bacf29b43421d0ba0aa8243f7b (presubmit successful).