In the Titanium CoffeeScript Compiler Plugin post from yesterday I introduced the plugin and described how to install it and use it for Titanium Mobile applications. Since then, I’ve had some inquiries concerning whether the plugin can be used for Titanium Desktop.

Titanium Desktop does not support the registering and use of <plugins> in your project’s tiapp.xml file. But today I updated the plugin.py so that it can be run directly by the python interpreter, thus making it available to command-line scripts. Either the working directory needs to be your project folder …

~/myprojectfolder $ python "/Library/Application Support/Titanium/plugins/ti_coffee_plugin/1.0/plugin.py"

… or you can pass your project’s folder as an argument:

~ $ python "/Library/Application Support/Titanium/plugins/ti_coffee_plugin/1.0/plugin.py" ~/myprojectfolder

So if you install the newest version of plugin.py (please see the previous post and video — or the README — for installation instructions), then run the script whenever you’re about to build your Titanium Desktop project, then you’re good to go.

Better yet…

If you are using Titanium Studio, which I highly recommend you do, you can take advantage of its Eclipse capabilities and add a “builder” to your project so that the plugin.py gets executed automatically each time you build. This video shows how to do that:

Note that the use of Builders is just one way in which custom actions can be executed inside Titanium Studio. Take a look at the Titanium Studio documentation section regarding Customizing Studio, which includes a sample script that executes when a file is saved inside Titanium Studio.

I’ve created a small plugin for Titanium Mobile which will scan your Resources/ folder (and sub-folders) at build time and, if it finds any CoffeeScript .coffee files, will run the coffee compiler on them to produce the .js files. Since build plugins run before the platform-specific build system kicks in, this actually works.

Find the project on GitHub at:

https://github.com/billdawson/ti_coffee_plugin

The README includes installation information. The short video below shows examples of installation and use.

NOTE: This is not an official Appcelerator project or utility. Do not request support from Appcelerator. Instead, feel free to file a ticket in the Issues section of the GitHub project, and I’ll try my best to respond in a timely fashion.

This is Part 3 of a series of posts about what’s coming up for Android development in the new Appcelerator Titanium Mobile SDK 1.3, which should be pushed out this week.

This time I’m featuring vertical layouts, which were implemented by Marshall Culpepper (@marshall_law.)

Vertical layouts allow for relative positioning along a vertical grid. Prior to this capability, you pretty much always needed to provide absolute positioning for your views and controls. If you follow the Titanium iPhone developments, you know that vertical layouts have been available there for a few versions now. They’ve now arrived to Android as well.

This very simple and unattractive example shows labels, text boxes and buttons stacked vertically.

To achieve this, I did not need to do any absolute position whatsoever. The code was this simple:

var win = Ti.UI.currentWindow;
win.layout = 'vertical';  

for (var i = 0; i < 3; i++) {
    win.add(
        Ti.UI.createLabel({
            text: 'This is label ' + i,
            color: 'black',
            width: 'auto',
            height: 'auto'
    }));
    win.add(
        Ti.UI.createTextField({
            hintText: 'This is text field ' + i,
            width: 'auto',
            height: 'auto'
    }));
    win.add(
        Ti.UI.createButton({
            title: 'This is button ' + i,
            width: 'auto',
            height: 'auto'
    }));
}

As you see, no "top" attributes were specified and all "height" attributes were just set to "auto".

Obviously sometimes you want to grid things horizontally as well, while still maintaining an overall vertical layout going down the screen. You can achieve this by adding views to your layout, and positioning child controls inside the views using absolute positioning. This hideous example shows three views which adhere to the vertical layout -- one stacked upon the other -- without specific 'top' properties. The first view has, within itself, some absolutely positioned controls, including a label whose 'left' and 'top' properties are specified.

The code for that example is as follows:

var win = Ti.UI.currentWindow ;
win.layout = 'vertical';

var view1 = Ti.UI.createView({
    backgroundColor: 'red',
    width: 'auto',
    height: 'auto'
});

var label1 = Ti.UI.createLabel({
    text: 'view1/label1',
    color: 'white',
    left: 1,
    top: 1,
    width: 100,
    height: 50,
    verticalAlign: 'top',
    backgroundColor: 'blue'
});

