CommonJS Modules as Windows and Memory

You must Login before you can answer or comment on any questions.

Hi,

I am doing my best follow Ti Studio's best practices and I have the following situation/question.

I have a module inside which there is a table view where each row is the id to an ACS place. When a row is clicked I call the following function: 

var openDetail = function( placeId ) {
 
    var Location = require('ui/Location').Location;
    var locationDetail = new Location(placeId);
    appname.ui.currentTab.open(locationDetail);
 
};
and open another module which pulls the corresponding ACS place and renders its details.

The problem which I am encountering is that: when I hit 'back' inside the detail view (to get back to the original window with the table view) and then reopen the detail view for another location a few times, memory (presumably allocated for the ui related to each location) gets 'trapped' and the performance of the detail view degrades significantly.

Another manifestation of the same problem is that: if I open the detail view for one and the same location twice but change the data in ACS before the second time I open it, I get the two versions of the data/ui rendered on top of each other.

So my question is: what is the proper way to remove the old detail view and free up the memory associated with it before I open it a second, third, fourth time?

Thanks.

1 Answer

Accepted Answer

I have used the same technique with much success, and I have not seen the performance degradation you describe. I'm not doing anything special to manage the memory of the detail view, either.

When you close the detail view and open a second detail view, the locationDetail now references the second detail view. Nothing should be referencing the first detail view. Therefore, the garbage collection should clean it up, along with all its child views.

How do you know this is a memory issue, and not something else? Have you profiled the app? Are you looking at memory usage through another tool?

What if you try opening up a "dummy" window with no controls (or minimal controls)? Do you have similar slowdowns?

There could be something else wrong with your code that is causing the issue.

— answered 7 months ago by Jason Priebe
answer permalink
7 Comments

  • I should mention one other thing. I see that you're using a namespacing pattern, which implies to me that you are using a mixture of CommonJS and include(). Or at the very least, you're relying on this global appname variable. If you're relying on the global, you should know that your code won't run on android.

    I think if you move to a pure CommonJS design, you may find some of your memory issues go away on their own. A pure CommonJS-based app enforces a certain discipline and structure on your code that minimizes opportunities for proxy object references to get left lying around.

    — commented 7 months ago by Jason Priebe

  • Hi Jason,

    Thanks for the response.

    1) I have abandoned the include/global pattern everywhere except for in maintaining the current tab and one other place where I couldn't get an iOS modal window to work with CommonJS modules for more or less the same reasons as mentioned above.

    What is the best way to keep track of the current tab using CommonJS modules only? I saw a pattern in the new sample app provided with Ti Studio which sets a "containingTab" property in applicationTabGroup.js and an event listener for changing the tab inside the window constructor module. I was also thinking about implementing the current tab as part of a stateful module (where the current tab is the state).

    2) I have not profiled the app. How can I do that?

    3) I have not measured memory usage with another tool. Could you point me in the direction of such tool?

    I will alter keeping track of my current tab depending on what you say about #1 above and post here if that solves my problem.

    I was just assuming it's a memory issue because when I was trying to get the iOS modal window to work with CommonJS (in the exact same way as my code above) a lot of my variables and events would clearly get added on top of the existing ones from the previous time I opened the view -- events would fire multiple times for the same button and so on. So given the complexity of my views I can't imagine that I would be doing well with memory... when certain things are added every time I open the view but never discarded.

    I am hoping that my main/only issue is in keeping track of the current tab... and after I adjust that everything will be great.

    Thanks!

    — commented 7 months ago by Stoyan Vasilev

  • Some stuff that I found out myself:

    1) I am checking out your TitanUp library. More specifically these two files ui/UITGWMDemoWindow.js and TitanUp/UI/TGWM.js

    2) I am trying to open the XCode project in XCode 4.5 and profile the app there. We'll see how that goes.

    3) I'm gonna try to output this in the console every time I open the detail view http://docs.appcelerator.com/titanium/2.1/index.html#!/api/Titanium.Platform-method-getAvailableMemory

    I'd still be very happy if you can let me know if I'm on the right track with these 3 things.

    Thanks.

    — commented 7 months ago by Stoyan Vasilev

  • Show 4 more comments

Your Answer

Think you can help? Login to answer this question!