[Navigation Experiment] Add WKBasedNavigationManagerImpl.

ios/web/web_state/ui/web_view_navigation_proxy.h

+// 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_WEB_WEB_STATE_UI_WEB_VIEW_NAVIGATION_PROXY_H_
+#define IOS_WEB_WEB_STATE_UI_WEB_VIEW_NAVIGATION_PROXY_H_
+
+@class NSArray;
+@class WKBackForwardListItem;
+
+namespace web {
+
+// Interface to expose navigation related functionality on WKWebView.

[Eugene But (OOO till 7-30), 2017/06/29 16:25:04]

If we end up with keeping the wrapper, could you please explain in the comments
that the purpose of proxy is to limit WKWebView interface.

[danyao, 2017/06/29 22:03:29]

Acknowledged.

+class WebViewNavigationProxy {
+ public:
+  virtual ~WebViewNavigationProxy() {}
+
+  virtual bool CanGoBack() const = 0;
+  virtual bool CanGoForward() const = 0;
+  virtual void GoBack() const = 0;
+  virtual void GoForward() const = 0;
+  virtual void GoToBackForwardListItem(WKBackForwardListItem* item) const = 0;
+
+  virtual WKBackForwardListItem* GetCurrentItem() const = 0;

[Eugene But (OOO till 7-30), 2017/06/29 01:48:19]

Sorry I just realized that proxy still exposes WK primitives, which I think
defeats the purpose of wrapping WKWebView. WebViewNavigationProxy does not
really help with testing, because WKWebView can be easily mocked and it does not
encapsulate the fact that WKWebView is used. Maybe I'm missing something?

[danyao, 2017/06/29 16:05:26]

Ah I didn't realize that I can use OCMockObject. So this proxy is probably not
particularly useful, other than limiting the caller to only the navigation
related calls. I don't think a thicker layer of abstraction makes sense, because
that's essentially what WKBasedNavigationManager is.

I'm tempted to keep this class, because I don't like the alternatives:
- We can expose WKWebView* from CRWWebController, but it makes me uncomfortable
to expose the entire API
- We can push the APIs into NavigationManagerDelegate, but now it adds 5 methods
to several different classes.

The second alternative seems less objectionable to me than the first. What do
you think?

[Eugene But (OOO till 7-30), 2017/06/29 16:25:04]

Yeah, second alternative adds more code to WebController, which is something
that we should try to avoid (so I don't like it either).

WKBasedNavigationManager is a wrapper around WKWebView API. NM is so tightly
coupled with WKWebView API that making a separate abstraction layer does not
really add much. Do you think that exposing whole WKWebView interface to
WKBasedNavigationManager will cause a problems in the future? Maybe instead of
building a wrapper we can do something with Objective-C protocol (protocol will
have small subset of WKWebView APIs) or NSProxy object? I'm almost convinced
that keeping WebViewNavigationProxy wrapper is fine.

+  virtual NSArray* GetBackList() const = 0;
+  virtual NSArray* GetForwardList() const = 0;
+  virtual WKBackForwardListItem* GetItemAtOffset(int offset) const = 0;
+};
+
+}  // namespace web
+
+#endif  // IOS_WEB_WEB_STATE_UI_WEB_VIEW_NAVIGATION_PROXY_H_