Settings People Revamp: Easy Unlock: Add browser proxy and setup flow.

chrome/browser/resources/settings/people_page/people_page.js

Index: chrome/browser/resources/settings/people_page/people_page.js
diff --git a/chrome/browser/resources/settings/people_page/people_page.js b/chrome/browser/resources/settings/people_page/people_page.js
index 6e5f80d6878ac1deb02ed79d3c8d43808e5dc9cb..831a0aa0c165712569ca75c85e0c9d802c11deb3 100644
--- a/chrome/browser/resources/settings/people_page/people_page.js
+++ b/chrome/browser/resources/settings/people_page/people_page.js
@@ -57,6 +57,14 @@ Polymer({
     profileName_: String,
 
 <if expr="chromeos">
+    /** @private {!settings.EasyUnlockBrowserProxyImpl} */
+    easyUnlockBrowserProxy_: {

[dpapad, 2016/03/16 22:17:01]

Nit: How about renaming this simply to "browserProxy_"? Since there is no other
browser proxy this component talks to, I think it is more readable.

[tommycli, 2016/03/17 00:33:26]

Done.

+      type: Object,
+      value: function() {
+        return settings.EasyUnlockBrowserProxyImpl.getInstance();

[dpapad, 2016/03/16 22:17:01]

Do you think it would be worth adding unit tests for <settings-people-page>? It
could test that the correct proxy methods are called when this element is
attached and also when each of the buttons is tapped.

If so, you might have to move this assignment within the ready() lifecycle
method instead (otherwise you will not have an opportunity to swap with the fake
proxy).

[tommycli, 2016/03/17 00:33:26]

Yes, the unit tests are in the very next patch I'm sending you. You may preview
it at https://codereview.chromium.org/1811813002, however, I have not
self-reviewed this yet, so it's not ready for a full review. I can combine the
two if you prefer.

In the unit tests, I modify the loadTimeData before I recreate the
settings-page-element for the test. Is that also acceptable?

[dpapad, 2016/03/17 00:52:23]

No need to merge them. I'll review the follow up once ready.

Regarding setting loadTimeData during testing, it seems fine, unless we have a
better solution.

The only alternative that comes to mind is to at least move any information that
does not need to be available in a synchronous way (if any) from loadTimeData to
a cr.sendWithPromise() call via the proxy. But I am guessing that what you have
in loadTimeData() is there because it is needed synchronously (otherwise
probably UI flicker would occur).

[tommycli, 2016/03/17 18:38:07]

Exactly. The data is retrieved via cr.sendWithPromise anyways, but making it
available within loadTimeData prevents the UI flicker.

+      },
+    },
+
     /**
      * True if Easy Unlock is allowed on this machine.
      * @private {boolean}
@@ -93,6 +101,8 @@ Polymer({
       this.addWebUIListener(
           'easy-unlock-enabled-status',
           this.handleEasyUnlockEnabledStatusChanged_.bind(this));
+      this.easyUnlockBrowserProxy_.getEnabledStatus().then(
+          this.handleEasyUnlockEnabledStatusChanged_.bind(this));
     }
 </if>
   },
@@ -175,6 +185,18 @@ Polymer({
     this.$.pages.setSubpageChain(['sync']);
   },
 
+<if expr="chromeos">
+  /** @private */
+  onEasyUnlockSetupTap_: function() {
+    this.easyUnlockBrowserProxy_.launchSetup();
+  },
+
+  /** @private */
+  onEasyUnlockTurnOffTap_: function() {
+    // TODO(tommycli): Implement Easy Unlock turn off functionality.
+  },
+</if>
+
   /** @private */
   onManageOtherPeople_: function() {
 <if expr="not chromeos">