In this simple example, if you click the close button in the\r\nsecond window the close event listener runs FOUR times:
\r\n\r\n\r\n/*global Ti, Titanium, alert */\r\nTitanium.UI.setBackgroundColor('#000');\r\nvar win1 = Titanium.UI.createWindow({ title:'Test', backgroundColor:'#fff', fullscreen: true, exitOnClose: true });\r\n\r\nvar win2 = Ti.UI.createWindow({title:'window 2', fullscreen:true, backgroundColor: 'green'});\r\nwin2.addEventListener('close',function(){Ti.API.info('CLOSE');});\r\n\r\nvar open = Ti.UI.createButton({title: 'open'});\r\nopen.addEventListener('click', function(){win2.open();});\r\nwin1.add(open);\r\n\r\nvar close = Ti.UI.createButton({title: 'close'});\r\nclose.addEventListener('click', function(){win2.close();});\r\nwin2.add(close);\r\n\r\nwin1.open();\r\n\r\nNote: if you click the back button instead of clicking the close\r\nbutton, it fires only once.
After this is fixed see if it helps at all with the OOM\nexperienced by Friedrich Seydel in \nthis comment from ticket 1827.
Assign to Don for milestone/priority. (Feel free to assign back!\n:) )
cf #1489 re the backgroundImage and OOM
Related to Activity refactor. There are multiple close paths\nthrough the different exit methods that can fire 1 to n events.
Please change that back to 1.5 and make sure this issue is\nresolved in the Q4 release. This is a critical issue and we've had\nto work around this for 2 major projects and over 9 months.
\nIf Android is not going to receive the attention it needs to be\nstable, we will be canceling our account and moving to another\ncross-platform development suite at the first of the year.
Unfortunately 1.5.0 is fully planned and we're working to get it\nshipped in December. I've created a new 1.5.1 M01 milestone and I'm\nmoving this ticket there so we can start working on it as soon as\n1.5.0 is out the door. It will then be available from the CI\nbuild.
This is a major problem for me as well. Is there any workaround\nany one can think of at the moment until this bug is fixed and any\nideas when a fix for this will be complete?
I'm opening windows and showing them modally. Since javascript\nallows methods and properties to be added dynamically to an object,\nI can get around this problem with code like this (from the example\nabove):
\n\nvar win2 = Ti.UI.createWindow({title:'window 2', fullscreen:true, backgroundColor: 'green'});\nwin2.CloseFired = false;\n\nwin2.addEventListener('close',\nfunction()\n{\n if (this.CloseFired) return;\n \n this.CloseFired = true;\n // do what needs to be done \n Ti.API.info('CLOSE');\n});\n\nIt's not very sophisticated, but seems to do the trick.
Quick follow-up; the technique I used above works ok for\nAndroid, but not for iPhone which seems to somehow reuse the\nwindows/listeners. I've made the fix conditional for Android only\nin my code and both seem to now work as expected.
To QA:
\nTo test this, use attached CloseTest.zip (import the project\ntherein). When you run it, you should see only one\nclose event (in the console / logcat) when you close the windows\nthat are opened with the \"no url\" buttons -- in fact, with the\nfailing version of the SDK, you'll see 3 per closure, which is a\nbug. For the \"own url\" windows, you should see two\n(one from an event listener created in the main window, one from an\nevent listener created inside the second window's own JS file), but\nyou'll see six.
(from [4ede763ab6c786a90f2e0397152d78b0a79781f5])\n[#1827 state:fixed-in-qa] Fix multiple window\nclose event firings by making sure that the multiple possible code\npaths from a window closure still only result in one close event\nbeing fired. \nhttps://github.com/appcelerator/titanium_mobile/commit/4ede763ab6c7...
confirmed on a G2 running 2.2 and a g1 running 1.6. [INFO] Titanium SDK version: 1.6.0 (12/28/10\n10:46 4ede763). results as Bill describes.