Creates coordinators for displaying alerts

ios/chrome/browser/ui/alert_coordinator/alert_controller_coordinator.h

Index: ios/chrome/browser/ui/alert_coordinator/alert_controller_coordinator.h
diff --git a/ios/chrome/browser/ui/alert_coordinator/alert_controller_coordinator.h b/ios/chrome/browser/ui/alert_coordinator/alert_controller_coordinator.h
new file mode 100644
index 0000000000000000000000000000000000000000..b35171607c69de660b6073d5b5d8323f3995ced4
--- /dev/null
+++ b/ios/chrome/browser/ui/alert_coordinator/alert_controller_coordinator.h
@@ -0,0 +1,38 @@
+// 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_UI_ALERT_COORDINATOR_ALERT_CONTROLLER_COORDINATOR_H_
+#define IOS_CHROME_BROWSER_UI_ALERT_COORDINATOR_ALERT_CONTROLLER_COORDINATOR_H_
+
+#import <Foundation/Foundation.h>
+
+#include "base/ios/block_types.h"
+#import "ios/chrome/browser/chrome_coordinator.h"
+
+// A coordinator specialization for the case where the coordinator is
+// creating and managing an alert (popup or action sheet) to be displayed to the
+// user. This is an abstract class and should not be initialized directly. Use
+// one of its subclasses.
+@interface AlertControllerCoordinator : ChromeCoordinator

[lpromero, 2016/07/06 09:03:59]

How do we make sure we don't end up with a huge tree of subclasses? The issue
being if we want to share traits between two different subclasses. That was a
mess with GoogleKit content views.
Can't we compose somehow? Or just share the common interface with a protocol?

[gambard, 2016/07/07 08:57:43]

I used delegates for Model Alert and Action Sheet.

+
+// Whether the context menu is visible. This will be true after |-start| is
+// called until a subsequent |-stop|.
+@property(nonatomic, readonly, getter=isVisible) BOOL visible;
+// Message of the alert.
+@property(nonatomic, copy) NSString* message;
+
+// Adds an item at the end of the menu if |visible| is false.

[lpromero, 2016/07/06 09:03:59]

Instead of silently fail, should it DCHECK?

[gambard, 2016/07/07 08:57:43]

It does not fail, it does nothing. I think it is better than a DCHECK, but if
you think otherwise, please tell me.

+- (void)addItemWithTitle:(NSString*)title
+                  action:(ProceduralBlock)actionBlock
+             destructive:(BOOL)isDestructive;

[lpromero, 2016/07/06 09:03:59]

Pass a UIAlertActionStyle instead.

[gambard, 2016/07/07 08:57:43]

Ok but it crashes if two UIAlertActionStyleCancel are passed. It will do nothing
if a cancel button has been added.

+
+// Creates a cancel button. This button will be displayed at the end.

[lpromero, 2016/07/06 09:03:59]

I'd remove the word "Creates". What about:
// Adds a cancel item with a default title.

[gambard, 2016/07/07 08:57:43]

Done.

+- (void)addCancelButton;
+
+// Returns the number of action attached to the current alert.

[lpromero, 2016/07/06 09:03:59]

s/action/actions

[gambard, 2016/07/07 08:57:43]

Done.

+- (NSUInteger)actionCount;

[lpromero, 2016/07/06 09:03:59]

s/actionCount/actionsCount

[gambard, 2016/07/07 08:57:43]

Done.

+
+@end
+
+#endif  // IOS_CHROME_BROWSER_UI_ALERT_COORDINATOR_ALERT_CONTROLLER_COORDINATOR_H_