historical blindfold games, current events and videos



Feb 16 15

Titanium without Titanium Studio

We recently built a small project using the Titanum framework for mobile apps. Pretty quickly I realized I wanted to escape from Titanium Studio. What motivated me? Let’s just say Eclipse and I don’t get along. Below I describe how I set up my Titanium dev environment with Webstorm, TIDebugger and typescript.

First things you have to do, which I won’t be describing here:

  • Titanium installed
  • android sdk installed
  • properly set up the PATH variable to reach android binaries (my is C:\android-sdk-win\platform-tools;C:\android-sdk-win\tools)
  • latest java development kit (jdk) 1.7

If your environment is configured correctly you should be able to run the command “android” from your TI project folder to start the “android sdk manager” application.  At the time of this writing, the latest android API was 21, which contains “intel x86 atom system image”. I used this for my “fast” andriod emulator.  Before launching the command line interface, you should create your “Android Virtual Device” (AVD) by “Android Avd Manager”. Open this by running

android avd

from the command line and create a new one as shown here.

02-avd

Save me WebStorm

Ok, now you are ready to free yourself from Titanium Studio.  I have had great experiences with Jetbrains WebStorm with its superb code completion, cutting edge technology support, and it’s cool looking darkula color scheme. You can write code in notepad if that’s what works for you, but at some point you’ll have to do some compiling and deploying. Luckily Titanium has Titanium-CLI – command line interface. This contains tools for building, packaging and deploying app to device/emulator. So far, so good. The call to build titanium for android platform and push the package to emulator is –

titanium build -p android -T emulator

03-cli build 01

It needs to be executed in the project folder, so the CLI will find the project and get its settings. If it hangs on the “waiting on emulator message,” it means the emulator itself hasn’t been started. Just start your emulator manually. Sometimes when the emulator is already running, another one is kicked off in parallel, and the application is deployed to the first one. Similar behavior happened in Android Studio so I suspect the android sdk.

cli04-cli build 0205-emulator

After few minutes you should be able to see something similar as above. On second screenshot you can see how long it took to build and deploy the app – 2 minutes.

OK, so now we are writing code with WebStorm and in a terminal window we are triggering titanium-CLI to build/package/deploy. WebStorm is cool, but the speed of deploy is really an awfully slow process. Doesn’t matter if the package is deployed to device or emulator — it’s painfully slow. On top of that some devices you even have to uninstall previous version before redeploying. Still very uncomfortable and so many steps.

Bring on TIDebugger

There is a project TiShadow and based on this, the TIDebugger (https://www.npmjs.com/package/tidebugger). I didn’t believe it at first, but this tool is really the key to happy application development with Titanium!  Trust me, you’re going to want to install this. Installation is through NPM, and is straight forward.

Ok, what is it? It’s a hook to the Titanium build/package/deploy process. It provides a kind of client/server application deploy infrastructure. It means that the client (emulator/device) is connected to server (developer machine) over IP network.  The server can handle multiple clients and can push to these clients modified version of javascript files.  If you’re unfamiliar with the way Titaium works, you might not yet see how this can help us. Part of the appeal of the Titanium UI layer is that the resulting applications have real platform controls, but the code you’re writing is Javascript and it’s important to know that it’s never compiled. Instead, it’s packaged and the interpreted on-device.  Due to this architecture design, it’s possible to update ONLY the javascript and, after simply restarting the application, we can immediately see our changes. This is approximately 1000% faster than rebuilding, redeploying and THEN launching the app. Plus or minus.

05-tidebugger 01 06-tidebugger 02

After you’ve installed tidebugger, trigger your Titanium build using the tidebugger option to titanium-cli:

titanium build -p android -T emulator --itdebugger

It’ll ask for some details about the server IP address and target device to deploy on. This –tidebugger option triggers the build/package/deploy, starts the server and does even more. It starts the filewatcher on .js files, which triggers the automatic new file version deploy. This leads to the current modern style of rapid web coding using grunt library with filewatchers, less compilers, test tasks and so on.

Well I wrote how cool it is, but also it has few limitations

  • you cannot add new .js file. In case you want to, you have redeploy the app
  • you cannot hit created breakpoint and read variables. As workaround the console.log would be enough
  • sometimes the ADB (android debugger bridge) or client/server of tidebugger broke, so you have to restart adb and redeploy the app

But in meanwhile it does work well, I really enjoyed the speed of the loop – change the code, ctrl+s and see the result.

Bringing in Typescript

I’ve been addicted to typescript for a while, so time to bring that into the fold, especially since WebStorm supports “compiling” TS  to javascript using file watchers.  So let’s say we have some modules written in TS, compiled to JS.. now the question is how to use them in a Titanium project.  Titanium is using CJS module style (module.exports and require(‘path/module’) – http://addyosmani.com/writing-modular-js/ ). So in TS file at bottom you just add “module.exports = ClassName”. This is compiled to JS literally equal, so it follows the CJS guide. Then in JS code you will write “var ClassName = require(‘path/ClassName’)” and you call constructor of ClassName. We’ll get to an example soon.

But again, there is one drawback with existing workaround :D. As I wrote above, tidebugger is using filewatchers to trigger the update of the JS files on emulator/device. But the WebStorm TS compiler filewatcher does no update the JS files with final content. It deletes whole content, and then writes the new JS content. So each file is updated more than once, which really confuses the tidebugger on device/emulator side so much that it fails and stops. The solution is to modify tidebugger not to trigger push to clients immediately.

It’s a bit of a hack, but it can be done just by commenting a few lines in tidebugger npm. You have to find where your tidebugger npm is located – I install it globally, so I have it in C:\Users\zdenek\AppData\Roaming\npm\node_modules\tidebugger. Or if you install it locally to project, it will be in node_modules folder. Then you will find tidebugger file in cli subfolder, open it in editor and comment notifier settings like this:

.action(function(env) { // run package notifier but only on server command.
// var notifier = updateNotifier({
// packagePath: "../package.json",
// updateCheckInterval: 1000 * 60 * 60 * 24 * 7
// 1 week // });

// if (notifier.update) { // notifier.notify(); // }

config.init(env); require("../server/app.js"); });

Once you’ve done this, the auto trigger will be disabled. That means you have to trigger it manually by executing

tidebugger run

from command line. There are several switches to the command which are nicely described here: https://www.npmjs.com/package/tidebugger#what-you-can-do-with-tidebugger

So that’s it!  Hopefully this improves your Titanium development experience.  Please leave any questions or comments below!