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.

First off - a big thank you to everyone who attended my presentation at cfObjective today. I hope it was a useful introduction to some of the cool new stuff in HTML5. That sounds really lame, but it's honestly how I feel. The web (well the front end) is incredibly fun again. I'm hoping to do many more presentations in the future, but with a more focused topic. I'm doing a presentation soon on HTML5 Storage options and I'm planning one just on Forms. (Since, you know, forms are kind of important. Unlike other things. Looking at you Canvas.)

You can download the presentation and code from Github: https://github.com/cfjedimaster/HTML-Code-Demos

It should "just run" in your browser, but some of the demos are a bit bleeding edge.

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. ;)

In case you haven't figured it out yet, debugging in mobile is "sub-optimal". (Whatever you do - don't do a Google Images search on sub-optimal.) Brian Leroux has an epic presentation on the topic and I highly encourage taking a look through it. I thought I'd share how I'm debugging in PhoneGap and Android right now.

To be clear - this is a sucky way of doing it. "Sub-optimal" is being too nice. Whenever possible I do as much work as I can on the desktop. But when I get desperate and need to test something on a device, I end up resorting to console.log messages. I know this is only one step better than a bunch of alerts, but I thought it might be useful to show how this is done with Android and some tips to make it a bit more palatable.

Enjoy. I'm going to have some followup blog posts on this coming up this week.

Recording URL: http://experts.adobeconnect.com/p459pvx19cw/

The demo files may be found at the bottom of this blog post.

First off - a huge thank you to everyone who came to our PhoneGap Open Q and A today. We had more than 50 attendees for most of the two hour block which I think is a great turnout. We even had a troll (for a few minutes), so that means we must be doing something right!

The questions were very interesting. I noticed lots of attention around notifications and push, two areas I've not really dug into yet. I also noticed a few questions on the front-facing camera. (According to Andrew, on devices with two cameras, the native UI should simply prompt you when you request the camera.)

The Q and A transcript, as well as the more random general chat, are attached as zip files below.

As always - if you have any feedback about the session concerning how we could improve it, just let me know in the comments below.

p.s. I had a few requests for plain text versions. Here is a plain text version of the Q and A and here is a plain text version of the chat.

Curious about PhoneGap? Have questions? Tomorrow, Andrew Trice and myself are hosting a 2-hour Adobe Connect session on PhoneGap. This will be an open session for your questions, not a presentation. The Connect URL is: http://my.adobeconnect.com/adobehtml. The date/time is Tuesday 1PM CST to 3PM CST (that's 11AM to 1PM PST).

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.