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 some downloaded, that are all included).

My question simple 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 to 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?

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.

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.

I've blogged about Adobe Shadow before, and I've played with it, but I don't think I truly appreciated it till just now.

A coworker pinged me about an issue he was having with a jQuery Mobile page and iOS. I got the code from him, dropped it in my local web root, turned on Shadow, and began editing.

The code in question had a bunch of JS libraries in play, and I simply commented them out one by one. My 'process' was...

• Edit the file
• Reload the tab in Chrome
• Look at my iPad and see if the issue was fixed

This took me about 2-4 minutes to correctly figure out which JavaScript file was causing the issue. Adobe Shadow dramatically increased my testing speed and made the entire process a heck of a lot simpler.

So I know I'm biased, but damn - I'm sold on Shadow.

This weekend I was reading an email on my phone when I noticed something odd. The link, to a Wikipedia article, prompted me to ask if I wanted to load it in my browser, or in the Wikipedia app. Knowing that the Wikipedia app was built with PhoneGap, I decided to dig into this and see how it was done.

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