Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1223] Dynamic properties not carried across contexts

GitHub Issuen/a
Resolution Date2011-04-17T01:55:34.000+0000
Affected Version/sn/a
Fix Version/sRelease 1.5.0
Labelsandroid, blackberry, defect
ReporterBill Dawson
AssigneeDon Thorp


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.


  1. Don Thorp 2011-04-15

    This is related to #1005 as well.

  2. Matthew Lieder 2011-04-15

    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).

  3. bxgrant 2011-04-15

    +1 for prioritizing this in 1.5. It makes it difficult to create meaningful abstractions for enterprise apps without this functionality.

  4. Don Thorp 2011-04-15

    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.

  5. Matthew Lieder 2011-04-15

    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...

  6. Matthew Lieder 2011-04-15

    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.

  7. Don Thorp 2011-04-15

    Marshall is actively working on the required refactor to support this capability.

  8. dailynerd 2011-04-15

    Thank you for increasing the priority, a fix for this would be great!

  9. Don Thorp 2011-04-15

    This should be fixed by #915

  10. Matthew Lieder 2011-04-15

    Thank you! Confirmed fixed on Android 2.1.

  11. Thomas Huelbert 2011-04-15

    confirmed iOS 4.0.2 and 3.1.2. Android 2.2. Thanks for confirming 2.1 Matthew!

  12. Matthew Lieder 2011-04-15

    FYI parts of this fix appear to have regressed in master (1.5.0); see #2221.

JSON Source