Re: ActionHandlers vs "App resources" (was: An updated draft of the schema.org/Action proposal)

On Fri, Feb 21, 2014 at 12:21 PM, Sam Goto <goto@google.com> wrote:

>
>
>
> On Mon, Feb 17, 2014 at 12:44 PM, Markus Lanthaler <
> markus.lanthaler@gmx.net> wrote:
>
>> On Friday, February 14, 2014 7:11 PM, Sam Goto wrote:
>> > On Fri, Feb 14, 2014 at 9:33 AM, Markus Lanthaler wrote:
>> >>> 2) How would you be able to express that you CANNOT BuyAction on the
>> >>> AndroidAppLink resource (e.g. your mobile app resource isn't as fancy
>> >>> as your website)?
>> >>
>> >> That's something we would need to decide. I think in most cases
>> >> these resources are not really exactly the same. Thus, I'm not
>> >> sure whether it makes that much sense to "inherit" the operations
>> >> from the Web resource. I think it would be sensible to require
>> >> them to be declared separately. I don't think "expects" etc. are
>> >> needed for apps, are they? If not, it's really just a short list of
>> >> supported operations similar to the one in your example above, likely
>> >> with min. version constraints etc.
>> >
>> > Not quite on both points.
>> >
>> > 1) Most often than not, these are the same resources. That's the basic
>> > premise of the android-app://foobar.com/resource/1234 with
>> rel=alternative
>> > links.
>>
>> Fair enough. How do you thought of dealing different sets of operations
>> then? You moved the list out from the action handler, didn't you?
>>
>>
>
> You'd have specific action handlers attached to the action. Example (of a
> Movie that can be "watched" on android and "bought" via a webpage):
>
> {
> @type: Movie
> action: [{
>   @type: WatchAction
>   handler: {
>     @type: AndroidHandler
>   }
> }, {
>   @type: BuyAction
>    handler: {
>      @type: WebPageHandler
>   }
> }
> ]
> }
>
> How would we go about this using sameAs/alternate?
>

Here is an interesting idea:

At run time, both android as well as HTTP allows you to "check" whether a
specific operation is available in a specific resource (for HTTP that's an
OPTIONS request).

On Android, you can query the intent system to check whether a specific
application listens to a specific intent. I think this should work, but I'm
investigating. Here is a code snippet [1].

Jason J, could you explore whether something like the following [1] would
work for windows native applications?

If we have "run-time" mechanisms to query these "operations", the App Url
mechanism could potentially replace ActionHandlers (which I agree is
overall a better design).

Lets keep exploring this path.

Additionally, anyone can think of any other challenge we may face with the
change?

[1]

Intent intent = new Intent(WATCH_ACTION);
intent.setDataUri("android-app://com.netflix/movies/1234");List<ResolveInfo>
resolveinfo_list =
activity.getPackageManager().queryIntentActivities(intent, 0);
for(ResolveInfo info:resolveinfo_list){
if(info.activityInfo.packageName.equalsIgnoreCase(application_name)){
    launchComponent(info.activityInfo.packageName, info.activityInfo.name);
    break;
  }}



>
>
>> > 2) "expects" apply to apps as much as web resources. as you are
>> > "buying" an item on the web or in an app, things like your credit
>> > card / quantity information needs to be passed either way. That
>> > is, i'd expect to see things like
>> > http://amazon.com/products/1234?action=buy&quantity=2 as much as
>> > things like android-app://com.amazon/products/1234 with
>> > putExtra("quantity", "2") in the intent extra bag.
>>
>> So you don't just open the specific screen in the app but you really
>> carry out an operation (or at least pre-fill a form)? Where comes the data
>> from to invoke the operation or pre-fill the form? Is there an intermediary
>> UI (such as the review widget in Gmail)?
>>
>
> Right, that's the review widget in gmail case.
>
>
>>
>>
>>
>> --
>> Markus Lanthaler
>> @markuslanthaler
>>
>>
>>
>