[TIMOB-3220] Android: new ActivityProxy being created for light weight windows

GitHub Issue	n/a
Type	Bug
Priority	Medium
Status	Closed
Resolution	Fixed
Resolution Date	2011-04-17T02:01:13.000+0000
Affected Version/s	n/a
Fix Version/s	Sprint-2011-08
Components	Android
Labels	android, defect, listener, release-1.6.1, release-1.7.0, reported-1.6.0, window
Reporter	Opie Cyrus
Assignee	Don Thorp
Created	2011-04-15T03:39:46.000+0000
Updated	2011-04-17T02:01:13.000+0000

Description

When a light weight window is opened, a new ActivityProxy is created rather than using the existing proxy for the activity. When setting listeners in the new context for the window, events do not fire back to the correct proxy and cannot be handled.

Work around is to open the new window as heavy weight or set the activity listeners in the parent context where the activity was created. Example of the work around attached.

Attachments

File	Date	Size
resources_lh.zip	2011-04-15T03:39:47.000+0000	825124
resources.zip	2011-04-15T03:39:47.000+0000	825123

Comments

Opie Cyrus 2011-04-15

(from [115a4af5af5d168f9b07832ae3e1993125f900b7]) [#3220 state:fixed-in-qa] when creating light weight windows, use existing ActivityProxy

When creating LW windows, use the existing ActivityProxy associated Activity rather than creating a new ActivityProxy which would cause activity listeners set on the new ActivityProxy to not fire correctly
https://github.com/appcelerator/titanium_mobile/commit/115a4af5af5d168f9b07832ae3e1993125f900b7"> https://github.com/appcelerator/titanium_mobile/commit/115a4af5af5d...
Opie Cyrus 2011-04-15

(from [62eb136eb4ef9e4e6f0e260a295da565480169f4]) [#3220 state:fixed-in-qa] when creating light weight windows, use existing ActivityProxy

When creating LW windows, use the existing ActivityProxy associated Activity rather than creating a new ActivityProxy which would cause activity listeners set on the new ActivityProxy to not fire correctly
https://github.com/appcelerator/titanium_mobile/commit/62eb136eb4ef9e4e6f0e260a295da565480169f4"> https://github.com/appcelerator/titanium_mobile/commit/62eb136eb4ef...
Opie Cyrus 2011-04-15

I have attached the resources directory for a test to this issue. Upon opening the window, you should see the resume, pause, destroy events handled in the log.
Bill Dawson 2011-04-15

Uh oh, this seems to have broken KitchenSink. KS crashes immediately upon launching now, and I've traced it to this commit 115a4af5af5d (I'm talking about the master branch here.) KS works fine with the commit before that.

Can you have a look ASAP Opie? Thx.

Trace:

http://pastie.org/1617608">http://pastie.org/1617608
Bill Dawson 2011-04-15

fyi broken in 1_6_X as well.

Bill Dawson 2011-04-15

Simple fail case for the crash:

app.js:

   Titanium.UI.setBackgroundColor('#000');
   var tabGroup = Titanium.UI.createTabGroup();
   var win1 = Titanium.UI.createWindow({  
       title:'Tab 1', backgroundColor:'#fff', url: 'win1.js'
   });
   var tab1 = Titanium.UI.createTab({  
       title:'Tab 1', window:win1
   });
   tabGroup.addTab(tab1);  
   tabGroup.open();

win1.js:

   Ti.API.info('hi');

Bill Dawson 2011-04-15

(from [7b91bba6d4625743452c391adb05b3254d7ff7ce]) Make sure activityProxy gets filled also for tab windows with urls [#3220 state:fixed-in-qa] https://github.com/appcelerator/titanium_mobile/commit/7b91bba6d4625743452c391adb05b3254d7ff7ce"> https://github.com/appcelerator/titanium_mobile/commit/7b91bba6d462...
Bill Dawson 2011-04-15

(from [671a39a2c51f6fe389bab2815258f59eac31b32d]) Make sure activityProxy gets filled also for tab windows with urls [#3220 state:fixed-in-qa] https://github.com/appcelerator/titanium_mobile/commit/671a39a2c51f6fe389bab2815258f59eac31b32d"> https://github.com/appcelerator/titanium_mobile/commit/671a39a2c51f...
Natalie Huynh 2011-04-15

Tested with Titanium SDK version: 1.7.0 (03/02/11 13:57 5d8c78a) on
Galaxy Tab 2.2
Emulator 2.1
(Test specific to Android only)

JSON Source