Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-16985] TiAPI: Remove window.url property

GitHub Issuen/a
TypeStory
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2016-07-28T06:59:19.000+0000
Affected Version/sRelease 3.2.3
Fix Version/sRelease 6.0.0
ComponentsTiAPI
Labelsbreaking-change
ReporterMalcolm Hollingsworth
AssigneeAshraf Abu
Created2014-05-15T12:37:59.000+0000
Updated2018-08-06T17:49:21.000+0000

Description

The window.url property was a solution fit for another time in Titanium's history. That time has long since gone. Too many newbies are using window.url as if it is the correct pattern to develop their apps against. The only reason against deprecation is that some older apps still use window.url. However using this as a reason only serves to increase the number of apps this will affect. Note: Ti.UI.currentWindow should be removed as well.

Comments

  1. Ritu Agrawal 2014-05-19

    Moving this deprecation request to engineering for further evaluation and prioritization.
  2. Benjamin Hatfield 2014-12-11

    Doc changes are taken care of by these PRs: https://github.com/appcelerator/titanium_mobile/pull/6452 https://github.com/appcelerator/titanium_mobile/pull/6451/
  3. Tony Lukasavage 2014-12-12

    I'm against removal in the sense that there's no way to create a new execution context in a cross-platform manner with this API gone. This would cause [triple](https://github.com/tonylukasavage/triple) not to work anymore, or at the very least break some functionality. If we are going to remove the only means of creating a new context, we should be replacing it with a more appropriate API. I agree that hanging a url property off of Window doesn't make sense, but we should have something along the lines of node.js's [vm](http://nodejs.org/api/vm.html) module in order to allow devs to manage their own execution contexts.
  4. Malcolm Hollingsworth 2014-12-12

  5. Fokke Zandbergen 2014-12-12

    So... dump Ti.UI.Window.url and add Ti.App.createContext right?
  6. Tony Lukasavage 2014-12-12

    [~core13] Sounds like we're saying the same thing. [~fokke] I don't know what the exact API should be, but yes, something entirely separate from any UI element for sure.
  7. Jason Kneen 2014-12-12

    Agree the functionality shouldn't be removed - changed / re-positioned maybe if that makes sense.
  8. Ingo Muschenetz 2014-12-12

    For those interested in the "createContext" feature, please provide a sample bit of code that demonstrates how you would use it properly.
  9. Tony Lukasavage 2014-12-12

    Here's the chunk of code from triple that relies on Window.url, but would be better served by a true context creation API: 
       // create a new execution context with createWindow's url property
   function resetContext() {
   	var hasCurrent = !!current;
   	if (hasCurrent) {
   		current.removeEventListener('close', resetContext);
   		current.removeEventListener('open', returnReset);
   		Ti.App.fireEvent('app:reset');
   	}
   	current = Ti.UI.createWindow({
   		url: 'context.js',
   		exitOnClose: false
   	});
   	current.addEventListener('close', resetContext);
   	hasCurrent && current.addEventListener('open', returnReset);
   	current.open();
   }
   resetContext();
    Instead of all those window and application event hacks, it would be nice to just have an API that either clears the current context, or creates a new one. But, that's not entirely useful unless we have APIs for executing code inside a given context, like the vm module I mentioned above. So my proposal would be implementing the vm API from node.js in Titanium (it's small). Where it goes in the namespaces is not important to me, be it Ti.App or Ti.VM or whatever.
  10. Chris Barber 2014-12-12

    I'm all for adding VM context support, but I'm not sold that we should put it in the Titanium namespace. I strongly believe we should design this feature to be compatible with Node.js's VM API (http://nodejs.org/api/vm.html). I think it would be great if we could implement this in a Titanium Module. This gives us a clean Titanium-free way of require()'ing the module (like node) and invoking the API.
  11. Tony Lukasavage 2014-12-15

    [~cbarber] I'm totally down with that idea. I thought I'd be the only one to propose such a radical deviation from the normal Titanium pattern, but I should have known better. Does anyone know if creating contexts is possible through the module system? On all platforms? Who can we include in this conversation to get some clarity?
  12. Alan Young 2014-12-28

    I would like to learn more about this sounds intresting I quite a new titanium developer so need all the helpi can get from the pro's
  13. Malcolm Hollingsworth 2015-09-04

    McFly, Bueller, Bueller, McFly. I am sure this throw back from the dark ages feature that was signed off to be removed July last year is hanging around for a good reason - anyone have one? The reason it was set by [~ingo] to be removed for 3.6 was due to JeffH telling him that it must be.
  14. Fokke Zandbergen 2015-12-30

    [~cng] shouldn't breaking changes be in 6.0?
  15. Hans Knöchel 2016-07-26

    PR (iOS): https://github.com/appcelerator/titanium_mobile/pull/8036 We also need an Android-PR for this accordingly.
  16. Chee Kiat Ng 2016-07-27

    PR Merged. [~msamah] ^
  17. Ashraf Abu 2016-07-27

    Noted.
  18. Ashraf Abu 2016-07-27

    Master (6.0.0) PR to remove URL property from Window (Android): https://github.com/appcelerator/titanium_mobile/pull/8161 Is there anything else that's needed? [~hansknoechel]
  19. Ashraf Abu 2016-07-27

    -Currently checking on the Android TiJSActivity class as well...- That class is fine.
  20. Eric Merriman 2018-08-06

    Cleaning up older fixed issues. If this issue should not have been closed as fixed, please reopen.

JSON Source