[ios] Adds support for Find in Page to the new architecture.

ios/clean/chrome/browser/ui/find_in_page/find_in_page_mediator.h

Index: ios/clean/chrome/browser/ui/find_in_page/find_in_page_mediator.h
diff --git a/ios/clean/chrome/browser/ui/find_in_page/find_in_page_mediator.h b/ios/clean/chrome/browser/ui/find_in_page/find_in_page_mediator.h
new file mode 100644
index 0000000000000000000000000000000000000000..23796a7f0be640ab3523678a59e2a7f477537abc
--- /dev/null
+++ b/ios/clean/chrome/browser/ui/find_in_page/find_in_page_mediator.h
@@ -0,0 +1,46 @@
+// 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.
+
+#ifndef IOS_CLEAN_CHROME_BROWSER_UI_FIND_IN_PAGE_FIND_IN_PAGE_MEDIATOR_H_
+#define IOS_CLEAN_CHROME_BROWSER_UI_FIND_IN_PAGE_FIND_IN_PAGE_MEDIATOR_H_
+
+#include "base/macros.h"
+#include "ios/shared/chrome/browser/tabs/web_state_list_observer.h"
+#include "ios/web/public/web_state/web_state_observer.h"
+
+@protocol FindInPageConsumer;
+@class FindInPageModel;
+
+class WebStateList;
+
+@protocol FindInPageMediatorDelegate
+// Called when the mediator needs a non-nil consumer. Implementors must call
+// set_consumer() with a non-nil consumer before returning.
+- (void)createConsumer;

[rohitrao (ping after 24h), 2017/03/14 01:10:37]

8) In general, feature code can trigger model queries even when the
corresponding UI is hidden.  In the specific case of this mediator, we may get
FIP results when the UI is closed and no consumer exists.  I've addressed this
by introducing a delegate interface that allows the mediator to request a
non-nil consumer (which will generally mean starting the coordinator and showing
the UI).

[marq (ping after 24h), 2017/03/16 13:37:05]

I'm not 100% happy with this pattern, but I'm not sure why (yet).

[rohitrao (ping after 24h), 2017/03/16 14:00:18]

We'll also have the opposite scenario, where "model" changes can cause the UI to
be hidden and destroyed.  (For example, when you switch from a tab that's
currently finding-in-page to a different tab that is not.)

+@end
+
+class FindInPageMediator : public WebStateListObserver {

[marq (ping after 24h), 2017/03/16 13:37:05]

Other mediators are (so far) ObjC objects, so we should either change this, or
change all of the others.

The advantage of keeping to ObjC is that a common way to factor complexity out
of a coordinator will be to extract some logic into a mediator.

[rohitrao (ping after 24h), 2017/03/16 14:00:18]

Is it important to be consistent across mediators, or is this a case where we
can pick the language that fits best for a given mediator, case-by-case?

For FIP, I will eventually need a C++ object to listen for callbacks from the
FindTabHelper.  (I also need a WebStateListObserver, but we've already bridged
that to ObjC.)  Given the situation, it seemed simpler to have a single C++
object, but it's not hard to do it the other way.

[marq (ping after 24h), 2017/03/17 14:45:33]

On one hand, consistency. On the other hand, mediator is a pattern, so we should
be able to implement it in whatever language makes sense.

So I guess leave it as is for now, but I think there will be a general pull
towards having mediators be ObjC. We'll see.

+ public:
+  FindInPageMediator(WebStateList* web_state_list,
+                     id<FindInPageMediatorDelegate> delegate);
+  ~FindInPageMediator() override;
+
+  // Sets the consumer for this mediator.  Can be called with nil, in cases
+  // where there is no current consumer.
+  void set_consumer(id<FindInPageConsumer> consumer) { consumer_ = consumer; }
+
+  // Called when the model signals that new results are available.
+  void OnFindInPageResultsAvailable(FindInPageModel* model);
+
+  // web::WebStateListObserver implementation.

[lpromero, 2017/03/14 17:17:56]

WebStateListObserver doesn't seem to be in the web namespace. Why this comment
at all?

[rohitrao (ping after 24h), 2017/03/16 14:00:17]

Cruft that will be useful once TabCoordinator stops being specific to a single
WebState.

+
+ private:
+  WebStateList* web_state_list_;

[marq (ping after 24h), 2017/03/16 13:37:05]

Why does this need the list rather than a specific webstate?

[rohitrao (ping after 24h), 2017/03/16 14:00:17]

Once TabCoordinator supports multiple WebStates, this mediator will become a
WebStateList observer and update the find bar UI whenever the active WebState
changes.

[marq (ping after 24h), 2017/03/17 14:45:33]

Or should something else be that observer and just update a WebState property on
this object? Should it be this object's job to know about the list of webStates?
This is probably part of a larger discussion about what happens when the active
webState changes.

[rohitrao (ping after 24h), 2017/03/20 23:37:55]

As you said, we can either farm this out and make everyone a
WebStateListObserver, or we can push updates down from the top.  I'm inclined to
the former, because otherwise we're going to add a bunch of plumbing that looks
similar to WebStateListObserver.

Is one of the options more testable than the other?

+  __strong id<FindInPageConsumer> consumer_;
+  __weak id<FindInPageMediatorDelegate> delegate_;
+
+  DISALLOW_COPY_AND_ASSIGN(FindInPageMediator);
+};
+
+#endif  // IOS_CLEAN_CHROME_BROWSER_UI_FIND_IN_PAGE_FIND_IN_PAGE_MEDIATOR_H_