Use floating labels for preference forms

chrome/browser/android/preferences/autofill/autofill_profile_bridge.cc

+// Copyright 2015 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 "chrome/browser/android/preferences/autofill/autofill_profile_bridge.h"
+
+#include <jni.h>
+
+#include "base/android/jni_android.h"
+#include "base/android/jni_array.h"
+#include "base/android/jni_string.h"
+#include "base/bind.h"
+#include "jni/AutofillProfileBridge_jni.h"
+#include "third_party/libaddressinput/src/cpp/include/libaddressinput/address_ui.h"
+#include "third_party/libaddressinput/src/cpp/include/libaddressinput/address_ui_component.h"
+#include "third_party/libaddressinput/src/cpp/include/libaddressinput/localization.h"
+#include "ui/base/l10n/l10n_util.h"
+
+using base::android::ConvertJavaStringToUTF8;
+using base::android::ToJavaArrayOfStrings;
+using base::android::ToJavaIntArray;
+

[Evan Stade, 2015/01/28 03:07:47]

namespace autofill

[Theresa, 2015/01/28 03:33:47]

Re comment from newt@: consensus on chromium-dev@ is not to use namespaces in
src/chrome.

[Evan Stade, 2015/01/29 01:07:22]

The convention in autofill code in src/chrome is to use namespace autofill
because it usually relies heavily on stuff in components/autofill, which uses
that namespace. 

If you still don't want to add this namespace, you don't need ::i18n everywhere,
which is only necessary to distinguish ::i18n from ::autofill::i18n.

[Theresa, 2015/01/29 05:22:14]

I am using a method from components/autofill now, so I'll follow convention and
add the autofill namespace.

+static void GetAvailableCountries(JNIEnv* env,
+                                  jclass clazz,
+                                  jobject j_country_list) {
+  std::vector<std::string> region_codes =
+      ::i18n::addressinput::GetRegionCodes();
+  Java_AutofillProfileBridge_stringArrayToList(env,
+                                               ToJavaArrayOfStrings(
+                                                   env, region_codes).obj(),
+                                               j_country_list);
+}
+
+static void GetAddressUiComponents(JNIEnv* env,
+                                   jclass clazz,
+                                   jstring j_country_code,
+                                   jstring j_language_tag,
+                                   jobject j_id_list,
+                                   jobject j_name_list) {
+  std::string best_language_tag;
+  std::string language_code;
+  std::vector<int> component_ids;
+  std::vector<std::string> component_labels;
+  ::i18n::addressinput::Localization localization;
+  localization.SetGetter(l10n_util::GetStringUTF8);
+
+  // Format ui_langage_tag by replacing _'s with -'s. The Java strings coming
+  // from Android are in the format en_US and the C++ equivalent is en-US

[Evan Stade, 2015/01/28 03:07:47]

It's not Java vs. C++. Hypens are used in the IETF language tag.

It looks like the underscores are coming from
::i18n::addressinput::GetRegionCodes(), not Android. Why are these not using
hypens? Why does ::i18n::addressinput::BuildComponents expect something
different from what ::i18n::addressinput::GetRegionCodes returns? We must have
run into this somewhere else in the code.

[newt (away), 2015/01/28 03:15:26]

Also, beware the Java's Locale.getDefault() returns different values for a
couple special locales (e.g. Locale.getDefault() returns "iw" for Hebrew,
instead of the standard "he"). You'll need to be careful to compensate for this
(we *might* have an existing function for this) if libaddressinput doesn't
understand "iw" and the other non-standard language codes.

[Theresa, 2015/01/28 03:33:47]

estade@ - This string does come from Android, around line 214 in
AutofillProfileEditor.java; it passes Locale.getDefault().toString() as an
argument.
I'll spend some more time looking at libaddressinput's language codes and
Android's Locale and it's BCP-47 compliance (it looks like new methods were
added in API level 21 for BCP-47 support. First, I'll try dropping the argument
and just getting the current language tag from some c++ class; I hadn't realized
Android was using non-standard (or a different standard) language tags.

+  std::string language_tag = ConvertJavaStringToUTF8(env, j_language_tag);
+  std::replace(language_tag.begin(), language_tag.end(), '_', '-');
+
+  std::vector<::i18n::addressinput::AddressUiComponent> ui_components =
+      ::i18n::addressinput::BuildComponents(
+          ConvertJavaStringToUTF8(env, j_country_code), localization,
+          language_tag, &best_language_tag);
+
+  for (auto ui_component : ui_components) {
+    component_ids.push_back(ui_component.field);
+    component_labels.push_back(ui_component.name);
+  }
+
+  Java_AutofillProfileBridge_intArrayToList(env,
+                                            ToJavaIntArray(
+                                                   env, component_ids).obj(),
+                                               j_id_list);
+  Java_AutofillProfileBridge_stringArrayToList(env,
+                                               ToJavaArrayOfStrings(
+                                                   env, component_labels).obj(),
+                                               j_name_list);
+}
+
+// static
+bool RegisterAutofillProfileBridge(JNIEnv* env) {
+  return RegisterNativesImpl(env);
+}