The application architecture

This section dives into the open source code base of the augmentedTi example application, explaining how it has been implemented.

An overview

The augmentedTi application has been developed to demonstrate Augmented Reality in action; it has been coded using the Appcelerator Titanium Framework. This framework enables a "code once, adapt everywhere" approach to mobile application development.

It uses the commonJS architecture at its core and has a set of best practices, which can be read at https://wiki.appcelerator.org/display/guides/Best+Practices. The application follows these guidelines and also implements an MVC style architecture, using a controller, and event driven flow control methodology incorporating localization.

Note

At the current time trying to implement a CSS applied look and feel using the frameworks JSS method is not viable. The application gets around the issue of hard coding fonts, colors, and images into the application by using two files—ui/layout.js and ui/images.js. These files contain the look, feel, and images applied throughout the application, and are standalone modules, enabling them to be included in any other modules.

The application

As you start to explore the application you will see that the main bootstrap file app.js only contains the require of the controller file and the call to the initial function startApp():

var ctl    =    require('/control/controller');
ctl.startApp();

To implement methodology for separating the code into distinct commonJS modules, the following file structure is applied:

i18n/en/strings.xml
resources/app.js
resources/control/controller.js
resources/images
resources/services/googleFeed.js
                   location.js
resources/tools/augmentedReality.js
                common.js
                iosBackgroundService.js
                persHandler.js
ui/images.js
     layout.js
     common/activity.js
            titleBar.js
     screens/ARScreen.js
             homeScreen.js

The main file which controls the application is controller.js. When an activity is completed, the control is returned here and the next activity is processed. This has an implication with enabling the program flow—application-level event listeners have to be added, using up resources. The application gets around this by creating a single custom event listener, which then calls a function to handle the flow. The fire event is handled within the tools/common.js file by providing a single function to be called, passing the required type and any other parameters:

Ti.App.addEventListener('GLOBALLISTENER', function(inParam){
    var gblParams    = {};
    for(var paramKeyIn in inParam) {
        if(inParam[paramKeyIn]) {
            gblParams[paramKeyIn] = inParam[paramKeyIn];
        }}
    processGlobalListener(gblParams);});

function launchEvent(inParam){
    var evtParams    = {};
    for(var paramKeyIn in inParam) {
        if(inParam[paramKeyIn]) {
            evtParams[paramKeyIn] = inParam[paramKeyIn];
        }}
    Ti.App.fireEvent('GLOBALLISTENER', evtParams);}

common.launchEvent({
   TYPE :    'ERROR',
   MESS :    'E0004'});

Throughout the application's commonJS modules, a standard approach is taken, defining all functions and variables as local and exporting only those required at the end of the file:

exports.startApp    =    startApp;

In keeping with the commonJS model, the modules are only required when and where they are needed. No application-level global variables are used and each part of the application is split into its own module or set of modules.

Within the application where data has to be stored, persistent data is used. It could have been passed around, but the amount of data is small and required across the whole application. The persistent data is controlled through the tools/persHandler.js module, which contains two functions—one for setting and one for getting the data. These functions accept the parameter of the record to update or return.

var persNames    = {
    lon :    'longitude',
    lat :    'latitude',
    width :    'screenWidth',
    height :    'screenHeight',
    bearing :    'bearing'
};

function putPersData(inParam){
    Ti.App.Properties.setString(persNames[inParam.type],
    inParam.data);

    return;}

    persHandler.putPersData({
        type :    'width',
        data :    Ti.Platform.displayCaps.platformWidth
    });

The application does not use the in-built tab navigation; instead it defines a custom title bar and onscreen buttons. This enables it to work across all platforms with the same look and feel. It also uses a custom activity indicator.

The rest of the application should be easy to follow. We will dive deeper into the Augmented Reality code in the next section.