[TIMOB-1223] Dynamic properties not carried across contexts
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-04-17T01:55:34.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.5.0 |
| Components | Android |
| Labels | android, blackberry, defect |
| Reporter | Bill Dawson |
| Assignee | Don Thorp |
| Created | 2011-04-15T02:46:58.000+0000 |
| Updated | 2011-04-17T01:55:34.000+0000 |
Description
By "dynamic properties" here we mean "unofficial" (unregistered) properties, such as if a developer just sets a property in JS on one of our proxies, like:
var win = Ti.UI.createWindow();
win.secret = "my secret message";
"secret" is not a registered property of WindowProxy. In Android/BB, we handle the assignment by passing it on to the scriptable -- we don't give it to the proxy. Later, if the proxy is wrapped again into a different KrollObject, and code tries to get the property value, it will fail.
This happens with currentWindow, for example, when a new context is created for a window and then Ti.UI.currentWindow is set to a wrapped instance of that window proxy. Here's a complete fail case example:
File: app.js
// ....
var win = Ti.UI.createWindow({url:'win1.js'});
win.secret = "My secret message";
Ti.API.info(win.secret); // ok -- .secret is on the scriptable
win.open(); // causes new context win1.js
File: win1.js
var win = Ti.UI.currentWindow;
Ti.API.info(win.secret); // fails -- currentWindow is different scriptable than win was in previous context
In our iPhone/iPad implementation, these unregistered properties are put right into the proxy's (target's) dynprops collection and are therefore available even if the proxy gets wrapped into a different scriptable.
This is related to #1005 as well.
To help with prioritizing, I just want to note that I (and others too) are currently being stymied by this problem and are eagerly looking forward to "Passing Data" being supported on Android and BlackBerry (see http://developer.appcelerator.com/helpdesk/view/28391)">http://developer.appcelerator.com/helpdesk/view/28391).
+1 for prioritizing this in 1.5. It makes it difficult to create meaningful abstractions for enterprise apps without this functionality.
There are a few cases where this will work. We are adding features for Android where this will absolutely not work by design. Please don't rely on it as a silver bullet. Blackberry may have some of the same restrictions but in different areas.
So how will child contexts be able to access data from their parent context? Only through manual Ti.API.Properties calls? Or will I need to have it fire an event on the parent that fires an event back on the child, passing it the data? Neither of those two options seems like something that should be done (let alone the only way to get something done) in a modern framework...
Do you have any guess yet as to when you'll be able to code a fix for this? Trying to gauge if it's worth waiting for the fix or if we'll need to make the time to rearchitect our code around this problem.
Marshall is actively working on the required refactor to support this capability.
Thank you for increasing the priority, a fix for this would be great!
This should be fixed by #915
Thank you! Confirmed fixed on Android 2.1.
confirmed iOS 4.0.2 and 3.1.2. Android 2.2. Thanks for confirming 2.1 Matthew!
FYI parts of this fix appear to have regressed in master (1.5.0); see #2221.