@tkinson

Phonegap and Titanium Mobile compared in 2011

I've used each of Titanium Mobile and Phonegap ato develop apps for iPhone. I've not built anything for Android yet, although I plan to.

I read a lot of rubbish about these frameworks on the web, I think it's mostly because they've changed so much in their short history.

Titanium Mobile allows you to 'script' native device controls using JavaScript (no HTML or CSS). It has a fairly mature and useful abstraction over SQLite, including some handy utility functions for pre-populating the database. The result looks and feels native, but underneath your code runs in a JavaScript interpreter. You also get access to the sensors - Accelerometer, Camera, GPS - and you get access to the core apps (Photo Library, Maps, Camera etc).

Phonegap no longer exposes any native control API's in JavaScript. But they do provide you with a Mobile Safari runtime environment with a slightly more fully featured HTML5 implementation than Apple provides by default. (eg: File, Geolocation). Also you get some of the sensors - eg: Camera, Accelerometer.

I've used each of them one project this year. Phonegap has definitely lost the edge to Titanium as far as functionality and productivity goes. Titanium is simply more practical and solution oriented.

For example, it took me nearly a day to figure out how to reliably pre-populate your SQLite database in phonegap (https://github.com/atkinson/phonegap-prepopulate-db), on the other hand Titanium provides you with a very simple API call to do all of this.

Interestingly, Titanium Desktop is a bit different again; it allows you to write desktop apps using HTML5, CSS and JavaScript.

IMHO: Titanium and Phonegap both suffer from a poor sense of developer community, although Titanium is making an effort here while Nitobi seem to neglect (all non paying users on) their support forum. It's a shame as it makes Phonegap quite a high friction environment to use.

Pre-populate an HTML5 WebSQL database

HTML5 WebSQL databases are currently available in Safari (including Mobile Safari), and the HTML5 FileAPI is implemented in Phonegap.

Unfortunately the WebSQL API isn't prescriptive in a number of areas; there is no canonical method of furnishing your HTML5 offline app with a pre-populated SQL database.

I moved from Phonegap to Appcelerator Titanium shortly after figuring this out (Titanium is much better than Phonegap; although Titanium creates native apps rather than HTML5).

However, it took me quite a while to figure out how to get this to work reliably, and so I didn't want to throw it away.

Here's the solution on github.

Posted April 9, 2011

jQuery plugin for django.contrib.messages - GitHub

jQuery django messages

<script type="text/javascript"> 
$(function()
{
    {% if messages %}
        var messages = ['{{ messages|safeseq|join:"','" }}'];
        $.showMessages(messages);
    {% endif %}
});
</script>

I created this jQuery plugin to support multiple messages, and now it works pretty well with Django's contrib.messages.

Download this jQuery plugin from github.com

Posted April 9, 2011

Happy Birthday Linux

Media_httpwwwlinuxfou_bnxuk

I think my first Linux machine ran Slackware, circa 1992/93.

Posted April 7, 2011

Javascript closure memory leak

The foillowing is an excerpt from the Google JavaScript style guide:

The ability to create closures is perhaps the most useful and often overlooked feature of JS.

One thing to keep in mind, however, is that a closure keeps a pointer to its enclosing scope. As a result, attaching a closure to a DOM element can create a circular reference and thus, a memory leak. For example, in the following code:

function foo(element, a, b) {
  element.onclick = function() { /* uses a and b */ };
}

the function closure keeps a reference to element, a, and b even if it never uses element. Since element also keeps a reference to the closure, we have a cycle that won't be cleaned up by garbage collection. In these situations, the code can be structured as follows:

function foo(element, a, b) {
  element.onclick = bar(a, b);
}

function bar(a, b) {
  return function() { /* uses a and b */ }
}

I expect this is by far the most commonly made Javascript memory leak.