Fire callbacks only after UIAlertView has been closed.

[Adam-Langley]

In iOS applications, attempting to push a new UIViewController while a UIAlertView is still being dismissed (currently running the hide animation), will cause iOS to ignore the UIViewController push request.

Hence code such as this:

if (await _userInteraction.ConfirmAsync("Do you want to continue?")){
    Show<NextViewModel>();
}

will silently fail to navigate to the NextViewModel upon an affirmative user response.

This patch fixes this by only returning from the await once the UIAlertView has been fully dismissed.

[brianchance]

I do not see where answer is being called on the confirm click with the result so it is returned to the caller.

It might be easier to put an artificial delay before your call to Show<NextViewModel>()

[Adam-Langley]

Hi Brian,

I have just changed every call to 'answer', into assigning the result to a variable. The 'answer' is invoked once the dialog has been completely dismissed. See lines 31, 59, and 128, where 'answer' is now invoked. This is based on the belief that UIAlertView dismissal is mandatory.

I actually discovered this bug 2 months ago, and consumed several hours trying to figure out why my UIViewController was being swallowed. I came across this bug again a few days ago, and had forgotten by then, so (luckily) only lost 2 hours :) I previously resolved it by using a 200ms Task.Delay, as you have also suggested, but this is a non-deterministic implementation leakage that I feel is best avoided.

I figured I would submit this so it doesn't bite anyone else (or myself, for a third time!). I am surprise that there hasn't been any discussion on this already, as the issue reproduces consistently. Perhaps there has been an iOS change internally that previously didn't fail quietly.

[Adam-Langley]

I'd like to follow up with a quick "thank you" for building this plugin Brian - it's one of those simple, elegant and absolutely necessary plugins that I use in pretty much everything I build. Hence why I'd love to have this fix applied in-place so I can continue to just pull it from nuget :) Entirely selfish motivations!

[brianchance]

You must need to push an update the PR, I do not see where answer is being called. In Confim...

confirm.Clicked += (sender, args) => result = confirm.CancelButtonIndex != args.ButtonIndex;

[brianchance]

Sorry, been 18 months since I have really looked at this code. If I am reading this right, you are setting the result on Clicked, then calling answer in Dismissed, which happens after the alert view is gone. Correct?

[Adam-Langley]

Hi Brian, no worries. This is my first time contributing on GitHub, so it's entirely possible I've done the pull request incorrectly...

Yes, that's exactly what the change-set does.

I see that the code has been stable for some time - if there is anything I can do to assist in getting this into Nuget, please let me know.

[brianchance]

Looking at the docs (https://developer.xamarin.com/api/type/MonoTouch.UIKit.UIAlertView/), I thinkDismissed gets invoked with the same arguments as Clicked? If so, can you try to just change the original Clicked to Dismissed

[Adam-Langley]

Ha! You're absolutely right. Let me update....

[Adam-Langley]

Ok, that's committed, and it also worked just the same. Good spotting.

[brianchance]

Thanks @nimble99, I will work on getting a nuget package out eventually. Need to install all the tools at this point.