Yesterday a reader asked me about building context menu support for images within a jQuery Mobile operation. Turns out it's pretty easy. Obviously there is no such thing as a right click menu on a touch device. That being said - the convention that most mobile applications use is a "taphold" listener. You touch the item with your finger and wait. In a second or two, the context menu pops up. The taphold event is trivial to use in jQuery Mobile (with a caveat I'll get to in a second), but what isn't as trivial is decided what UI to use. jQuery Mobile will - soon - have a popup UI item. For now though I decided on the excellent SimpleDialog2 plugin by JTSage. Let's look at an example.

A reader asked me if it was possible to watermark images (like those taken with a camera) in PhoneGap. This is rather trivial using Canvas (hey, it does have a use!) so I whipped up the following example to demonstrate it in action.

Ben Forta pinged me with an interesting question (and when the Forta pings you, you respond) that I thought I'd share here. It's one of those "best practices" questions that really has no best answer, so as always, I'm very eager to hear what my readers have to say. Don't feel afraid to tell me I'm completely off my rocker - that makes for fun conversation. Ok, so the question:

I have a JQ+jQM=PG app. It started off as 2 small pages and 50 lines of code, and is now 10 pages and over 1000 lines of code (excluding lots of .js libraries, some my own and some downloaded, that are all included).

My question simply is how would you go about organizing the code? Each "page" in its own HTML file? Would you put page supporting event handlers with those pages? What about handlers that use JQ to manipulate other pages? Separate all JavaScript in included files? And actually, how the heck do you even use JQ to manipulate controls in another page?

I know there is no right or wrong answer, but I am about to start refactoring this entire mess, so ... any thoughts you'd like to share?

One truly disappointing aspect of IndexedDB is that there is no (simple) support for search across your data. It is very much based on the idea of knowing your keys and fetching data based on those keys. You can easily retrieve the "Ray" user object, but you can't search for user objects that have an age within a certain range and a skill property of so and so. That's not to imply you can't do some sorting and filtering though.

IndexedDB supports the idea of key range objects. As you can probably guess, these allow you return objects based on a range of values that match with a particular index. Remember that IndexedDB objects can have any number of properties, but you have to specify which are indexed. And now you know a good reason why - it gives you a chance to filter later on.

Ranges can go in either direction and can be inclusive or exclusive. By that I mean, you can say "Anything object with a name 'above' and including Barry" or "Anything object with a name 'below' Zelda but not including that name." You can also combine both and get a single object too.

For my use-case, I wanted to use a range filter so that I could support 'filter as you type'. My data consists of notes that include a title, body, and created property. I'm not going to go through the steps of setting that up as my previous blog entries (linked at the bottom) went over most of the detail there. Instead, let's focus on how I built in the 'filter as you type' metaphor.

To begin with, I had a function that handled "get all" and displaying the data. It worked by opening a cursor and looping while data existed. Here's how that version looked:

In order to support a bound range, you have to change how you open your object store (remember, think of this like a database table). When we just get everything, we run openCursor on the objectStore (line 18 above). When we want a bound list of data, we get an index first (this is the property we said we wanted to be able to filter on), create the range, and then open a cursor on that. So with a small amount of work, we can update our displayNotes function to take an optional filter. (Note that I also switched to a table display. The change in HTML isn't terribly important here so I won't cover it.)

Focus on lines 31 to 40. You can see the different ways to open the cursor. Note specifically we do our binding based on an input string, like "ra" and append "z" to give an end to the range. So typing in "ra" means we want all notes with a title from "raa" to "raz".

Outside of that - the code is identical. I moved the success portion into a new inner function (handleResult), but it works the same no matter how I get the cursor itself.

You can demo this yourself by hitting the demo button below, but as before, this is Firefox only due to - what I believe - is a bad implementation in Chrome. (I think it could be made to work in Chrome, but as I'm building these examples to help me learn more about IndexedDB, I'm fine supporting the most compatible browser.)

You can find the complete source by .... viewing source. ;)

While preparing for my presentation earlier this week on WebSockets and ColdFusion 10, I ran into an issue trying to wrap my head around one of the features: invokeAndPublish. The docs describe it like so:

