Looking for validation on commonjs code design attempt

I'm beginning to refactor an app I'd written that used multiple windows defined in their own .js files and called by …createUIWindow({ url:'xyz.js'}) style calls.

Thoughts are to preserve a lot of the work in the separate .js files, but 'require' them in as needed. I'm sensitive to issues of leaving a lot of global objects lying around that will eventually cause memory issues, so I would prefer to get this setup figured out correctly now and not have to redo again.

So for SDK and iOS5 platform, does the following make sense for code separation, for memory, for performance, or would anyone suggest a different approach?

// app.js
var myApp = require('/lib/myapp');
var rootWindow = Titanium.UI.createWindow();
var winHome = myApp.createHomeWindow();
var navGroup = myApp.createNavGroup(winHome);

// lib/myapp.js
    createHomeWindow : function() {
        var winHome = require('/lib/ui/winhome'); 
        return winHome.buildWindow();
    createNavGroup : function(w) {
        var navGroup = Titanium.UI.iPhone.createNavigationGroup({
        return navGroup;

// lib/ui/winhome.js
module.exports = {
    buildWindow : function() {
        var w = Ti.UI.createWindow({

        // build views, etc... add to window
        return w;

and so on for other screens. All are built off initial home window and could be required in as needed. NavGroup should hopefully take care of cleaning up as they are exited. Thoughts?

1 Answer

  • Accepted Answer

    Without seeing a lot more code I would say that you are along the right lines.

    I will try and explain about the lack of global scope and memory management. Within commonJS there is no global scope so if you require a variable accessible across all windows then you would need to create a common module with the variable in and require it within each window.

    This may seem like it is going to cause a memory leak, but the file is actually only loaded into memory once and used be the different files. You can do the same with common routines, again they will only be loaded into memory once.

    however the module.exports should be exports.name { …. };

    A few gotchas is that you need to be very strict about syntax, do not forget to close all elements etc with a ; or commonJS will complain.

    so an example would be


    exports.globalVars    =
      globalVar1:        'Hello World';
    exports.commonFunc    =    function()
      if (!android)
          return true;
          return false;

    you can then require these in any other module and use them like


    var inCommon = require ('common');

    So using this way enables you to have as many variables as you need and as many functions which can each be handled individually.

    Hope this helps


    — answered 4 years ago by Trevor Ward
    • Heed Trevor's syntax warning. Go turn on JSLINT to help with missing semi-colons, etc.

      — commented 4 years ago by Stephen Feather
    • Stephen fancy posting something about JSLint so the folks know what it is and how to use it…

      — commented 4 years ago by Trevor Ward
    • JSLint: The annoying little friend

      — commented 4 years ago by Stephen Feather
    • thanks Stephen now stop answering questions so I can catch you up in the top 100 :) …….. (hehehehehe)

      — commented 4 years ago by Trevor Ward
    • LOL. I was once well into the top 10. Then I spent 2 months writing an app. sigh priorities.

      — commented 4 years ago by Stephen Feather
    • Thanks for the feedback and JSLint suggestion. Code is a lot further down the track at this point. Each js file is now basically a set of function calls with no TI objects stored internally to it. I'm about to run it through XCode memory analysis and see how it's doing there.

      — commented 4 years ago by Lance Spellman