Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-6994] iOS: UI - AlertDialog needs to be displayed after locking & unlocking the phone

GitHub Issuen/a
TypeNew Feature
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2012-08-29T16:19:08.000+0000
Affected Version/sn/a
Fix Version/sSprint 2012-17 API, Release 3.0.0
ComponentsiOS
LabelsSupportTeam, module_alertdialog, qe-review, qe-testadded
ReporterAnthony
AssigneeSabil Rahim
Created2012-01-03T08:45:24.000+0000
Updated2012-09-07T09:52:45.000+0000

Description

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();

Comments

  1. Paul Dowsett 2012-01-05

    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
  2. Anthony 2012-01-05

    Thank you for correcting the link. Do you know in how long this bug will be fixed there?
  3. Shawn Lipscomb 2012-04-05

    An HD ticket about this issue: http://support.appcelerator.com/tickets/APP-445384
  4. Blain Hamon 2012-04-09

    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.
  5. Shawn Lipscomb 2012-04-09

    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.
  6. Stephen Tramer 2012-04-09

    We no longer support iOS < 4.0 so this shouldn't be a problem.
  7. Blain Hamon 2012-04-12

    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.
  8. Blain Hamon 2012-04-12

    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.
  9. Shawn Lipscomb 2012-04-13

    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?
  10. Mauro Parra-Miranda 2012-04-13

    Moving this a to a feature request.
  11. Vishal Duggal 2012-07-23

    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.
  12. Shawn Lipscomb 2012-07-23

    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.
  13. Sabil Rahim 2012-08-21

    Testing Code
        // 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 button1 = Ti.UI.createButton({
        	title: 'normal alert',
        	top: 30,
        	height:Ti.UI.SIZE,
        	width:Ti.UI.SIZE
        });
        button1.addEventListener('click',function(){
        
        	var alertDialog = Titanium.UI.createAlertDialog({
        	    title : "Alert Dialog",
        	    message : "I will go away if you background the app. ;(",
        	    buttonNames : ["Yes", "No"],
        	});
        	alertDialog.show();
        });
        var button2 = Ti.UI.createButton({
        	title: 'persistant alert',
        	top: 80,
        	height:Ti.UI.SIZE,
        	width:Ti.UI.SIZE
        });
        button2.addEventListener('click',function(){
        
        	var alertDialog = Titanium.UI.createAlertDialog({
        	    title : "Alert Dialog",
        	    message : "This Alert Should be persistant, I will not go away unless you cancel me!",
        	    buttonNames : ["Yes", "No"],
        		persistent : true,
        	});
        	alertDialog.show();
        });
        var label = Ti.UI.createLabel({
        	text:'Perfrom the following test.\n1.Click on normal alert.\n2.Without Cancelling the Alert background the app.\n3.On reopening the alert should be hidden.\n4.Click on persistant Alert\n5.Follow step 2. and when you reopen the app the alert should be run.\n6.If the second alert dialog still shows then the test is PASSED.',
        	height:Ti.UI.SIZE,
        	width:Ti.UI.SIZE,
        	bottom: 10
        })     
        win1.add(label);
        win1.add(button1);
        win1.add(button2);
        tabGroup.addTab(tab1);  
         
        tabGroup.open();
        

    Testing Instruction

    1.Click on normal 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
  14. Sabil Rahim 2012-08-21

    [Pull pending](https://github.com/appcelerator/titanium_mobile/pull/2804)
  15. Shawn Lipscomb 2012-08-22

    Sabil, the "persistant" property you added is misspelled. The correct spelling is "persistent".
  16. Sabil Rahim 2012-08-22

    D'uh updating. Thanks Shawn.
  17. Shyam Bhadauria 2012-08-31

    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

JSON Source