How to setup Deployd on Ubuntu server

Intro


So, you watched Deployd video (http://deployd.com/) and you're so impressed that you want to try it right away. Here is guide of how to setup Deployd on Ubuntu server.


NodeJS


Install NodeJs following this instructions (find instructions for Ubuntu):

https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager

Verify installation by typing "node" (you should get something like "v0.8.15") and "npm" (you should get something like "1.1.66").

There seem to be a bug in NodeJs and NPM. NPM by default installs global modules to "/usr/lib/node_modules/" and that path is not included in paths that NodeJs searches. You can check that by echoing NODE_PATH variable: echo $NODE_PATH. If "/usr/lib/node_modules/" is not present, you’ll need to add it: "export NODE_PATH=$NODE_PATH:/usr/lib/node_modules/"


MongoDb


Before installing Deployd, you’ll need to install MongoDb:

http://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/

Configure MongoDb if you like by editing "/etc/mongodb.conf" file. You may want to change default port (remember port number, you'll need it later), bind IP to “localhost” (add line "bind_ip=localhost" anywhere) and uncomment "nohttpinterface = true" (remove "#").

Make sure "/var/lib/mongodb/" and "/var/log/mongodb.log" exist and have right privileges.

Kill process that runs "/usr/bin/mongod —config /etc/mongodb.conf" ("ps -ef", find PID, "kill -9 " with PID appended)

Start MongoDb: mongod —fork —dbpath /var/lib/mongodb/ —smallfiles —logpath /var/log/mongodb.log —logappend —config /etc/mongodb.conf


Forever


Forever is NodeJs module that we will use for continuous Deployd running.

To install Forever type: npm install forever -g


Deployd


Just type: npm install deployd -g

Verify installation by typing "dpd -V" (you should get "0.6.9" or something like that).


Deployd app


Make directory in which Deployd apps will be hosted. I used "/var/www/". Go to that directory and create "hello world" app:

dpd create hello-world

Go to that directory ("cd hello-world") and create "production.js" according to this: http://docs.deployd.com/docs/server/run-script.md

You’ll need to use your own MongoDb data (and credentials if you use them, otherwise just comment out that part).

After that, just fire up Forever:

forever start production.js

and go to:

www.yourserver.com:5000

You should see "Welcome to Deployd!".

Next, to login to Deployd dashboard, type "www.yourserver.com:5000/dashboard" in your browser. You should be prompt for authentification key.

To get key, in "hello-world" directory type:

dpd keygen

and

dpd showkey

you should now have key. Copy that key in the browser and login. You should see Deployd dashboard. Enjoy creating with Deployd!

http://docs.deployd.com/

Prototype-based inheritance in Titanium mobile framework

The problem

Since I was working on large in-house mobile application, I decided to wrap Titanium API (in my opinion, it's good practice to wrap third-party code in general). I've built wrapper for every Titanium component because I thought it would be easier to fix something in the wrapper than in whole application when particular Titanium component brakes, or changes its functionality. Here, I'll concentrate on UI wrappers.

In last wrappers that I used, I used configuration objects in OOP (described in one of previous posts). That approach was not very satisfying to me because of few reasons. That approach was not prototype based, rather I would copy objects, which led to slower performance and bugs (shallow VS deep object copy). What I also mind about it, is that approach just does not fit well into JS language and larger projects.


I wanted to develop something faster and intuitive that would feel natural to JS and Titanium in particular. Also, Titanium SDK moved towards CommonJS approach, so I wanted to develop something that would fit into CommonJS.

But before that I needed to learn native OOP in JS (and not how to emulate classes or something like that), which is prerequest for anyone who wants to understand this article. I will explain it briefly here (I'll skip explanation of "this" value - everything you need to know about "this" value can be found here: http://dmitrysoshnikov.com/ecmascript/chapter-3-this/ ).

OOP in JavaScript

OOP in JavaScript is very hard to truly understand for someone who comes from class-based programming languages, although it's very simple.


JavaScript is object-based OO language. So, it doesn't have classes, it has prototype objects.


New objects are created with functions, there are no constructors like in class-based languages where constructors are part of the class. Functions can be called in few ways - as regular function or as function constructor (that is, function that constructs new objects). Note that same function can be called as regular function and as function constructor, those two functionalities are not separated, it's just a matter of how function is called:

function func() {

}

func(); // regular call
var obj = new func(); // call as constructor

So, what happens if this function is called as constructor? This seems pretty obvious in this particular case - new empty object "{}" will be created, but there are few details that are missing in that picture.

Every function has "prototype" property that contains prototype object reference and when that function is called as function constructor, newly created object will have its internal "__proto__" property set to "func.prototype". That's a link between newly created object and its prototype object. That property cannot be read directly, instead "Object.getPrototypeOf" must be used:

Object.getPrototypeOf(obj) === func.prototype; // true

"this" value inside function constructor is set to newly created object and it is returned from function unless something else is returned.

function func() {
   this; // {} - newly created object
   return { dontDoThis: true };
}


var o = new func(); // { dontDoThis: true }

By default, every function has "prototype" property set to "Object.prototype" and therefore, newly created objects will have their "__proto__" property set to point to "Object.prototype".



Let's add some properties and methods to prototype object:

function Guide() {

}

Guide.prototype = {
    theAnswer: 42,
    theQuestion: 'What is the Answer to the Ultimate Question of Life, the Universe and Everything?',
    askQuestion: function() {
         return this.theQuestion;
    },
    answerToTheQuestion: function() {
         return this.theAnswer;
    }
};

var hitchhiker = new Guide(); // {}.__proto__ -> Guide.prototype
var anotherHitchhiker = new Guide(); // {}.__proto__ -> Guide.prototype 

hitchhiker === anotherHitchhiker; // false
// but
Object.getPrototypeOf(hitchhiker) === Object.getPrototypeOf(anotherHitchhiker); //true

So, this newly created objects are different objects, but they have same prototype object. In some sense, prototype object is what class is in class-based languages.


If properties of newly created objects are added or modified, that change is going to be reflected only on them. We can say that they have they own property.

For example, "hitchhiker" has no its own properties (as I mentioned, it's empty object), although "theAnswer" property can be read:

hitchhiker.theAnswer; // 42

Basically, when property is read, firstly object is check for existence of that property, if object has no its own property, its "__proto__" object is checked by same algorithm until reached object has no "__proto__" set ("Object.prototype.__proto__" is "null"). We can say that object and its prototype objects form prototype chain.

So ...

hitchhiker.hasOwnProperty('theAnswer'); // false

but ...

hitchhiker.theAnswer = 11;
hitchhiker.hasOwnProperty('theAnswer'); // true

// hitchhiker -> { theAnswer: 11 }.__proto__ -> Guide.prototype -> { theAnswer: 42, ... }

Note that prototype object is not modified, the algorithm now finds property right away and prototype chain is not searched for that property.


You can modify prototype object from "hitchhiker" object, but that is not smart thing to do:

If prototype object is modified, all objects that have that object as prototype object will also be modified.



So ... inheritance in JavaScript is implemented through prototype chains and definition of object's own properties.If you want to extend some object, use it as prototype object and add or override its properties.

function ExtendGuide() {

}

ExtendGuide.prototype = new Guide(); // new Guide = {}.__proto__ -> Guide.prototype

ExtendGuide.prototype.theAnswer = 11;



var newHitchhiker = new ExtendGuide(); // {}.__proto__ -> ExtendGuide.prototype

// comment shows property resolution
newHitchhiker.theAnswer // newHitchhiker --> newHitchhiker.__proto__  == ExtendGuide.prototype ~ [theAnswer]


>newHitchhiker.answerToTheQuestion; // newHitchhiker --> newHitchhiker.__proto__ == ExtendGuide.prototype --> ExtendGuide.prototype.__proto__ == Guide.prototype --> Guide.prototype ~ [answerToTheQuestion]

Usually, developers make mistakes in approach when they want to override some method. When they come to the realm of JavaScript, they still have class-based way of thinking and they want to override some method by modifying its functionality and calling parent method (super-method).

The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns.

That "super" method pattern is really unnecessary. Unfortunately, some developers had gone so far that they use "this.super()" and that is:

If you see something like that, run away, that's voodoo magic. :)

The rule of not calling "super" method is simple - if you think that you need to call "super" method, refactor that "super" method and think again, otherwise proceed.

In most cases, that can be achieved by splitting that "super" method to few smaller methods and simply overriding particular method.

For example:

function ExtendExtendedGuide() {

}

ExtendExtendedGuide.prototype = new ExtendGuide();

ExtendExtendedGuide.prototype.askedTimes = 0;

ExtendExtendedGuide.prototype.super = function() {
    this.askQuestion();
    this.askedTimes++;
};

Now, if I want to increase "askedTimes" by 2 and not by 1, in overridden method I could first call "super" and then again increase "askedTimes".

function CallSuperGuide() {

}

CallSuperGuide.prototype = new ExtendExtendedGuide();

CallSuperGuide.prototype.super = function() {
    ExtendExtendedGuide.prototype.super.call(this);
    this.askedTimes++;
};

But, I could also refactor that part of "super" function:

ExtendExtendedGuide.prototype.super = function() {
    this.askQuestion();
    this.increaseAskedTimes();
};


ExtendExtendedGuide.prototype.increaseAskedTimes = function() {
    this.askedTimes++;
};

and then I would not need to call "super" method:

function NoSuperGuide() {

}

NoSuperGuide.prototype = new ExtendExtendedGuide();  


NoSuperGuide.prototype.increaseAskedTimes = function() {
    this.askedTimes += 2;
};

Hopefully, now you understand OOP in JavaScript. Let's go to Titanium specifics.

Approaches in writing Titanium wrappers

There are more approaches that came from Titanium community, but they all have one thing in common. Native JS object acts as proxy object for Titanium UI object. Something like this:

function View(props) {

  var viewWrapper = {};
  viewWrapper.Element = Ti.UI.createView(props);

  //do something with wrapper like add a method
  viewWrapper.doSomething = function() {};
  return viewWrapper;
}

var view = View({ height: 42 });

More efficient way of doing this would be this:

function View(props) {
  this.Element = Ti.UI.createView(props);
}

View.prototype.doSomething = function() {};

var view = new View({ height: 42 });

This approach has a problem in object-oriented programming because this newly created object cannot be used as function's prototype object.

function ExtendedView() {}

ExtendedView.prototype = new View(); // only one TiUIView is created!

var view1 = new ExtendedView(); // Element property points to same TiUIView through prototype object
var view2 = new ExtendedView(); // but two objects are created

One way to solve that issue is calling super-constructor ("View.call(this)") in every function constructor that extends "View". That solution is not the best one because super-constructor calls are growing with every new extension.

ExtendedViewN -> ... -> ExtendedView2 -> ExtendedView1 -> View (weee, we're done)

The other way that I found on the internet that solved this problem is calling "init" method in function constructor:

function View() {
  this.init(); 
}
View.prototype.init = function(){
  this.Element = Ti.UI.createView();
};

function ExtendedView() {
 this.init(); 
}


ExtendedView.prototype = new View();

That solution is fine and better than previous one, but "init" function has to be called in function constructor if ExtendedView is going to be extended.



I wanted to make more Zen-ish solution. :)

Theoretical approach in ZenTi

The problem in approaches described above is that Titanium UI objects are created in function constructors. Function constructors are outside entities and they do not belong to prototype objects (not like constructor in classes which belong to particular class) and many developers put logic there, which is semantically wrong. Function constructors do construct new objects, but they need to be used only for setting some object-specific data.

//for example

//wrong
function ConstructSomething(something) {
   if (something == 'Something') {
      this.doSomething();
  }
}

//better
function ConstructSomethingElse(something) {
   this.init(something);
}
 ConstructSomethingElse.prototype.init = function(something) {
   if (something == 'Something') {
      this.doSomething();

  }

So ... to create Titanium prototype-based wrapper, TiUI component needs to be constructed in the object that models wrapper and not in function constructor. It took me a while to figure out how to do that, but the basic idea is quite simple. The trick here is that TiUI component does not need to be created right away, it can be created when it is needed. There are a lot of moments when TiUI component is needed, but all moments have one thing in common - they all want to get TiUI component. So, instead of using (static) property, I'm using (dynamic - so to say) method that tries to read property that holds a reference to TiUI component and if that property does not contain TiUI component, it creates it first.


Basic implementation can be seen in this Gist: https://gist.github.com/3314660


Described approach in that gist has a problem: https://jira.appcelerator.org/browse/TIMOB-10829

But that can be solved by using "Object.defineProperty" and define properties with "enumerable" set to "false".




"__getTiElement" is main function that shows lazy creation of TiUIView (I use similar pattern often). If something needs to use TiUIView, it won't use "__TiElement" property that actually holds TiUIView directly. Rather, "__getTiElement" will be used. For example, "addEventListener" implementation would look like this:

View.prototype.addEventListener = function(type, listener) {
  this.__getTiElement().addEventListener(type, listener);
}



So ... basic workflow of some component would be:

var test = new View(); // creates new empty object - {} with "View.prototype" as prototype
test.addEventListener('click', function() {}); //{} -> "View.prototype.addEventListener" -> "View.prototype.__getTiElement" -> "create test.__TiElement (via this)" -> "test.__TiElement.addEventListener (via this)"


As you can see, TiUIView is not created right away, it is created when needed.

Conclusion

This was theoretical explanation of basic concept of prototype-based OOP in ZenTi. It can be used to implement prototype-based OO inheritance in Titanium in general.

ZenTi is relatively large, I wanted to create library that would help me easily develop highly reusable CommonJs modules and I wanted to have some functionality that Titanium lacks. Also, I wanted to avoid direct usage of Titanium API as much as possible and I wanted to have something reliable.
There are some things that needs to be fixed and refactored in it and it can be faster - I created some overhead in favor of reliability that can be avoided, because of nature of application that I was developing, speed wasn't the most important thing (but it was important).


All that and ZenTi architecture in detail will be topic of my next posts. Hopefully I'll release it in near future (I terribly lack free time). But that does not prevent you from using this approach in your applications.

The Ultimate Answer to Titanium memory leaks

The question


What are memory leaks and should Titanium programmer worry about memory leaks?


The answer to that question is as usual - it depends.


Memory leaks are situations when allocated memory in applications grows in uncontrolled way and never gets released. In some situations that can lead to application slowdown and crash.


Memory allocation and deallocation in JavaScript environments is managed automatically by garbage collection mechanism and programmers, in theory, should not worry about memory. In practice, there are situations where programmer should worry about memory handling.

JavaScript by itself has no memory problems, it's always interaction of native and host objects, or host objects themselves, that cause memory leaks. Titanium, as JavaScript host environment, is not different, but it has its own specifics.


One thing that can cause memory leaks in Titanium are application-level event listeners: Ti.App.addEventListener, "location", etc. That kind of listeners remain in memory until application runs (or until they are removed) and in situations where they are being added multiple times (by programer's error), the application will eventually crash.
Sometimes programmers use app-level events for communication between different UI components and in that cases memory leaks can happen because components will be "trapped" in app-level event. They are not like component-level events that are removed when component is removed from memory (usually, when window closes).


The problem


There are more situations that can potentially cause memory leaks. No one is sure in what situations cause memory leaks in Titanium (situations vary and are very specific) but it seems that similar things from other JavaScript environments apply in Titanium also (closures, listeners, circular references). In some cases it's Titanium's fault, but sometimes it is just lack of understanding.


Let's say that "app.js" contains this:

function createViews() {
    var views = [];
     for (var i = 0; i < 100; ++i) {
         views.push(Ti.UI.createView());
    } 
}
createViews();

Should views be freed from memory?

There was actually a bug filled with this kind of situation as memory leak situation. The problem here was not in Titanium, but in understanding (and Android emulator :) ). Some people suggested that "views" variable should be set to "null". Some suggested that all items in "views" array should be set to "null". But nothing is necessary here (and it shouldn't be) because "views" array is local variable in scope created by "createViews" function that will be destroyed after that function finishes with execution. Setting a variable to "null" in this case has no sense (as it has been shown in that bug report).

Setting a variable to "null" comes from web development, where in some cases (in older versions of IE primarily) interaction between host and native objects caused memory leaks and setting a variable to "null" would solve memory issues. But we should not be blind and use that technique everywhere without understanding the problem because it is not guarantied that setting a variable to "null" will solve memory issue or that setting variable to "null" is really necessary. We, as web developers, must deal with memory leaks in older versions of IE just because it is still used by many people. As Titanium developers we are in much better situation and we can report memory leak issue and wait until it's fixed (usually memory leak issues are fixed soon) and release our application without ugly workarounds.



The solution


Understanding.


The key of finding memory leak situations and solution of that problem is understanding. Titanium environment is one implementation of ECMAScript standard and therefore it should obey to the rules defined by that specification. I'll try to explain some basic concepts.

Scope is part of the program in which variables are bound to the values (variable is always declared with "var" keyword). We usually say that variable references value, but it would be better to say that variable identifies value (to not mix terminology with references from C-like programming languages). So, variables are not true references and we don't deal with low level things, but rather with higher level abstraction.


There is one global scope and new scopes are created by functions. When new function is defined, a reference to parent scope is stored (only global scope has no parent scope). That's why scopes are static (lexical), but variables and their values are resolved dynamically:

//app.js
//global scope 
this; //global object
this.Ti; //Titanium object

//cool so far :)
//let's declare a variable

var obj = { prop: 'abc' }; //created new object with string property
this.obj === obj; //true, variables defined in global scope are properties of global object
hm = 42;
this.hm === hm; //true, when no "var" is used, 
//property of global object is accessed if value is set, 
//reference exception is thrown otherwise

var oneMoreObj = obj; //created one more identifier to the object

function createNewScope(destroy) {
    destroy = null;
    var something = 2; 
    Ti.API.info(obj.prop);
}
createNewScope(obj); // abc

obj.prop = 'cba';

createNewScope(oneMoreObj); //cba

What happened here?

As I said, functions upon creation store a reference to the scope in which they are created. When they are executed, they create list of their own local variables, inner functions and formal parameters (we say that variables are "hoisted" to the top of the scope). When some variable is accessed during execution, it is resolved by lookup in list that current scope contains and if it is not found, it's searched in similar way in parent scopes (until global scope is reached). That's how "obj" variable is resolved inside "createNewScope" - variable is not found in current scope and it is searched in parent scope in which it's defined.
Note that "destroy" variable does not actually destroy outside object (although, modification would change it) because "destroy" is just one more identifier and setting it to "null" is just identifies different value (it doesn't change what "obj" identifies).
When function finishes with execution, local variables ("something" in this case) are destroyed in most cases. But there are cases when function has finished with execution, but scope and its variables are not destroyed. Functions are first-class citizens and they can be stored in variables, returned from function, etc. Because of that and the fact that scopes are static (they contain a reference to scope in which they are defined), they are not closed when they are finished with execution in cases when some child scope uses variables from parent scope (it forms so called closure). For example:

function createFunc() {
    var test = "Closure"; 
    return function() { alert(test); } 
}

var func = createFunc();
//createFunc has finished with execution, but we can still get "test" variable
func();

Sometimes that can lead to strange effects.

for (var i = 0; i < buttons.length; ++i) {
    buttons[i].addEventListener('click', function() {
        alert(i);
    });
}

This use-case usually produces WTF-moment because click of any button alerts same value. What happened here ... "buttons" (as identifiers of host objects) will hold event listener function. That function will contain a reference to parent scope. The point here is that all listener functions will contain a reference to same parent scope and that at the time button was actually clicked, "for" loop has finished with execution (and "i" variable will have same value it had at the end of the loop). To avoid that, closure can be created that captures value of "i" variable in each loop:

for (var i = 0; i < buttons.length; ++i) {
    buttons[i].addEventListener('click',
        (function(currentI) {
            return function() {
                alert(currentI);
            }; 
         })(i)
    );
}

The trick here is creation of self-invoking function. Functions can be anonymous and they can be invoked upon creation. To create anonymous function:

function() {}

To invoke it:

(function() {})()

Note that value of "i" is formal parameter to self-invoking function and because of created closure, parent scope of event listener function (scope created by anonymous function) won't close itself until button is removed from memory (along with reference to listener function).
In Titanium, button should be removed from memory when window closes and when nothing else identifies it from JS. Current documentation, in my opinion, does not explain that precise enough.

win.remove(view);  // view & button still exist
view = null; // deletes the view and its proxy, but not the button!

To be precise, "win.remove" should remove view's visual representation on the screen. When it is not present on the screen and nothing identifies it from JS, it should be removed from memory (otherwise, it's memory leak situation by definition). Setting variable to "null" does not delete the view directly (as it may sound from the comment from docs), the point here is that "view" variable now identifies to different value and Titanium host object "TiUIView" is not identified from JS anymore and therefore should be marked for garbage collection sometimes in the future. We could also set "view" to 42 (or anything else), it would not make a difference. If "view" variable is created in scope that is not global, it should be marked for garbage collection when that scope closes (remember bug report above). That's why, the best is to avoid using global scope except for function definition and some other controlled use cases.

So why to set a variable to "null" (or 42 :) ). In some cases (closures, circular references), when garbage collection mechanism misses to detect objects that it needs to deallocate, that can help. But it is not guaranteed that will help. As I said, it's important to understand the problem so it can be solved. Hope this article helps that cause. :)

How to (NOT to) build and structure large Titanium Mobile application

Why to structure application



Well, you could put all source code files in same (root) application directory and everything would work fine. The thing here is ... when application grows, it becomes difficult to find particular file or to know where particular part of application is located if files in it are not organized in some meaningful way (for initial application developer, but also for all developers that will work on application at some time).

That's human nature. If you imagine large number of books, finding particular one can be difficult if they are not organized in any meaningful way. Search for particular book can be accelerated if books were sorted alphabetically. Human will search from left to right for first letter first and then for particular book. If books were sorted vertically in rows by first letter, human could find particular one even more faster because letters are clearly separated.

So, organizing things can be beneficial and the way they are organized is important.

That's why good application structure can be very useful. And not only application structure, but conventions in application also.



Why "NOT to"



The answer is simple. Latest versions of Titanium framework introduced CommonJS standard that brought some new functionality, while changed old. That's why this way of structuring application is no longer good (and won't work in future SDK versions), but similar principles can be translated to new, CommonJS, functionality (and I'll show how).



Basic concepts in my library



To understand application structure that I use, I need to explain some basic concepts that I use. This approach might not suit your needs, but it might give you some directions or ideas how to build your library for Titanium framework or how to structure your own application.


I'm using wrapped Object object as basic component. That component is basically container that has methods like add, remove, get, removeAll and getAll.

var component = Component();
var view = View();
component.add('MyView', view);
component.get('MyView'); //view

View is special component that is wrapper around Titanium UI View component. I wrote wrapper for every Titanium UI component (so, I don't use generic wrapper). Every wrapper can do everything what basic component can do, but beside that it proxies Titanium functionality (for example it adds or removes Titanium UI components in the background) and alters Titanium provided functionality where necessary (workarounds, simpler or enhanced usage, ...).


A good thing about this approach is that you can use this wrappers with native JS functionality without a fear that something will brake because they are native JS objects and not Titanium host objects. Titanium host objects in many cases do not behave like native JS objects and it's dangerous to do anything with them that is not documented. Also, this wrappers provide secure layer in cases when Titanium API changes or brakes (which is not so rare case). If you write code that depends directly on Titanium API, you could eventually end up in rewriting a lot of code. For example, "children" property in recent version was removed from some components. It is not so rare case that we need to get all child components of some component. If you depend directly on Titanium API, you would need to rewrite every part of your application that uses that property.




To simplify functionality of getting particular component, I add its reference as a property.

component.MyView // same as component.get('MyView')

I use string names to differentiate component instances of same type because it is easier to remember string component name, than integer index position in array of child components. Also, code that uses child component is not dependent on position in parent component so position can be changed without consequences.


I make component for everything that can be reused:

function Toolbar(config) {
    var view = View({ bottom: 0, height: '10%' });
    return view;
}

...
var toolbar = Toolbar();
toolbar.add('SaveButton', Button({ title: 'Save' });
toolbar.add('CancelButton', Button({ title: 'Cancel' });

"Toolbar" can again become some kind of component (everything is a component):

function ActionBar() {
    var toolbar = new Toolbar();
    toolbar.add('SaveButton', Button({ title: 'Save' });
    toolbar.add('CancelButton', Button({ title: 'Cancel' });
    return toolbar;
}

This approach is very similar to the one that can be found in EnyoJs (http://enyojs.com/). So, basic idea is to build small components first and then use them to build more and more complex components until whole UI is built. This approach has showed to be very flexible and scalable. Also, once all low level components are built, building higher level components is easy task.


I implemented some things that Titanium framework lacks, like FormView and GridView. FormView is awesome component, basically, every component it contains and that implements "setValue" or "getValue" method FormView can simply use to set its value and to get its value. That way I made that component very generic and it can use literally anything that somehow implements that methods (for example, I use table view in forms, table view is actually collection of data that can be dynamically added or removed). FormView component also implement that methods, so they can be nested.

function Login() {
    var formView = FormView();
    formView.add('Content', View());
    formView.add('Toolbar', ActionBar());
    var textField = TextField({ value: 'iskugor' }); //implements "getValue" and "setValue"
    formView.Content.add('UserName', textField).
    formView.getValue(); // returns { 'UserName': 'iskugor' }
    formView.setValue({ 'UserName': 'anonymous' }); //sets text field's value
    return formView;
}

Basic application would look like this:

//very simplified
var win = Context();
var form = Login();
win.add('Form', form);
win.open();

Context is window abstraction. It is different from all other components because it is important for memory management. Before 1.8 and especially before 1.7 SDK, Android part of Titanium was unstable and building something complex was mission impossible. Tom Cruise in me made this Context window abstraction that would remove all components and their events when window would close. From what it seemed to me at that time, in some cases, some event listeners were not removed so after window was re-created and re-opened, application would crash. By removing events manually, application would not crash. Also, at that time, many people had memory leak problem that sometimes just could not be solved even with some workarounds that came from community (workarounds that I tried did not work for me). By removing components manually, I did not have memory problems. From what my tests shows, 1.8 has much better memory and event handling and I actually don't use this features any more.





Removing components is easy task when there are wrappers that have "getAll" method, but what about listeners? In Titanium, event system is very basic and don't have much features. Also, Titanium component's "listeners" property was the only way to get list of all listeners, but it was unfortunately removed (partially, at least).


That's why I implemented my own publish/subscribe pattern.

Events.subscribe(button, 'click', function(e) {
     //do something
});

Internally, Events is a container that can register events, publish events, remove (all) events,  remove events by particular event type and so on.

Events.subscribe(button, 'CustomEvent', function(e) {
    Ti.alert('Custom event!');
});
Events.publish(button, 'CustomEvent');
Events.removeByEventName(button, 'click'); //removes all click events
Events.removeAll(button); //removes all events

In the background, I don't use "listeners" property, but my own container, similar to the one I use for basic component. Events are registered by event type and because of that it is easy to remove all events associated with particular event type. Also, to remove events by some event type, there is no need to store anonymous function anywhere (it is stored internally in "Events" container).


If first argument is omitted, app-level event is created. App-level events are dangerous to use because they they remain in memory all the time application runs and they can potentially create memory leaks, so functionality described above is great to have in cases then app-level events are used (all app-level events can be removed with one statement).


With all this functionality, removing events is trivial task.


Because I don't manually remove events when context closes anymore (starting from 1.8), some extra measures are needed to be done in this implementation to prevent memory leaks. I found that this event system is limited (and IMHO it forces some bad practices) and I have a design idea for new, more advanced, event system that would suit better to usage with my library.




Namespaces and naming convention




To easily name and find components, I split components to different namespaces. I have one root namespace that has subnamespaces.

Ns = {}; //root namespace
Ns.components = {}; //components namespace
Ns.components.ui = {}; //components ui namespace
Ns.components.filesystem = {}; // components filesystem namespace
Ns.events = {}; // events namespace

Concrete implementation of some component would be added to particular namespace where it belongs:

Ns.components.ui.Toolbar = function() {
    ...
};

Component name, as every other function constructor, starts with capital letter, while namespace names are lower case.

I made convention that component's code is located in one file and that component namespace name is mapped to file path relative to "Resources" directory and file name. For example Toolbar component's code would be stored in toolbar.js file. Since Toolbar is in "components.ui namespace",  toolbar.js file would be located in "Resources/components/ui" directory (FormView component's file name would be form_view.js).

I never put concrete, instantiated component to namespace, because that's a bad practice that might work on iOS, but brakes on Android. Using one component, or even more, adding one component to different windows (even if that doesn't happen in the same time) can have strange side effects. The best approach is to create twin-component whenever it is needed by using function constructor.




To load particular component, I use custom loader:

Ns.require('Ns.components.ui.Toolbar');

That method first checks if component is already present in the namespace, if not it includes it:

Ti. include('/components/ui/toolbar.js');

Every component can have default preferences, which I store to global configuration object (although, code is located in component's file):

Ns.config.add('Toolbar', {
    height: '10%',
    bottom: 0,
    layout: 'horizontal'
});

which is usually merged with configuration object passed to component's function constructor:

Ns.components.ui.Toolbar = function(configuration) {
    var config = Ns.config.merge(configuration, Ns.config.get('Toolbar'));
    var component = View(config);
    return component;
};

That way other components can change default behavior of some component by passing configuration object modifications as function parameter.

MVC



To separate concerns and to make simple implementation of MVC pattern, I separated how components are defined in the interface and how do they behave (this is actually very useful when one component is used in different situations and therefore they have modified behavior but same appearance).


To do this, I enhanced some Titanium wrappers so they can automatically add other components through configuration object. That is done by convention, configuration object can have special "items" property which defines components that will be automatically added:

var actionBar = Ns.components.ui.View({
    height: '10%',
    bottom: 0,
    layout: 'horizontal',
    items: {
        'SaveButton': function() {
            return Ns.components.ui.Button({ title: 'Save' });
         },
        'CancelButton': function() {
            return Ns.components.ui.Button({ title: 'Cancel' });
         }
    }
});

actionBar.SaveButton; //button 

This basically is used for "View" part of MVC.

"View" is defined through configuration object defined for every component.

For example, "View" part of ActionBar component would be:

Ns.config.add('ActionBar': {
    height: '10%',
    bottom: 0,
    layout: 'horizontal',
    items: {
        SaveButton: function() {
            return Ns.components.ui.Button({ title: 'Save' });
        },
        CancelButton: function() {
            return Ns.components.ui.Button({ title: 'Cancel' });
        }
    }
});

Ns.components.ui.ActionBar = function(configuration) {
    var config = Ns.config.merge(configuration, Ns.config.get('ActionBar'));
    return Ns.components.ui.Toolbar(config);
};

To make Controller part of MVC, View part has to do something. I defined that before in when I described "Events":

Events.subscribe(form.Toolbar.SaveButton, 'click', function(e) {
    Ti.alert('Username: ' + form.getValue().UserName);

             //do something with login data

});

Besides interaction, Controller is responsible for component construction, parameter passing, gluing components together, passing data to View, getting data for View and so on. Controller is what gives life to View, View is stupid as it can be (it's just definition through configuration object).



"Model" part is up to you. :)

I use modified version of Joli ORM (https://github.com/xavierlacot/joli.js/) and Sqlite for database models.




Application structure



Application structure has three main parts: library, components and modules.


In library, there are all common things, like functionality for including components, creating namespaces, events system definition, database ORM and so on.


In components there are all general components that have no specific data in them. That components can be reused in multiple projects. For example, there are UI components (Button, Toolbar, FormView), filesystem component, XML component, ...

/components/ui/button.js

In modules there are all project-specific components with data in them grouped into modules and their submodules where necessary (for big modules it's handy to group them into submodules). This components are general components with specific data in them. For example, if Button is general component, specific component would be LoginButton which is Button component with specific title.

/modules/user/ui/login_button.js

View part is stored in "ui" namespace, while Controller is stored in module's root directory. Beside that two, I store models in module's directory also.

/modules/user/models/db/users.js

Common practice that many people follow is not to separate this two kinds of components (with and without specific data), but I think it is better to separate them. If you mix project specific data with general components, then it will not be possible to reuse them in future projects. By separating them clearly, you can just copy components to new project (or link common library when that functionality become available in TiStudio) and start working on project specific modules.
 



Translation to CommonJS



I'll show you how I easily translated to CommonJS standard from this namespace-based application structure.



The biggest problem in CommonJS implementation in Titanium framework is that it does not have global variable implementation. As you might have noticed, namespace object in my application is stored in global variable which is accessible everywhere in the application. :)



Other problem is that CommonJS standard forces specific syntax.

exports.ModuleName = function() {};
//or
module.exports = {};

Other things are pretty much the same.

To translate from namespace syntax to CommonJS syntax I had to do two things. First was to use regular expression to replace all this kind of patterns:

Ns.components.ui.ComponentName

to

exports.ComponentName


Second, I had to modify my "Ns.require" method so it does not use "Ti.include", but "require" instead. The trick I used to do that coincidentally was basic idea that I used to solve problem of global variables. :)
"Ti.include" basically copy-pastes source code, while "require" returns what module exports. The trick here is to simulate what "Ti.include" was doing by using "require" function. That is, I just add module exports to global namespace object. The only thing that needed to be fixed was to "require" this global object on top of each module's file:

Ns = require('library/ns');

And that was it.

That is still not real CommonJS approach, but the thing here was following: on Android, "Ti.include" did not work inside functions (while "require" did when it was introduced), so everything had to be preloaded in the application (there was no way to include file on demand). For large project this was a disaster, I had to wait 10 seconds just to start application. Add 10 seconds of compilation time to that and you'll understand the secret of my high position in Appcelerator's Q/A. :)


I still don't use CommonJS in real sense, but I am slowly refactoring my application. For example, now I don't store configuration objects in global object, but in module's private variable.

var defaultConf = {
    ...
};

exports.ComponentConstructor = function(configuration) {
    //merge
};

Final words



Although this approach is very nice in many cases, I found it limited in some ways. I miss some things in it, some things would be better if they were made in a different way.
Also, it's not the optimal. When building complex things for mobile devices, it is important to be aware of performance of your code from the beginning. Optimizing server is easy, you just buy more/better hardware. But you can't do that on mobile devices and with application size increasing, micro-optimizations are more and more noticeable (you will never, and not even then, do micro-optimization of server code).




After one year of programming with Titanium I have found two things.

To know how to program with Titanium, you must know JavaScript that is defined by ECMAScript specification (forget your jQuery skills). Basic JS skills are the best investment in your knowledge of Titanium.


After one year of intensive JS programming I have found that I don't know to think in JS (good thing is that now I am aware of that).