Simple ToDo app – jQuery Mobile / WebSQL Part 1

Our app with cover the following
Before you get started
You can download/clone the project here or view a live demo

  • Download: You can download all of the code used in this tutorial here.
  • Clone: If you use git you can clone from: git@github.com:jamesjacobs/jqm-websql-todo.git
  • Demo: You can see a working finished version here (your browser will need to support WebSQL).

This is the first in a series of ongoing blog posts exploring different JavaScript frameworks mainly from a mobile dev point of view. I thought it best to start with something fairly simple, something we can build upon and make comparisons against and what better way to do that than a tried and tested simple todo app. The app will deal with common requirements such as database access, dealing with JSON, multi-level views and parameter passing between different views with the eventual goal of being packaged as a native app with PhoneGap. If you are not familiar with PhoneGap, I’ll provide more details on how to incorporate PhoneGap and access some of its APIs, such as the camera, in a future post.

I’ve worked with jQuery Mobile in the past and been both pleased and frustrated with how it tackles certain aspects of HTML5 app development. For those that don’t know, jQuery Mobile is what some would call a full stack mobile framework dealing with the UI, routing and some of the architectural structure.

In this post I’ll be using WebSQL for data storage. WebSQL is a client-side web technology that allows developers to build applications that are able to store data locally. Unlike LocalStorage, which enables the storage of simple key/value pairs, WebSQL supports the storage of structured data in a relational database. This enables developers to build more complex applications.

WebSQL, although widely supported on mobile browsers has been deprecated (more information on WebSQL Databases can be found here - http://www.w3.org/TR/webdatabase/). In the future you we might want use IndexedDB, server side storage or some other method so we need to allow for this and structure our app accordingly, abstracting away data storage functions.

Building the Application View

Before we start writing the JavaScript code that will power the application we first need to set up a new page to display the todo items.

Create a new file called index.html that contains the following HTML code.

Note: You will need to serve this HTML file from a local development server in order to have access to WebSQL. If you don’t already have a local development server installed you might want to try XAMPP, MAMP (OSX) or WAMP if your on Windows.

Perhaps the first thing you might notice is that we’re including all of the Javascript in the <head> of the document rather than just before the closing </body> as is normally recommended. This is due to how jQuery Mobile handles pages. Rather than having individual pages (as you may be used to on a static website) jQuery mobile loads the index.html page first and then grabs the contents of other pages (anything between data-role="page", which can be a separate file or multiple data-role="page" within index.html) and injects it into the dom. Therefore JQM needs to load first. You can read more about how JQM handles pages here - http://view.jquerymobile.com/1.3.2/dist/demos/widgets/pages/

Next lets add our view.html and add.html. These view will be responsible for viewing/editing and adding todos.

You might have noticed I’ve left the script links in the header. Whilst JQM will ignore these when loading the pages through index.html (remember it grabs the data-role="page" content via an ajax request and injects it into the DOM) if for some reason add.html or view.html gets displayed before index.html (the user would have to know the exact URL to them – which wouldn’t happen if the app was packaged in PhoneGap) the page would be not function without these links.

Lastly, we’ll add small stylesheet to add a strikethrough to items when they have been completed. Create style.css in our css folder with the following contents:

Ok, with our front end in place, next post we’ll start on our storage object that will handle our database transactions.