SDCAlertController doesn't queue alerts

[futuretap]

Two subsequent alerts presented using SDCAlertController are not queued the way UIAlertController does. Is there an easy way to add this?

[sberrevoets]

As far as I know, this is not possible at all with UIAlertController. What behavior are you looking for exactly?

[futuretap]

I'm almost certain that UIAlertController prevents displaying two alerts on top of each other. They would be displayed sequentially, so alert 2 would be displayed after dismissing alert 1. And this is exactly what I want.

[sberrevoets]

let alert = UIAlertController(title: "Test", message: "Message", preferredStyle: .Alert)
alert.addAction(UIAlertAction(title: "OK", style: .Cancel, handler: nil))
presentViewController(alert, animated: true, completion: nil)

let alert2 = UIAlertController(title: "Test 2", message: "Message 2", preferredStyle: .Alert)
alert2.addAction(UIAlertAction(title: "OK", style: .Cancel, handler: nil))
presentViewController(alert2, animated: true, completion: nil)

This spits out a message in the console: Warning: Attempt to present <UIAlertController: 0x7f8793656400> on <ViewController: 0x7f8793474340> which is already presenting <UIAlertController: 0x7f879358dce0>

After dismissing the first alert, the second alert is then not shown.

[futuretap]

OK, thanks for testing this. I was right in that I never saw two UIAlerts on top of each other. I was wrong in that the second alert isn't queued but just discarded.

I guess I'll have to implement some kind of queuing on top of SDCAlertController.

[sberrevoets]

Yeah, this is one of the unfortunate changes that came along with UIAlertController. Check out this year's "Advanced NSOperations" session from WWDC, they explain how a queuing mechanism would work.

I can also look at implementing this on SDCAlertController itself, but I want to release the Swift version first (which should be soon).

[gmondada]

I suggest that SDCAlertController just has a callback/delegate that tells when it is dismissed. In this way, the enqueueing mechanism can be implemented in a separate class and SDCAlertController can continue behaving just as a view controller. Another solution is to make the SDCAlertController class open (instead of public), in order to let us implement the needed behaviour in a subclass as we can with UIAlertController.

[sberrevoets]

I'm not a fan of opening up SDCAlertController as that's a permanent decision (can't go back to public later) for a "temporary" problem that I think can be solved in a different way.

I looked into this at some point, and implementation aside I think there are some other questions to look at. For example, should it be possible to "dismiss()" an alert that's been enqueued to prevent it from showing? What should the animations look like? What should happen to the keyboard if 2 alerts with text fields are shown right after each other?

Depending on the answers to these (and probably more) questions, it may not be worth incurring the complexity for only a few cases where it's a little more work to get a few alerts in a row.