Android: Extend ViewAndroid

ui/android/view_android.cc

Index: ui/android/view_android.cc
diff --git a/ui/android/view_android.cc b/ui/android/view_android.cc
new file mode 100644
index 0000000000000000000000000000000000000000..eba043b354f1ade2cd633f7e2bc9d396dbbdde9e
--- /dev/null
+++ b/ui/android/view_android.cc
@@ -0,0 +1,84 @@
+// Copyright 2016 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.
+
+#include "ui/android/view_android.h"
+
+#include <algorithm>
+
+#include "base/android/jni_android.h"
+#include "cc/layers/layer.h"
+
+namespace ui {
+
+using base::android::AttachCurrentThread;
+using base::android::JavaRef;
+using base::android::ScopedJavaLocalRef;
+
+ViewAndroid::ViewAndroid(const JavaRef<jobject>& delegate,

[Yusuf, 2016/07/08 16:35:05]

I feel like we need a comment paragraph somewhere that explains the current
state of who owns what and how they are connected. But can't decide what the
right place for it is. Probably either in CVCImpl or RWHVAndroid somewhere.

[no sievers, 2016/07/08 18:29:04]

I'm guessing it needs to evolve a bit but I can put some comments in the header
here.

Also see my other comments for what direction this is possibly going into. And
the discussion in https://codereview.chromium.org/2103243002/ where it's about
potentially bubbling up the adding removing of anchor views from the lower
native layer to the embedder through ViewAndroid (and its delegate).

[no sievers, 2016/07/08 19:22:10]

Done.

+                         WindowAndroid* root_window)
+    : parent_(nullptr), window_(root_window), delegate_(delegate) {}
+
+ViewAndroid::ViewAndroid() : parent_(nullptr), window_(nullptr) {}
+
+ViewAndroid::~ViewAndroid() {
+  if (parent_)
+    parent_->RemoveChild(this);
+
+  for (std::list<ViewAndroid*>::iterator it = children_.begin();
+       it != children_.end(); it++) {
+    DCHECK_EQ((*it)->parent_, this);
+    (*it)->parent_ = nullptr;
+  }
+}
+
+void ViewAndroid::AddChild(ViewAndroid* child) {

[Yusuf, 2016/07/08 16:35:05]

these(parent_ being accessible this much) worry me a bit. Also when we add a
ViewAndroid as a child, what do we do about the root_window in it? Should that
not be checked/removed/processed somehow?

[no sievers, 2016/07/08 18:29:04]

Good point. We could check that a child being added has no root window set.
 
Would it make sense if WindowAndroid was also a ViewAndroid so that it's
literally just the |parent_| at the root?

[no sievers, 2016/07/08 19:22:10]

Done.

[Yusuf, 2016/07/08 23:06:00]

I would say yes it would make sense for WindowAndroid to be a ViewAndroid, but
is it the case in any of the other platforms NativeWindow/View pairs? That might
be a reason to not to do it if there are no precedents.

Even if there are feel free to do that in a follow up patch.

+  DCHECK(child);
+  DCHECK(std::find(children_.begin(), children_.end(), child) ==
+         children_.end());
+
+  children_.push_back(child);
+  if (child->parent_)
+    parent_->RemoveChild(child);
+  child->parent_ = this;
+}
+
+void ViewAndroid::RemoveChild(ViewAndroid* child) {
+  DCHECK(child);
+  DCHECK_EQ(child->parent_, this);
+
+  std::list<ViewAndroid*>::iterator it =
+      std::find(children_.begin(), children_.end(), child);
+  DCHECK(it != children_.end());
+  children_.erase(it);
+  child->parent_ = nullptr;
+}
+
+WindowAndroid* ViewAndroid::GetWindowAndroid() const {
+  if (window_)
+    return window_;
+
+  return parent_ ? parent_->GetWindowAndroid() : nullptr;
+}
+
+void ViewAndroid::SetWindowAndroid(WindowAndroid* root_window) {
+  window_ = root_window;
+}
+
+const JavaRef<jobject>& ViewAndroid::GetViewAndroidDelegate()
+    const {
+  if (!delegate_.is_null())
+    return delegate_;
+
+  return parent_ ? parent_->GetViewAndroidDelegate() : delegate_;
+}
+
+cc::Layer* ViewAndroid::GetLayer() const {
+  return layer_.get();
+}
+
+void ViewAndroid::SetLayer(scoped_refptr<cc::Layer> layer) {
+  layer_ = layer;
+}
+
+}  // namespace ui