Add InfoBarPickerController for displaying a picker view from an infobar

ios/chrome/browser/infobars/infobar_picker_view.h

Index: ios/chrome/browser/infobars/infobar_picker_view.h
diff --git a/ios/chrome/browser/infobars/infobar_picker_view.h b/ios/chrome/browser/infobars/infobar_picker_view.h
new file mode 100644
index 0000000000000000000000000000000000000000..faeee9b6b9fa39e509763029a1e4938e527f1c4b
--- /dev/null
+++ b/ios/chrome/browser/infobars/infobar_picker_view.h
@@ -0,0 +1,27 @@
+// Copyright 2016 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_INFOBARS_INFOBAR_PICKER_VIEW_H_
+#define IOS_CHROME_BROWSER_INFOBARS_INFOBAR_PICKER_VIEW_H_
+
+#import <UIKit/UIKit.h>
+
+@class InfoBarPickerView;
+
+@protocol InfoBarPickerViewDelegate<NSObject>

[marq (ping after 24h), 2016/06/28 13:43:18]

Instead of having a protocol for passing UI events up to a controller, I'd like
to see the target/action pattern used here.

The owning VC would implement these methods (which would have to follow the
target/action pattern and take no parameter or (id)sender, which will be the
control that triggers them).

+- (void)infoBarPickerViewPressedDone:(InfoBarPickerView*)infoBarPicker;
+- (void)infoBarPickerViewPressedCancel:(InfoBarPickerView*)infoBarPicker;
+@end
+
+@interface InfoBarPickerView : UIView
+
+@property(nonatomic, weak) id<InfoBarPickerViewDelegate> delegate;
+@property(nonatomic, weak) id<UIPickerViewDelegate> pickerDelegate;

[marq (ping after 24h), 2016/06/28 13:43:18]

If the picker view is public, then its delegate and data source are, too, so
there's no real need for these properties.

My current thinking for the coordinator pattern is that the view controller
owned by the coordinator will handle view-to-controller communications and
initial view setup ("binding" model values to the view), but it will signal to
the coordinator (by means of a protocol) any actions that should mutate model
state. Additionally, if the mapping from whatever model code provides the
content for the VC's views is nontrivial, it should be handled by a mediator
object. In any case, since the coordinator is creating the view controller, it
should provide it with any model or mediator objects it needs to populate its
views.

[Jackie Quinn, 2016/06/28 13:51:45]

That makes sense.

Would it make more sense to just write this class as  a view controller instead
of a custom view? All it's really doing is view setup and binding.

[marq (ping after 24h), 2016/06/28 14:43:21]

Well, maybe. The view layout isn't too involved here, but I'm also trying to get
as many things off the plate of view controllers as possible, and laying out
views is one of the areas that's still kind of muddy. This case is probably
simple enough that it can all be in a view controller without too much scope
creep. I would still want to see target/action set up generically, however, so
that the view code can easily be transplanted out.

+@property(nonatomic, weak) id<UIPickerViewDataSource> pickerDataSource;
+@property(nonatomic, retain) UINavigationBar* navigationBar;
+@property(nonatomic, retain) UIPickerView* pickerView;
+
+@end
+
+#endif  // IOS_CHROME_BROWSER_INFOBARS_INFOBAR_PICKER_VIEW_H_