view1.add(label1);

var label2 = Ti.UI.createLabel({
    text: 'view1/label2',
    color: 'black',
    backgroundColor: 'gray',
    left: 110,
    width: 100,
    verticalAlign: 'top',
    top: 20,
    height: 70
});

view1.add(label2);

win.add(view1);

var view2 = Ti.UI.createView({
    backgroundColor: 'purple',
    width: 'auto',
    height: 80
});

var label3 = Ti.UI.createLabel({
    backgroundColor: 'green',
    color: 'white',
    verticalAlign: 'top',
    width: 'auto',
    height: 'auto',
    text: 'view2/label1'
});

view2.add(label3);

win.add(view2);

var view3 = Ti.UI.createView({
    backgroundColor: 'black',
    width: 'auto',
    height: 'auto'
});

var label4 = Ti.UI.createLabel({
    color: 'white',
    text: 'view3/label1',
    left: 1
});

view3.add(label4);
win.add(view3);

Stay tuned for more Android goodness!

This is Part 2 of a series of posts about what’s coming up for Android development in the new Appcelerator Titanium Mobile SDK 1.3, which is coming next week.

Here in Part 2, I feature the ability of the WebView control to handle mime types for videos and then launch the full-screen video player appropriately. This magic was programmed by Marshall Culpepper (@marshall_law.)

In this short video, I show the Android emulator running a small Titanium app that contains just a label (the one that reads “WebView control showing http…”) and a WebView control that is displaying Marshall’s Vimeo page. I click on one of Marshall’s videos, which takes me to that video’s page. I then click on the play button for that video, which successfully launches the video player. That last step would not have worked in prior versions.

Nice job, Marshall!

Stay tuned for more Android goodness!

Titanium 1.3 EmailDialog in both iPhone and Android emulators

Appcelerator Titanium 1.3 is coming next week, and I thought I’d take the time to go over at least a few of the upcoming features related to their Android support.  I’ll make this a short series of blog posts tagged “titanium-1.3-android“.

So for the first installment, I couldn’t help but indulge myself and feature the item that I actually contributed to the project (with loads of hand-holding from Don Thorp (@donthorp)), namely the EmailDialog.

The EmailDialog was available in the pre-0.9 versions of the Titanium Mobile SDK, but since the major architectural change that came with 0.9, it has been waiting to be ported over. Now it’s ready for 1.3.

To see it in action, I’ve included the screenshot showing the iPhone and Android emulators side-by-side while running the KitchenSink example for the EmailDialog.

Stay tuned for more Android goodness!

This is a quick, very quick, blog entry about building Titanium Mobile from source. No hand-holding or fancy screenshots.

1. Get the sources from Github. You can use git if you want or just download the sources. For the latter, see the “Download Source” link near the upper-right of the Github page.
2. Make sure you have Python 2.6 or higher on your system. If you don’t, you go figure out how to install it! Maybe 2.5 is okay — I’m not going to go check. What I can tell you is that 2.6 works.
3. Make sure you have Scons 1.3 installed. And make the “scons” script accessible via your PATH so you can call it from anywhere.
4. Make sure you have the Sun (Oracle) Java JDK 6 installed. You may also need to set your JAVA_HOME properly and you should also put JDK’s bin folder in your PATH. You can figure all that out on your own!

When all that’s finished, go the source folder where you put the Titanium Mobile sources (the folder with the SConstruct file in it) and enter the “scons” command.

When it’s done building, copy the resulting mobilesdk-x.x.x-[os].zip in the “dist/” folder to your local Titanium SDK installation folder. The location of that folder depends on your OS. On my Mac it’s “/Library/Application Support/Titanium”. On my Ubuntu box it’s under ~/.titanium. On my Windows XP box it’s under “c:\documents and settings\all users\application data\titanium”. (God I hate Windows XP.) If you can’t find your location, try searching your file system for a folder named “Titanium”. It’s the folder that has “mobilesdk” as a subfolder.

Unzip the ZIP there.

