Making An App With PhoneGap & jQm Part III: A Stateless Authentication Layer 33

If you missed Part II: Loading JavaScript Properly, you may want to go there and grab the code we wrote so far so that you can follow more easily what we’ll do in this part.

Today, we’ll see how to implement a RESTful, stateless authentication layer in our application. Let’s first talk a bit about REST; the acronym stands for “REpresentational State Transfer” and describes a way of handling client-server transactions in a uniform, layered, stateless, scalable and cacheable way. I know that’s a lot of adjectives to process so I won’t delve into much more details here. We’ll focus on the stateless constraint, which requires that the exchanges have no memory per se, they always contain all the information that the other party has to know to process them correctly.

I have tried to simplify my code examples as much as possible. The goal being “stateless authentication“, I have focused on that, which means that for now we will deal with “ugly” URLs like https://foo.bar/server.php?a=b&id=123; we’ll see in a while how to do the same with “clean” URLs like https://foo.bar/users/bob

The REST philosophy is widely considered one of the best ways to solve communication challenges between a client and a server over the Internet. You may want to read the linked Wikipedia article for more details about the how and why.

Now what we’re interested in is the design of a system in which we can “phone home” from our application to an online server. This is needed for applications which have to pull data from a remote host like news items or score boards, or on the contrary push data to a remote host like creating a new account or updating profile information. Obviously such a system must allow for authentication, or we could end up with users accessing or modifying other users’ data at will!

Phoning Home (Cross-Domain) With jQuery

Phoning home is surprisingly easy with PhoneGap & jQuery, and at the same time it can prove hard to do it right. What I mean is that on the one hand jQuery provides us with powerful tools like jQuery.ajax(), which we can leverage in order to query our servers; on the other hand, there is a bunch of things we need to do so that our query is not blocked by the anti-cross-domain security features embedded in web browsers like Chrome.

Making An App With PhoneGap & jQm Part II: Loading JavaScript Properly 10

If you missed Part I: A Simple HTML5 Skeleton, you may want to go there and grab the code we wrote so far so that you can follow more easily what we’ll do in this part.

One of the challenges in developing apps using PhoneGap and jQuery.Mobile is to make sure that the libraries are properly loaded before any critical code is executed. Another challenge is to make the difference between code which is due to execute only once, code which will execute on every activity, etc. In this part we’ll explore those differences and I’ll present to you a way of making sure that your functions execute at the right time.

Namespacing The Application’s JavaScript

Namespacing your functions into an object is a great way of avoiding potential conflicts with existing functions; it also serves as an additional separation of your JS code from your HTML, it can make it easier to debug errors by keeping related entities close to each other. It may also make the use of a test framework like QUnit easier to implement.

Here is the base skeleton we’ll use for our app:

var App = {
	"app_loaded": false,
	"testing_on_desktop": true,

	"init": function () {
	},

	"utilities": {
	},
};

A quick note before we go deeper: you can make use of the object notation in JavaScript to nest multiple namespaces, like I did with “utilities”. This is a pretty cool feature to make your code a bit more organized than putting everything at the same level.

Setting Up jQuery.Mobile In <head>

As we’ve seen in Part 1, jQuery.Mobile is a bit special in the sense that it modifies the DOM upon loading. For this reason, any configuration code we’d like to see executed must be set before the library is loaded, using the “mobileinit” event which marks the beginning of jQuery.Mobile’s execution.

As an example of what you can configure, as my app needs to “phone home” I had to activate the cors option in both jQuery and jQuery.Mobile. The full list of configuration variables is available here. Here’s the result in <head>:

	<script charset="utf-8" src="js/app.js"></script>
	<script>
		jQuery(document).bind("mobileinit", function () {
			console.log("configuring jqm...");

			// required for "phoning home" (load external assets, etc.)
			jQuery.support.cors = true;
			jQuery.mobile.allowCrossDomainPages = true;
			
			jQuery.mobile.phonegapNavigationEnabled = true;
			jQuery.mobile.defaultDialogTransition = "pop";
			jQuery.mobile.defaultPageTransition = "none";
			
			jQuery.mobile.loader.prototype.options.text = "loading";
			jQuery.mobile.loader.prototype.options.textVisible = true;
			jQuery.mobile.loader.prototype.options.theme = "a";
		});
		App.init();
	</script>
	<script charset="utf-8" src="js/jquery.mobile-1.3.1.min.js"></script>

I advise you to systematically add console.log("[funcName]") at the beginning of every function as it makes debugging much much easier, especially when callbacks are involved because they can be rather messy in the way/order they fire. Oh, notice the App.init() call? Let’s see what we can put in there.