A customer reported that if he created a view in a window and\nthen removed that view, he could add it back. I tried the following\ncode provided from the customer and it does only remove the view\nfrom view, not from memory.
\nvar room = Ti.UI.createView({
\nborderRadius:5,borderWidth:1,borderColor:'#336699',
\nbackgroundColor:'#ffffff',
\nwidth:Titanium.App.Properties.getString(\"rwidth\"),
\nheight:Titanium.App.Properties.getString(\"rlength\"),
\nleft:5,
\ntop:5
\n}); SplitViewPlain.detailWindow.add(room);
var alt2 = Ti.UI.createButton({
\nleft:100,
\nbottom:5,
\nheight:70,
\nwidth:70,
\nborderRadius:35,
\ntitle:'alt2',
\nbackgroundColor:'#ff0000'
\n}); alt2.addEventListener('click', function()
\n{ SplitViewPlain.detailWindow.remove(room);
\nTi.API.info(alt2);
\n}); var alt3 = Ti.UI.createButton({
\nleft:180,
\nbottom:5,
\nheight:70,
\nwidth:70,
\nborderRadius:35,
\ntitle:'alt2',
\nbackgroundColor:'#ff0000'
\n}); alt3.addEventListener('click', function()
\n{ SplitViewPlain.detailWindow.add(room);
\nTi.API.info(alt3);
\n});
Okay, there are two ways to take this:
\n(1) should never happen. (2) should only happen on a memory\npanic.
(from [c910323037d1ce1ef5d8cba6c816d77961beb1b6])\nCloses #1066 (sort of): Views released on memory panic\nif we're able. \nhttp://github.com/appcelerator/titanium_mobile/commit/c910323037d1c...
Here is my opinion on #1. coming from a flex background, when I removed\nan object from a container, view, etc, I wanted it gone, not just\npartially removed. I know lots of people want this same\nfunctionality as well. Here is scenario. If I have a rather\ncomplex, heavy view/window, and I want it removed to free up\nmemory, I want it gone, destroyed etc..
If you want to free up the memory that way, here's how it\nhappens.
\nEven if we immediately deallocated the view upon remove(), this\ndoes NOT invalidate the object which was removed. If the user truly\nwishes to do that, they can use a remove()/delete combination.
\nThink of remove() as lazy-unload. Unloading a view on demand is\ndangerous and could lead to performance problems.
The lazy unload is actually very common, if not essential for\nthe iPhone. That is, it's a perfectly valid action to remove a\nview, yet hold onto it, to put it into a different view, or to\nre-add it at a later time, releasing ONLY when there's a memory\npanic.
\nYou can see this in action in Apple's own code, such as tab\nviews and navigation views, where the underlying action for a tab\nchange or pushing or popping a view literally is to remove the\nprevious view from, er, view, signaled by a -[viewDidDisappear:]\nmethod. The owning viewcontroller does not release the unattached\nviews until a memory panic, triggering the -[viewDidUnload] method,\nwhich may never need to happen.
Ok, then remove is not really a true remove, but rather a hide\nuntil the os decides it needs to go.
\nTab and Navigation views are the exception in my mind. I relate\nthose to a ViewStack or a TabNavigator in Flex in which we have a\nstack of views and each controls their own children. but if inside\none of the stacks, I need to remove something, then it's gone.
\nI can see not destroying windows, especially if they are linked\nto any type of navigation type group. I am mainly thinking of Views\nand controls. I will chalk this one up to just being a different\nplatform and treat it as such.