You should be ready to go. Next time you use the Titanium Developer, you should see the newer SDK available as one of the options next to “Titanium SDK” on your mobile project’s properties screen.

Did I forget anything?

I’ve noticed a fair amount of people who comment in the Q&A section at the Appcelerator Titanium developer website don’t really like the style of Q&A forum that resembles stackoverflow.com.

As there’s no way to put a poll up there at the Appcelerator Q&A site, I thought I’d try a poll here on my site.

So if you have an opinion on this issue, feel free to vote in the Poll in the right sidebar here. If you select “a third way”, I encourage you to leave a comment to this post so you can describe your idea.

This is, of course, totally and completely unscientific. First of all, I would imagine that most people who take the time to vote are people who want to go back to a classic forum. People who are pleased with the status quo might not take the time to vote.

Nevertheless, I’m interested in running the poll and seeing responses.

[Update 22 April 2010: Poll closed, with final score 23-0 in favor of "classic."]

[UPDATE: Since Mobile SDK 1.3 is released, I no longer recommend this. The launching of the emulator succeeds just fine under 1.3. Also, the major disadvantage of my suggested approach here was that since you would be launching the emulator outside of the Titanium Developer program, your Titanium.API.info() calls would not show messages inside the Developer console. So I'll leave this post here for posterity, but I do not recommend it any longer.]

The slowness of the first-launch of the Android emulator can cause so much grief for Titanium developers targeting the Android platform. If the emulator loads slowly, the build of your own project often finishes before the emulator is ready, causing the emulator to just sit there when it’s finally finished loading. No error message is displayed to you to describe why nothing is happening.

Also, it’s my belief that the recent speed-ups to the code-build-release-code-build-release round-tripping under Android have actually made things worse if the first attempt to install the application on the emulator fails. It seems to me that subsequent attempts will then fail again, because Titanium doesn’t think that anything has changed since the last build/release, so the files in your Resources folder actually never make it on to the device’s SD card, which is used for the speed-up process. I’ve spent loads and loads of time trying to overcome this problem. It is extremely frustrating and I think that — with the way it is now — it can put some would-be Android developers right off of Titanium.

I’m glad to say that Appcelerator is aware of the problem and there are already some relevant tickets. But it’s not clear when any fixes will be pushed out to users.

So in the meantime, take my advice and save yourself the grief of the problems that can occur when the Android emulator (plus its virtual SD Card) is not ready to accept files from the Titanium installation process. Load the emulator before doing any development work in Titanium. To find out which command-line to use for the emulator, take these steps:

• Open Titanium Developer as per ususal.
• Create a dummy mobile project that you don’t really need.
• Go to the Test & Package tab for that project, and select the Android SDK plus screen size you want to target.
• Click Launch.
• Set the Filter to “Trace” and copy all of the contents of the console window. It doesn’t matter that your project is still building — we just need some lines up at the top of the trace.
• Paste your copied lines into some text editor, just so you can look through them.

Near the top of the trace, you will find the command-line used to start the emulator. Example:


[DEBUG] From: C:android-sdktoolsemulator.exe
[DEBUG] SDCard: C:Documents and Settingsbill.titaniumandroid.sdcard
[DEBUG] AVD ID: 11
[DEBUG] AVD Skin: HVGA
[DEBUG] SDK: C:android-sdk
[DEBUG] C:android-sdktoolsemulator.exe -avd titanium_11_HVGA -port
5560 -sdcard C:Documents and Settingsbill.titaniumandroid.sdcard
-logcat '*:d *' -no-boot-anim


(I put some line-breaks in there for clarity.)

Copy that command-line and paste it into a new editor (Notepad, whatever) window, then save it as a batch file or shell script, depending on your platform.

You may need to clean it up a bit. My example above, for instance, will not execute because of the space in “Documents and Settings”, so I needed to surround the whole “C:Documents And Settings….” path in double quotes. Also, I had to change those single quotes around “*:d *” to double quotes.

Now run that batch file / shell script when you’re ready to start your Android development for the day. And keep the emulator open!

When you do that, you’ll see magic like in my sample video here below (no sound.) Because the round-trip speedups done by Marshall Culpepper (@marshall_law) are friggin’ awesome when they work! Watch the video to see how fast it re-launches when I change app.js! Still not lightning fast, but much, much faster than before (thanks Marshall!I)

After several years of only using Linux distros at home, I broke down and got the cheapest possible Mac Mini last year.  I’m even using an old 17″ monitor on it, and have only had an Apple keyboard for it since two weeks ago.  Prior to that I used a wireless PC keyboard that I already had.

In other words, I’m a pretty cheap guy, right?

No, I’m just not an Apple fanboy.  I’m not willing to fork over gobs of money for that whole “Apple experience”.  I don’t refer to Mr. Jobs as “Steve”, and I don’t tune in to webcasts of his stage performances.  I often wince with embarrassment when hearing Leo and the guys on MacBreak Weekly (though I like the show and listen to it.)

In fact, when it comes to software, I lean very heavily towards open source.  But I’m also fairly pragmatic, and when evaluating things last year I just had to admit that OS X is simply the best desktop experience right now.  Because I could get it for about EUR 700, I went ahead and did so, taking the cheapest possible route (short of a Hackintosh).

One of the deciding factors for allowing myself to make that change was the recognition that the command-line experience (i.e., Terminal) and general Unix-y characteristics of the operating system would make me not miss Linux so much.  It’s that “kinda open source but not really” aspect of OS X that makes it very acceptable to me.

I got an iPhone several months before the Mac Mini, at a time when other smartphone alternatives weren’t stacking up real well against it.  Prior to the iPhone, I had the Nokia N95 8GB, which I bought at a time when it was absolutely the best smartphone available over here in Europe.  After about a year with that Nokia, I held and played with someone else’s iPhone, and had to admit that it blew the Nokia out of the water.

So, why did my heavily-leaning-towards-open-source self accept the very closed, highly controlled iPhone platform?  Because, at the time, I found it far and away the best smartphone available.  It was a trade-off I was willing to make.

See, when it comes to highly secretive, very controlling corporations like Apple, it’s all about trade-off: how much you’re willing to put up with in return for getting a good user experience.

Now, as of yesterday’s iPhone OS Agreement spectacle, I gotta feel that Apple is pushing their luck on this trade-off thing.  I look at some of these new Android phones and, honestly, I don’t see that huge gap anymore like I did when I held my Symbian-based Nokia in one hand and the iPhone in the other.  I read about the zenPad (UPDATE: okay, that was a seriously crappy example) and rumors about HP’s plans for a “slate”, and I’m thinking: watch out, Apple.  If you guys push up the pain meter on your side of the great trade-off, then fare thee well and au revoir and seeyawouldntwannabeya.

All of the above was about Me The Consumer.  Now a few words from Me The Programmer: Screw you, Apple, and your Objective-C!  I hate square brackets.  I already know some great programming languages that I can use on more than one platform.   I really have no intention of getting good at yet another programming language just for the sake of one platform.  So if the fears about your new developer agreement are founded, then you lost me in the mobile sphere.

Whither Titanium goeth, I go too.  Either you let me do mobile apps in a language I already know, or I don’t do mobile apps for your platform.  It’s really that simple.

After my gripes yesterday, I find it important to also give lots of credit where it’s due.  After some problems in the 1.2 release, the folks at Appcelerator have been very responsive, Don Thorp (@donthorp) especially.  And I’m not a paying customer, so it’s nice to see that!

As I’ve indicated elsewhere already, the problem with importing projects was very quickly solved.  When running Titanium Developer, you’ll be prompted to upgrade to 1.2.1 (or perhaps later, if you’re reading this later), which will then be able to import projects.

There was another problem whereby if you created a new project and then tried to launch it in Android by going to the “Test & Package” screen, you would have no option to launch the application.  Don immediately created a ticket when becoming aware of the problem, and Marshall Culpepper fixed it (@marshall_law) pronto in the github sources.

At the Q&A forum, I give some instructions if you want to put that change on to your machine ASAP.  (I’m not sure when it will be pushed by Appcelerator as an update; it’s tagged as 1.3, which isn’t expected until end of May.)