Re: Supporting extra parameters on the Intent object

The majority of apps I have built so far care nothing about the
filename at all because the data is consumed directly in the app and I
would hate to mandate that the we need a file name or hardcode it
someway.

Android extra's are a point of burden in that for basic actions you
never know the extra's to expect and they are not implemented
consistently.  If we start with a good solid grounding of
documentation, yet keep it freeform then we are in a better place.

Can we light-weight encode the extras required by the client app so
services can say only list services that defintely support "fileName"
extras?

If you look at the spec [1] we have thought about how we can ask for
specific types of data such as a JPEG encoded as a link
("text/uri-list;type=image/jpeg" - the picker will list services that
return links, but only links to images), and to Gregs' point earlier
can we encode this requirement for a file name in the a way that will
allow the UA to filter (or ignore)?  For example could we say
"text/uri-list;requires=filename" then if a service didn't say it can
provide this data it would not be presented in the picker?

Taking this further, if a service initiated an action using `new
Intent("http://webintents.org/pick", "text/uri-list", ... );` then a
service registered to support "text/uri-list;requires=filename" would
still be listed, but a service that only supports "text/uri-list"
wouldn't as it has said it can't support the required data for the
operation.

P

[1] - http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html

On Mon, Jan 30, 2012 at 3:36 PM, Rick Byers <rbyers@google.com> wrote:
> I agree that having some such mechanism is essential.  I've been
> experimenting with some real-world scenarios using the pick intent and it
> seems clearly broken without a filename.  The proposed mechanism seems
> reasonable to me.
>
> My only concern is whether we really want to commit to all metadata for any
> intent being strictly optional.  For the specific case of 'pick', I suspect
> that services that don't have any reasonable filename will be much rarer
> than clients that require a filename, and so I'd much rather put the burden
> on services to fabricate the filename when necessary than on the clients
> that need it (this can be non-trivial - eg. choosing an appropriate
> extension to match the mime type of the data for compatibility with systems
> like Windows).  It would be a shame for every client of pick to have to
> maintain non-trivial filename generation code that only gets used in very
> rare cases - or worse, services deciding they have to fabricate filenames
> anyway due to a couple popular clients that don't properly do it themselves.
>  Regardless, I think this API is OK for required metadata too - as long as
> we're clear in the definition of each intent on what is required.
>
> Rick
>
> On Mon, Jan 30, 2012 at 9:10 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
>>
>> On 01/30/2012 02:30 PM, Paul Kinlan wrote:
>> > Because we want the data described by the "type", specifically a
>> > mime-type, to describe the just the data being sent.  If you say it is
>> > an image/jpeg it must be a JPEG image that is received (which does not
>> > include the file name), not a JSON object with arbitrary values
>> > defined.
>>
>> I don't see the relation with JSON here...
>> Anyway, I wouldn't mind to have a Dictionnary returned instead of the
>> requested data but I understand your point here. Though, we could use
>> some WebIDL tricks to have this behaving as you want with data.value
>> always returning the requested data and [PutForwards=value] but I'm not
>> a big fan of PutForwards in general.
>>
>> --
>> Mounir
>>
>



-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan

Received on Tuesday, 31 January 2012 13:49:30 UTC