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.

Hi everybody, and thanks to those of you who checked out our Titanium For New Developers webinar this morning. Just wanted to quickly share the slides from this morning’s presentation, and invite you to join us tomorrow morning when we talk about the new features available in our 1.4 release. Here you go…

There have been a few questions around how to package for distribution for iOS starting with Titanium SDK 1.4. Apple has changed the requirement on how you package and submit your application to iTunes connect. You can no longer use the web-based portal to upload your application.

I thought I’d explain the steps on how to package and distribute with some screenshot walk throughs.

In Titanium, you’ll do the normal package for distribution step, selecting your distribution profile.

NOTE: I have circled the “Select Distribution Location” since this is no longer required. In 1.4 SDK, we ignore this value. We didn’t want to rev Titanium Developer just to remove this field and to keep in backwards compatible. However, you will still need to enter a value for this field. In a future release of Developer, we’ll improve this.

After packaging, we’ll automatically start Xcode Organizer. Select the “Archived Applications” on the left menu and you should see your Application with a package date.

If you select the date, you will be able to enable the buttons at the bottom.

First step, you’ll want to validate your application. This will actually validate your application with Apple prior to submission and let them perform some pre-flight checks.

You’ll need to login to iTunes connect before you can validate. (The first time, you’re credentials will be empty. Subsequent times, if you check “Remember my…” if we remember).

After successful login, you’ll need to choose the appropriate application and profile. IMPORTANT STEP: If you don’t have an application setup in iTunes Connect (on the website), these subsequent steps SILENTLY FAIL.

NOTE: Organizer gives no visual clues to as what’s happening. The UI will lock-up while it runs network operations and when it fails, it simply does nothing and you have no idea. The biggest problem I’ve encountered is when someone doesn’t actually have an application setup (see above).

Choose your app and profile and you should see this alert result (after a few seconds to minute):

Since you’re building with Titanium, everyone should work. However, we’ve seen a few issues mainly related to the wrong size icon when validating. Apple has gotten more strict on icon sizes, etc.

To submit your application, click the “Submit Application to iTunes Connect..” button. BEWARE: when you do this, it will immediately upload your app and submit it for approval (assuming that your application details are setup).

At this point, your application should be submitted and in the queue for approval.