iOS 7.1 app is crashing in showing alert view - ios

I have used alertview many times but currently i have an issue. My app is working in all the version except it is crashing in iOS 7.1. Below is the log message.
[_UIBarBackgroundCustomImageContainer image]: message sent to deallocated instance 0x13b88840
UIAlertView *alert = [[UIAlertView alloc]initWithTitle:#"Title" #"Test" delegate:self cancelButtonTitle:#"OK" otherButtonTitles:nil, nil];
[alert show];
I don't understand why it is only crashing in iOS 7.1

Are you sure to be on main thread ?
You can test it like this : [NSThread isMainThread];

As requested by the OP I have just moved my comments to be an answer.
There are a few issues wrong with the following line:
[[UIAlertView alloc]initWithTitle:#"TestTitle" #"Test" delegate:self cancelButtonTitle:kActionOk otherButtonTitles:nil, nil];
just replace it with
[[UIAlertView alloc]initWithTitle:#"TestTitle" message:#"Test" delegate:self cancelButtonTitle:#"OK" otherButtonTitles:nil];
As for what the issues are with that line, they are:
1) The method initWithTitle:delegate:cancelButtonTitle:otherButtonTitles: isn't a real instance method for UIAlertView so it shouldn't work in any iOS where as you have said it does work in iOS versions prior to 7. The method that you should be using is initWithTitle:message:delegate:cancelButtonTitle:otherButtonTitles: notice the extra parameter message: this is the main issue and should create a compiler error and if it got passed that should throw a runtime error of unrecognised selector.
2) The second is is that you have two nils being passed in for the last parameter for otherButtonTitle:, this parameter is nil terminated so as soon as it sees nil it will end what can be passed into that parameter so the second nil is pointless and never seen. This also may create a compiler error but would be in the shadows of the first issue (1)
For more information in regards to UIAlertView please the Apple Documentation on UIAlertView

Related

_UIViewServiceInterfaceErrorDomain

I'm having a problem with MFMailComposeViewController
I'm getting this error
viewServiceDidTerminateWithError: Error Domain=_UIViewServiceInterfaceErrorDomain Code=3 "The operation couldn’t be completed. (_UIViewServiceInterfaceErrorDomain error 3.)" UserInfo=... {Message=Service Connection Interrupted}
with this code
- (IBAction) mailbutton:(id)sender
{
if([MFMailComposeViewController canSendMail])
{
[MSAPP.globalMailComposer setModalTransitionStyle:UIModalTransitionStyleCoverVertical];
[self presentViewController:MSAPP.globalMailComposer animated:YES completion:nil];
}
else
{
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:#"Error"
message:#"Unable to mail. No email on this device?"
delegate:self
cancelButtonTitle:#"OK"
otherButtonTitles:nil];
[alert show];
[MSAPP cycleTheGlobalMailComposer];
}
}
This is a known issue with the iOS 8 simulator. Please see this post for a possible workaround.
You MUST allocate and initiate MFMailComposeViewController in an
earlier stage, and hold it in one static variable, whenever it's
needed, get the static MFMailComposeViewController instance and
present it.
AND you will almost certainly have to "cycle" the global
MFMailComposeViewController after each use. It is not reliable to
"re-use" the same one. Have a global routine which release and then
re-initializes the singleton MFMailComposeViewController. Call it each
time after you are finished with it
Credit goes to "Joe Blow" for the post. Judging by your code, you have already declared global mail composer. Try "recycling" it as the post suggests to see if that solves your problem. I am having the same issue and unfortunately this solution doesn't fix mine. I can confirm this solution works on the iOS 7.1 simulator but not iOS 8, although it has been suggested it will work on a physical iOS 8 device.

Observe NSLog messages in Xcode

I'm debugging a 3rd party SDK which puts lot of useful information into the console.
I used to display some messages in tooltips (for our tester), which I'm receiving from SDK delegate.
But delegate methods don't include many details and sometimes it turns helpless, otherwise console includes much more helpful information (especially if the SDK's log level is set to DEBUG_ALL or something like that).
So, my question - is it possible to observe NSLog messages and to be notified in some way when they are printed to console? Of course I would like to have string message as a parameter?
I would like to display it on device/simulator screen, so that the tester doesn't have to run XCode or view the device's console.
I'm using iConsole for the same purpose. It's quite useful.
What SDK? If the SDK supports CocoaLumberjack, then I suggest installing that, and configuring the loggers to do what you want -- even route somewhere else.
CocoaLumberjack gives you a lot of power and configurability when it comes to logging.
If your SDK uses NSLog to print the details in the console, then you can use macros to redefine the NSLog.
#define NSLog(FORMAT, ...) ShowLogInAlert(FORMAT);
void ShowLogInAlert(NSString *format, ...){
//show the log in the alert here.
va_list ap;
va_start (ap, format);
format = [format stringByAppendingString:#"\n"];
NSString *msg = [[NSString alloc] initWithFormat:[NSString stringWithFormat:#"%#",format] arguments:ap];
// NSLog(#"%#", msg);
UIAlertView *alert = [[UIAlertView alloc]initWithTitle:msg message:#"" delegate:nil cancelButtonTitle:#"Ok" otherButtonTitles:nil];
[alert show];
va_end (ap);
}

Issue when using MFMailComposeViewController

I have a tricky problem. In one of my app, with over 150.000 downloads... I have a problem which seldom occurs and which I can't seem to figure out.
The problem is the following:
In a view where the user can share a list via email, I open the mail window using MFMailComposeViewController. However, in some few cases the app seems to get a problem using the mail composer. The user presses the share button, the mail windows slides up, waits about 1-2 sec and then closes again. No content in the mail window, although I do send data to it.
I myself have not been able to re-create the problem on any device or in the simulator, however one colleague has.
I ran the app using XCode on his phone and got the following in the logs:
2013-03-01 14:43:39.604 appname[318:907] <MFMailComposeRemoteViewController: 0x1ebfb100> timed out waiting for fence barrier from com.apple.MailCompositionService
2013-03-01 14:43:39.631 appname[318:907] viewServiceDidTerminateWithError: Error Domain=XPCObjectsErrorDomain Code=2 "The operation couldn’t be completed. (XPCObjectsErrorDomain error 2.)"
I googled the error "timed out waiting for fence barrier from com.apple.MailCompositionService" but can't really find any help.
Does anybody have any experience with this? How can I solve it?
My code for opening the view:
-(void)displayComposerSheetWithBodyString:(NSString *)aBody
{
if ([MFMailComposeViewController canSendMail])
{
MFMailComposeViewController *picker = [[MFMailComposeViewController alloc]init];
picker.mailComposeDelegate = self;
[picker setSubject:#"Lista"];
NSString *emailBody = aBody;
[picker setMessageBody:emailBody isHTML:NO];
[self.navigationController presentModalViewController:picker animated:YES];
}
else
{
[[[UIAlertView alloc]initWithTitle:NSLocalizedString(#"Din enhet är inte redo att skicka e-post. Kontrollera dina inställningar", nil)
message:nil
delegate:self
cancelButtonTitle:NSLocalizedString(#"OK", nil)
otherButtonTitles:nil]
show];
}
}
Not sure if you have fixed the problem, but I have met it recently in my project.
A workaround I did was to allocate and initiate MFMailComposeViewController in an earlier stage, and hold it in one static variable, whenever it's needed, get the static MFMailComposeViewController instance and present it.
It seems working for me, hope it will work for you, too.
a had the same issue, and this fixe helped me:
https://twitter.com/christian_beer/statuses/321295533077565440
"#nathangaskin well… that was long ago :) But if I remember correctly, it worked after I removed the custom fonts from my UIAppearance code"
It works fine for me.
Also, second option is to simply wrap displaying call into
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 0.3 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{
block
I have exactly the same issue. I think I have nailed it down to the time it takes to formulate the message body string.
Content from comment
//Message Body
NSString *msgBody = [NSString stringWithFormat:
#"I noticed these results in pocketKPI. The %# was at %# which is a variance of %#(or %#) to the target defined as %#. When you have some time let's discuss.",
self.itemToView.kpiName,
[DFSKpiFormatter formatNumberAsString:self.itemToView.currentValue], [self.itemToView determineVarianceLabelText],
[self.itemToView determineVariancePercentLabelText],
[DFSKpiFormatter formatNumberAsString:self.itemToView.targetValue]];

ios 6.0 new addressbook ABAddressBookRequestAccessWithCompletion

I want to ask that how I can detect whether my AddressBook was first accessed by an app on ios6.0. I have learnt that no matter an app was reinstalled or not , the system only thinks that the first installation an first launch is the first time an app launched. the question is that I want to remind an user to allow the app access AddressBook with an UIAlertView,but this alertview will appear shortly after the system's alertview .How can I avoid this condition. Any help will be greatly appreciated.
You should basically ignore ABAddressBookRequestAccessWithCompletion. It is useless. If you want to know whether you have access to the database, call ABAddressBookGetAuthorizationStatus().
Further Discussion
ABAddressBookRequestAccessWithCompletion is said by the docs to request address book access from the user. But it doesn't. I will now demonstrate that ABAddressBookRequestAccessWithCompletion is useless. There are two situations:
(1) If this is a completely unknown new app, ABAddressBookRequestAccessWithCompletion is otiose: access will be requested from the user automatically when the app tries to access the address book, so there is no need for ABAddressBookRequestAccessWithCompletion.
(2) If the user has either denied or granted access, ABAddressBookRequestAccessWithCompletion is a no-op! Calling it does nothing; it does not put up the access request alert!
So ABAddressBookRequestAccessWithCompletion is just a bug and should be ignored.
A Major Correction
EDIT In iOS 6.1, this behavior appears to have changed. (I am assuming that my tests on iOS 6.0 were valid, but I have every reason to believe they were.) Now, however, in iOS 6.1, ABAddressBookCreateWithOptions never causes the authorization alert to appear. The only way to make it appear is with ABAddressBookRequestAccessWithCompletion! Thus this function is now essential; if ABAddressBookGetAuthorizationStatus that access is undetermined, you must call ABAddressBookRequestAccessWithCompletion or you won't get access.
I have solved it by this way.
__block BOOL accessGranted;
- (IBAction)accessAddressBook:(id)sender {
CFErrorRef error;
ABAddressBookRef addressBook = ABAddressBookCreateWithOptions(NULL,&error);
ABAddressBookRequestAccessWithCompletion(addressBook, ^(bool granted, CFErrorRef error) {
// accessGranted = granted;
if (!accessGranted && !granted) {
UIAlertView * alertView = [[UIAlertView alloc]initWithTitle:#"Deny Access" message:#"Deny" delegate:self cancelButtonTitle:nil otherButtonTitles:#"cancel", nil];
[alertView show];
[alertView release];
}
});
}
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
if ([alertView.message isEqualToString:#"use contact"] || alertView.message == #"use contact") {
accessGranted = YES;
}
}
The system already shows an alert when you call ABAddressBookRequestAccessWithCompletion()
just augment the system app with your own string.
You should have in your InfoPlist.strings:
"NSContactsUsageDescription" = "Tap 'OK' or this app is useless.";

Using standard Apple translations for Alert button?

Is this true? When you instantiate a UIAlertButton, you have to pass it an explicit title for the Cancel button, like so:
UIAlertView *av =
[[UIAlertView alloc]
initWithTitle:#"Error"
message:err.localizedDescription
delegate:nil
cancelButtonTitle:#"Cancel"
otherButtonTitles:nil];
That means that if you want a localized app (which of course you do), you have to localize the Cancel string too, even though Apple has obviously got a canonical translation already. Am I really forced to write something like this to handle it (or is this even OK)?
NSBundle* uikitBundle = [NSBundle bundleForClass:[UIButton class]];
UIAlertView *av =
[[UIAlertView alloc]
initWithTitle:NSLocalizedString(#"Error", #"Title for Alert box when error occurs")
message:err.localizedDescription
delegate:nil
cancelButtonTitle:NSLocalizedStringFromTableInBundle(#"Cancel", #"Localizable", uikitBundle, nil)
otherButtonTitles:nil];
This looks horrible to me, but the idea that I have to maintain my own translations of words mandated by Apple's HIG (like "Cancel" or "OK") seems equally absurd.
As you expect, that's not recommended as your code introduces an undocumented, unsupported dependency which could break your app if a future iOS update comes along that changes how Apple localizes their UIButton (not very likely, but who knows).
Really, "OK" and "Cancel" are not difficult things to translate. If you don't wish a translator to re-localize these for you as part of your app's localization work then you could retrieve these yourself from iOS (using your code) and copy the translation to your .strings file, so that you'll have a reliable copy of the translation from now on!

Resources