In our app.js we create our application namespace. These namespace variables will be used to reference our CommonJS modules later in the example.

//Create our application namespace
var my = {
  ui:{
    mod : require('dateWin')
  },
  tools:{},
  controllers:{}
};

Ti.UI.Window is then created using the my.ui.mod already added to our app namespace. The open method is then called on our win object to open our example app's main window.

my.ui.win = my.ui.mod.createWindow();

my.ui.win.open();

In the Resources folder of our project, we have a CommonJS module datehelpers.js. This module has the following code:

The module.exports is the object returned as the result of a require call. By assigning the helpers function to module.exports, we are able to make the private helpers function publically accessible.

module.exports = helpers;

Also included in the Resources folder of our project is a CommonJS module dateWin.js. The following code section discusses the contents of this module.

To use a CommonJS module you must use the globally available require function. This function has a single parameter through which you provide the path to your JavaScript module. The following line demonstrates how to load a CommonJS module called datehelpers.js located in the root of your Titanium project.

var myModule = require('datehelpers'),

Titanium has optimized the module loading process so that when a module is first loaded using the require method, it is then cached to avoid the need to re-evaluate the module's JavaScript. This approach significantly improves the load performance for modules which share common dependencies. It is helpful to keep in mind the JavaScript is not re-evaluated if you have the need to manage/alter the module on load.

Adding a property to your CommonJS module is easy. You simply attach a variable to the exports object.

The following snippet demonstrates how to create a basic CommonJS property with a default value.

exports.myProperty = "I am a property";

More complex object properties can also be created, for example, as follows:

exports.myObjectProperty = {
  foo:1,
  bar:'hello'
};

You can also use a private variable to set the initial property's value. This often makes for more readable and streamlined code.

Create a local variable reflecting your business need.

var _myObjectProperty = {
  foo:1,
  bar:'hello'
};

You can then assign the local variable to a property attached to the exports object, for example, as follows:

exports.myObjectProperty = _myObjectProperty

Creating public functions is easy in CommonJS, you simply add a function to the exports object. Create an Adddays method as part of the exports object. This function accepts a date in the value parameter and an integer as the n value.

exports.AddDays = function(value,n){

Create a new variable to avoid the provided value from mutating.

  var workingValue = new Date(value.getTime());

Increase the date by using the n value provided. This could be either a positive or negative value. Negative values will decrease the date value provided.

  workingValue.setDate(workingValue.getDate()+n);

Return the new adjusted value.

  return workingValue;
};

You can also assign an exports method to a privately scoped function. This can be helpful in managing large or complex functions.

Create a locally scoped function named addDays.

function addDays(value,n){
  var workingValue = new Date(value.getTime());
  workingValue.setDate(workingValue.getDate()+n);
  return workingValue;
};

The addDays function is then assigned to exports.AddDays exposing it to callers outside of the module.

exports.AddDays = addDays;

Titanium provides the ability to create a module instance object using module.exports. This allows you to create a new instance of the function or object attached to module.exports. This is helpful in describing one particular object and the instance methods represent actions that this particular object can take.

This pattern encourages developers to think more modularly and to follow the single responsibility principle as only one object or function can be assigned to the module.exports.

The following code snippets demonstrate how to create and call a module using this pattern:

The CommonJS implementation across Android and iOS is largely the same with one major scoping exception. If you are using a version of the Titanium framework below version 3.1, Android scopes all variable access to the module itself, while iOS allows the module to access objects outside of the module already loaded in the execution context. This should be considered an anti-pattern as it breaks many of the encapsulation principles the CommonJS specification was designed to prevent.

In Titanium Version 3.1, the decision has been made to deprecate global scope access in both iOS and Android in favor of the new Alloy.Globals object. You can read more about the Alloy.Globals object at http://docs.appcelerator.com/titanium/latest/#!/api/Alloy.

The following recipe demonstrates this common anti-pattern and highlights the CommonJS implementation differences in this area between iOS and Android.

//Create our application namespace
var my = {
  tools: require('scope_test'),
  session:{
    foo: "Session value in context"
  }
};

The testScope method is called on the tools module. This demonstrates how CommonJS module scope anti-pattern works.

my.tools.testScope();

The tools module containing the testScope method is part of this recipe's code and can be found in the scope.js file root of our project. This module contains the following code:

exports.testScope = function(){
  Ti.API.log
  ("Test Module Scope - Foo =  " + my.session.foo);
  return my.session.foo;
};

The scope-access anti-pattern is shown when calling the my.tools.testScope() method. In iOS, my.tools.testScope() returns "Session Value in context", because it has access to my.session.foo from the current execution context. In Android, prior to Titanium SDK Version 3.1, undefined object used to be returned as the module did not have access to the my.session.foo object. In the Titanium SDK Version 3.1 and greater, Android now returns "Session Value in context" as it has access to the my.session.foo object.

Access to global scope has been deprecated on both platforms starting with Titanium SDK Version 3.1 and will be removed in a future version of the SDK. If you have previously implemented this anti-pattern, corrective action is recommended as the deprecation of this feature will cause breaking changes within your app.