[AiS] Add a structured representation of Answer JSON.

chrome/android/java/src/org/chromium/chrome/browser/omnibox/AutocompleteController.java

Index: chrome/android/java/src/org/chromium/chrome/browser/omnibox/AutocompleteController.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/omnibox/AutocompleteController.java b/chrome/android/java/src/org/chromium/chrome/browser/omnibox/AutocompleteController.java
index 2835c612904ac874983f808944c923e87f8e1f31..dba52a053ff25717fd13ebde3ec7b1df78e33803 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/omnibox/AutocompleteController.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/omnibox/AutocompleteController.java
@@ -9,6 +9,7 @@ import android.text.TextUtils;
 import com.google.common.annotations.VisibleForTesting;
 
 import org.chromium.base.CalledByNative;
+import org.chromium.chrome.browser.omnibox.OmniboxSuggestion.Type;
 import org.chromium.chrome.browser.profiles.Profile;
 import org.chromium.content_public.browser.WebContents;
 
@@ -209,6 +210,14 @@ public class AutocompleteController {
     @CalledByNative
     private static void addOmniboxSuggestionToList(List<OmniboxSuggestion> suggestionList,
             OmniboxSuggestion suggestion) {
+        // Don't add answer suggestions if their answer contents were malformed and failed to parse
+        // (and thus populate the answer property).
+        // TODO(jdonnelly): Land the new type CL before landing this CL then switch to the
+        // type-based check:
+        //if (suggestion.getType() == SEARCH_SUGGEST_ANSWER && !suggestion.hasAnswer()) {
+        if (!TextUtils.isEmpty(suggestion.getAnswerContents()) && !suggestion.hasAnswer()) {

[Ted C, 2014/06/13 23:54:16]

I just remembered that we log selections based on position.  If we change the
ordering in the list, then these will be off.

Take a look at onSuggestionSelected(...) below.  I don't know if it is something
we can cull from the native results or not.  You'll probably want to check with
pkasting@ about that.  Even if we add position information to the suggestions
and separate it from the list position, I suspect it would mess up our tracking
as it would appear people are clicking on suggestions further down the list.

I don't know if falling back to a search suggestion is better or not than this.

[Justin Donnelly, 2014/06/16 19:32:54]

Well, on further reflection, maybe fallback is better anyway.  If we get an
Answer for "weather los angeles" I think that replaces the simple "weather los
angeles" suggestion we otherwise would have gotten.  To be honest, my motivation
to avoid fallback was just that fallthrough in a switch statement makes me
queasy.  Might be better to just rework that code a bit to avoid the
fallthrough.

But then there's Peter's point in my other CL about logging something as an
Answer and then later displaying it as just a regular suggestion.  Let's discuss
in the meeting this afternoon.

[Justin Donnelly, 2014/06/17 21:34:03]

Per our discussion yesterday, removed this code.  We'll stick with fallback to
display as a regular search suggestion in SuggestionView.  This means we'll
potentially log answers incorrectly if the JSON is malformed until we move the
JSON parsing and validation to the C++ side.  Since we're just launching as a 1%
experiment and there's no reason to believe that the JSON will ever be
malformed, we're not overly concerned about this.

+            return;
+        }
         suggestionList.add(suggestion);
     }