Thanks for the tip, I'll look into it.
(As a general thought, though, it would appear that UIAlertController
should be a singleton app-wide, and it should manage its own serialized
presentation. Any other solution seems like external plumbing to fix a
design problem.)
-Carl
> Pretty sure the WWDC 2015 video on NSOperations tackles a similar scenario
> in a quite elegant way. That might be worth investigating.
>
> Peter
>
>> On Nov 5, 2015, at 6:42 PM, Carl Hoefs <newsli...@autonomy.caltech.edu>
>> wrote:
>>
>> A queue of what? I would think that if only a single alert view can be
>> presented at a time, then iOS would serialize them and present them when
>> earlier ones complete. Is there no system-level solution to this?
>> -Carl
>>
>>
>>> Make a queue.
>>>
>>> Sent from my iPhone
>>>
>>>> On Nov 5, 2015, at 6:10 PM, Carl Hoefs
>>>> <newsli...@autonomy.caltech.edu>
>>>> wrote:
>>>>
>>>> I don't want more than 1 alert presented at a time, of course, but
>>>> they
>>>> get generated asynchronously. I thought dispatch_get_main_queue()
>>>> would
>>>> nicely serialize any that occur. Thus David's comment that I'm just
>>>> getting the requests issued in a serialized fashion.
>>>>
>>>> I'm not certain how to have alerts that are scattered all throughout
>>>> the
>>>> app to wait until some other alert's completion block executes. Are
>>>> you
>>>> saying to have it control a global flag or some such?
>>>> -Carl
>>>>
>>>>> On Nov 5, 2015, at 3:53 PM, Eric E Dolecki <edole...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> That's the way. You should never need more than one presented at a
>>>>> time.
>>>>>
>>>>> Sent from my iP6+
>>>>>
>>>>>> On Nov 5, 2015, at 5:44 PM, Tomasz MuszyÃ
Âski <t...@union.waw.pl>
>>>>>> wrote:
>>>>>>
>>>>>> You should present next UIAlertController when first one has been
>>>>>> dismissed (when UIAlertAction handler is called).
>>>>>>
>>>>>> Tomek
>>>>>>
>>>>>>> WiadomoÃ
ÂÃÂ napisana przez Carl Hoefs
>>>>>>> <newsli...@autonomy.caltech.edu> w dniu 05.11.2015, o godz. 23:37:
>>>>>>>
>>>>>>> iOS 9.1, iPhone 5S, ObjC
>>>>>>>
>>>>>>> I'm getting the following runtime warning due to multiple
>>>>>>> simultaneous UIAlertControllers presenting at the same time:
>>>>>>>
>>>>>>> Warning: Attempt to present <UIAlertController: 0x1835c000> on
>>>>>>> <MyViewController: 0x17d26e70> which is already presenting
>>>>>>> <UIAlertController: 0x18381400>
>>>>>>>
>>>>>>> I know only one alert view controller can be presenting at a time,
>>>>>>> so
>>>>>>> the way I thought to serialize execution of each
>>>>>>> -presentViewController:: is:
>>>>>>>
>>>>>>> dispatch_async( dispatch_get_main_queue(), ^{
>>>>>>> [ self presentViewController: alert
>>>>>>> animated: YES
>>>>>>> completion: nil ];
>>>>>>> });
>>>>>>>
>>>>>>> Why isn't dispatch_get_main_queue() enforcing serialized execution?
>>>>>>> Is there another way to do this?
>>>>>>> -Carl
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>>>>>
>>>>>>> Please do not post admin requests or moderator comments to the
>>>>>>> list.
>>>>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>>>>>
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> https://lists.apple.com/mailman/options/cocoa-dev/thom%40union.waw.pl
>>>>>>>
>>>>>>> This email sent to t...@union.waw.pl
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>>>>
>>>>>> Please do not post admin requests or moderator comments to the list.
>>>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>>>>
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> https://lists.apple.com/mailman/options/cocoa-dev/edolecki%40gmail.com
>>>>>>
>>>>>> This email sent to edole...@gmail.com
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>>>
>>>>> Please do not post admin requests or moderator comments to the list.
>>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>>>
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> https://lists.apple.com/mailman/options/cocoa-dev/newslists%40autonomy.caltech.edu
>>>>>
>>>>> This email sent to newsli...@autonomy.caltech.edu
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>>
>>>> Please do not post admin requests or moderator comments to the list.
>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>>
>>>> Help/Unsubscribe/Update your Subscription:
>>>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>>>>
>>>> This email sent to z...@mac.com
>>>
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/vast.grapes%40gmail.com
>>
>> This email sent to vast.gra...@gmail.com
>
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
