[TIMOB-1066] Window.remove does not remove the view from memory
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-04-17T01:55:06.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.4.0 |
| Components | iOS |
| Labels | defect, ios, iphone, remove, view |
| Reporter | ctredway |
| Assignee | Reggie Seagraves |
| Created | 2011-04-15T02:43:02.000+0000 |
| Updated | 2011-04-17T01:55:06.000+0000 |
Description
A customer reported that if he created a view in a window and then removed that view, he could add it back. I tried the following code provided from the customer and it does only remove the view from view, not from memory.
var room = Ti.UI.createView({
borderRadius:5,borderWidth:1,borderColor:'#336699',
backgroundColor:'#ffffff',
width:Titanium.App.Properties.getString("rwidth"),
height:Titanium.App.Properties.getString("rlength"),
left:5,
top:5
}); SplitViewPlain.detailWindow.add(room);
var alt2 = Ti.UI.createButton({
left:100,
bottom:5,
height:70,
width:70,
borderRadius:35,
title:'alt2',
backgroundColor:'#ff0000'
}); alt2.addEventListener('click', function()
{ SplitViewPlain.detailWindow.remove(room);
Ti.API.info(alt2);
}); var alt3 = Ti.UI.createButton({
left:180,
bottom:5,
height:70,
width:70,
borderRadius:35,
title:'alt2',
backgroundColor:'#ff0000'
}); alt3.addEventListener('click', function()
{ SplitViewPlain.detailWindow.add(room);
Ti.API.info(alt3);
});
Okay, there are two ways to take this:
(1) should never happen. (2) should only happen on a memory panic.
(from [c910323037d1ce1ef5d8cba6c816d77961beb1b6]) Closes #1066 (sort of): Views released on memory panic if we're able. http://github.com/appcelerator/titanium_mobile/commit/c910323037d1ce1ef5d8cba6c816d77961beb1b6"> http://github.com/appcelerator/titanium_mobile/commit/c910323037d1c...
Here is my opinion on #1. coming from a flex background, when I removed an object from a container, view, etc, I wanted it gone, not just partially removed. I know lots of people want this same functionality as well. Here is scenario. If I have a rather complex, heavy view/window, and I want it removed to free up memory, I want it gone, destroyed etc..
If you want to free up the memory that way, here's how it happens.
Even if we immediately deallocated the view upon remove(), this does NOT invalidate the object which was removed. If the user truly wishes to do that, they can use a remove()/delete combination.
Think of remove() as lazy-unload. Unloading a view on demand is dangerous and could lead to performance problems.
The lazy unload is actually very common, if not essential for the iPhone. That is, it's a perfectly valid action to remove a view, yet hold onto it, to put it into a different view, or to re-add it at a later time, releasing ONLY when there's a memory panic.
You can see this in action in Apple's own code, such as tab views and navigation views, where the underlying action for a tab change or pushing or popping a view literally is to remove the previous view from, er, view, signaled by a -[viewDidDisappear:] method. The owning viewcontroller does not release the unattached views until a memory panic, triggering the -[viewDidUnload] method, which may never need to happen.
Ok, then remove is not really a true remove, but rather a hide until the os decides it needs to go.
Tab and Navigation views are the exception in my mind. I relate those to a ViewStack or a TabNavigator in Flex in which we have a stack of views and each controls their own children. but if inside one of the stacks, I need to remove something, then it's gone.
I can see not destroying windows, especially if they are linked to any type of navigation type group. I am mainly thinking of Views and controls. I will chalk this one up to just being a different platform and treat it as such.