Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

android: window.close(), is the memory used by objects inside ever freed?

i'm trying to create a custom tabgroup, by using views and windows for each tabs content area. those windows are opened/closed when clicking a imageview (btw, on android it's not possible to change a buttons background-image after creating the button object)

it's working, however it seems that a closed window doesn't free its scope, which means that after switching tabs approx 10 times the memory is full. am i doing something fundamentally wrong here, or is this simple not implemented by appcelerator devs (which would be a shame to say at least)

here is my implementation:

basically i have a tabgroup object

this.tabview = Ti.UI.createWindow({…})

and have two methods that get called when a tab should be activated (first i remove the old window, then i open the new one)

this.removeContent = function() {



this.addContent = function(url) {

 this.tableview = Ti.UI.createWindow({

       url: url




shouldn't this completely free the tabcontent (the window) and replace it with a new one (window)? this is my third attempt (and almost complete rewrite) to get a custom tabgroup working, attempts before got blocked by bugs at some point in development that can be found in the lighthouse bug-database

after working with the android implementation the last four weeks, i must say that it is in a inferious state, compared to the iphone implementation (which isn't perfect at all). there are so many basic properties and methods missing, also it's often impossible to change properties in runtime, event-handling in subviews doesn't work as it should (or as one could believe, when looking at appcelerator marketing). hidden views do accept touch-events, tablerow-children can't be accessed, orientation is buggy, splashscreen can't set to go completely fullscreen, the list goes on and on. in summary i think the product isn't even near a 1.0 beta canditate when it comes to android

i'm going to lose a big customer, if i can't get this working in a few days, and i'm starting to think that the decission for "lazy coding" instead learning java and objective-c will fall back at me at some point in the not to distant future. i spent half the time coding now, for shipping around "bugs" that are shifted to later ti mobile releases for months or missing implementations, that i surely could have done the project in java instead, including the steep learning curve and the bugs to be found in the native android sdk

i'm no paying customer, but looking at the quality of ti mobile at the moment, i don't think that i ever will, because i don't believe that buying a premium or pro support account will have magically dissappear those bugs listed above. what i don't get, am i the only one who is finding those bugs, or are customers developing for iphone only?

— asked June 25th 2010 by Christian Sigl
  • android
  • crash
  • leak
  • memory
  • window.close

20 Answers

  • I have an app too that's crashing every session on Android, just takes a few tab changes and it's a guaranteed crash. If I run it in the emulator, in ddms I can see the error is "bitmap size exceeds VM budget".

    Not sure if it's the same error you guys are seeing or not but I feel your pain. No way I can release an app that I know is so easy to make crash.

    — answered June 25th 2010 by Dan Giulvezan
    • yes, this is the error i receive before the app is crashing

      i'm now trying to use the sencha-ui plattform and recreating the whole app inside a webview, but i'm seriously pissed at the moment. not because of the existance of this bug, but because of appcelerators unprofessional way of dealing with this matter

      — commented June 25th 2010 by Christian Sigl
    • Your experience is common and there are a lot of people that share your frustration. We've completely abandoned Android development using Titanium as it simply isn't mature enough to even be considered a 1.0 beta IMO. That would be fine if its deficiencies were acknowledged, but we wasted many hours tracing down bugs thinking our code was at fault, when in reality we were constantly running into unimplemented or buggy features. A little more transparency would go a long way, and I believe they're working on just that based on recent comments.

      — commented June 25th 2010 by Alan McConnell
    • this is exaclty my experience (you even used similar wording here), but i for one do not feel like this is a problem transparency, because a official statement coming from appcelerator telling us that android is still in a very experimental state of progress, would have saved me hours of work. if you're doing serious business as a freelancer, you can't stop a project 4 days before its deadline, because you finally found that those bugs you thought are caused by your own code are in reality basic design flaws inside the framework you're using, which is marketed as version 1.4, which to me would mean that features included at least went to some point through quality control. my customer has a testing team wich will test the app 2 days on quite a range of android phone models, so they are quite serious, when it comes to quality served to their customers - which is exactly the thing you have to do, if dealing with your customers in a fair and professional way is part of your philosophy of customer relationsship

      — commented June 25th 2010 by Christian Sigl
    • I'd personally love to see Blackberry support pushed back a bit and more attention given to Android. So damn frustrating.

      — commented June 27th 2010 by Dan Giulvezan
  • just found that this bug (even by appcelerator recognized as not only happen with imageviews) is known now for 2 months, without any steps taken it seems

    this is the original q&a post by Bryan Jackson:


    — answered June 25th 2010 by Christian Sigl
  • i tried the following:

    • using the window-close event i'm removing all view-instances from the window, including their subviews and most important sub-windows
    • in the titanium developer console, trace-mode shows some information coming from the sandbox that seems to indicate that this indeed is freeing some memory, however i'm not exactly sure about this
    • use plain (basic) tableviews, without background-graphics for its rows (as imageviews are leaking)
    • use as few images on a window as possible or replace existing ones by changing the image-property of imageviews objects instead adding a new one (for an example, if building a swipe-able imageviewer, do not use scrollableview, instead use one imageview for all images and simple replace it's source by catching the imageviews touch-events) as it seems that replacing a imageview source is indeed freeing its memory, accoring to the ti developer console
    • it seems that for simulating a tabgroup (if building a custom one by using standard ti-view-objects), it's better to use windows (and open/close events) for the tabs content-area, instead showing/hiding or even adding/removing views when it comes to memory usage

    i will post my tabgroup-code in a few days, and also the photoviewer if anyone is interested!

    — answered June 27th 2010 by Christian Sigl
    1 Comment
    • I hope this helps. That's just too big of a bug there. It should be fixed asap. Thanks for your advice.

      — commented December 3rd 2010 by George Marmaridis
  • to those who have tried to code around this bug: do you think removing all of a windows child objects in the windows 'close' event, would be similar to what is done within a destructor in native sdk land?

    i really need a solution here

    — answered June 26th 2010 by Christian Sigl
  • Good idea about trying to remove all the child object on the window close even, wish I knew more about native Android development to give an educated guess.

    If you have a chance to try it out would love to hear how it goes, I won't have a chance to try that in my app for a couple more days.

    — answered June 27th 2010 by Dan Giulvezan
  • I've been having issues using custom rows on tableviews, Scroll was Really bad. So i took the individual row and wrapped it in a view and it's working fine

    So here's a example code that works. Obviously there's some code missing that is my own table but yeah, scrolling seems good after the view wrapping

    for (var i = CustomData.length - 1; i >= 0; i--) {
    var row1 = Titanium.UI.createTableViewRow({height:100});
    var row =  Titanium.UI.createView({height:100,width:300});
    row1.className = CustomData[i].Type;
    — answered June 28th 2010 by Ryan Tregea
  • Dear Appcelerator Devs, i need an urgent answer how to handle this. is there a safe way to free a window, when closing it?

    — answered June 28th 2010 by Christian Sigl
  • Hey Christian, I just saw this tweet from Don @ Appcelerator and it sounds like a fix may be hitting git tonight


    — answered June 30th 2010 by Dan Giulvezan
    1 Comment
    • thanx for this information, looks like they are indeed progressing on this bug!

      — commented June 30th 2010 by Christian Sigl
  • I am too sitting on my app and can't release it due to the low memory bug that kept crashing it. Basically what I have is a scrollableview that dynamically load images, but after 40 something plus+ image, it will crash the app. Yes, I do resize/scale/compress my images and even resorted to closing windows and bunch of other ways, but it didn't really help. Gosh, I even go back and optimized every little piece of codes, objects, and functions – trying to work around the bug…but it still failed me.

    I might take Christian's suggestion above and just make one single image instead of a scrollableview, but hate the fact that i would have to hack up an animation-like to show that pic is appearing sliding back/forth. But I think that would be my only option now.

    By the way I do use the 1.3.2 RC 1 SDK for all of this.

    I agree with other folks here, that I don't think Titanium is matured enough yet.

    — answered July 14th 2010 by jd nguyen
    1 Comment
    • hi, i'm a premium support customer now, and while the price may seem to be high first, it' worth it's money. the bug got fixed already in github and will be in the next official release. also appcelerator devs are very responsive to their paying customers and deserve your money, if you already earn some with your apps. android is sure not as developed as the iphone version, but it's progressing pretty fast

      — commented July 15th 2010 by Christian Sigl
  • double post

    — answered July 14th 2010 by jd nguyen
  • I am trying to work around a low memory problem in my app as well.

    The documentation states that using 'window.close()' will free up the memory used by that window and its resources.

    As far as I can tell, this is NOT the case. This is a HUGE problem.

    Appcelerator? Where are you guys at on this?

    — answered August 27th 2010 by Todd Soligo
  • There have been several memory related fixes pushed lately. You might want to try a Continuous Integration (CI) build. Look in the programming guides section for instructions.

    — answered August 27th 2010 by Don Thorp
  • Hi Don.
    Issue seems to be even worse with latest CI build (continous 1.4.1, downloaded yesterday).
    I tried reusing an window with an imageview for different pictures and this does work with 1.4.0 but not with 1.4.1.
    It seems the close handler of the window gets called only once (though I do close and open the window for every new picture).
    Maybe connected with Lighthouse Tickets #1470 and #1472 ?

    — answered September 8th 2010 by Friedrich Seydel
  • Here is a tracking ticket for the problem Friedrich Seydel mentioned about 10 hours ago (event listeners not working in re-opened window). It's high priority and I'm working on it immediately.

    — answered September 8th 2010 by Bill Dawson
  • If Friedrich is still listening…

    Can you show us the code you are using to set the event listener, and the code that is opening the image view window, and the code that closes the image view window?

    — answered September 9th 2010 by Bill Dawson
  • Yes, I'm still listening!
    I built a stripped down version of my problem.
    app.js: pastie

    Try the "Show Next" button a few times.

    App is working with 1.4.0.

    With continous-1.4.1 the close handler gets called only once. The application is crashing with:
    Unable to load bitmap. Not enough memory: bitmap size exceeds VM budget

    — answered September 10th 2010 by Friedrich Seydel
  • Found a workaround it (maybe?)

    Add an event listener for window close, and remove ALL the views you've added to the window you're trying to close.

    currentWin = Ti.UI.currentWindow;
        // Remove ALL views from current window
        currentWin.remove(view1); // For example

    Tell me if I'm mistaken. Thanks.

    — answered January 8th 2011 by Zheng Da Clinton Goh
  • still experienceing this issue with 1.7.2

    — answered July 28th 2011 by dev 1605
  • could it be that this bug is related to the memory leak produces by imageViews i read somewhere else in this q&a section? because the first sign indicating that memory is almost full (before the app finally crashes) are dissappearing tableview background images?

    — answered June 25th 2010 by Christian Sigl
  • There is no doubt a memory leak issue with Android. I don't think it has been address in 1.4. Basically, the more memory your windows use and the more back and forth the user does in your application between windows, the faster it will crash due to out of memory error.

    My workaround was to keep memory use as low as possible on my windows so it takes a long time for it to reach a force close state.

    This is a nasty bug but it hasn't gotten a lot of attention on here.

    — answered June 25th 2010 by Vinh Bui
    1 Comment
    • unfortunately, keeping memory low inside my windows is no option here, if this is really known to appcelerator, then they should let people know before having them download the product. this is a serious flaw, and for me this results in having worked on the project for almost a month now, while not being able to finish it not because a feature would be missing, but a crash-bug that is clearly reproduce-able

      — commented June 25th 2010 by Christian Sigl
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.