Problem
Back from a standby phone, [Titanium.UI.AlertDialog](
http://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI.AlertDialog-object) is no longer displayed on the screen.
Test Case
In the iOS device
* Run the code below
* The "Alert Dialog" opens
* Lock the phone
* Unlock the phone
* The "Alert Dialog" is no longer present
// this sets the background color of the master UIView (when there are no windows/tab groups on it)
Titanium.UI.setBackgroundColor('#000');
var tabGroup = Titanium.UI.createTabGroup();
var win1 = Titanium.UI.createWindow({
title:'Tab 1',
backgroundColor:'#fff'
});
var tab1 = Titanium.UI.createTab({
icon:'KS_nav_views.png',
title:'Tab 1',
window:win1
});
var alertDialog = Titanium.UI.createAlertDialog({
title : "Title",
message : "Message",
buttonNames : ["Yes", "No"]
});
alertDialog.show();
tabGroup.addTab(tab1);
tabGroup.open();
Thank you for taking the trouble to raise this ticket with such care, Anthony - it's perfect! :) Just so that you are aware, you were looking at version 1.2 of the apidocs. The latest version is always at http://developer.appcelerator.com/apidoc/mobile/latest. Let me know if there is an erroneous link on our site, and I will correct it. I will escalate this ticket now. Cheers
Thank you for correcting the link. Do you know in how long this bug will be fixed there?
An HD ticket about this issue: http://support.appcelerator.com/tickets/APP-445384
This is actually intentional design, due to [Apple's comment](https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIAlertView_Class/UIAlertView/UIAlertView.html) {quote} Important In iOS 4.0 and later, alert views are not dismissed automatically when an application moves to the background. This behavior differs from earlier versions of the operating system, where alert views were automatically cancelled (and their cancellation handler executed) as part of the termination sequence for the application. Now, it is up to you to decide whether to dismiss the alert view (and execute its cancellation handler) or leave it visible for when your application moves back to the foreground. Remember that your application can still be terminated while in the background, so some type of action may be necessary in either case. {quote} We do run risks of regression if we change this behavior, but I'm not sure which behavior we should adhere to going forward.
Seems like the relevant text is: *In iOS 4.0 and later* So if the iOS version is >= 4.0, don't hide the alert. If the iOS version is < 4.0, keep hiding it.
We no longer support iOS < 4.0 so this shouldn't be a problem.
The point being that when the version of iOS was < 4.0, we had no control over it, the OS hid the alert. During the time when we supported 3 and 4, for consistency's sake, we'd match the behavior. The issue isn't about 4.0 or not anymore, it's that this asks for a behavior change of an intentional behavior. Changing it without considering this would be a regression for everyone else. The reasoning for this was because AlertDialogs are meant for short term decisions. And if an application goes into the background (Not just locking, but fully background) there's a chance that you wouldn't get any sort of callback as the app may quit. I do want to poke about and do some research on a happy medium, but this is why I'm hesitant to simply change the behavior. In the mean time, note that listening for an app resume would give you time to reinstate or update the alert, or if this is something that requires user input, a modal window may be a better way to express it.
Followup: Unfortunately, the research was thus. In native iOS, there's two methods called to the Application Delegate, one called applicationWillResignActive (which has been around since iOS 2.0) and one called applicationDidEnterBackground (which replaced applicationWillTerminate in iOS 4.0). In 3.0, locking the screen would trigger willResignActive, but not applicationWillTerminate. I was hoping that 4.0 would be similar, but it's not: it calls both willResignActive and applicationDidEnterBackground. Short version: Locking the screen is the same as exiting to home, and we can't tell the difference.
OK, so if the user "Home"s away from the app (or the screen locks), then resumes the app, I'd want to see the AlertDialog again. I understand that this would be different behavior, so what about adding a new property to AlertDialog (perhaps persistent:true) to accomplish this? And OK, this is not a bug, technically. Can this JIRA be turned into a new feature request?
Moving this a to a feature request.
We already expose pause, paused, resume and resumed events on IOS. This can be done in the code itself by acting appropriately based on these events.
Vishal, using the pause, paused, resume, and resumed events would mean setting up at least two of these event listeners every time an AlertDialog is presented to the user (and then removing the event listeners afterward). That seems a little clumsy. This request is for Titanium to handle this for the app.
Testing Code
Testing Instruction
1.Click onnormal alert
. 2.Without Cancelling the Alert background the app. 3.On reopening the alert should be hidden. 4.Click on persistant Alert. 5.Follow step 2. and when you reopen the app the alert should be run. 6.If the second alert dialog still shows then the test is PASSED or else FAIL[Pull pending](https://github.com/appcelerator/titanium_mobile/pull/2804)
Sabil, the "persistant" property you added is misspelled. The correct spelling is "persistent".
D'uh updating. Thanks Shawn.
Environment used for verification - Tested with Titanium SDK: 2.2.0.v20120830182512 Tested with Titanium Studio: 2.1.2.201208301612 Device - iPhone 3G S iOS 5.0.1,iPHONE 4S iOS 5.0.1 Machine OS - MAC 10.8