Choosing Between Alloy MVC and Classic Titanium in Appcelerator Projects

Decision and Constraints

When starting a new Appcelerator Titanium project you must decide whether to use the Alloy MVC framework or stay with the classic Titanium approach. The decision hinges on maintainability, code reuse, team expertise, and project size.

Constraints to consider

• Team familiarity with JavaScript MVC patterns (e.g., Backbone, Angular).
• Expected project size and lifespan; larger, long‑lived apps benefit from modular structure.
• Need for rapid UI prototyping versus fine‑grained control over native APIs.
• Compatibility with existing Titanium modules that may rely on classic APIs.

Comparison of Options

Aspect	Alloy MVC	Classic Titanium
Project structure	MVC folders (controllers, views, models) generated automatically.	Single app.js (or few files) with direct API calls.
Data binding	Automatic binding between model and view via <Alloy> markup.	Manual updates; developer must call view.setProperties or similar.
Build step	Requires Alloy compiler to generate Titanium code before the usual Titanium build.	No extra compilation step; source runs directly through the Titanium builder.
Boilerplate	Reduced; controllers and views are generated from XML/JSON definitions.	Higher; UI creation, event wiring, and model handling written by hand.
Learning curve	Requires understanding of Alloy conventions and MVC concepts.	Straightforward for developers already familiar with Titanium APIs.
Testability	Controllers can be unit‑tested in isolation; views are declarative.	Testing often requires UI automation due to tangled logic.

Trade‑offs

Alloy adds a compile step and introduces a new set of conventions, which can slow initial setup and obscure errors if the Alloy compiler version mismatches the Titanium SDK. However, it reduces repetitive UI code, enforces separation of concerns, and makes the codebase easier to extend and test as the project grows.

Classic Titanium avoids the extra build step and gives developers full, immediate access to every Titanium API. This can be advantageous for small utilities, proof‑of‑concept apps, or when integrating with legacy modules that expect classic‑style code. The downside is that as the UI becomes more complex, logic tends to accumulate in app.js, making the code harder to maintain and reuse.

Concrete Implementation: Creating an Alloy MVC Project

Below is a step‑by‑step guide to scaffold a new Alloy‑based Titanium app for Android. The same steps apply to iOS by changing the platform flag.

Prerequisites

• Titanium CLI installed globally (npm install -g titanium).
• Android SDK configured and ANDROID_HOME set.
• Sufficient user permissions to write to the workspace directory (no sudo required for a local install).

Steps

1. Open a terminal and run the creation command, replacing <project-name> with your desired identifier:

   ti create -p android -n <project-name> --type alloy

   This command generates a folder <project-name>/ containing the standard Alloy directory tree (app/, app/controllers/, app/views/, app/models/, app/styles/).
2. Navigate into the project folder:

   cd <project-name>

3. Add a simple view to demonstrate data binding. Edit app/views/index.xml and replace its contents with:

   <Alloy>
     <Window class="container">
       <Label id="greeting" text="Hello, {name}!" />
     </Window>
   </Alloy>

4. Define the model data in the controller app/controllers/index.js:

   function doOpen(e) {
     var name = 'Titanium Developer';
     $.greeting.text = 'Hello, ' + name + '!';
   }
   $.index.addEventListener('open', doOpen);

5. Build and run the app on a connected device or emulator:

   ti build -p android -T device

   The command invokes the Alloy compiler first, then the Titanium builder. Watch the output for any Alloy compilation errors; a successful build will end with a line similar to [INFO] Built application to /path/to/build/android/bin/<project-name>-debug.apk.
6. Upon launch, verify that the window displays the label with the text “Hello, Titanium Developer!”. If the label shows the placeholder text or is missing, check the console for binding errors.

Verification Checklist

• Build log contains no Alloy compiler errors.
• APK installs without failure.
• Runtime UI matches the view definition (label text is interpolated).
• No uncaught exceptions appear in device logcat.

When to Choose Classic Titanium

If your project is a thin wrapper around an existing Titanium module, or if the team prefers to avoid any extra build tooling, create a classic project instead:

ti create -p android -n <project-name> --type classic

Then add UI components directly in app.js, for example:

var win = Ti.UI.createWindow({backgroundColor:'#fff'});
var table = Ti.UI.createTableView({data:[{title:'Item 1'},{title:'Item 2'}]});
win.add(table);
win.open();

Build with ti build -p android -T device and confirm the table renders two rows. This approach skips the Alloy compiler step but places all UI logic in a single file.

Summary

Choose Alloy MVC when you need maintainable, modular code and are comfortable with an additional build step. Opt for classic Titanium for minimal overhead, rapid prototyping, or when working with legacy codebases that rely on the classic API. Validate your choice by building a small sample project and checking that the UI renders as expected without compiler or runtime errors.