this.tableview.close();

 this.tableview = Ti.UI.createWindow({

       url: url

 });

 this.tableview.open();

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.

• 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:

  http://developer.appcelerator.com/question/22621/android-memory-leak-issue

• 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!

• 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

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

• 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});
  row.add(GameID);
  row1.className = CustomData[i].Type;
  row1.add(row);
  data.push(row1);
  };
  TheTable.setData(data);
  

• Dear Appcelerator Devs, i need an urgent answer how to handle this. is there a safe way to free a window, when closing it?

• Hey Christian, I just saw this tweet from Don @ Appcelerator and it sounds like a fix may be hitting git tonight

  http://twitter.com/donthorp/status/17383802881

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

• double post

• 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?

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

• 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 ?

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

• 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?

• 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

• 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;
  currentWin.addEventListener('close',function(e){
      // Remove ALL views from current window
      currentWin.remove(view1); // For example
  });
  

  Tell me if I'm mistaken. Thanks.

• still experienceing this issue with 1.7.2

• 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?

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