More on “exec returned: 2″

I thought I was in the clear. I had it all figured out once and for all. ERR#2 NO MORE! And then I changed the structure of my java module project a little bit…

I was getting the same error again. I tried cleaning my project. I tried deleting compiled classes in the build folder and the libs folder. It didn’t help.

Here’s the last few lines from the compilation output:

[exec] /users/ophir/android-ndks/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/darwin-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /var/folders/69/dscwd_6j1lzfdx3x88mpb4kw0000gn/T//ophir/myprojectmodules-generated/obj/local/armeabi/objs/com.myprojectapp.modules/com.myprojectapp.modules.ParallaxImageProxy.o: previous definition here
[exec] collect2: ld returned 1 exit status
[exec] make: *** [/var/folders/69/dscwd_6j1lzfdx3x88mpb4kw0000gn/T//ophir/myprojectmodules-generated/obj/local/armeabi/] Error 1

So if you read more closely you could see that the a class called ParallaxImageProxy – which I deleted from my project all together! So why does it keep bothering me – especially after the intensive cleaning I’ve done. Well honestly – I don’t know. But it did supply me one more clue – a directory where that .o file is.

All I had to do is to navigate to that directory go a few directories up, until I see a folder that’s named after my project namespace and delete it entirely.

Now everything compiles :)

Appcelerator Titanium Android Native Module “exec returned: 2”

I get this error a lot! don’t really know why. I’m guessing is has to do with something in the environment getting changed/updated. The result is the same every time – when building with ANT you (eventually) get “exec returned: 2”.

If you google the problem, you’ll find one post too many about the subject. Some of them actually did the trick in the past. But mostly it was some combination of Android API version and the NDK version (defined in file).

I recently just ran into the same problem again, in a project that was previously compiled fine. The only thing that changed on my machine (other than new Titnaium SDK and the new Appcelerator Studio – which don’t affect the native module compilation since I was not compiling against the new SDK) – was a new version for xCode.

If you’re already familiar with the problem, you know that one of the suggested solutions is to install Apples’s Command Line Tools – which I tried (since updating xCode) – but that did not work.

