Re: iOS 8: Can any of you guys think of why an async creation of a UIAlert would generate an exception on a show?
Re: iOS 8: Can any of you guys think of why an async creation of a UIAlert would generate an exception on a show?
- Subject: Re: iOS 8: Can any of you guys think of why an async creation of a UIAlert would generate an exception on a show?
- From: Carl Hoefs <email@hidden>
- Date: Wed, 29 Jul 2015 12:01:43 -0700
Could this issue be due to whatever reason Apple deprecated UIAlertView in iOS 8?
"Important: UIAlertView is deprecated in iOS 8. (Note that UIAlertViewDelegate is also deprecated.) To create and manage alerts in iOS 8 and later, instead use UIAlertController with a preferredStyle of UIAlertControllerStyleAlert."
-Carl
> On Jul 29, 2015, at 11:40 AM, Alex Zavatone <email@hidden> wrote:
>
> Huh. Within the @try block, we can see that the navigationControllerSupportedInterfaceOrientations: is being sent to the UIAlertController.
>
> 2015-07-29 14:15:56.967[719:244869] -[SignInViewController displayErrorMessage:] [Line 289] <- ***
> 2015-07-29 14:15:56.985 [719:244869] -[UIAlertController navigationControllerSupportedInterfaceOrientations:]: unrecognized selector sent to instance 0x156e29f0
>
> 0x156e29f0 is _alertController inside the instance of alert.
>
> Yes, the view controller class this is happening in is conforming to UINavigationControllerDelegate and I have set the self.navigationController.delegate to self.
>
> What I can't wrap my head around is why or how it is possible for something like this to happen.
>
>
>
> On Jul 29, 2015, at 2:08 PM, Alex Zavatone wrote:
>
>> I've got a completion block in an NSURLSessionDataTask that checks if the NSURLResponse statusCode is not 200 and in that case, it places a cell to a method to display a generic error message like so:
>>
>> // If no error occurs, check the HTTP status code.
>> NSInteger HTTPStatusCode = [(NSHTTPURLResponse *)response statusCode];
>>
>> // If it's other than 200, then show it on the console.
>> if (HTTPStatusCode != 200) {
>> DLog(@"HTTP status code = %ld", (long)HTTPStatusCode);
>> NSString *errorMessage = [NSHTTPURLResponse localizedStringForStatusCode:HTTPStatusCode];
>> DLog(@"HTTP error message is: %@", errorMessage);
>>
>> // display error message;
>> [self displayErrorMessage:errorMessage];
>> return;
>> }
>>
>>
>> And in displayErrorMessage is will asks GDC to dispatch an async call to display the message on the main thread.
>>
>> // Error messages
>> - (void)displayErrorMessage:(NSString *)errorMessage {
>> DLog(@"<- ***");
>> // handle on the main thread
>> dispatch_async(dispatch_get_main_queue(), ^{
>> NSString *internalErrorMessage = @"An error occurred. Please try again.";
>>
>> UIAlertView *alert = [[UIAlertView alloc]
>> initWithTitle: nil
>> message: internalErrorMessage
>> delegate: nil
>> cancelButtonTitle: @"OK"
>> otherButtonTitles: nil, nil];
>>
>> if (alert) {
>> [alert show];
>> } else {
>> DLog(@"For some reason, the alert instance isn't ready for a show.");
>> }
>> });
>> }
>>
>> What's happening intermittently when I'm causing the server call to time out is that I'll get a bad access on the [alert show].
>>
>> I've spent all morning trying to narrow this down, to find out where the bad access is and why this is occurring. Sometimes in the stack trace, I'll see 3 or 4 calls to display the alert in different threads. Sometimes, I see that the [alert show] exception is being caused by navigationControllersupportedInderfaceOrientations: being sent to alert and the instruction pointer is on the [alert show line].
>>
>> I've included a screenshot of thread 1 to see if any of this makes any sense to anyone else.
>>
>> Thanks in advance if you're able to spend some time to help me out on this one.
>>
>> Adding an @try block around the [alert show] and retesting now.
>>
>> Stack trace screenshot below:
>> http://i.imgur.com/KfILPLE.png
>>
>> - Alex Zavaotne
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden