iPhone: UIAlert dialog Appears 3 Times for Every Call - iphone

I have a UIAlert that pops up 3 times every time it is called. It appears and then disappears before I can click on it. Could it be that the viewDidLoad itself is being called 3 times?
I implemented an UIAlert in the viewDidLoad of my app:
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:title message:alertMessage delegate:self cancelButtonTitle:ok otherButtonTitles:nil];
This is the viewDidLoad in the rootViewController, that manages the views:
- (void)viewDidLoad {
Kundenkarte *kartenAnsicht = [[Kundenkarte alloc]
initWithNibName:#"Kundenkarte" bundle:nil];
kartenAnsicht.rootViewController = self;
kartenAnsicht.viewDidLoad;
self.map = kartenAnsicht;
[self.view addSubview:kartenAnsicht.view];
[kartenAnsicht release];
// [super viewDidLoad];
}
The viewDidLoad that evokes the UIAlert is in the kartenAnsicht view controller.
I hope someone can help me because I'm out of ideas.

You don't need to call -viewDidLoad yourself, it's run automatically by the NIB-loading mechanism. That means you get extra invocations of -viewDidLoad: one by design, and extras whenever you call it.

First of all, you should never put any type of display in viewDidLoad. That method is intended for behind the scenes configuration after the view is first read from nib. There is no certainty that it will be called every time the view displays because after the first time it loads, the view maybe held in memory and not reloaded from nib.
Instead, put the call to evoke the NSAlert in viewWillDisplay or viewDidDisplay. This will display the alert each time the view appears.
I doubt that viewDidLoad is called three times but to check for that just put an NSLog in the method to see how many times it is called.
When you say that:
i implemented an NSAlert in the
viewDidLoad() of my app:
... what does that mean? What object exactly has the method? If it is the application delegate, this will not work because the application delegate protocol does not respond to viewDidLoad. It has to be in a UIViewController.
Edit01:
See this post that had the same problem: UIAlertView Pops Up Three Times per Call Instead of Just Once
Short answer: You kill the alert by releasing it. Either retain it as a property of the view controller or better yet, display the alert with runModal instead of show and capture the button number returned immediately.

It would be helpful to see the code around the alert call.
I am using an alert whenever the reachability changes. Since reachability is checked repeatedly, the alert could get called repeatedly. To alleviate that, I wrap the alert code like so:
if (!myAlert) { /* set up and show myAlert */ }
However, one problem with this is that when you click the Cancel button, the alert will remain non-nil, and therefore can never show again because of that conditional. If someone could add to this response with a fix for that, that would be great. I assume I can add a handler for the cancel button that will destroy myAlert.

Related

Presenting a ModalViewController inside a ModalViewController

I have a view which is presented as a modal view controller which takes username and password credentials. I want this view to check the delegate, and if the user hasn't previously set an unlock pin for the app, to then show the change pin view as a modal view controller. This is my code...
+(void)presentCredentialsViewController:(UIViewController *)vc{
CredentialsViewController *cvc = [[CredentialsViewController alloc] init];
[vc presentModalViewController:cvc animated:FALSE];
}
and then in CredentialsViewController
-(void)viewDidLoad{
[super viewDidLoad];
if([appDelegate.pin isEqualToString: #""]){
UserPrefsViewController *upvc = [[UserPrefsViewController alloc] init];
upvc.cancelButton.hidden = true;
[self presentModalViewController:upvc animated:FALSE];
}
}
But for some reason it doesn't work. The debugger steps through the code without error, never the less, the second modal view controller isn't displayed.
First, I would suggest checking that your appDelegate.pin is blank and not nil. If it is nil, the if statement would not be satisfied and your second ModalView would not be presented.
You may also want to try the previous suggestion, calling presentModalViewController from viewDidAppear, or setting a delay if leaving it in viewDidLoad. It is possible that the CredentialsViewController is trying to present the second view when it has not yet presented itself.
The if statement is being hit and the second PresentModalViewController is executing without error, but it just wasn't displaying. I did try putting the code in ViewDidAppear and a load of other places as well, such as applicationWillBecomeActive etc. Although not actually crashing the code, still none of these approaches would show the view controller. In the end I have opted for this:
start with pin of #""
on applicationDidEnterBackground check if pin has been set
if yes
PresentModalViewController: PinViewController
if no
do nothing
Bit of a hack but it will do for now. I suppose I should put some sort of notification in somewhere warning that the pin hasn't been set. The suggestion about the delay may possibly work I suppose. I might give it a go in the future. Thanks guys....points up!

UIALertView customization

I am developing an iPhone application, in which I want to use customized alert sheet. The customization is required since I want to set image for Alert-Sheet buttons, change the size of these button etc.
I have done the following things:
Created UIView with customized controls that I wanted.
Created and displayed UIAlertView
In the delegate method of UIAlertView (UIAlertViewDelegate) i.e
- (void)willPresentAlertView:(UIAlertView *)alertView
I am removing all the subviews of UIAlertView and adding my customized view as subview.
Everything works fine till here. Since I have used customized buttons, I need to remove the alert sheet explicitly in the Action Method of the button by calling dismissWithClickedButtonIndex:animated: on UIAlertView.
Even though the UIALertView gets dismissed, it takes around 0.5 second to get dismissed.
Can someone help me out to solve the problem of this delay in dismissing OR some other way of customization of Alert View buttons.
Thanks and Regards,
Deepa
I could get it worked by passing YES to dismissWithClickedButtonIndex:animated: call i.e [alertView dismissWithClickedButtonIndex: 0 animated: YES]. Initially I was passing the flag as NO. But, I don't know whey it takes less time if we pass the animation flag as YES.
Anyone knows this?
Instead of doing this
/*
1. Created UIView with customized controls that I wanted.
2. Created and displayed UIAlertView
3. In the delegate method of UIAlertView (UIAlertViewDelegate)
*/
do this:
Create a class like this:
#interface CustomAlertView : UIAlertView
{
//For ex:
UIButton *myCustomButton;
//and other custom controls
}
Implement it in following method:
-(id)init
{
}
In the above method use:
[self addSubView: myCustomButton];
I have given just the idea. I have code but not presently to share with you.
If you are not able to implement the above I will provide later.
Thanks.
Here is the library which can solve your UIAlertView Customisation issue. It can also work as UIActionSheet. It has very good customisation options.
https://github.com/Codigami/CFAlertViewController

Why releasing an UIAlertView just afer showing it whereas it is not a blocking method?

I have been studying how to display a modal view with UIAlertView for a few hours and I understood that showing it does not "block" the code (the modal window is displayed and the program keeps running - we must use delegate to catch the selected actions on this modal window). Then I studied several examples and noticed that every example always release the modal window just after showing it. How can this work properly since the view will be released instantly as the code does not stop ?
Here is the example (there are many others on Google):
[[UIAlertView alloc] initWithTitle:#"Title" message:#"Message..." delegate:NULL cancelButtonTitle:#"OK" otherButtonTitles:NULL];
[alert showModal];
[alert release];
Thanks for your help,
Apple 92
I'm not sure where you're getting -showModal from (the usual method is just -show), but that act adds the alert to the view hierarchy. When a view is added as a subview of another view (I believe in this case it's a system-level view that is being added to) it's retained automatically, so you don't have to.
The alloc method will return you an instance that has a retain count of 1.
The showModal method probably retains the alert view so it remains on screen (and retained) until a button is tapped. It makes sense to me, since you are presenting it as a modal window, so it doesn't have a "parent", that is responsible of releasing it.

Is there a way to stop a UIViewController from being popped from a UINavigationController's stack when the backBarButtonItem is tapped?

I have a UINavigationController with a root view controller and then I push a UIViewController onto the navigation controller's stack. When the user taps the backBarButtonItem I'd like to be able to have an alert view pop up if there are certain conditions met and cancel the pop of the view controller. For example, the user can make certain selections but some combination of them may be invalid so I want to notify them to make changes.
I know that I can prevent the user from making an invalid combination or have an alert view pop up when the invalid combination is selected but I'd rather not do that. The user may be changing selections and may be aware that a certain combination is invalid but I'd rather let them select something that makes the combination invalid then go change something else (and notify them if they haven't made changes before trying to go to the previous screen). For example, if I prevent them from selecting something that makes an invalid combination then they may have to scroll up on a screen, change something, then scroll back down instead of making a selection then scrolling up and changing something.
Using viewWillDisappear: doesn't work because, although I can produce an alert view, I cannot figure out a way to prevent the pop from occurring. The alert view displays but the view controller still pops and they are back to the root view controller (with the alert view displaying).
Is there a way to prevent the pop from occurring? If not, is this something worth filing a bug report about or is this unnecessary and/or esoteric?
You can replace the back button with your own that calls the method you want in loadView
cancelButton = [[UIBarButtonItem alloc] initWithTitle:#"Cancel"
style:UIBarButtonItemStyleBordered
target:self
action:#selector(onCancelButtonSelected:)];
self.navigationItem.leftBarButtonItem = cancelButton;
then later
-(void)onCancelButtonSelected:(id)sender {
if (!hasSavedProduct)
{
cancelAlert = [[UIAlertView alloc] initWithTitle:#"Product not saved"
message:#"Exit without saving?"
delegate:self
cancelButtonTitle:#"Exit"
otherButtonTitles:#"Save",
nil];
[cancelAlert show];
[cancelAlert release];
}
then let them go
- (void)alertView:(UIAlertView *)actionSheet clickedButtonAtIndex:(NSInteger)buttonIndex {
if ([cancelAlert isEqual:actionSheet])
{
if (buttonIndex == 0)
{
NSLog(#"Fine. Exiting without saving");
[self.navigationController popViewControllerAnimated:YES];
}
else
{
NSLog(#"Save here");
}
}
This sounds like something more appropriate for a Modal View Controller than it is for a View Controller on a Navigation stack.
If you're married to doing it on the stack though, it'd be nice if you could do this with UINavigationControllerDelegate, but you can't.
Is it possible to set the Back button to disabled, until the entries are valid? Perhaps when the user tries to enter something, but it's invalid, near the top of the View you have a Label animate into place with red text that tells the user they need to fix it. Meanwhile the back button is disabled and it's re-enabled after they make corrections.
Or get really creative with how your UI controls work to ensure that the user can never enter bad data.
Let them go back, just don't save anything unless it's completely valid. That's typically the approach Apple takes.

Remove delegate on dealloc from unreferenced object

If learned the hard way that you should remove the delegate from an object if the life span of the delegate is shorter than the object. But how do you do this if you don't have a reference to the object anymore?
In my iPhone application I have a view controller vc which performs an asynchronous activity and is displayed as a modal view. A cancel button dismisses the modal view. If an error occurs, an UIAlertView alert is displayed. If the user taps on ok, both alert and the modal view disappear. Therefore vc is set
as delegate for alert and implements alertView:didDismissWithButtonIndex:. Something like this:
// UIViewController vc
...
UIAlertView *alert = [[UIAlertView alloc]
initWithTitle:#"Error"
message:#"Something went wrong"
delegate:self
cancelButtonTitle:#"OK"
otherButtonTitles:nil];
self.alertView = alert; // needed to unset alertView.delegate in dealloc
[alert show];
[alert release];
...
}
- (void)alertView:(UIAlertView *)alertView didDismissWithButtonIndex:(NSInteger)buttonIndex {
[self dismissModalViewControllerAnimated:YES];
}
}
Normally, the alert view blocks all input. Unfortunately, it fails to do so in some edge cases.
If the user touches down on the cancel-button before the alert view appears and touches up after the alert view appears, the view is dismissed, but not the alert. vc gets deallocated and if the user then taps "ok" on the alert, the application crashes because a message was sent to the released object.
I solved this by assigning alert to a property of vc so I can set alert.delegate to nil in dealloc. I find this solution to be not very elegant, because I don't really need the reference to alert.
Is there a better approach?
Edit: Added the text in italics as clarification
Although, normally an alert view is presented over non changing content. So if the delegate is alive when the view appears it will likely be alive when it's dismissed. If that's not the case, you have to do exactly what you did, and unset the alert view's delegate manually if you no longer care about it's result.
So you do care about the alertview since you care about it's delegate method. The wrinkle is that the delegate may not apply by the time the alert is dismissed. So you need logic there, and for that logic you need to save a reference to the alert view in question.
In other words, you are doing it right. Although, it may have been helpful if UIAlertView retained it's delegate, but it doesn't seem like it does if it crashes when it's dismissed.
Lastly, I thought alert view blocked all screen input? If not, you can make it truly modal by setting vc.view.userInteractionEnabled = NO when the alert appears and switch it back when it's dismissed. This way the user can't dismiss the controller while the alert view is up. Which sounds a bit more sane to me.
From a UI perspective, when an alert view is present, it should demand the user's full attention. Perhaps you might consider disabling the Cancel button (as well as any other visible non-alert-view widgets) when there is an alert view present, and adding a button title to the UIAlertView instance which performs the same task. This would provide a clearer user interface and should also neatly solve your memory issue.
-(void)delayedDismiss {
[self dismissModalViewControllerAnimated:YES];
}
- (void)alertView:(UIAlertView *)alertView didDismissWithButtonIndex:(NSInteger)buttonIndex {
[self performSelector:#selector(delayedDismiss) withObject:nil afterDelay:0.0];
}
If you no longer care about the results of the UIAlertView you should probably also dismiss it in the - (void) viewWillDisappear:(BOOL)animated