Replace OnPageTranslate Obsever by a responder of delegate.

components/translate/core/browser/translate_infobar_delegate.h

Index: components/translate/core/browser/translate_infobar_delegate.h
diff --git a/components/translate/core/browser/translate_infobar_delegate.h b/components/translate/core/browser/translate_infobar_delegate.h
index 6a8a77b94dbb3de095bcfff8d57f2ea1170a0868..cb4a7bc4c002d5b10f99137629fe1d2a025ac689 100644
--- a/components/translate/core/browser/translate_infobar_delegate.h
+++ b/components/translate/core/browser/translate_infobar_delegate.h
@@ -37,6 +37,19 @@ class TranslateManager;
 
 class TranslateInfoBarDelegate : public infobars::InfoBarDelegate {
  public:
+  // A responder to handle different translate steps' UI changes.

[groby-ooo-7-16, 2017/05/20 21:30:39]

If I remember correctly, you don't need this class at all.

ChromeTranslateClient::CreateInfobar is called every single time the
TranslateStep changes. You can query that value from the delegate. (See
chrome/browser/ui/cocoa/infobars/translate_infobar_base.mm for an example)

If I read the Android code correctly, that means you're rebulding the Infobar
every time TranslateStep changes anyways, with a new delegate. 

Can you use that fact instead of adding an additional object? (Or is this subtly
different on Android, and I am misunderstanding?)

[Leo, 2017/05/21 04:15:20]

I think the fact you described is  the original logic for handling each step of
the translation.

In our new design, translate infobar will be created only once then it will be
reused for responding all the possible steps later. 

Eg. after showing the initialized UI, when user asks for translating. Old one
will create a "Translating" UI to replace initialized UI but in the new design, 
we will modify part of the current UI to indicate that it's being translating.

Since the rule of creating its own UI for each step is defined in very common
level and followed by its hierarchical logics, which means breaking the rule
will take a lots of cost(eg. in bubble UI, translateDelegate is abandoned and
they have to create quite a few modules to make it work...)

In our case, in order to reuse the current code as much as possible, adding a
responder(or observer) inside translateDelegate is the smallest change we can
do.

+  class Responder {

[groby-ooo-7-16, 2017/05/20 21:30:39]

We usually call those "Observer"

[Leo, 2017/05/22 09:08:10]

Thanks for questioning the class name, I have struggled quite a while to name
it. "Observer" was one of my options and "Responder" was closer.

The role of this class here is kind of A commitment. If Any delegate was
assigned with this class, it means this delegate will let it (the class
assigned) to handle all the possible steps without recreating another delegate
or infobar.

Now I am persuaded, so I Changed the name to "Observer".

+   public:
+    // Handles UI changes on the translate step given.
+    virtual void ActionOnStep(translate::TranslateStep step,

[groby-ooo-7-16, 2017/05/20 21:30:39]

Suggested name: OnTranslateStepChanged()

That's closer to the usual Chrome naming scheme.

[Leo, 2017/05/22 09:08:10]

Thanks, Done.

+                              TranslateErrors::Type error_type){};
+    // Return whether user declined translate service.

[groby-ooo-7-16, 2017/05/20 21:30:39]

Does "declined" include dismissing the infobar, or is it an active decline only?

[Leo, 2017/05/22 09:08:10]

"declined" here is just a flag used to evaluate user's behaviors. PM and UX of
the new design, want to understand users better, in our user flow, "declined"
means things below
1, user closed the infobar without using it at all.
2, user didn't touch the infobar at all until the page got navigated
3, user kept the infobar for a few seconds (eg. 20s) without touching
anything...

All these behaviors are recorded in the front-end and before user closing
infobar, we need a clear decision about whether this infobar server is declined
by user or not. If yes, we will commit a "Declined" logging.

So the method itself is just a few checking, and doesn't introduce any operation
of the infobar.

I will rename it to IsDeclinedByUser()

[groby-ooo-7-16, 2017/05/22 14:34:11]

Thank you - the reason I asked was that we use "Declined" for many different
things in the translate system. It's very helpful to have a name that explains!

+    virtual bool Declined();
+
+   protected:
+    virtual ~Responder() {}
+  };
+
   static const size_t kNoIndex;
 
   ~TranslateInfoBarDelegate() override;
@@ -182,6 +195,9 @@ class TranslateInfoBarDelegate : public infobars::InfoBarDelegate {
   // May return NULL if the driver has been destroyed.
   TranslateDriver* GetTranslateDriver();
 
+  // Set a responder.
+  void SetResponder(Responder* responder);
+
  protected:
   TranslateInfoBarDelegate(
       const base::WeakPtr<TranslateManager>& translate_manager,
@@ -219,6 +235,10 @@ class TranslateInfoBarDelegate : public infobars::InfoBarDelegate {
   // (due to language detection, preferences...)
   bool triggered_from_menu_;
 
+  // A responder to handle front-end changes on different steps.
+  // It's only used when we try to reuse the existing UI.
+  Responder* responder_;
+
   DISALLOW_COPY_AND_ASSIGN(TranslateInfoBarDelegate);
 };