【轉】About Titanium framework

[url=http://zenborgium.blogspot.com.au/2011/12/about-titanium-framework.html]http://zenborgium.blogspot.com.au/2011/12/about-titanium-framework.html[/url]

[b]In general[/b]

Titanium framework is a framework for cross-platform application development which is developed by a company called Appcelerator (http://www.appcelerator.com/). Titanium framework is open-source (https://github.com/appcelerator/titanium_mobile) and free of charge, although Appcelerator provides payed profesional services (http://www.appcelerator.com/products/plans-pricing/). Titanium Studio is IDE for Titanium framework and is also free of charge, but some extra functionality can be purchased.

Titanium framework consists of Titanium Mobile for mobile and tablet application development (Android, iOS, Blackberry in beta status currently) and Titanium Desktop (Windows, OS X, Linux) for development of desktop applications. Also, Titanium Mobile Web version is coming soon.

"Cross-platform" means that you need to write code once and that code, when "compiled", can run on any platform Titanium supports without any modifications. Sounds nice, but in practice it's not ideal like that (that will be mentioned later).

Titanium mobile as (common) programming language uses JavaScript (so, pre-request for development with Titanium framework is knowledge of JavaScript), while Titanium Desktop besides JavaScript supports PHP and Python. I'll focus primarily on Titanium Mobile development.

[b]Types of cross-platform development strategies[/b]

To give more broader picture, I must mention what kind of approaches exists in mobile and tablet development.

In general, if you want to develop application for more than one platform, lets say Android and iOS, you have to write two different applications. One in Java for Android and one in Objective-C for iOS. This approach is called native because of the usage of platform specific language to develop native applications. The disadvantage of this approach is obvious. For everything you need to do, you need do it twice. You need to learn two languages, you need to write two applications, you need to maintain two applications and so on. Since there are more than two possible platforms, for example there is Windows Phone, there is WebOS, there is Symbian, BlackBerry OS ... it is obvious that developing one application for all platforms can be very difficult. Or from company point of view, developing applications can be expensive because company needs to hire a man for every platform it plans to develop applications for.

That's why some people came with different approach. Basic idea was to use something that exists on all platforms for application development. That thing was HTML and JavaScript inside web browser's engine. So basically, this new approach is web-based mobile and tablet applications. Advantage was obvious, you could write application once and run it on every platform that has embedded browser in itself. Sounds awesome, but the problem is application speed. JavaScript engines are getting better and faster every day, but mobile phones still have limited computing power. Also, that kind of applications could not create all native UI components, although they have access to native functionality like accelerometer, camera and so on.

Somewhere in between this two approaches is the third one - hybrid approach. Titanium is one good example of this approach. Titanium framework provides JavaScript environment in which native functionality and components are exposed as JavaScript host objects.

If you're not familiar with JavaScript host objects, in general, there are two kind of objects in JavaScript, native objects like Object, Array, Date and so on (the ones defined in ECMAScript specification), and there are host objects that are provided by host environment in which JavaScript code is executed. For example, in browser's JavaScript environment host objects are window, document and so on. Titanium framework environment is not like browser environment so it does not have any of host objects that are present in browser environment, but it has it's own host objects.

So, one application part developed by Titanium framework is native (host objects implementation is native), while other is not (application source code is written in JavaScript which is interpreted and executed in JavaScript engine).

[b]Titanium JavaScript environment[/b]

All Titanium objects and functions are present under "Titanium" or "Ti" global object that represents namespace. Under that namespace, there are sub namespaces that represent encapsulation of some particular functionality.

In that namespaces, there are factory style methods which call results as call of some native functionality provided by platform for which Titanium application is compiled. In the background, Titanium framework is a bridge to native components and native functionality, while itself is not completely native. JavaScript code is still interpreted during runtime and is not converted and compiled to native code. In most cases, that is good compromise and Titanium applications can run fast. When there is a need for real native speeds, Titanium provides ability of extension through modules which are native. So for performance important parts (and for parts which Titanium framework does not implement) you can develop module that will run at native speeds, but you still call that functionality from JavaScript.

Some of Titanium sub namespaces are:

[list]

[*]UI - contains user interface functionality

[*]Network - for network related functionality

[*]Database - functionality for SQLite database access and querying

[*]API - different logging functionality

[*]App - functionality related to application in general

[*]XML - for manipulation with XML documents (DOM 2 compliant)

[*]Platform - functionality that is related to platform on which application runs

[*]Map - functionality for map display in user interface

[/list]

... and so on.

Typical call of some Titanium functionality would be:

var button = Ti.UI.createButton({ titile: 'Click me!' });
Ti.API.info('Titanium application is running ...'); 
var xmlDocument = Ti.XML.parseString('<root><node>Test</node></root>'); 
           

That would create simple button with "Click me!" text on it, print output in console and the last statement creates XML document from a string.

[b]Titanium mobile UI[/b]

The most important thing to understand in Titanium is "UI" namespace. Under this namespace, there are a lot of factory-style methods responsible for creation of different UI components.

There are three types of UI components - contexts, containers and controls (in official documentation they are not called this way, but they have similar names).

Contexts are components which are basically windows. When created and opened, they make new visual window in the application. They are top level components, which means, nothing can contain them. They are used for navigation.Beside regular Window component (created with "Ti.UI.createWindow" method), there is TabGroup component. TabGroup component contains Tab component, which contain Window component. TabGroup component is basic navigation system between windows in each tab. Although, Window component can stand for itself, TabGroup must contain Tab component and Tab component must contain Window component. Similar pattern can be found in other types of UI components, so some of UI components have parent elements and they can't be found in other components. So here for example, Tab can't be added to the Window, it can only exists in it's parent component, which is TabGroup.

Containers are UI components that have rectangle box representation. They are used for presentation. Typical example of UI container is View component (and it is the most generalized component), while others are ScrollView, TableView (which contains TableViewSection and TableViewRow) and others. They can contain other UI components except those of context type. There are some restrictions, similar as there are in context type components. Here, for example, TableViewRow component can't exists for itself, it must be in TableViewSection (actually it doesn't, but one is created implicitly if you don't define one) and TableViewSection must be in TableView component. Then, TableViewRow, since it's container type itself, can contain other containers and controls. Other restrictions are related to scrolling. There are two containers that are scrollable - ScrollView and TableView. The thing here is, what if one of them contains other. Both can't be scrollable, therefore one of them loses ability to scroll (the one that is child container).

And the last one UI component type are controls. Some of them are TextField, Picker, Switch, Button, Label and so on. They are special units in interface that are responsable for user iterations like text input, choosing between options, displaying text and so on. They can't have other controls, but there are exceptions. Here is present similar pattern as the one that exists in context and container type, some controls can't exists for themselves, they can only exist as a part of some other control. For example, there is PickerRow control that can only exist inside PickerColumn control (actually, it's not completely true, similar thing stands as for TableViewSection) that can only exist in Picker control.

There are also some special components: different types of notifications that in general doesn't have parent element (AlertDialog and ProgressBar for example) and animations and transformations.

This was not complete UI reference, only short overview. Complete reference can be found here: http://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI-module

All UI components respond to events, it's their way of communication with other components. User interaction with UI components produces event, but device itself can produce different events like gestures for example.

In general, there are two types of events in Titanium framework - component based events (component.addEventListener("eventName", eventListenerFunction) and application level events (Ti.App.addEventListener("eventName", eventListenerFunction). Component based events are bounded to component and they "live" while component "lives". On the other hand, application level events are accessible throughout application and they live until application runs.

[b]Cross-platform development in Titanium mobile framework[/b]

In Titanium UI namespace, there can be found components that are special for one particular platform. So, "cross-platform" in general is wishful thinking. All platforms are different and all platforms are specific. Therefore, true "cross-platform" isn't possible. There will always be some kind of platform specific tweaks. But the thing here is that the most of the code can be reused because all code is written in JavaScript. If proper abstraction is made in application design, percentage of code that can be reused on different platforms is greatly increased (it would be ideal if only some UI parts should be written as platform-specific). When counting amount of code that can be reused and speed of development with JavaScript compared to speed of development with Objective-C or Java, you can come to conclusion that developing applications this way can be very beneficial in most cases.

But, I must say that, justified or not, iOS side of Titanium mobile framework was preferred by Titanium makers (I think that in first it supported only iOS). Android side of Titanium mobile framework has much more bugs, while iOS side has much more modules developed. So, accomplishing great amount of cross-platform code can be hard task. There are also parity issues between platforms, so in practice you'll have to write platform-specific code that will handle those parity issues. Also, there are still a lot of bugs that are related to basic functionality. Just see this topic from Q/A: http://developer.appcelerator.com/question/130158/text-field-weirdness-on-ios-simulator-and-differences-to-android-implementation

So, things can be better and they are getting better. Current version of Titanium mobile framework (1.8.0.1) has introduced new JavaScript engine on Android side (v8 instead of Rhino) which is much more faster and has less bugs (although, it's still in early stage and has it's own bugs, but with time I'm sure they will be fixed). Also, new version of Titanium mobile framework will be focused on parity issues and I hope more modules will be developed for Android side.

That way, Titanium framework would stay on the track of being (good) cross-platform solution.

[b]Getting started[/b]

To get started programming with Titanium, I recommend to download Titanium Studio (http://www.appcelerator.com/products/titanium-studio/) and to start exploring Wiki (https://wiki.appcelerator.org/display/guides/Quick+Start) for all pre-requests (but also other useful information). Once you installed everything you need, try to compile simple application. For development, I recommend that you use Mac (or Linux) machine instead of Windows machine. It's much faster that way, not to mention less bugs. Also, Android emulator can be really, really, really slow. Investment in Android device is a must if you plan to develop for Android primary.

KitchenSink examples (http://github.com/appcelerator/KitchenSink) are good reference on how to use different Titanium API parts, but - don't use KitchenSink project structure to structure your project.