Making answer card to behave like other results.

ui/app_list/views/search_result_answer_card_view.h

+// Copyright 2017 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.
+
+#ifndef UI_APP_LIST_VIEWS_SEARCH_RESULT_ANSWER_CARD_VIEW_H_
+#define UI_APP_LIST_VIEWS_SEARCH_RESULT_ANSWER_CARD_VIEW_H_
+
+#include "ui/app_list/app_list_model_observer.h"
+#include "ui/app_list/views/search_result_container_view.h"
+
+namespace app_list {
+
+class AppListModel;
+class SearchResultPageView;
+
+namespace {
+class SearchAnswerContainerView;
+}  // namespace

[xiyuan, 2017/05/25 16:42:53]

nit: "// namespace" is not needed for forward decl

[vadimt, 2017/05/25 20:15:16]

Done.

+
+// Result container for the search answer card.
+class APP_LIST_EXPORT SearchResultAnswerCardView

[xiyuan, 2017/05/25 16:42:53]

nit: The name is a bit confusing. It is the container of search answer view, not
the answer card itself. How about call it SearchAnswserCardContainerView ?

[vadimt, 2017/05/25 20:15:16]

There are 2 sibling classes:
SearchResultListView
SearchResultTileItemListView
So the naming rule looks like:
SearchResultXView.
Since X is AnswerCard (essentially), I came with this name.

(The third sibling, though, doesn't play by rules:
StartPageView::StartPageTilesContainer, but I prefer following the majority.)

[xiyuan, 2017/05/25 20:52:04]

The name of the two siblings are clear to see that they are containers (both
names have "List" in it). They start with SearchResult because they carry views
for app_list::SearchResult. So SearchResultListView is a list of views
representing SearchResult and SearchResultTileItemListView is a list of tile
view of SearchResult. It is clear to tell what they are from their names.

But for this class, it is hard to tell from its name that it is a container for
the actual answer card view. And this class does not have direct relationship
with SearchResult other than it is derived from SearchResultContainerView. 

Anyway, it is a nit and I can live with the name.

[vadimt, 2017/05/25 22:59:04]

Cool; here I'm leaving my version; thanks!

+    : public SearchResultContainerView,
+      public AppListModelObserver {
+ public:
+  SearchResultAnswerCardView(AppListModel* model,
+                             SearchResultPageView* search_results_page_view,
+                             views::View* search_answer_view);
+  ~SearchResultAnswerCardView() override;
+
+  // Overridden from SearchResultContainerView:
+  void OnContainerSelected(bool from_bottom,
+                           bool directional_movement) override;
+  void NotifyFirstResultYIndex(int y_index) override {}
+  int GetYSize() override;
+
+  // Overridden from views::View:
+  const char* GetClassName() const override;
+
+ private:
+  // Overridden from SearchResultContainerView:

[xiyuan, 2017/05/25 16:42:53]

nit: Can we group overriddens from the same interface together?

[vadimt, 2017/05/25 20:15:16]

Done.

+  int DoUpdate() override;
+  void UpdateSelectedIndex(int old_selected, int new_selected) override;
+
+  // Overridden from AppListModelObserver
+  void OnSearchAnswerAvailableChanged(bool has_answer) override;
+
+  // Unowned pointer to application list model.
+  AppListModel* const model_;
+  // Pointer to the container of the search answer; owned by the view hierarchy.

[xiyuan, 2017/05/25 16:42:53]

nit: insert an empty line before

[vadimt, 2017/05/25 20:15:16]

Done.

+  // It's visible iff we have a search answer result.
+  SearchAnswerContainerView* const search_answer_container_view_;
+
+  DISALLOW_COPY_AND_ASSIGN(SearchResultAnswerCardView);
+};
+
+}  // namespace app_list
+
+#endif  // UI_APP_LIST_VIEWS_SEARCH_RESULT_ANSWER_CARD_VIEW_H_