How Does Appcelerator Titanium Mobile Work

How Does Appcelerator Titanium Mobile Work?

Titanium takes your Javascript code, analyzes and preprocesses it and then pre-compiles it into a set of symbols that are resolved based on your applications uses of Titanium APIs. From this symbol hierarchy we can build a symbol dependency matrix that maps to the underlying Titanium library symbols to understand which APIs (and related dependencies, frameworks, etc) specifically your app needs. I'm using the word symbol in a semi-generic way since it's a little different based on the language. In iPhone, the symbol maps to a true C symbol that ultimately maps to a compiled .o file that has been compiled for ARM/i386 architectures. For Java, well, it's more or less a .class file, etc. Once the front end can understand your dependency matrix, we then invoke the SDK compiler (i.e. GCC for iPhone, Java for Android) to then compile your application into the final native binary.

So, a simple way to think about it is that your JS code is compiled almost one to one into the representative symbols in nativeland. There's still an interpreter running in interpreted mode otherwise things like dynamic code wouldn't work. However, its much faster, much more compact and it's about as close to pure native mapping as you can get.

We're obviously still got plenty of room to improve this and working on that. So far in our latest 1.0 testing, it's almost indistinguishable from the same objective-c direct code (since in most cases it's exactly mapped to that). From a CompSci standpoint, we can now however start to optimize things that a human really couldn't easily do that - much like the GCC compiler already does today.

How Titanium Appcelerator project works?

Take a look here, where jhaynie from Titanium answers those questions. You do not write the code in Titanium, though. You write HTML, CSS and Javascript in the program of your choice, then Titanium builds it to apps for you.

Where does Appcelerator Titanium Mobile cross-compile JS to native code?

In Titanium 1.4 on Windows/Android look in C:\ProgramData\Titanium\mobilesdk\win32\1.4.0\android\compiler.py and you will find:

def compile_into_bytecode(self,paths):
    jar_path = os.path.join(self.template_dir,"js.jar")
    for package in paths:
        args = [self.java,"-cp",jar_path,"org.mozilla.javascript.tools.jsc.Main","-opt","9","-nosource","-package",package,"-d",self.classes_dir]
        count = 0
        for path in paths[package]:
            # skip any JS found inside HTML <script>
            if path in self.html_scripts: continue
            args.append(path)
            count+=1
            self.compiled_files.append(path)
        if count > 0: run.run(args)

Is Titanium appcelarator an interpreted application?

Yup, the JavaScript code is interpreted on runtime. That's why it depends on Rhino/V8 for Android, for example.

It was also mentioned on part of a talk during CODESTRONG 2011.

You can always read more about How Appcelerator Works

Downsides of using Appcelerator Titanium (or equivalent)?

The Good:

Can create iPhone apps using very simple Javascript.

The Bad:

Apple has been rejecting some Titanium apps due to private API calls but Appcelerator hasn't responded to requests for help, nor updated their SDK. http://developer.appcelerator.com/question/123785/app-has-bee-rejected-by-non-public-api
"Native Widgets" are used, but only nominally: there's a layer of
logic and abstraction between them and your code; and this layer
changes their behavior and reduces their speed. The difference is
visible in the Showcase apps.
API docs are perpetually out of date. (no process for refreshing).
A wiki was created, which is becoming out of date. Editing only

allowed for employees.
Github projects do not have wiki enabled.
Appcelerator isn't true open source: they do not accept contributions from the community: The
titanium_mobile project on github has a long list of open pull
requests.
The help forum software has many technical & design weaknesses.
Email notifications from the help forum often do not work.
Staff rarely answers questions in the Q&A forum. Haven't been seen

in months.
Showstoppers appear continuously in "all the little gaps":
Correctly displaying images on the iPhone 4
Correctly loading images in a scrolling list
Although the platform does simultaneously support iOS and android,

the library/framework does not. A lot of runtime testing (if/then's)
is needed in apps that will work on android and iphone.
Continually releasing new products but not fixing existing products

and website problems. The "new" products are announced while in beta
and release candidate phases.
"Chat with Sales" app not attended to.
Appcelerator does not take down outdated training videos.
Stretching the truth and bait-and-switch with pricing: a 30% sale

only applies to yearly memberships, not month-to-month. The blog

posts & marketing materials do not state this. Only upon checkout is
this shown.
[Seen 8/13/2011] Another way in which Q&A forums are broken: The order of

results for a search is trashed: each page of results orders its hits
from oldest to most recent, at the bottom of the page. Go to the next
page of results (i.e. 51-100), and again, the 1-year-old hits are

first, with 6-weeks-old at the bottom.

My Unanswered Questions:

[Seven unanswered Q&A questions not shown: I don't want to be personally identified by Appcelerator staff
and receive sub-par treatment.]

Results:

Am spending many hours trying to discover an API in the absence of documentation, and hacking to discover workarounds. This time is wasted, and would have been better spent simply learning to make apps in XCode & Objective-C.

What happens to JavaScript code after app is compiled using Titanium Mobile

Titanium is not a wrapper around a web view as stated before (though that accurately explains how Phonegap works). Jeff's answer, linked in the question, is a technically correct explanation of how Titanium works, but here's the best version I've heard so far, from Marshall Culpepper:

It's true that Titanium Mobile used the WebView (in both Android and iOS) in the pre-1.0 days. However, this is no longer true and hasn't been since our 1.0 release is March 2010.

Since 1.0, we've shipped two separate Javascript runtimes with our apps, and we are running the Javascript code directly without a WebView. Your entire app from start to finish is now controlled by JS, and we provide a comprehensive set of Native APIs that enable this. Everything from UI widgets (yes, including WebView), Core APIs like Networking, Filesystem, Database, all the way to OS-specific things like JS Activities in Android. On the JS runtime front, we're shipping a forked version of WebKit's JavaScriptCore in iOS and a snapshot of Rhino 1.7 R3 CVS for Android. What we actually do with your javascript source is dependent on the platform, but generally it breaks up like this:

Source is statically analyzed to find references to Titanium modules
Localization strings (strings.xml), App metadata (tiapp.xml), and density specific images all generate platform specific analogs.
In iOS:
- An XCode project / configuration is generated
- JS Source is base64'd and inlined as a variable into a generated C file
- xcodebuild is used to generate the final binaries
- provisioning profiles, signing keys etc are applied
- iTunes and some other glue are used to send the IPA to your iOS device
In Android:
- An Android / Eclipse project is generated
- In "Development" mode, JS source is packaged as APK assets
- In "Distribution" (production) mode, when you're ready to ship the app, we compile the JS to Java bytecode using the Rhino JSC compiler. You can also enable this during development mode by setting "ti.android.compilejs" to "true" in tiapp.xml, see: http://developer.appcelerator.com/question/100201/enable-android-byte-code-compile
- dex, aapt, and other Android SDK tools are used to build and generate the final APK
- adb and keytool are used for pushing the APK out to the emulator and/or device

There are many more details that I could dive into specifically on each of these points, but the point I wanted to drive home is that we no longer use the WebView as our Javascript engine. You can however still embed WebViews, and we provide some simple integration that allows you to call Titanium APIs from an embedded WebView.

Appcelerator Titanium Mobile App Screens?

no..

you can do it like

var button = Ti.UI.createButton({..});

button.addEventListener('click',function(e){
    var window = Ti.UI.createWindow({
            url:"../newWindow.js",
            title:"newWindow"
    });

    Titanium.UI.currentTab.open(window,{animated:true});
});

i recommend to use the MVC-pattern like i already posted here.

How Does Appcelerator Titanium Mobile Work