Earlier this week Steve wrote to me asking how to use data retrieved in a ColdFusion Component in a Handlebars template. While ColdFusion makes it trivial to serve up query data via JSON, the result format isn't always easy to use in JavaScript utilities. Here's a quick example I wrote that demonstrates how to work around this.

Earlier today a reader asked me about the possibility of converting his mobile-friendly site into a "real" application via PhoneGap. I told him that this could be very easy. You can take your HTML, upload it to the PhoneGap Builder service, and see what you get. This works with simple HTML sites, but is not going to work well with dynamic sites built with server-side languages. In this blog post, I'll explain why it won't work, and also walk you through an example of converting a (simple) dynamic web site into a PhoneGap application.

Before I begin - two quick notes. I'll be using jQuery Mobile for the UI and ColdFusion for the back-end. This is completely inconsequential to the task at hand. Ok, ready?

First, let's discuss why a dynamic web site can't be simply converted as is into a PhoneGap application. Most of my readers are web developers so you should know this, but when it comes to dynamic server-side languages like ColdFusion, PHP, Ruby, etc, the HTML your browser gets is created dynamically.

Take for example this simple ColdFusion site. When you request this URL with your browser, my web server hands off the request to ColdFusion. ColdFusion does its magic (hits the database) and outputs raw HTML. That HTML is returned to the browser and rendered as is. The same would apply for PHP, Ruby, etc. When you click on the detail page, we hit one template that is passed a URL parameter that instructs the code to load a particular record and display it.

Now - consider PhoneGap. PhoneGap takes your HTML files and packages them up into a native application for your mobile platform. But it is not a web server. You can't bundle in ColdFusion or PHP and have it execute server-side code like in the example above.

Does this mean you're completely out of luck? Not at all. Let's look at how we can convert our code into a PhoneGap application.

First, let's look at the initial application. As I said above, the choice of the server-side language isn't relevant to the discussion. Therefore, I won't go into detail about what the ColdFusion code is doing. Those of you who don't know ColdFusion should be able to mentally map it to the language of your choice. First - the index page.

Then the detail page:

And finally - here is the component that drives the data. Basically it just wraps up the logic to get our list and detail.

Ok - so that's our old school (although nicely mobile optimized) web site. To begin the conversion to PhoneGap, I create a new file for my home page that is pure HTML, no ColdFusion.

Notice that the layout is the same as before, but our content is gone. Previously that was sourced on the server by a database call. So how do we add this dynamic data back in? With JavaScript.

First - let's add some logic to run when the home page is created. This specific event is based on how jQuery Mobile does things, but again, you could do this without any particular UI framework.

This code block performs a HTTP request to our server. (Note: I'm using localhost in the example above but in a real application it would be your site's domain, something.com.) I've built a new set of server-side code just to handle getting and returning data in JSON format. So there's still a server involved, but now it's simply returning data, nothing more. I loop over the result and render it out into the page.

The detail page is built much like the index page. It's a copy of the earlier version minus any code or actual content.

To handle this, back in my JavaScript I added code to run when the page is loaded.

And that - as they say - is basically it. To summarize:

• The code in the PhoneGap application is just HTML and JavaScript.
• The dynamic data from the earlier application was rewritten to expose itself remotely.
• PhoneGap then simply uses Ajax to fetch that data.

I've attached a zip of all the code used for this blog post below. If any part of this doesn't make sense, let me know, and I hope this was helpful.

