Why Should You Use Alloy to Develop Titanium Apps?

0 Flares 0 Flares ×

There are a LOT of good reasons for using Alloy to develop mobile apps with Titanium! In this post, I’ll explain some of my favourite features of Alloy and how they improve upon developing apps with “classic” Titanium.

MVC

Alloy is based on an MVC methodology, which separates data (Models) with visuals (Views) and business logic (Controllers).

Models and Collections (of models) are based on BackboneJS — Alloy comes with it built-in (along with Underscore) and whilst it has its own way of defining models and collections in an Alloy app, any models and collections are based on Backbone, so work with other Backbone code or libraries.

Binding data with models and collections in Alloy is a breeze — with a simple config, an attribute and a line of JavaScript code, your data is retrieved from a database, local storage, a remote API or an array and bound to a repeating view, like a ListView, TableView, ScrollView etc.

Better still, if your data changes it’s updated in those views automatically — what can normally take 50+ lines of code to bind data to say a TableView, can be achieved with a single line of code. This means you write less code; have less chance of bugs and your codebase is cleaner and easier to navigate for you and other developers.

Models themselves are an instance of a data record — and collections are “collections” of models — each model and collection is configured so that Alloy and Backbone know how to deal with them; how to fetch, update, delete, create etc.

This means you can update a property in a model, call model.save() and the model updates, whether it’s in local storage, a database, remote API or in an array — that’s all there is to it!

When I first started using Alloy I ignored the models and collections for a long time (as you can still use classic methods of binding data in Alloy too). When I finally got into using models and collections it was a revelation — I couldn’t believe how little code I had to write!

And, it led me to develop tools like RESTe and Mocx, which help integrate other kinds of APIs, or bind data in Alloy apps with mock data.

The V in MVC is for “Views” — these are XML-based and feel a lot like laying out a web page. Every View starts with an Alloy tag, and then you have different elements you can add to a view, with all based on a naming convention that follows classic Ti.UI controls, just with the prefix removed.

So, to create a Ti.UI.Window, you create a Window tag. To create a Ti.UI.alertDialog, you create an AlertDialog tag. Pretty much all the visual elements follow the same principle, so it’s quick and easy to adapt to laying out views in Alloy. Your XML views can, but don’t need to, have any styling in them at all.

You can add in-line styling if you like, and sometimes this is useful for the odd spacing or positioning where you don’t want to create specific style definitions. But, it’s entirely possible to have a View defined that has no layout.

<Alloy>
	<Window>
		<View>
			<Label id="myLabel">Click the button!</Label>
			<Button onClick="doClick">Click me!</Label>
		</View>
	</Window>
</Alloy>

In the example above, you can see that the main View is within the Window, and the View contains a Label and Button. This is what’s great about Alloy and MVC — you can instantly see the relationship between elements. I could add some attributes to this to position elements or define the layout of a view.

Contrast that with classic Titanium apps, where developers can have different ways of laying out a screen. They might define all the elements first, then add them all to each other at the end, OR they may create each element and add it to its parent as they go. There’s different ways of doing it and typically you can spend some time going through a file working out where the visual elements are and how they relate to each other.

The next part of Views is Styles or TSS (Titanium Style Sheet). Not to confuse with CSS, TSS is just the representation of the properties of an element. It can be related to its tag, e.g. styling ALL Button tags, or an individual item (its id) or a class of style that can be applied to many elements, for example:

// this defines the Window tag
“Window” : {
	width: Ti.UI.FILL,
	height: Ti.UI.FILL,
}

// this defines the View tag
“View” : {
	layout: "vertical",
	width: Ti.UI.FILL,
	height: Ti.UI.FILL,
}

// this is id based for all platforms
“#myLabel” : {
	top: 40,
	width: 300,
	height: 45,
}

// this is id based and overridden for Android
“#myLabel[platform=android]” : {
	height: 50
}

// this defines the Button tag
"Button" :{
	top: 20,
	width: 300,
	height: 45,
}

Views and Styles can also have platform and formFactor specific conditions (as well as custom conditions too), so you can easily target specific elements, classes etc. to be visually different on Android, iOS, Windows Phone and also based on if the app is running on a Tablet, Handheld etc. You can also create specific conditions – for example, Alloy.Globals.isIPhoneX() as a method that returns true or false based on if the app is on an iPhone X.