After doing some digging I found an interesting thing – there’s a problem with Android Native Module projects that has the underscore ( _ ) sign in the name (opened Jira ticket here:

So if your project file, contains an underscore sign in the name, know that it might be your problem. Do a search inside all the files in your project for your project name and remove the _ sign from it.

It’s been a while – here’s what you missed (or… what I haven’t told you)

Due to spamming of my WordPress bolg, it was down – but I fixed it. I had to manually delete comments (which I’m not done with yet – since I found there are child tables that still need deleting from).

What I’ve been up to since my last post?

– I’ve released a new open source project named Poco.Sql – it’s a lightweight .NET library for generating SQL statements from plain objects with advanced features and mapping.

– I’ve got an invite from Appcelerator to try out the new Appcelerator Platform – So after dealing with some issues, and helping out with a few bugs, I’m now on my way to further testing the new Appcelerator Studio, SDK 4.0 beta and the new Platform services…

– I’m finally working on a new app (shhhhhh… it’s a secret) – but I will tell I’ve been waiting a long time to be working on that one.

– I’ve learned some more cool stuff that I’ll be writing baout soon (promise)…

Just released an update for my Kid In Car app

It’s my first post about this app of mine. It’s also my first update to the app – and a major one! I’ve changed the graphics, fixed some bugs, and added new features.

As a parent, I think it’s an important app to have installed on your phone – even if you don’t use it on a regular basis (you can set up working hours/days and disabling the app now works – bug fix!).

What this app does, is try to guess when you’re driving in your car, and than guess when you leave your car after driving it. It then shows an alert (even if the phone is locked and muted) to remind you to check that you didn’t forget your child in the car. There had been too many such cases, and this app hopes to prevent the next one.


I would love to hear what you think of it – and of course if you have ideas for new features…

Currently, it’s available only for Android:

You can also visit the website I’ve built for this app that explains a little more about it:

KidInCar alert when leaving the car

Hacking Titanium: Prevent default Alloy Controller (IndexController) from loading / load a custom controller

Titanium Alloy projects are built with conventions, and as such, one of the things you accept is a default controller that is loaded and run when you start up your app – the IndexController. But what if you would like to start a different controller as default? or want to have your own logic before launching a controller or the main window of your app?

In a “Classic” Titanium project you would do that in your app.js file – which is the first file that Titanium executes. You would run your logic and decide what window you would like to open.

I started my way in Titanium before Alloy came – with what today is called “Classic Titanium Project”. To navigate between the different windows of my apps, I used a cross-platform navigation controller. And I ran that logic in my app.js.

When moving to Alloy, I searched where to put this logic – since (and I was new to Alloy) IndexController was a window. And I didn’t want to open a window just to put my logic there and open another one. The result I eventually got to (and later was answered by the community), was that IndexController is the right place to put this logic, I can still use my cross-platform navigation control (since after all you can always use “classic” Titanium code/controls in your Alloy project), just to remove the <Window> element from the view.

Now, while this does the work, and is the “official” way of doing things in Alloy, I think we need to understand a little more about what’s going on behind the scenes…

I think I’ve mentioned it before, but if I haven’t it’s worth repeating – Titanium Alloy project compiles to “Classic” Titanium project (the actual javascript code that makes use of Titanium SDK), and only than compiles to the native platform.

So lets see what goes on behind the scenes (after the <Window> tag was removed from the view, the tss file is cleared and I removed the command to open the index window from IndexController)…

This is how index.js looks now when compiled to “classic”:

function __processArg(obj, key) {
    var arg = null;
    if (obj) {
        arg = obj[key] || null;
        delete obj[key];
    return arg;

function Controller() {
    this.__controllerPath = "index";
    if (arguments[0]) {
            __processArg(arguments[0], "__parentSymbol");
            __processArg(arguments[0], "$model");
            __processArg(arguments[0], "__itemTemplate");
    var $ = this;
    var exports = {};
    exports.destroy = function() {};
    _.extend($, $.__views);
    _.extend($, exports);

var Alloy = require("alloy"), Backbone = Alloy.Backbone, _ = Alloy._;

module.exports = Controller;

So as you can see, even if we have a blank controller, it still has some default code that it has to run, and variables it needs to initialize – so a correct question would be – why? why should I run this unnecessary code just to load a different controller?

So how do we hack this?

If in the compiled Titanium javascripts we have a look at another file – the app.js file – the first file that runs at startup, we will find this code:

var Alloy = require("alloy"), _ = Alloy._, Backbone = Alloy.Backbone;



This is an autogenerated code by the Titanium Alloy compiler. The first line requires the alloy module, and the underscore (_) and Backbone libraries, which Alloy project depends on – standard stuff!

The second line is interesting – it loads the index controller. Even though we didn’t specify ANYWHERE in our code to do so – this is the normal behaviour of an Alloy project – this is part of the convention.

This was my starting point when I started investigating the subject. How can we override this? Well, unless you open the compiler code (which we don’t want to do) we can’t remove this line. What if can somehow not have it executed?

The alloy.js file

In an Alloy project under app we have the app.js file. In this file you would put all of your app initialization, and global object/values (be sure to do that as part of the Alloy.Globals namespace so you don’t pollute the global scope). And in the remark of that file, it mentions the following:

The contents of this file will be executed before any of your view controllers are ever executed, including the index.


Lets add an alert (alert(‘Hello World!’); ), run the app and see what happens in the complied “classic” app.js file:

var Alloy = require("alloy"), _ = Alloy._, Backbone = Alloy.Backbone;

alert("Hello World;");


So now we learn, that what we put inside the alloy.js file is injected before the index controller is created. So how can we make the index controller creation not to execute? how about adding this line AT THE VERY END of the alloy.js file (it has to be the last line so it will come right before that call):

And to my surprise while writing this post…

var Alloy = require("alloy"), _ = Alloy._, Backbone = Alloy.Backbone;

alert("Hello World!");

The compiler was smart to remove the creation of the controller completely. Which is good – that is what we wanted! it’s actually better than the last time I have tried it – than it just added the if(false) just before the controller creation, which caused it to never get executed. like in the following example:

var Alloy = require("alloy"), _ = Alloy._, Backbone = Alloy.Backbone;

if (false)

alert("Hello World!");

In each case, the result is the same – we can add out initialization code in the alloy.js file and cancel the creation of the default IndexController.

log4ti Appender structure

Unlike platforms like c#, javascript don’t have interfaces that you implement and your app is bound to. So instead, we use conversions – a predefined structured that we agree on for a specific object.

So, if you don’t know what log4ti is, you can read about it here. Basically, it’s a logger library for Appcelerator Titanium projects that works on the same principles of log4net/log4j.

This post is to describe the structure that an appender object needs to hold in order for log4ti engine to work with it.

File name and path convention

The appender file is just a regular js file. The name could be anything you need and so does the location. By convention only, I have put all my appenders in a designated directory where the log4ti.js file resides named log4ti_appenders.

For the file name, I gave it the appender output target (like Console or File) underscore (_) appender. Example: console_appender.js


The appender object structure

An appender can be either a javascript class that needs to be initialized, or a “static” class – a javascript object. I won’t get into the differences of both as far as log4ti goes in this post – I will do it in a later post when I discuss about the log4ti engine.

The basic object structure:

	configure: function(cfg) { },
	write: function(l, m) { },
	dispose: function() { }


This function is being called when the appender is loaded, passing configuration options object passed by the loadAppender. In this function the general configuration of the module should be made.


This function will be called every time you wish to output to log. The functions accepts 2 parameters – the first one, l, is the logging level (debug, info, warn, error… or your own custom ones). The second parameter, m, is the actual message being sent to be logged.


This function will (and should) be called once the appender is disposed to clear any “static” variables in the commonJS module.

Titanium build stuck on “Compiling localization files” ?

I just wanted to run my project in simulator, but it didn’t get pass the message “Compiling localization files” – no error message.

I remembered from when I started to develop Titanium apps that this part of compilation (for some reason) could take time. So I let it be. But still nothing…

Turns out that the i18 xml file was invalid – but didn’t show any errors, nor did it show compilation error messages. So, if you have the same issue – carefully check your i18 files.

log4ti – A new logging library for Titanium apps

For those who are looking for a handy logger for their apps, I’ve now released my log4ti logger on github. It’s a first working version, but I plan on adding more options to it in the near future.

I was looking to do some kind of implementation to the popular log4net / log4j library.

The logger currently support all logging levels + adding custom logging levels.

I’ve developed 2 appenders for it to start with:

  1. Console Appender
  2. File Appender

Once loaded (see examples on github) you can map different levels to your loaded appenders.

I would love to hear what you think of it. Any ideas / bug reports are welcome either here or (more preferred) on Github issues.

Next planned on this project:

  • Add AlertAppender
  • Add header feature to file appender
  • Add option to configuration logger with json object
  • Add option to load configuration from configuration file (should be done after json configuration is implemented)

Project URL:

Using comment headers in your source code files

This is a small tip. It’s always recommended to at the top of every code file to include some little comments of copyrights, who created the file, and description. This helps to both keep your copyrights notice and describe who created and who changed the file. It’s mostly useful if you’re part of a development team working on a project, but also for yourself. It’s not a substitute for tracking your changes with a version control or a bug tracker.

So here is the format I use:

* Copyright         : <Year> <Copyright Owner>
* File Name         : <Filename>
* Description       : <Write your file description here>
* Revision History  :
* Date				Author    							Comments
* ---------------------------------------------------------------------------
* 07/11/2014		<Person working on the file>		<Short change description>


And here’s an example filled out:

* Copyright         : 2014 Ophir Oren (WEBe)
* File Name         : example.cs
* Description       : This file contains the my logic for the app.
* Revision History  :
* Date				Author    		Comments
* ---------------------------------------------------------------------------
* 07/11/2014		Ophir Oren		Created.
* 07/11/2014		Ophir Oren		Added function to return something.