- From: Sam Goto <goto@google.com>
- Date: Wed, 26 Feb 2014 06:35:03 -0800
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: Jason Johnson <jasjoh@microsoft.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>, public-hydra@w3.org
- Message-ID: <CAMtUnc6gwEtsm0KE-LH=svc=r_YcXP2X7Nd1gJ3jDnj5k6vntg@mail.gmail.com>
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 >> >> >> >
Received on Wednesday, 26 February 2014 14:35:32 UTC