What’s cool about this approach is that because Alloy is a pre-processed framework, ONLY the elements relevant to the platform are included in the build. This means you can have entire views, screens, assets and more associated with JUST Android and they’ll only be included in that build.

One of the great benefits of using Alloy is that it can take care of the cleaning up of a Window or View for you. Traditionally in Titanium, you might create Windows, Views, Labels, Buttons, adding them to each other to create your view. When your View is closed, you may have written code to clean it up — removing elements, nullifying them and releasing memory.

The good news is that with Alloy, as long as you define the elements in views, Alloy will take care of the clean-up itself, meaning you don’t have to write all this unnecessary clean up code.

You can even write your own code to intercept some of the Alloy methods that create controllers and views — AlloyXL for example is a library that intercepts the Alloy.createController method, adding additional events and other features to help you write less code.

The final part of MVC is “Controllers” — these are JavaScript files that usually accompany each view (although you can create controllers without views). Each View usually would have a controller and that handles the JavaScript logic of the View. This separates the JavaScript code from the View in a way that makes it easier to interact with a view with very little code, or adapt per platform etc.

In the example above, we have a simple View with a button and label. Notice the Label has an id and the Button has an onClick event handler specified. Our Controller pairs with the View and has the handler function defined. You’ll notice that it’s using $.myLabel to reference the label in the view and changing its content when the button is clicked:

function doClick(){
	$.myLabel.text = "You clicked me!";
}

There’s SO much to controllers in Alloy — you can have a kind-of inheritance using baseControllers, you can require other controllers / views and add them to your controller / view. You can fire triggers from controllers and pick up these events from other controllers, allowing you to create loosely coupled connections between screens and views.

Controllers, like views are also platform specific. So you can have one controller for all platforms, or create an Android, iPhone, Windows subfolder with specific versions for that platform. This is useful if you have very differing code in the controller that would require a lot of conditional statements and become long and complex to navigate.

Since Alloy is based on CommonJS, you can have additional JS files in the lib folder of a project (or use ES6 require) to add in additional library support, shared functions etc.

In reality, controllers are typically pretty small in terms of JavaScript code — handling the interaction between the controller and the view, with business logic usually coming from required files or other parts of the app.

Themes

Another cool feature of Alloy is theming — with themes you can create separate styles and assets for different versions of your app. You might have an app that has a single codebase but builds several different apps. For example, a Golf Course app built for different courses, or a Student app for different schools. They might share much of the functionality of each other, but also may look different with different icons, splash screens, styles etc.

With theming, it’s really easy to setup multiple themes, and tools like TiTh let you switch these at the command line easily, even theming TiApp.xml too — so with a single script, you can build multiple apps for different brands for iOS, Android and Windows.

Widgets

Widgets are like mini Alloy apps that can be included in your main app. So for example, you might create a “Login” widget that contains a username / password field, forgot password option etc. This could have a generic style, but be customised via TSS — so switching the forgot link off and on, or specifying the URL it goes to etc. You can use triggers and events to handle interactions with the widget, and each widget can be styled and built with multi-platform support built-in, so you can be confident that dropping in a calendar picker widget will work on all platforms.

Widgets are a great way to create reusable components that you can use throughout all your apps — there’s some amazing examples out there and even a web site gitt.io where you can lookup, install and test widgets.

Custom tags and components

One of my favourite features of Alloy is the ability to override the tags in a view to add new features OR create your own. As I mentioned earlier, most Alloy tags are based on Ti.IU components. When Alloy pre-processes the app, it looks through the view and turns every tag into a Titanium component using Ti.UI.createWindow etc. Because Alloy is based on commonJS, it’s really easy to intercept this and define your own control.

There’s a detailed blog post on this which talks about how you can use this to define your own Alloy tags, or make existing ones like Ti.UI.iOS.NavigationWindow cross-platform!

Of course, Alloy isn’t the only way to build apps with Titanium. You can still use classic Titanium if you like, and we recently launched technical previews of Angular and VueJS, which alongside Alloy, give you a lot of flexibility in terms of how you want to build mobile apps with Titanium.

What do you like best about Alloy? What libraries, tools, utilities do you use to make Alloy development easier? Let us know in the comments.

Stay tuned for the follow up post to this one, in which we talk about how you can take a classic Titanium app and migrate it to Alloy.

Find out more about Alloy

Happy Coding!

0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×

Sign up for our blog!

computer and tablet showing Appcelerator software
Start free, grow from there.
0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×