[Android] Refactor NativeView to be able to use it for AutofillDialog.

ui/android/java/src/org/chromium/ui/NativeView.java

Index: ui/android/java/src/org/chromium/ui/NativeView.java
diff --git a/ui/android/java/src/org/chromium/ui/NativeView.java b/ui/android/java/src/org/chromium/ui/NativeView.java
new file mode 100644
index 0000000000000000000000000000000000000000..13ff45c8deef01c0c4ff1d806fe3843f076f313c
--- /dev/null
+++ b/ui/android/java/src/org/chromium/ui/NativeView.java
@@ -0,0 +1,55 @@
+// Copyright (c) 2012 The Chromium Authors. All rights reserved.

[joth, 2013/04/12 19:00:48]

2012 is over (multiple places)

[nilesh, 2013/04/12 19:07:10]

2013

[aurimas (slooooooooow), 2013/04/12 22:00:41]

Done.

+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.ui;
+
+import org.chromium.base.JNINamespace;
+import org.chromium.ui.ContainerViewDelegate;
+import org.chromium.ui.gfx.NativeWindow;
+
+/**
+ * NativeView class that is used to access the the ContainterViewDelegate. It should only be
+ * used to attach decorations like Autofill popup.

[joth, 2013/04/12 19:00:48]

maybe useful to also document this guys purpose from the chromium architecture
point of view: chrome expects to have a cross platform 'handle' to a system view
type; as views are java objects on android, this class exists to provide the
expected abstractions on the C++ side and allow it to be flexibly glued to a
java view at runtime. (Handwave/)

[aurimas (slooooooooow), 2013/04/12 22:00:41]

Done.

+ */
+@JNINamespace("ui")
+public class NativeView {
+    // Native pointer to the c++ ViewAndroid object.
+    private int mNativeViewAndroid = 0;
+    private final NativeWindow mNativeWindow;
+    public final ContainerViewDelegate mContainerViewDelegate;

[nilesh, 2013/04/12 19:07:10]

make it private final and add a getter if needed.

[aurimas (slooooooooow), 2013/04/12 22:00:41]

Done.

+
+    /**
+     * Constructs a View object.
+     */
+    public NativeView(NativeWindow nativeWindow, ContainerViewDelegate containerViewDelegate) {
+        mNativeViewAndroid = 0;
+        mNativeWindow = nativeWindow;
+        mContainerViewDelegate = containerViewDelegate;
+    }
+
+    /**
+     * Destroys the c++ ViewAndroid object if one has been created.
+     */
+    public void destroy() {

[joth, 2013/04/12 19:00:48]

in webview we need to allow ContentViewCore to cleanup nicely when GC'd. We use
CleanupReference to achieve that ... I think we'll need one on this guy too.

oh.. and you'll need to move CleanupReference to base. (I was actually hoping to
move it up to android_webview, as right now our one and only finalizer is on
AwContents and we rely on WebContents::UserData to delete all the
similar-lifetimed native objects when the owning AwContents (and hence
ContentViewCore) java objects have died.
... unless we can arrange for this not to be a native-object-owning java class,
and in the same pattern, lean on some existing appropriate life-timed native
object to do the cleanup? I'm not fully clear on the use cases to know if that's
reasonable

adding cleanup ref makes life a bit more complicated as you need to deal with
the java object going away but the native object may not yet know (the finalizer
can get delayed indefinitely). Also, need to be confident that when the native
object is finally deleted (via explicit destroy() or by finalizer) we don't have
any dangling pointers to that NativeView still lurking in other native objects.

[aurimas (slooooooooow), 2013/04/12 22:00:41]

So I was hoping that ContentViewCore.java is the owner ViewAndroid.java.

ViewAndroid.java is the owner view_android.cc object.

I though when ContentViewCore.java goes away, it would destroy ViewAndroid.java
and that in turn would kill view_android.cc. I was hoping that the
view_android.cc would not be destroyed in any other way.

So I guess that is an illusion?

[joth, 2013/04/16 04:02:42]

It's all an illusion.
ContentViewCore.destroy() will be called by a conscientious user that does
pro-active resource cleanup. For everyone else, we have to rely on finalizers.

+        if (mNativeViewAndroid != 0) {
+            nativeDestroy(mNativeViewAndroid);
+            mNativeViewAndroid = 0;
+        }
+    }
+
+    /**
+     * Returns a pointer to the c++ AndroidWindow object and calls the initializer if
+     * the object has not been previously initialized.
+     * @return A pointer to the c++ AndroidWindow.
+     */
+    public int getNativePointer() {
+        if (mNativeViewAndroid == 0) {
+            mNativeViewAndroid = nativeInit(mNativeWindow.getNativePointer());
+        }
+        return mNativeViewAndroid;
+    }
+
+    private native int nativeInit(int windowPtr);
+    private native void nativeDestroy(int nativeViewAndroid);
+}