Add ContentSuggestionsMediator

ios/chrome/browser/ui/content_suggestions/content_suggestions_data.h

Index: ios/chrome/browser/ui/content_suggestions/content_suggestions_data.h
diff --git a/ios/chrome/browser/ui/content_suggestions/content_suggestions_data.h b/ios/chrome/browser/ui/content_suggestions/content_suggestions_data.h
new file mode 100644
index 0000000000000000000000000000000000000000..fb83376d967336294aaecc7d577f8e062151ece8
--- /dev/null
+++ b/ios/chrome/browser/ui/content_suggestions/content_suggestions_data.h
@@ -0,0 +1,18 @@
+// 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 IOS_CHROME_BROWSER_UI_CONTENT_SUGGESTIONS_CONTENT_SUGGESTIONS_DATA_H_
+#define IOS_CHROME_BROWSER_UI_CONTENT_SUGGESTIONS_CONTENT_SUGGESTIONS_DATA_H_
+
+#import <UIkit/UIKit.h>
+
+// Protocol to give data to the UI of the ContentSuggestions.
+@protocol ContentSuggestionsData

[marq (ping after 24h), 2017/01/27 12:44:55]

Avoid very general words in name like 'Data', "Value', 'Object', 'Result'. This
sounds like it can just be a 'ContentSuggestion', maybe?

[gambard, 2017/01/30 15:19:17]

Done.

+

[marq (ping after 24h), 2017/01/27 12:44:55]

I'm also not sure about the merits of defining data containers like this with
protocols. A superclass seems fine as long as it remains unencumbered by
dependencies.

Protocols are great for defining interfaces with behavior behind them, but they
are limited in how we can type-check them, and -conformsToProtocol can actually
have performance issues in some cases. So *maybe* it's better to just use a
class here.

[gambard, 2017/01/30 15:19:17]

I will use the class directly for now. If it causes trouble I will revert back
to protocol.

+@property(nonatomic, readonly, copy) NSString* title;
+@property(nonatomic, readonly, strong) UIImage* image;
+
+@end
+
+#endif  // IOS_CHROME_BROWSER_UI_CONTENT_SUGGESTIONS_CONTENT_SUGGESTIONS_DATA_H_