In the upcoming 1.5, we’re adding some additional functionality to help you improve dealing with the various screens (thank you Android and RIM) as well as handling applications for a variety of languages around the world. These are two big areas that have needed much improvement and we’ve made some big changes (that landed this weekend in Git) to start to make the easier for you.

Internationalization and Localization (i18N)

Up until to date, there wasn’t a built-in Internationalization and Localization framework per se in Titanium. We’ve had numerous different approach to handling this, mainly through meta frameworks on top of Titanium. However, for 1.5, we’ve brought this in as a first-class citizen in Titanium. We’ve also made is cross-platform out of the box to help you deal with the various types of devices and specifics around how each platform handles it differently.

We’re adopting a new directory (optional) in the project root, aptly titled i18n. Inside this directory, you’ll create one or more directories for each locale/language combination you’re localized for. For example, for English, you could create a directory titled “en”. Or, for US english, you might create one titled “en-us”.

Inside this directory, you’ll create an XML file titled “strings.xml”. Save it either as UTF-16 or UTF-8 and then create your strings like so:

<?xml version="1.0" encoding="UTF-8"?>
<resources>
  <string name="welcome">Hello</string>
  <string name="format_test">My name is %s</string>
</resources>

Now, you might want to provide this localization also in Spanish. Let’s create another directory, titled “es” and create the following file:

<?xml version="1.0" encoding="UTF-8"?>
<resources>
  <string name="welcome">¡Hola</string>
  <string name="format_test">Mi nombre es %s</string>
</resources>

Now, this will automatically create the appropriate platform-specific localization files/bundles/etc when your application is compiled.

You have a couple of options for handling these strings in your application code.

First, you can use the new built-in L function. This is a short-cut to the longer Titanium.Locale.getString method.

alert(L("welcome"));
alert(Ti.Locale.getString("welcome"));

You’ll also sometimes need to format your strings. We’ve provided some new helper functions to make it easier to do that as well. For example, you can perform formatting for example:

var message = String.format(L("format_test"),"Jeff");

String.format takes a string formatted using IEEE printf specification.

You can retrieve the current locale using Ti.Locale.currentLanguage property.

Dealing with multiple screen sizes and varying layouts

We’ve been working on various techniques for how to deal with the differences in platforms, screen sizes and densities. As Android continues to grow and as we expand to new devices, it’s becoming apparent we need to provide better capabilities in this area and we’re making the first step of several in this direction.

In our experience and looking at all the source code of applications that come through support, it’s apparent that more than 60% of your time and code is spent in layouts. Constructing the UI can be rather easy in Titanium but can become tedious as you’re trying to make it work seamlessly and natively across different screens. It’s also hard to reuse layouts and code as well as make it portable if you’re not careful and thoughtful from the beginning.

We’re introducing a new native framework built-in that we’re calling JS Stylesheets or JSS. They’re are syntactically the same as Cascading Stylesheets (CSS) for the most part, but we’re calling the JSS to not confuse or interfere with HTML5 CSS you might want to include in your application.

Titanium does special stuff now with the introduction of JSS. First, you’ll create a file with the name of your context and the jss file extension and place it in your Resources directory. The Titanium compiler knows how to compile this file into special code.

Let’s give you a simple demonstration on how you’d use it in app.js. First, let’s start out by creating the new JSS-powered app.js file that creates a window with a simple button.

var window = Ti.UI.createWindow();
var button = Ti.UI.createButton( { id : "b" } );
window.add(button);
window.open();

OK, much less code. Now, let’s create the layout/styling of the button by creating a file named app.jss:

#b 
{
   width:100;
   height: 40;
   title: "Hello"; 
}

Now, we’ve externalized the layout/styling from the actual business logic. We have some very specific ideas on how to take this to the next level, including some layout tools, however, we’re going to stop there for 1.5 and make this solid first.

So, you’ll be able to also do some advanced layouts by naming convention. Say, you have a high-density device you want to have the sizes or positioning different. In those cases, the business logic of the application is the same. No more “if than else” in your code. Let’s do it with compile time JSS files.

Create a file named app.android.high.jss.

#b 
{
   width:200;
   height: 45;
   title: "Hello"; 
}

In this case, we’re saying on an Android high-density device, you a different set of stylings for the button with the id “b”.

You can also use CSS keywords like @import to import other files to combine them and to make it easy for meta frameworks on top of Titanium.

@import "common.jss";

So, how about internationalization and JSS? That’s easy with locale-aware keywords like titleid:

#b 
{
   width:200;
   height: 45;
   titleid: "button_b"; 
}

Beyond 1.5, we’ll have a lot more capabilities beyond as this is just one of the many ways we’re going to make it easier and faster for you to use Titanium in your cross-platform applications.

We’d love your feedback and ideas, too.

A couple of questions have surfaced from community members recently with regard to execution contexts in a Titanium Mobile application. I thought I would take a few minutes to explain execution contexts to folks for whom the concept is still a little foggy. First, let me explain what I mean when I say “execution context”.

A JavaScript application running in a web browser is single threaded and has a global variable scope for the entire application. A Titanium Mobile application is similar, except that a single application may have multiple JavaScript processes running at once, each with it’s own unique scope. We call these “execution contexts”.

Every Titanium Mobile application has at least one execution context, the one created by the app.js JavaScript program which bootstraps your entire application. New execution contexts are created when a window is created that points to an external JavaScript file, which would then bootstrap the new window. We refer to windows that have their own execution contexts as “heavyweight” windows (making those that do not “lightweight” windows, since a window need not point to an external JavaScript file). The syntax for creating a heavyweight window is below, and familiar to the majority of you I am sure:

var win = Titanium.UI.createWindow({
  title: 'New Window',
  url: 'win.js'
});

When this new window is opened, it will have it’s own context and scope, so any variables declared in other contexts will not be available. Say that my app.js file contains the following code:

var awesome = true; //this is visible in the current execution context
var win = Ti.UI.createWindow({
  title: 'New Window',
  url: 'win.js',
  backgroundColor:'#fff'
});
win.open();

And win.js contains the following code:

var label = Ti.UI.createLabel({
  text: (awesome) ? 'JavaScript is awesome!' : 'Yeah, well so\'s your old lady!'
});
Ti.UI.currentWindow.add(label);

This example would fail because the code in win.js is not executed in the same context as the code in app.js, so the variable awesome is out of scope.

Occasionally, it is necessary for one context to communicate with another. This is accomplished using the custom events facility that is built into the Titanium API. You can fire application-level events that will be received in all currently active execution contexts (app.js plus any open windows) via fireEvent. Custom events can have arbitrary data passed along with them, as shown in the example below:

Ti.App.fireEvent('myCustomEvent', {
  myCustomEventValue: 'someValue'
});

You can listen for these custom events in any context by using addEventListener at the application level as well. The example below listens for our custom event – you’ll notice that any properties of the object passed as the second argument to fireEvent are available on the event object the callback function takes as an argument:

Ti.App.addEventListener('myCustomEvent', function(event) {
  Ti.API.info('You sent me: '+event.myCustomEventValue);
});

Note that only ACTIVE execution contexts will receive a custom event when it is sent, so any windows that are not yet open will not receive the event.

While not every application requires multiple execution contexts, it is good to know when execution contexts are created and how they work. Hope that helps, and let us know if you have any questions.