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

ui/android/view_android.h

Index: ui/android/view_android.h
diff --git a/ui/android/view_android.h b/ui/android/view_android.h
new file mode 100644
index 0000000000000000000000000000000000000000..0631b57a54bd2a4c38f4d75425e5a02a5f6ed419
--- /dev/null
+++ b/ui/android/view_android.h
@@ -0,0 +1,39 @@
+// Copyright (c) 2012 The Chromium Authors. All rights reserved.

[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.
+
+#ifndef UI_VIEW_ANDROID_H_

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

UI_ANDROID_VIEW_ANDROID_H

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

Done.

+#define UI_VIEW_ANDROID_H_
+
+#include <jni.h>
+#include "base/android/jni_helper.h"
+#include "base/android/scoped_java_ref.h"
+
+namespace ui {
+
+class WindowAndroid;
+
+// This class deals with the Android native window ref count.

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

i"m not sure what ref count that is?

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

Done.

+class ViewAndroid {

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

Can we get the java and native class names consistent, given they are identical
lifetimes?

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

Done.

+ public:
+  ViewAndroid(JNIEnv* env, jobject obj, WindowAndroid* window);

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

what's the lifetime relationship of |window| ?  it's safe to just hold a weak
pointer to it?

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

WindowAndroid has a life time of the application. It gets created by Main.java
and get removed once application is closed.

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

I see.

nit: I think you mean activity, not application. (Main is an activity, and
window_android.h seems to talk about activities).

Maybe comment here that WindowAndroid must outlive the view [and typically, is
bound to the lifetime of the android activity?]

However, now I get this I find a couple more problems:
1/ NativeWindow.java should be renamed to WindowAndroid.java for consistency
2/ NativeWindow.java has the same "assumes destroy() will be called" flaw as
with NativeView in this patch. (possibly can solve both together, although
NativeWindow is far less severe as it's only one leak per activity, rather than
per view), except...
3/ AwContents doesn't respect this contract, and it creating one NativeWindow
per WebView, not per activity. (iirc NativeWindow is to all intents a
placeholder in webview and so it's arbitrary when it's made. quick fix would be
to just turn it into a process-lifetimed singleton).

+
+  void Destroy(JNIEnv* env, jobject obj);
+
+  WindowAndroid* GetWindowAndroid();
+
+  base::android::ScopedJavaLocalRef<jobject> GetJavaObject();

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

note - will return NULL if the java side was GCed (but the native side not yet
finalized)

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

How can I fix this? Add null checks?

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

yeah.. we basically get this pattern that any time there's a native object with
long-lived relationship to java peer it must be prepared for the java side to
just disappear without any notice.

+
+  static bool RegisterViewAndroid(JNIEnv* env);
+
+ private:
+  ~ViewAndroid();
+  JavaObjectWeakGlobalRef weak_java_view_;
+  WindowAndroid* window_android_;
+
+  DISALLOW_COPY_AND_ASSIGN(ViewAndroid);
+};
+
+}  // namespace ui
+
+#endif  // UI_VIEW_ANDROID_H_