Introduce ash mojo interface for lock screen action handlers

ash/public/interfaces/tray_action_handler.mojom

+// Copyright 2017 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.
+
+module ash.mojom;
+
+// Supported actions.
+enum TrayActionHandlerAction { kNewLockScreenNote, };

[James Cook, 2017/05/03 23:31:50]

It doesn't seem like we will have many of these actions, at least for now. This
seems like premature generalization.

I would prefer to hard-code the concept of taking a note into this interface
(like have methods SetLockScreenNoteState / StartLockScreenNote or similar
below).

[tbarzic, 2017/05/04 20:58:30]

OK, sounds good, I've myself started considering the same - I do like to
generalize APIs; but yeah, given this is internal API, and should be easy to
change later, less generalization is more readable/easier to use.

+
+// An action handler state.
+enum TrayActionHandlerState {
+  // The client does not support the action.
+  kNotSupported,
+  
+  // The client supports the action and is not currently handling the action.
+  kAvailable,
+
+  // The client received the request for the action and it is launching the
+  // flow to handle it.
+  kLaunching,
+
+  // The client is currently handling the action.
+  kActive,
+
+  // The client is currently handling the action, but in background (e.g.
+  // handler window for lock screen action was moved to the background to
+  // surfeace user sign-in UI).
+  kBackground,

[James Cook, 2017/05/03 23:31:50]

I don't understand this state. Why would the app be in the background? It seems
like it should either be running and active, or it should be closed.

[tbarzic, 2017/05/04 20:58:30]

To preserve the state of the app window (and be able to show it behind the user
pods) when lock screen user pod UI is active.

+};
+
+// Used by a client (e.g. Chrome) to notify ash of tray action handlers’ 
+// state changes.
+interface TrayActionHandlerController {

[James Cook, 2017/05/03 23:31:50]

Sorry to thrash on names. Our preferred naming style is:

mojom::Foo for the mojo interface (here)
ash::Foo for the implementation in ash
FooClient for the client/delegate in chrome

The word "controller" in existing interfaces reflects the fact we were bolting
things onto existing ash classes called controller.

In this case, what do you think of:

mojom::TrayAction / ash::TrayAction for the ash piece (It's an "action" button
that lives on the tray)

and

TrayActionClient or TrayActionHandler in chrome

btw, I like to use tools/git/move_source_file.py and tools/git/mffr.py for these
sorts of renames

[tbarzic, 2017/05/04 20:58:30]

Don't be sorry :) I like having better names...

+   // Sets the client to be used to handle action requests.
+   SetClient(TrayActionHandlerClient action_handler);
+
+  // Updates action handler state for a tray action.

[James Cook, 2017/05/03 23:31:50]

Is it required to have a client before calling this? Either way, document it.

[tbarzic, 2017/05/04 20:58:30]

Done.

+  UpdateActionHandlerState(TrayActionHandlerAction action,
+                           TrayActionHandlerState state);
+};
+
+// Used by ash to request Chrome to handle an action.
+interface TrayActionHandlerClient {
+  // Requests an action to be handled.
+  RequestHandleAction(TrayActionHandlerAction action);
+};

[James Cook, 2017/05/03 23:31:50]

Nice interface docs, btw.

[tbarzic, 2017/05/04 20:58:30]

Acknowledged.