Pass command line arguments onto platform apps which provide the right intent.

chrome/browser/extensions/api/app/app_api.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CHROME_BROWSER_EXTENSIONS_API_APP_APP_API_H_
 #define CHROME_BROWSER_EXTENSIONS_API_APP_APP_API_H_
 #pragma once
 
 #include "chrome/browser/extensions/extension_function.h"
 
 class Extension;
 class Profile;
+class GURL;
 
 namespace extensions {
 
 class AppNotifyFunction : public SyncExtensionFunction {
  public:
   DECLARE_EXTENSION_FUNCTION_NAME("experimental.app.notify");
 
  protected:
   virtual ~AppNotifyFunction() {}
   virtual bool RunImpl() OVERRIDE;
 };
 
 class AppClearAllNotificationsFunction : public SyncExtensionFunction {
  public:
   DECLARE_EXTENSION_FUNCTION_NAME("experimental.app.clearAllNotifications");
 
  protected:
   virtual ~AppClearAllNotificationsFunction() {}
   virtual bool RunImpl() OVERRIDE;
 };
 
 class AppEventRouter {
  public:
-  // Dispatches the onLaunched event to the given app.
+  // Dispatches the onLaunched event to the given app, providing no launch
+  // data.
   static void DispatchOnLaunchedEvent(Profile* profile,
                                       const Extension* extension);
+
+  // Dispatches the onLaunched event to the given app, providing launch data of
+  // the form:
+  // {
+  //   "intent" : {
+  //     "action" : |action|,
+  //     "type" : |mime_type|,

[Greg Billock, 2012/05/14 16:16:27]

Should also have a "data" field.

[benwells, 2012/05/14 23:44:32]

When sending onLaunched there is no data field. At one point in time this was
valid for WebIntents, is it still valid?

I have seen that after a download the data field is populated with a blob. I
don't think that is worth the effort for this case as, once the next patch in
this series lands, a FileEntry can be easily retrieved, which will do reading
and writing (writing in the future).

[Greg Billock, 2012/05/14 23:55:38]

It's a valid intent, but I was thinking the API would be broader and more
potentially useful if it could carry the "data" payload as well -- that'd let
clients send text content, for instance.

On 2012/05/14 23:44:32, benwells wrote:

[benwells, 2012/05/15 00:11:46]

OK ... this could be added in future but for now I'd like to leave it as is.
This is only accessed when starting platform apps with file names on the command
line.

[Mihai Parparita -not on Chrome, 2012/05/15 00:39:28]

In that case, can "url" be named more specifically (launch_file_url or the
like)? I found the name too generic/confusing right now.

[benwells, 2012/05/18 03:36:02]

url is now gone, with a FileEntry instead in data.

+  //     "extra_data" : {
+  //       "url" : |url|
+  //     }
+  //   }
+  // }
+  static void DispatchOnLaunchedEventWithUrl(Profile* profile,

[Greg Billock, 2012/05/14 16:16:27]

How about "DispatchOnLaunchedEventWithIntent" and pass in the intent payload?

[benwells, 2012/05/15 00:11:46]

Yeah that would be nice. I started going down that track, but pulled back as
data is null. To do it we'd need to add a new DataType value NULL, is that
right?

[Greg Billock, 2012/05/15 00:54:59]

Couldn't it just be left blank if there's no "data" parameter? I guess I'm not
totally clear on the scope (perhaps I didn't read enough of the CL.) If this
ties into an existing facility to launch the app with a url, it looks fine, but
I'm not sure why you'd have the action/type then, for instance. Wouldn't that be
handled upstream in the matching logic, and not need to be passed in here?

+                                             const Extension* extension,
+                                             const string16& action,
+                                             const std::string& mime_type,
+                                             const GURL& url);
 };
 
 }  // namespace extensions
 
 #endif  // CHROME_BROWSER_EXTENSIONS_API_APP_APP_API_H_