I'm looking for the class name of the popup/message windows on the iPhone (it's a blueish window that comes up when you have a missed call, or a message comes in for example.)
The class is called UIAlertView. From the documentation:
Use the UIAlertView class to display an alert message to the user. An alert view functions similar to but differs in appearance from an action sheet (an instance of UIActionSheet).
Use the properties and methods defined in this class to set the title, message, and delegate of an alert view and configure the buttons. You must set a delegate if you add custom buttons. The delegate should conform to the UIAlertViewDelegate protocol. Use the show method to display an alert view once it is configured.
The examples you gave (missed call or incoming text message) are system level alerts that pop up over any application. That functionality is not available through the SDK. lajos's answer does provide the correct way to display an alert, but it is worth remembering you can only do this within your application. You cannot pop up an alert over another app because the SDK currently prohibits an app from running in the background.
Further to this response, UIAlertView is indeed the way to do this and the code you want is:
UIAlertView *alert = [[[UIAlertView alloc] initWithTitle:#"Message" message:nil delegate:self cancelButtonTitle:#"OK" otherButtonTitles: nil] autorelease];
[alert show];
Here the alert box will popup with the message "Message" and have a single button titled "OK" which will close the popup when clicked. Check the documentation for other things you can do (more buttons etc).
Related
I've got a UIAlertView with 3 buttons displayed vertically by default in the UIAlertView. I'd like the top button to be bold/highlighted. From my understanding and testing, the 'cancel' button is the one that is highlighted. The problem is no matter how I set the cancel button, it is placed last in this row. I cannot get it to be the first button.
I've tried setting the cancel button explicitly
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:title
message:message
delegate:self
cancelButtonTitle:#"Top Button"
otherButtonTitles:#"Middle Button", #"Bottom Button", nil];
as well as setting the index of the cancel button
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:title
message:message
delegate:self
cancelButtonTitle:nil
otherButtonTitles:#"Top Button", #"Middle Button", #"Bottom Button", nil];
alert.cancelButtonIndex = 0;
This problem is actually caused by changes Apple made in iOS 7. Prior to iOS 7 we were able to access the subviews of an UIAlertView by calling [alertView subviews]. But since iOS 7 doesn't give us access to any subviews ([alertView subviews].count will always return zero) we can't customize UIAlertViews the way we used to.
So the only way to achive your goal under iOS 7 is to build a custom view that looks like UIAlertView and then customize it as you like.
But if you're coding for an iOS version prior to iOS 7 than you could use this easy hack to access a button:
UIAlertView *alertView = [[UIAlertView alloc] init];
[alertView addButtonWithTitle:#"Yes"];
UIButton *yesButton = [alertView.subviews lastObject]; //is nil under iOS 7
This way you would get access to the first button. After that you can customize your UIAlertView as usual.
By the way: Apple did not only want to give all UIAlertViews the same design by changing the way we can customize them. The reason lies in HCI researches (Human-Computer-Interaction). People tend to think the bottom button is always the 'default' answer if that is the way it is implemented throughout all apps.
Also the bottom button is the only highlighted button in a UIAlertView. So its visual weight is stronger than the visual weight of the button with about the same amount of text. That's another factor why people tend to choose this one. And that is also the reason why the highlighted button never should cause disastrous and irreversible actions ('You wanna delete all your saved games' should always highlight the button 'Keep my saved games' and not the one telling 'Delete everything').
Therefore Apple always makes the Cancel Button the bottom one no matter in which order you added the buttons. So if your app doesn't make use of a fully custom interface and uses many User Interface Elements provided by Apple than I highly recommend you to not try to change that behavior and make the bottom button your 'default' button.
There is a customer alert view DTAlertView.
I hope it can help you.
I want to show the UIAlertView when user Click the Iphone Home button( means Close the application)
I have done these Code
- (void)applicationWillTerminate:(UIApplication *)application
{
NSString *errorString =#"Testing";
UIAlertView * errorAlert = [[UIAlertView alloc] initWithTitle:#"Alert" message:errorString delegate:nil cancelButtonTitle:#"OK" otherButtonTitles:nil];
[errorAlert show];
[errorAlert release];
}
But UIAlertView is not Showing. please help
Thanks in Advance
The user aims to close your app when he/she presses the home button. Apple suggest to let him/her to that. What I want to say: Don't do that. I think it is even not possible.
Look at Problem with applicationShouldTerminate on iPhone:
The alert view is never shown because
the 'show' method does not block, and
therefore, the end of
'applicationWillTerminate' is reached
immediately after you create the
alert view and try to show it. I
believe this is by design. You can't
really begin asynchronous operations
in 'applicationWillTerminate'.
applicationWillTerminate: may not be called in the newer version of iOS when pressing the Home button because the app could be only entering the background mode, not actually terminating.
Even if it is actually called (either the app is really terminated, or you're moving the code to applicationWillEnterForeground:), showing the alert is useless because the alert is associated with the active app, and your app has gone inactive by the time the alert is shown! So what happened really is, the alert is gone when the user press the home button, and when they resume your app, they see a mysterious alert popping up.
Don't ask if the user wants to quit your app. This isn't the norm in iOS. Instead, save all states in applicationDidEnterBackground:, and restore them in applicationWillEnterForeground: and application:didFinishLaunchingWithOptions:, making the user feel as if the app has never been terminated.
You might not want to use applicationWillTerminate but rather applicationWillResignActive. Check older posts like this one for more info.
You can't show a uialertview when application receive SIGKILL(Exit) Command.You can call any file or background functions in applicationWillTerminate - To do that you need to set a key in your plist.
UIApplicationExitsOnSuspend - Boolean - YES.
I have a UIAlertView set up with a textfield like so:
//***first set of code***
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:#"User Input Required" message:#"Please enter data into the field" delegate:self cancelButtonTitle:#"Cancel" otherButtonTitles:#"Ok", nil];
[alert addTextFieldWithValue:nil label:#"[Enter Text]"];
[[alert textField] becomeFirstResponder];
[alert show];
[alert release];
//***second set of code***`
How can I make it so that the user is required to click a button (I have that method already set up to send the input to a string) BEFORE any of the 'second set of code' is fired off?
I need that second set of code to be contained in the same section as the alert (so I can't just run it within the 'dismissWithClickedButtonIndex' method) and that second set of code is using the string obtained from the user input, so that is why I don't want that code to run prior to the user clicking a button.
Don't you just love it when people say "don't do it that way"... and then never give you any good/correct way you SHOULD be doing it.
Thanks.
You can't do that. show message in UIAlertView won't stop for user input. Associated delegates will need to handle the code you are planning to put in //***second set of code*** section.
Having said that, let me give you some advice. addTextFieldWithValue message is an undocumented API feature. Do not use it. It used to be a long time ago that approval process from Apple for you APP would let you pass even if your application used that addTextFieldWithValue message. But nowadays that does not happen anymore. Your application will be automatically rejected if it is using that undocumented feature. Here is a blog entry on the topic.
Hope it helps.
I'm running an application that requires LocationServices be enabled. I'm checking if they are by making a call to the service and catching the error. In the error case, I want to pop up an alertview notifying the user to activate location services. I have another AlertView open already when this test happens. I want to close that one and give the user the dialog box I mentioned previously.
Currently, I have
case kCLErrorDenied: // CL access has been denied (eg, user declined location use)
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:#"NOTICE"
message:#"Sorry, this application needs your location. Please select 'Allow' when asked to use your current location. You don't need to be on or near the trail."
delegate:self
cancelButtonTitle:nil
otherButtonTitles:#"EXIT"];
[alert show];
[alert release];
//exit(0);
break;
This causes the app to just exit. I had an NSLog output in there so I know it gets to this case.
here you are specifying delegate:self, then it searches for alert handlers declared at UIAlertViewDelegate and when it doesn't find it crashes.
So you should define
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
in your class.
Also you can implement other methods of UIAlertViewDelegate which will help you in your required task.
You need to keep track of the previous alert with an instance variable, and call the method to dismiss that previous dialog before showing the new one. You also need a delegate handler for the alert.
I write a piece of code to "do something->show alert1->do something->show alert2".
//do something
UIAlertView *alert = [[UIAlertView alloc]
initWithTitle:#"Alert 1"
message:nil
delegate:nil
cancelButtonTitle:#"OK"
otherButtonTitles:nil];
[alert show];
[alert release];
//do something
UIAlertView *alert2 = [[UIAlertView alloc]
initWithTitle:#"Alert 2"
message:nil
delegate:nil
cancelButtonTitle:#"OK"
otherButtonTitles:nil];
[alert2 show];
[alert2 release];
And suddenly a strange thing happened to multiple AlertViews: It shows "Alert 1"->"Alert 2"(Press 'OK')->"Alert 1". Why "Alert 1" shows again? I haven't written any delegate method yet. Maybe a bug?(Thanks to cobbal, alert1 is still there when alert2 appears.)
I find -(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex works well. Is the delegate method a common way to show multiple alertViews?
I would guess that alert 1 is shown and then covered by alert 2 since show isn't modal. When alert 2 is closed, alert 1 is still open.
To your second question, alertView:didDismissWithButtonIndex: may work better, but I haven't actually tested that.
The delegate is so that you can be notified when the alert is dismissed, and which button was used to dismiss it. It doesn't impact whether the alert is dismissed at all.
The alert will remain visible until it is dismissed either by you tapping a button (if any - they are not required) or you call either [UIAlertView dismissWithClickedButtonIndex:animated] or the (undocumented) dismiss method of the alert instance.
It looks like (as Cobbal suggested), alert 2 is popping up over alert 1, you dismiss alert 2, and alert 1 remains there (until it itself is dismissed).
Is there a particular reason you want to show a new alert while another is still showing? Perhaps some more context would help us to get to the root of the issue, which I suspect may be a design issue.
[edit] coming back to this and reading again, I wonder if what you are asking about with the delegate method is whether you should be showing alert 2 from there? In which case that's probably what you want - whether directly or indirectly. By indirectly I mean that you may have some state set elsewhere that determines whether alert 2 should be shown (or the circumstances that lead to it). That state (a flag, perhaps) could be set when you show the first alert, and cleared when the alert is dismissed (from the delegate method).
The reason this happens is because UIAlertView doesn't block while it's showing. Any code written after showing an alertview will run straight after the alert is shown.
What you should have is two different methods. One that does something and then shows an alert, and then another that does something and shows another alert.
Kick off the first method to do something and show an alert, and then hook into the alert's delegate method, and when you get the callback from the alertview, run the other method.
This way, the second part of the process won't happen until the user has pressed OK on the alert in first part of the process.