Book Image

Augmented Reality using Appcelerator Titanium Starter

By : Trevor Ward
Book Image

Augmented Reality using Appcelerator Titanium Starter

By: Trevor Ward

Overview of this book

Titanium Mobile has quickly become the platform of choice for many mobile developers and is growing and changing at a rapid rate. From the implementation of CommonJS, Cloud Services, MVC design patterns and more, the last year in Titanium development has been a roller coaster of change for the better. Augmented Reality is a hot area for mobile applications and this book along with the augmentedTi open source application will give a great start to all augmented applications. This book will show you how to build an Augmented Reality application, which is clean, efficient and usable. It shows how to hide the processing from the user and build a display which updates and rotates smoothly.Mobile devices have got more powerful, but they still have limitations. Augmented Reality applications test these devices to breaking point and without the correct coding techniques make the applications unresponsive and cumbersome.This book gives a solution, which will enable you to build an effective application, and is accompanied by a complete working application and source code. It's essential for anybody who is creating a multiple points of interest augmented reality application. It shows how to build this type of application efficiently and takes into consideration the devices limitations and processing capabilities.
Table of Contents (9 chapters)
Augmented Reality using Appcelerator Titanium Starter
Credits
Foreword
www.PacktPub.com
www.PacktLib.PacktPub.com
About the author
About the reviewers
Index

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.