This document details a sample Appcelerator Alloy mobile project for a class at Howard University, demonstrating cross-platform app development using a REST API sync adapter and model/collection databinding. It provides instructions for setting up the project with Kinvey as the backend and explains modifications to the default model for integrating the REST API, including the configuration of authorization headers. Key code implementations and best practices for utilizing the Alloy framework are discussed throughout the document.

1. Sample Appcelerator Alloy Mobile Project for Howard U SCS
Cross-Platform Mobile App Dev Class
Project is based off of the default 2 Tab template available in Titanium Studio.q
Project is a sample demonstrating the use of a restApi sync adapter along with Model/Collectionq
Databinding to a TableView
The project is connected to a Kinvey Datasource back end. See Kinvey to setup a free account toq
fully utilize this application
This code should run successfully on IOS and Android using the Appcelerator 3.5.0 SDKq
Getting Started
Please setup your constants by modifying the file kinveyConstants.js in the applib directory of
your project
Modify the code below to use your values from the kinvey console
exports.constants = {
url : 'https://baas.kinvey.com/appdata/kid_-XXXXXXX/Devices',
basicAuthValue : 'Basic a2lkXy1KZWlXXXXXXXOTliY2RhMDE0YzQ5ZDBmNjY2OA=='
};
Devices Model js file
This file is where the application is a bit different from the default model file.
The default file starts off like this
exports.definition = {
config: {
adapter: {
type: "properties",
collection_name: "Foo"
}
},
extendModel: function(Model) {
_.extend(Model.prototype, {
// extended functions and properties go here
});
return Model;
},
extendCollection: function(Collection) {
_.extend(Collection.prototype, {
// extended functions and properties go here
});

2. return Collection;
}
};
Lets start to explain the changes we have made...first off at the top, we are using javascript require
to include the kinveyConstants.js discussed above. This will provide access to the constants in the
model.
// I have saved constants in an external file that is included here using the
// javascript requires functionality
//
// Best Practices for Alloy and discussion on requires:
//
http://docs.appcelerator.com/titanium/3.0/#!/guide/Alloy_Best_Practices_and_Recomme
ndations
//
var KINVEY_CONST = require("kinveyConstants").constants;
Set the Sync Adapter
Next we need to set the model to use the appropriate sync adapter. I have included a default sync
adapter that we have used on some projects that you are welcome to use.
You need to make sure the sync adapter that you use in included in the lib/alloy/sync directory
in the project. In this case, the file name in restapi.js
config : {
adapter : {
// Specifiy the sync adapter to use for this model
// and collection
type : "restapi",
// collection name property, not really needed when using
// the REST API sync adapter
collection_name : "Devices"
}
},
Extend the Model to Specify URL
For the sync adapter to work with a rest API, it needs a base url. We provide a function that will
return the base url for the model and collection. We have the value for the url in the
kinveyConstants.js file that we loaded up in the top of the models file... this is how we use the
object KINVEY_CONST we loaded up
_.extend(Model.prototype, {
// extended functions and properties go here
url : function() {

3. return KINVEY_CONST.url;
}
});
This code is extending the default object to include/override the existing function with a new
function to provide the base url. Additional infomation on baseUrl can be found in the BackboneJS
Documentation
Extend the Model to Specify Authorization Header
For this example, we are authenticating our API calls with Basic Auth using the headers; This is not
the recommended apporoach, but meets the needs of this sample.
BackboneJS allows for specifying the headers before the request is made by setting the beforeSend
property with a function to call before sending the request. We will use that property to call a
function that will set the authentication header.
The code for the function to set the headers can be placed in the controller and would need to be
used everytime you wanted to access a collection, but from a design approach it might be better to
keep the code in the model.
What we have done is extend the model with a function to set the headers on the request. The
function is added here, in the controller code, you will see how it is utilized.
_.extend(Collection.prototype, {
// extended functions and properties go here
/**
* a function for setting the header when requests are made.
*
* @param {Object} xhr
*/
setHeader : function(xhr) {
xhr.setRequestHeader("Authorization", KINVEY_CONST.basicAuthValue);
},
});
Fetching the Data in index.js
In the index controller we can now create a new Devices collection by using the Alloy.instance
function'
var devicesCollection = Alloy.Collections.instance("Devices")
this will get the existing collection or create a new collection based on the information in the
Devices model .js file.
Now that we have a devicesCollection object now lets call the fetch method to get the data
associated with the collection. The data associated with the collection will be returned as model

4. objects. Remember though that we need to set the header for the authentication by using the
function we added to the collection.
See the BackboneJS Collection.fetch documentation for additonal information of fetch and the
associated options.
devicesCollection.fetch({
beforeSend : devicesCollection.setHeader, // the function from the extended
collection
success : function(collection, response, option) {
// dump the results from the fetch to the console
console.log("Collection Response: " + JSON.stringify(collection, null, 2));
},
error : function(collection, response, option) {
console.log('ERROR ' + collection);
}
});
Binding the the Data in index.xml View
Alloy Data-Binding Documentation
Responding to Events in index.xml View