Noodlecode parody of spaghetti code

Tag: commonjs

Lazyloading JS modules in Titanium app

In NodeJS project, usually modules are loaded at the beginning of the file:

var fs = require('fs');
var path = require('path');
var express = require('express');

When this NodeJS application being run, it loads all of the dependencies & start executing the program. In large application, there will be delay before the application can start operating, because of the dependencies loading.

For desktop or server application, this won’t be much issue, but in mobile app like Titanium, if it loads the whole dependencies during app launch, it might cause unresponsive app & consume large memory, even when those modules haven’t being used yet.

Another problem is there might be circular dependencies issue, in which module A require module B, but module B also require module A, and this lead to module A variable in B to become an empty object. Example:

// db.js - database module
var Person = require('model/Person');
Person.setup();

// Person.js - data model
var db = require('db');
db.execute('sql'); // TypeError, undefined is not a function

Restructuring the code flow is one method to fix, but in my experience, it cause a lot of repeated code

// Person.js
var Person = {};
Person.setup = function() {
     var db = require('db');
};

Person.getById = function() {
     var db = require('db');
};

Person.getAll = function() {
     var db = require('db');
};

Because of this, I use the lazyloading approach & make use of JS object getter to both solve the problem & make the code cleaner. The idea is to have a global variable, which will be included in each of the modules we have in a Titanium app, and this global object holds a reference to every modules we packaged into the app. This reference will then call a getter to do require() and return the actual module to the caller.

In addition, modules are categorized into folders which can act as namespace, to eliminate class name conflict

// globals.js
var g = {};

var modules = [
     'window/MainWindow',
     'ui/ContactList',
     'ui/ContactListItem',
     'model/Contact',
     'core/Db',
     'core/Http'
];

modules.forEach(function(mod) {
     var parts = mod.split('/');
     var namespace = parts[0];
     var className = parts[1];
     var obj = g[namespace];
     if (!obj) {
          obj = {};
     }
     Object.defineProperty(obj, className, {
          get: (function(path) {
               return function() {
                    return require(path);
               };
          })(mod),
          set: function() {}
     });
});

module.exports = g;

Now, the Person model class can be refactored like below:

// Person.js
var g = require('globals');
var Person = {};
Person.setup = function() {
     g.core.Db.execute('sql');
};
Person.getAll = function() {
     g.core.Db.execute('sql');
};

This is just a basic implementation of the idea, and you can extend it to support subnamespace & native module.

Indirect code execution flow

Intro: we have an Android app, with typical main and detail window structure.

Let’s see this situation: when user tap a button on main window and then open a detail window, later when user closes the detail window, it needs to update the main window UI.

Here, we have two method of how to update the UI – proactive / direct way, or passive / indirect way.

First, there are several point during detail window closing process, which we can run the function to update the main window UI.

  • when user press back button on detail window
  • when detail window close event
  • when main window resumed

Direct way – when running the function to update main window UI during the 1st and 2nd point above.

// in detail window class

detailWindow.addEventListener('androidback', function() {
	mainWindow.updateUI();
	detailWindow.close();
});

// or

detailWindow.addEventListener('close', function() {
	mainWindow.updateUI();
});

Some disadvantages for this method:

  • detail window need to keep a reference to main window.
  • if updateUI() function take some time, then closing detail window will be delayed

Therefore, to ensure responsiveness of the app, we need to utilize indirect way of executing the code. When main window resume, we run the code to update the UI. But, what if we need to update the UI only when user close the detail window? Here, we need a state variable (variable that keeps track of a state).

// in main window class

var detailWindowOpened = false;
btn.addEventListener('click', function() {
	detailWindowOpened = true;
	detailWindow.open();
});

detailWindowOpened is the state variable, it tracks whether detail window has been opened or not.

// in main window class

mainWindow.activity.addEventListener('resume', function() {
	if (detailWindowOpened) {
		updateUI();
		detailWindowOpened = false;
	}
});

Then, when main window resume, it will automatically update its UI. So here, we don’t need to keep a reference of main window inside detail window class, and closing detail window won’t be delayed.

Copyright © 2017 Noodlecode