It is here! Finally. 100% done. (Although Amazon still says it isn't released - that should be corrected soon.) The jQuery Mobile book I wrote with Andy Matthews is now published. The book covers creating jQuery Mobile apps and is up to date to the most recent release. The code is available via Github for easy forking/modifying as you learn. You can purchase via the Amazon link to the left (as I said, it is published so it should ship and I get a small kickback from the affiliate link) or via the Packt site.

I'm a strong believer in jQuery Mobile. It takes an incredible simple, practical direction that I think will be incredibly powerful for developers. If you haven't taken the time to look at the framework, now is a perfect time to check it out.

The second issue of Appliness has launched. Appliness is a free digital magazine available on Android and iOS (in stunning Retina graphics too). The May issue contains articles on...

• CSS Regions and CSS Exclusions, by Deepa Subramaniam
• Drag and drop with jQuery UI on mobile devices, by Michaël Chaize
• JavaScript Object Creation, by Keith Peters
• Using Backbone with jQuery Mobile, by Christophe Coenraets
• Crafting native looking iOS apps with HTML, by Christophe Coenraets
• Demo of Handlebars, by me
• Real-time data exchange in HTML5, by Ryan Stewart
• Swipe to delete items, by Michaël Chaize
• App-UI, a library by Andrew Trice
• HTML5 Multimedia components, by Ian Devlin
• Interview of Pamela Fox
• Colour Match, Cutest Paw, Bit Timer: showcase
• Which Element ? Pull quotes, comments
• PhoneGap and the File API
• WTFJS: False advertising
• Generate color palettes from HTML5 video
• CSS variables draft

I way to make special note of the "Generate color palettes from HTML5 video" article. This is not something that has been on my blog before. It's a brand new WebRTC demo I made that demonstrates generating color palettes from a live web-cam video feed. It's super hot. Really. OK, it's a bit silly. But it was fun as hell to write.

I've recently begun making uses of Gists to host my code blocks. I like the formatting - I like that folks can take the code and fork it - I just like it in general. Plus, all the cool kids are using it so why shouldn't I? However, I realized yesterday that the Gist embeds were not working on my mobile site. Why? Let's look at a simple example and it will soon make sense.

Consider the following simple jQuery Mobile page:

It's a one page template with an embedded Gist as well. Notice the two links at the bottom. If we open this up it will work just fine. Your browser sees the script tag and executes it. You can test this yourself here (but don't try the buttons just yet):

http://www.raymondcamden.com/demos/2012/apr/14/test.cfm

Now - let's look at the first page, the one I called testa.cfm. This page is "faking" dynamic content with some static text on top that is then output within our page. While I'm using ColdFusion to demonstrate that, please note this is not a ColdFusion issue.

If you were to click the first button, you will see the page load, but no gist will show up:

What happened? jQuery Mobile uses Ajax to load in your additional pages. When Ajax is used to load content and it includes a script block like that, it is not executed. This isn't jQuery Mobile issue - it's just how Ajax calls like are going to work. We could get around this by telling jQuery Mobile to not use Ajax for its link - that's super simple too: <a href="something.html" data-ajax="false">. But that felt wrong to me.

So I began thinking of a solution. First - I discovered that the Gist service has an API: Gists API. This API allows you to fetch the raw content of a Gist along with other metadata. I now had a conundrum. Do something client-side or server-side? While I figured I could do it client-side, something told me it made sense to handle this on the server instead. It would let me have a server-wide cache and possibly do other manipulations to make the content more appropriate for a mobile platform. I'm not sold on this needing to be server-side.

My solution then was rather simple. Given an input, we could use a regular expression to look for Gist embeds. For each we find, perform a HTTP call to the API to fetch the raw content and embed that into the document instead.

Obviously the additional HTTP call will be expensive. With that in mind I decided to employ caching. This is another good solution for the server as anyone who hits the page after the first user will also get the benefit of the cached version. This does - of course - mean that if the Gist is updated the cache will be stale. For simplicity's sake I'm just going to not worry about that now.

Here is my solution. It's ColdFusion-based, but simple enough that anyone could rewrite this in PHP, Ruby, etc.

If we take it step by step, you can see the regex used to find gists. I then loop over them (backwards because it is possible a gist may include an example of a gist, this blog post does!) and do some simple replacements. If the raw data isn't cached, we perform a HTTP request and cache the result after processing the JSON. This really needs some try/catches though. Finally - we wrap the result in some pre tags (which you customize) and insert it into the original string. Here's an example of a jQuery Mobile page making use of this API.

You can test this by going back to my demo and trying the "Good" demo.

Thoughts? As just an FYI, this is not being used on my mobile site yet. I'm hoping my readers provide some feedback to let me know how well this works (or doesn't).