Raymond Camden's Blog - jQuery

Simple Reverse Geocoding Example

Tue, 05 Mar 2013 09:07:00 -0400

Have you ever seen a web site that seemed to know where you were located? I'm not talking about a map, but the actual name of the location? This is done with a process called "Reverse Geocoding." Whereas geocoding refers to translating a human-readable address into a longitude/latitude pair, reverse geocoding is, well, the opposite of that. Given a longitude/latitude pair, what would be the description of that location. In this blog post I'll show a simple example of this process. My example application will attempt to report the city and state you live in.Once again I'll be making use of Google for my example. One of the services of the Google Maps API is geocoding as well as reverse geocoding. Their reverse geocode API needs a longitude and latitude, we can get that easily enough using Geolocation. Here is a snippet of code that begins the process: Please note that in this demo, if the user doesn't support geolocation I'm not going to do anything else. They won't get an error though and won't know what they are missing. Once we have the longitude and latitude, we then fire off a request to the geocode service. As with our initial geolocation support, all I care about here is a success. If anything goes wrong, I don't care and I just ignore it. So, here comes the difficult part. The result was from the geocode call is fairly complex. You get an array of results ordered by the quality of the match. If you check the docs, you can see an example of this. Each individual result is also fairly complex. You get an array of address parts that represent, obviously, parts of an address. If you read the "Address Component Types" section of the docs, you can see an explanation of the types of address parts. Each part has one or more of these types applied as a tag. Based on my reading of the spec, I determined I could get the city when the tag was "locality" and the state when the tag was "administrative_area_level_1." This is US-centric and I've not done any testing yet with other countries. Given that I knew which tags to look for, I decided to work with the first result and see if I could match those tags: Again, if there isn't a match I don't throw an error. Since this is simply window dressing for the site it doesn't really matter if we don't get a match. Want to see this in action? Check out the demo below.

Presentation: Browser Tools for Debugging

Fri, 22 Feb 2013 14:32:00 -0400

A huge thank you goes to Andrew Trice for spending hours on polishing and editing a video of my last presentation. He uploaded it to Youtube and now you guys can watch it as well. I'm proud of this presentation so I hope it is helpful. As always, criticism is welcome. You can download the demos and slide deck here: https://github.com/cfjedimaster/BrowserToolsForDebuggingAndProfit

Google Map/Directions Mashup

Mon, 18 Feb 2013 07:56:00 -0400

A while back I ran into an interesting problem with Google Maps. I was booking travel for a conference and needing to find the closest Marriott to the conference location. I didn't know the area very well so seeing a few addresses meant nothing to me. I figured Google Maps would be able to help me, but I could only plot one location at a time. (To be clear, I bet there is a way to plot multiple addresses, I just couldn't find it.) I then tried the Directions service. That too was only able to work with two addresses. I ended up entering 4 or 5 Marriott addresses and just trying to remember which one seemed shorter. To get around this, I built a simple application that lets you enter up to five starting addresses and a destination. It then plots driving directions and reports on the total distances for each. It also reports on which starting address is the best.The code for this application is relatively simple. I began by creating a simple Bootstrapped UI: I built in a bit of basic validation logic (which isn't too exciting) and then began work on the real meat of the application. Here's the entire JavaScript library behind the demo. The interesting part begins around line 47. I geocode the destination address first to ensure it is valid. (I should probably do the same for the starting addresses as well.) Once I have a valid destination address, I map it, and begin a loop for each of the starting addresses. I make use of the Google Directions API to get and plot the directions from each starting address to the destination. This API is very cool (I've blogged on it a bunch already), but modifying the display of the plot is a bit broken. Unless you want to handle all of the drawing yourself, you can't really (nicely) do small modifications, like changing the initial pushpin. (Which is documented to work, but does not.) Here's a quick example: You can try this yourself by hitting the demo button below.

jQuery Example: Related, hidden selects

Fri, 08 Feb 2013 13:12:00 -0400

This request came in from a reader and I thought I'd share it. I'm not sure how re-usable it is for others, nor will I promise that it is The Best jQuery Code ever. (Far from it.) But on the off chance the example helps others, I wanted to post it.The reader had a simple request - set up related selects. I've done this many times before so that part wasn't such a big deal. The only twist here is that he wanted the related selects to only show up when selected. His data supported, at most, three levels of options. But not every option would have three levels. Because of this restriction, I decided to simply build my code to support three levels total and not build some high level, super cool, infinite deep relation type doohicky. As it stands, if I were to see 4 or more related selects on a form I'd run away screaming. Let's then start off with the HTML portion of the code. You can see my three drop downs in the form block. The second and third drop downs are wrapped in DIV tags and hidden with CSS. Notice too that I've added in the drop downs with no options. The idea here is that I'll use jQuery to hide and manipulate the contents of these tags. Let's look at the code now. First up is a set of code used to cache my selectors. This is a general jQuery best practice. I then have change handlers for my two drop downs. (Remember, we only support three levels max. As I said, you could possibly build something fancy that supported N levels, but I'm one of those crazy people who like simple solutions.) In general, both handlers are pretty similar. They get the value from the drop down and then automatically hide anything "beneath" them. For the first drop down this is both of the related divs. For the second it is only the third. If a value was selected, an AJAX call is fired off. Typically this would be to a dynamic datasource. To keep things simple I just built some basic static JSON files that return arrays. I can then take that array and populate a select. Note that I abstracted that logic in populateSelect(). And that's pretty much it. Not rocket science, but maybe useful. You can play with the demo by clicking the ginormous button below. This was tested in Chrome, Firefox, and IE10.

A walkthrough of some basic jQuery help

Mon, 28 Jan 2013 21:58:00 -0400

Over the past few days I've exchanged emails with David. He had a simple jQuery-based application and he ran into some issues with it. His problems were, I thought, fairly common and I thought it might make sense for me to share what he did and what I suggested. We went through a couple of iterations of this so you can see how the project evolved over time. One thing I want to point out. David writes his code differently than I do (as I expect everyone does!). When he asked for help, I tried to make my help/suggestions as minimally invasive as possible. I was tempted to just delete all his code and do it "my way", but I thought working within his 'style' would be less jarring. Ok, with that out of the way, let's look at his code.David wanted a form that - when changed - would automatically sum up the values. He included a mix of form fields for testing purposes and wanted to sum those fields with a class name of foo. Here is what he started with. Right away I saw that his initial selector, #addhours, didn't actually match anything. Notice his form was actually identified as my-form. He made the same mistake with another selector as well. Don't forget that you can use Google Chrome Dev Tools to look into your DOM and ensure you're looking for the right IDs. If your DOM is big and messy (like my beard), you can also hop into the console and try selecting what your code is. In the screen shot below, look at the difference between a bad and good match. Continuing on - I then pointed out that his code wasn't within the $(document).ready block. Most people who write jQuery tend to always include this by reflex, but if you don't, you can run into problems with your selectors. His code was trying to find DOM items before the DOM was actually done loading. You can mentally translate the $(document).ready block as "I'm ready to get down to business." In most cases, you almost always want to have your code in there. (Not always of course!) I modified his code a bit and returned this to him. You can see the $(document).ready block as well as the corrected selectors. David then came back to me with this:

I was able to use your example and it works great. But how can the jquery be modified so that it runs on page load. It works fine on the change event for the field with class "foo". I also wanted it to fire once the page is loaded so that any fields on screen go ahead and get counted.

As he noted, the code handled changes just fine. But if the form loaded with some initial values (he was using ColdFusion to generate the HTML dynamically) then the 'total' field wasn't updated until he changed a value. To handle this, I simply broke out the event handler doing the math and added a call to it in the $(document).ready block. In the code sample below, notice too I modified one of the form fields to have an initial value. Once again, he was good to go. Until today. He modified his code a bit so that users could dynamically add form fields to the page. He wanted his 'sum' logic to apply to these new fields as well. Here is what he had: For this, the issue came down to this original code... $summands.on('change', doAdds); This says: "At the time of running, attach a change event handler to $summands." If you remember, summands was run like so, $summands = $form.find('.foo'), in document.ready. It was run immediately and one time. So it found stuff once, and then was done. It didn't know the user had (possibly) added more stuff. So first I changed the code to this: $("#addhours").on("change", ".foo", doAdds); This says: On any change event inside the addhours form, if it (the thing throwing the event) also has a foo class, run doAdds. This is a "live" event (in fact, the API used to be called live) and will find new stuff. The next fix was to remove the code that created summands on startup. You will see it inside of doAdds now. You can't make it once and cache it since it can change. Here is the version I sent back to him. A little messy - but again - I was trying to work within his original code. Anyway, I hope this post-mortem is useful to others.

Testing Globalization Support in PhoneGap 2.2

Thu, 15 Nov 2012 17:04:00 -0400

One of the more interesting new features in PhoneGap 2.2 iss the inclusion of a globalization plugin into the core of the SDK itself. This plugin has many features, but basically boils down to the ability to get the user's locale and language as well as being able to format numbers and dates. You can read the full API docs for a complete guide, but I thought it would be interesting to build a simple proof of concept application that tested out this feature.I began with a simple idea. I'd build an application that showed a table of product orders. There would be a column of dates, a column of order quantities, and an order of profit. This would give me a chance to demonstrate localization formatting of dates, numbers, and currencies. (Note that you can also do percentages as well. Again, check the docs!) The HTML of my application was essentially just a div to support the injected report. Here is the JavaScript code that generates the report. I'm using fake data as opposed to doing an AJAX request. The result is pretty much as you would expect: So - obviously the solution would be to make use of the API to format those columns. Unfortunately, here is where I ran into a snag. The API calls are all asynchronous. Ouch. Normally this isn't a big deal, I can handle callbacks, but we've got N*3 cells of data all of which must be fired off asynchronously. In order to create our display we have to wait for these to finish. Luckily there is a solution for this. Unluckily, for me, it involves jQuery Deferreds. This is one of the most powerful features of jQuery and also the one that makes my brain bleed. The solution comes down to creating an array of deferred promises, essentially, an array of things that finish in an unknown time. This array can then be passed to the jQuery when() and then() operators which handles all of the chaining/waiting/collecting for me. Ready? Here's the updated coded. Taking this step by step, what I've done is this:

First, create the array that will store the promises.
For each order, we create three deferred objects. One for the date. One for the quantity. And one for the price. Notice that the Globalization API supports a failure callback if it can't format the value. For this application I simply then default to the original value.
I pass this to when(), and then use then() to begin working with my result.
The arguments passed to then match the array of data I sent in. So the first 3 array elements relate to the first order. And so on. You can see the math I use in the fakeOrder loop to handle getting the right value from that array.

So did it work? Hell yes. Here is the result on my iOS simulator: How did I test other locales? I went into my iOS Simulator settings, went to General, then International. At first I changed the Language value. That was wrong. I then noticed Region Format. That's the one you want to tweak: I set it to French/France, closed my application and reran it, and got... Pretty sweet, right? Now my PhoneGap application will display data in a format that makes sense to my end users. For numbers and currencies this may not be a big deal, but for dates it can be huge. So - obviously the asynchronous nature of the code may be a bit problematic. But it's not something you can't overcome. If I were building this for a client I'd build a JavaScript function that would handle this behind the scenes so they could do one call and a callback and be done with it. That would keep my getData() function much cleaner. I've attached a zip of my code to this blog entry. Enjoy.

Data-driven Edge Animate projects

Wed, 07 Nov 2012 07:10:00 -0400

This week I demonstrated Edge Animate to two cities in Texas as part of the Create the Web tour. Animations are not something I typically spend a lot of time thinking about, but I was grateful for an opportunity to show off what I think is a pretty cool program. At my first presentation, an attendee asked if Edge Animate supported data-driven animations. Hear is what I told him, and a look at a simple proof of concept.First - I told him that - in my mind - Edge Animate would be fine for data-driven projects, but only those that involved at least some timeline based animation. That distinction may not make sense if you've never used Edge Animate before. (I encourage you to download it via the link I shared above.) Edge Animate has a timeline that allows you to create animations over time. So for example my animation may do one thing from time 0 to time 1, and something else from time 1 to time 4. Integrating data with that should not be a problem. Imagine a simple weather animation. You may have parts to a thermometer fly in and come together like a puzzle. At the end, you display the current temperature. The other example though would be an animation that is entirely data driven with no concept of "time". An example of this could be a simple pie chart that updates with live data, using animation to smoothly modify the pie slices. Obviously there's a gray area here and each project is different. Edge Animate also makes it easy to add interactivity to your projects so assuming that only projects with crap flying around makes sense isn't exactly fair either. Hopefully you get my drift here. With all that aside, let's look at a real demo. This won't be the most exciting Edge Animation you will see but it will hopefully illustrate the concept. For my demo I want to build an animation of a box that comes onto the screen and then just displays some text. The data-driven part will come from the fact that the text we display will need to come from a server-side file. You could imagine this being a ColdFusion, PHP, or some other script. For now though I just made it simple text. I began by creating the animation and using static text. I used two seconds for the 'rectangle fly in' animation and a second for the text to fade in. You can see this in action here: http://www.raymondcamden.com/demos/2012/nov/7/v1/Untitled-2.html. Note that I didn't bother setting up any preloader or providing accessible support. I'm trying to keep this as simple as possible. So now we have a basic animation done. We could tweak it to make it prettier. Modify the flow of the movement. Etc. But let's focus on making this data driven. In order to do that I need to first stop the animation from running automatically. My Ajax call may be slow so I don't want anything to run until I've gotten my data back. Turning off the autostart is as simple as clicking on the Stage in Edge Animate and disabling it in properties. That was easy. The next part was a bit more difficult. In a normal application, I'd listen for a DOM ready type event before doing whatever I need to do. But I know that Edge Animate also has its own events. I assumed - but wasn't sure - that there was an event I could listen in for and trigger my own custom logic. With the Stage still selected, I clicked the Actions icon: I noticed the creationComplete event and assumed that was a safe bet. Going with the assumption that all my logic would go in here, I used the helpful menu of actions to guide how I'd write the code. I first selected "Set Element Text" and Animate added the following block: My text symbol was already named Text so I left the code as is. The portion that read "NewText" would be changed to the result of my Ajax call, but for now, I just wanted to ensure this worked. Next, I knew that I'd want to start the animation itself. This too was easy. I selected the "Play from" action and specified a value of 0. At this point, I noticed something odd. When I tested my animation, the text in the rectangle did not update. Something told me though that it may be the event I used. I don't have proof of this (but I'll find out), but I was willing to bet that the when Edge Animate ran the animation in the tool itself, it never fired a creationComplete event. I saved my work instead, ran it in the browser, and saw everything worked as expected. You can view this version here: http://www.raymondcamden.com/demos/2012/nov/7/v2/Untitled-2.html. You should now see it run the animation and use the new text as opposed to the word "STATIC". Woot! So now my work was almost done. I made a copy of my work and opened it in another editor. The file Untitled-2_edgeActions.js contained the event handler and custom logic I had created. Here it is as Edge Animate exported it. And here it is after I modified it to do an Ajax call. Pretty simple, right? You can run the final version here: http://www.raymondcamden.com/demos/2012/nov/7/v3/Untitled-2.html

Stop using jQuery!! (all the time...)

Tue, 23 Oct 2012 08:49:00 -0400

I apologize for the link bait. I feel bad doing it. But - at least you know I'm not a slimy SEO person and there is something useful in this article. ;) Yesterday I blogged a simple little POC (Proof of Concept) that demonstrated adding a class to a random list element. As I said in the post yesterday, this was rather trivial code, but I wanted to share it because of the use of LocalStorage. About an hour or so after I posted it, something began to bug me. I opened up the template and looked at the Network requests in Chrome dev tools. Just in case it isn't obvious, let me break it down for you. My HTML document was a bit over 1.5K. The jQuery library, compressed, was 33K. To be fair, my HTML was limited to what was required for the demo, but even if I increased the size of my document ten fold, it would still be less than the size of the jQuery library. Don't get me wrong. I love jQuery. I love what it has done for my development, my career, and my skin care. (Um, ok.) That being said, you don't need jQuery as much as you think. Consider what my demo did:

Run a function when the DOM was loaded.
Find some DOM items via CSS selectors.
Remove a class from one thing, add it to another.

That's it. Surely I could do that without an entire library, right? First, I switched to listening for the DOMContentLoaded event. For finding DOM items, I made use of querySelector and querySelectorAll. For adding and removing classes, I made use of the classList property. After these changes, the size of my application was pretty much next to nothing. Here is the complete template. Any questions?

Building a Parse.com Enabled PhoneGap App - Part 2

Tue, 25 Sep 2012 14:39:00 -0400

Sorry it took me a few days to get part 2 done. My hope is to get a few more entries done this week with a wrap up by next week. If you haven't read the first part, follow the Related Entries links below. Hopefully you're up to date and ready to go.In the previous blog entry I discussed the purpose of the series and what the goal was for the application I'm building. The Cow Tip Line will allow you to both report and find cows ready for tipping. While not really an enterprise-level application, I'm going to touch on aspects that I think will be applicable and helpful for all. There are two main technologies I'll be using for this application. They are PhoneGap and Parse. In this blog entry I'm going to focus on the set up steps you'll need to make use of these technologies. Let's tackle the easy one first - PhoneGap. In order to circumvent the normal Getting Started process, I'm just going to make use of PhoneGap Build. PhoneGap Build is a free service that can take care of building out your native applications for you. Using PhoneGap at the command line is easy. Using PhoneGap Build is even easier. Signing up requires an Adobe or Github username, and for more details, I encourage you to read my Adobe Developer Connection article: PhoneGap Build Levels Up. I'm not even going to worry about this aspect till later in the series so you can entirely skip this part for now if you want. Parse's set up is slightly more complex so the rest of the entry will focus on that process. If you plan on following along and building your own copy of the application, you will need to follow these steps. (And do leave me a comment below if you plan on doing this - I'd just like to know who is paying attention. ;) First, navigate over to the Parse signup. Note that signup is 100% free and doesn't require a credit card. After signing up, you are immediately dropped into a form to create a new application: Now this part is a bit odd - after naming your first application, you get brought back to the main Parse site. Just click the Dashboard link, which will bring you to a listing of your apps - all one of them: Click the application and you're brought into the detail view of the application. Here you will want to make note of the keys to the left. There are two important values here, the Application ID and the JavaScript Key. You won't need them just yet, but keep in mind where they are. Finally, click Downloads. You will be interested in the JavaScript section. Development links to a readable copy of the JavaScript API whereas Production leads to the minified version. The blank project isn't necessarily blank. It actually has a bit of CSS and some code that automatically creates an object for you. You want to grab the minified version of the JavaScript library and drop it into a new folder. I've set up a folder for the root of my application called cowtipline. In there is a folder called "js" where I saved the Parse JavaScript library. I then made a very simple index.html file: I've provided my own Application ID and JavaScript Keys above. (And in case you're wondering about the safety of that - stay with me - the last entry in the series will discuss how we can secure those values.) If you run this - nothing will happen. But we've got the basics done and can now start coding. I've also set up the GitHub repository here: https://github.com/cfjedimaster/CowTipLine In the next entry I'll begin setting up the UI based on the mockups from the previous entry. I'll also add the first set of logic to let you start creating Tips from the application.

Example of a Parse.com JavaScript application with offline support

Fri, 14 Sep 2012 10:53:00 -0400

This morning I got a seemingly innocent question from a reader:

Came across your blog post on Parse + PhoneGap and wanted to get your opinion on the following use-case for that combo... I've been exploring the possibilities of an app that essentially has a web form (similar to the contact form you've got right here, actually) that would store the resulting data via Parse. The reason being...it would be important that the app would allow a form to submit, even if there wasn't an active Internet connection available. So, just wanted your thoughts on whether I am looking in the right direction to accomplish this. Don't have much experience in the way of iOS apps, but have to start somewhere, right?

I replied to him with a basic outline:

When you submit the form, hit Parse if you are online, hit WebSQL if not.
When the application starts, see if you have data in WebSQL, and if you are online, push it to parse.

That seemed simple enough, but I figured I might as well build a real demo just to prove it can be done. This is what I came up with. It's got some issues (don't we all?) but it covers the basics. As always though I'm open to suggestions for how this could be done better. I began by creating the layout for an application. Since the reader just mentioned a form, I built the entire application around one form. I decided to build a simple UFO Report Form. It has a field for the number of UFOs, your name, and the description. I didn't make use of any UI framework but instead directed my incredible design skills at the task. Here's the HTML behind the form, just in case your curious: Fancy, eh? Ok, now it's time to get into the code. I'm going to tackle this piece by piece, and it may get a bit confusing, but I'll post the entire file in one chunk at the end for your perusal. Whether or not we are online, we need to set up the database. This is done via the WebSQL API. While this API is deprecated, it is fully supported in PhoneGap and works great in Chrome, the main browser I use for testing. I'm not going to detail how this works as I've covered it before (Example of PhoneGap's Database Support), but even if this is brand new to you I think you can get the idea. After the database is set up, our application needs to upload any existing data to Parse. We're going to skip that now though and look at the basic form handling aspects of the code. I wrote a function to wrap my check for online/offline support. Why? I wrote this demo without actually building it as a PhoneGap application. It should work fine when converting into a mobile application, and at that point my wrapper function can be modified to use PhoneGap's API, but for my initial testing I just wanted to use the navigator.onLine property. Having a wrapper also let me easily add in a hack (see the commented out line) to test being offline. If we are online, I need to initialize Parse support. I won't repeat what is already covered in the Parse JavaScript Guide. Instead, this is just an example of how I initialize Parse.com with my API keys and define an object type I'm calling SightingObject (as in UFO sighting). Now let's look at the form handler. Remember, this needs to either save to Parse or to the database. This code block is a bit large, so let's break it down. The first thing I do is grab the values from the form. As mentioned in the comments, it would probably make sense to do some basic validation. Screw validation - this is a demo. Next I do some basic UI stuff to let the user know that exciting things are happening in the background (although in theory, not as exciting as the UFO in front of them). Then we have the online/offline block. I've taken the Parse logic out into another function that I'll show in a moment. The other part of the conditional simply writes it out to the database. In both cases we run a function, resetForm, that handles resetting my UI. Here is saveToParse. Notice how darn easy this is. Just in case it isn't obvious - this is all the code I need to store my data, permanently, in the cloud. It would only be easier if the Parse.com engineers fed me grapes and lime jello shots while I wrote the code. Before we get into the synchronization aspect, here is resetForm. Again, it just handles updating the UI and letting the user know something happened with their important data. I did some quick testing and confirmed it was working. I used Parse.com's online data browser first: I then tested offline storage. Chrome makes it easy to check since it has a database viewer built in: That's almost it. The final piece of the puzzle is handling uploading the database data. This turned out to be simple too. If we are online, we can run a SQL against the table. If anything exists, we upload it and remove it. That's basically it. The biggest issue with this code is that it doesn't handle a change to your online/offline status, specifically, if you start the application offline, save some sightings, and then become online, it won't upload the old rows. That wouldn't be too hard to fix, but I was trying to keep it simple. At minimum, the next time you run the application it will upload those old records. For folks who want to see the entire code base, simply view the gist here: https://gist.github.com/3723074 I've also included a zip attached to this blog entry. (Note that the animated gif is courtesy of jQuery Mobile.)

Proof of Concept - Build a download feature for IndexedDB

Thu, 23 Aug 2012 11:09:00 -0400

Before I begin, a quick editorial note. I almost didn't write this blog entry. After working on the code and getting everything working right, things quickly went to crap when I switched from Mac to Windows. I had odd results in Firefox as well. Overall, I feel that the solution I've come up with here is solid, but the current browser implementations are... less than ideal. So, please keep that in mind. Perhaps you are reading this a year from now while cruising around on your jetpack and the browsers have settled down in terms of their IndexedDB support. Perhaps. Until then, please consider that what follows is going to be less than perfect in your browser.IndexedDB is a nice way to store massive amounts of data on the user's machine. This allows for personal storage of - well - just about anything. Browsers are still working on their implementation, and the feature can be a bit... tricky (see my earlier posts), but overall it can be an incredibly powerful feature. I was thinking that it might be interesting to build a way to export and save data from an IndexedDB datasource. Why bother when the data is local? I don't know. Maybe as a way to save a 'version' to a USB stick. Maybe as a way to upload later to another machine. To be honest, I just wanted to build it and see what it took. Thinking about the process, I broke it down to a few steps. First - we need to get all the data from our datasource. IndexedDB has a simple way to iterate over an objectstore (think table). What isn't so easy though is handling the fact that this is an async operation. If you have more than one objectstore you have to wait until all are done. Second - once you have all the data, you need to serialize it. Luckily we can rely on the browser's native JSON support to quickly convert it. The third and final step is to stream it to the user. Fellow Adobian Christian Cantrell has a good blog entry on saving JavaScript data. But I used a modified version that made use of HTML5's new "download" attribute for anchors. Simple enough? I decided to begin with an earlier application I wrote that allowed for simple Note creation. If you've got a recent Firefox installed, you can play with it right now: http://www.raymondcamden.com/demos/2012/aug/23/test.html This will not work in Chrome... sometimes... due to the issue I reported here. Oddly - Google Canary, on Mac only, seems to work now - perfectly. That's the main browser I used for testing. But the exact same Canary on Windows did not work. Confusing - I know. Even if you aren't using a browser that will handle the demo, I encourage you to hit the page and view source. I'm going to be sharing lots of snippets as we go on. To make the application a bit more complex I added a new objectstore called log. This is defined here: This objectstore will simply contain log messages. I modified my code so that when I created and deleted notes it would simply log the actions. To simplify this I wrapped the logic into a nice utility function: The end result is that my application is using two objectstores. One main "note" objectstore for the actual content and one called "log" which isn't actually shown to the user. I began the process of adding export support by adding a nice button to the top right of the application. Clicking this button begins the process I defined above. As I mentioned, the first step was to actually get all the data. Because this is involves N asynchronous processes, I decided to make use of jQuery Deferreds. jQuery Deferreds are black magic to me still. I have the hardest time wrapping my head around them but I was able to get something working. I'm betting there are nicer ways of doing this and I hope my readers can share some tips. Basically though I loop through each objectstore in the database (and note this code is entirely abstract - it should work for any IndexedDB instance) and create a new Deferred to handle the data collection for an individual objectstore. When done looping over the data, I resolve the deferred by returning an array of objects. Finally, $.when is used to collect all of this. Let's talk about the last few lines above. You can see where I stringify the entire data set in one line. That's damn convenient. Any browser that supports IndexedDB will support the JSON object so it's a no brainer to use. Sending the data to the user was also pretty simple. You can see where I - initially - made use of the "Cantrell Solution" (yes, I'm using that term because it sounds cool ;). While this worked, it didn't allow for a file name. To get around this, I added an empty link to my DOM. That may not be necessary, I could have just made one in JavaScript, but it was quick and worked. If you view source you will see this in the layout: <a id="exportLink" download="data.json"></a> Again - I feel kinda bad just dropping this into the page like that. I'd probably do it entirely virtually in the future. But note the download attribute. That's all it takes to 'suggest' a filename for downloading. That's it! So given that I had a jQuery hook to the link already, I simply set the HREF equal to my serialized data. I initially tried to trigger a click, but for some reason, this didn't work correctly. Luckily I found a solution on StackOverflow - the fakeClick function. You can see it yourself if you view source. Unfortunately, Firefox does not quite work right with the download attribute. It should be coming soon, but for me, it never worked right. That means to truly test this demo, the only browser I know of that can do it all is Google Canary on OS X. Hopefully that will change soon. So - despite all the buts and warnings above - I hope this is an interesting demonstration for my readers. As always, I'd love to hear your feedback on how this could be improved.

Resources from my RIACon presentations

Wed, 08 Aug 2012 05:41:00 -0400

Thank you to everyone who showed up for my RIACon presentations. Any feedback, positive or negative, would be greatly appreciated. I've attached the code and slide deck for the jQuery Mobile presentation to this blog post (link at the bottom). The resources for my HTML5 presentation may be found on Github: https://github.com/cfjedimaster/html5-storage

Using jQuery to load HTML and filter it by N selectors

Thu, 02 Aug 2012 08:36:00 -0400

Forgive the somewhat awkward title. Hopefully an explanation will make things a bit clearer. I was working on an application yesterday that needed to load in a HTML file via AJAX and display it on screen. The HTML happened to be documentation so I was going to simply display it as is on screen. Since I wasn't doing any processing, my code was very simple: Easy, right? Well, the first thing I discovered was that the HTML I was loading included things I didn't want - headers, footers, etc. Again though this is easy enough to handle. You can tell jQuery's load() function to filter down to a DOM item. (As a reminder - if you are concerned about performance don't forget that you are still asking jQuery to load N bytes of HTML even though you are using <N bytes in the display.) Woot. Almost there. This worked great, but the "block" of HTML this rendered was missing a nice header on top. I went back to the original source HTML and discovered that there was another div, header, that contained the title and would be perfect. But here was a problem. How do I tell the load() function to select *two* DOM items? Turns out this was easy as well - just provide a list: This worked fine. But this leads to my question. Is this a good idea? Is there a better way? (Assuming you can't get "pure" data and must work with the HTML files.)

Example of form validation in a jQuery Mobile Application

Mon, 30 Jul 2012 08:17:00 -0400

Over the weekend I decided to write up a quick example of form validation in jQuery Mobile. Obviously there are many ways you can accomplish this and I just wanted to take my own little spin with it. Here's what I came up with and I'd love to hear how other jQuery Mobile users are doing validation.Let's start off with a real simple jQM site. It will have a home page with links to two sub pages. My form will be on the second page. To be honest, I could have just built a one page site, but I wanted something with a trivial bit of navigation to it so it felt just a bit more realistic. I won't bore you with all the code (you can view source on the demo yourself), but here is our simple form: The form consists of 6 fields: username, password, the password confirmation, your favorite color, and your home town. The validation rules should be:

Everything but the home town is required.
Username, password, and the confirmation must be 5 characters minimum.
The password confirmation must match the password.

Pretty simple, right? Without any validation at all, you can take this for a spin here: Round 1 And if you don't want to bother with that - a quick screen shot (which I generated from Adobe Shadow thank you very much): Ok, so let's talk validation. It would certainly be cool if we could just use HTML5 form validation, right? I mean, look at the mobile browser support for Canvas: That's a hell of a lot of green. So obviously - if there is that much support for canvas, which is only mildly useful in practical matters - surely there is even higher support for form validation, something we probably all use every single day. *sigh* Ok, so moving on from that, let's talk options. Obviously we can roll our own JavaScript. It isn't terribly difficult to do so. But I thought it might be nice try the jQuery Validation plugin. I've blogged on it before (see links at the bottom) and I liked how simple it made things. I thought I'd give it a shot here and see how it ran. The plugin provides two main ways of adding validation to a form. You can either add items to a class attribute of your form or supply a list of validation rules when initializing the plugin. Personally, I don't know which I prefer. I wish the plugin made use of a data-attribute instead of a class, but I like seeing my rules in the HTML. I went with that approach but just keep in mind you have the other option as well. Here's the updated HTML for the register page (just the form bits): Notice the addition of class="required" to my fields requiring validation. Also note the minlength of the first three fields. This is - pretty much - all it takes. The one big obvious piece missing is the "confirmation must match password" field but that can be handled in a custom rule. I also had to initialize the validation but that's one line of code: $("#registerForm").validate(); So far so good, right? But check out the result: First, the errors don't really stand out and second - note the error for the drop down. It's actually inside the custom jQM drop down field. Not good. Let's tackle the design first. By default, the validation plugin will use an error class for displaying errors. That means it is pretty trivial to make it look a bit nicer: Which results in: Nice. About halfway there. You can demo this version here: Round 2 So what about the weird drop down behavior? We can use another feature of the plugin to handle that. You can use a property, errorPlacement, that allows you to dynamically determine where errors should be written out. While we're at it, we can also go ahead and create the custom rule for password matching. To be honest, the use of .parent() there was a bit of a guess, but it worked on first try. In case you're curious, to add the custom validation to the second password field I just had to add the name to the class list: class="required passmatch". You can demo this version here: Round 3 So, what do you think? I'd like to work on this a bit more. On the iPad, the errors are left aligned under the labels, which is kinda cool, but I could also see them being aligned with the fields instead. On desktop it is way off but I kinda figure that is an edge case and not something I'd have to worry about. As always, comments and critiques are welcome.

Preventing navigation to a page in jQuery Mobile

Thu, 19 Jul 2012 18:00:00 -0400

Here's an interesting situation I ran into recently. Consider a simple web site that begins with a login page. After you successfully login, you proceed to a 'home' page with links to sub pages. But you want to prevent users from using their back button to return all the way to the login page. It isn't a security issue per se, but it is confusing. The user should only be able to go back to the post-login home page.In theory - this should be simple. jQuery Mobile exposes a pagebeforechange event. As you can guess, it is fired before you change to a page. According to the docs, using preventDefault effectively blocks the loading of the page. Easy then, right? The docs state that you are passed a data object that contains a "toPage" key. This is either a simple value (url) or a jQuery DOM item for the page. In theory, I can use this to detect someone loading the initial page and simply block it. Here's a snippet of the code I tried: You can demo this yourself here (opens in new window): http://raymondcamden.com/demos/2012/jul/17/index.html Now, if you try this, something interesting happens. When you click to visit page 2, and then click back in your browser, you will see that the page does not change, but the url does!. So jQuery Mobile kinda "half way" worked but not completely. In testing I saw various problems with this. Just now, I wasn't able to go back anymore, but in other testing I would go back after a second click. It was a bit inconsistent for me. I posted this to the jQuery Mobile forums and user Kevin B had a great solution. He correctly pointed out that I was preventing jQuery Mobile from navigating but not preventing the browser itself from doing so. He suggested modifying the history directly to correct it. This could be done with a simple history.go(1) statement. You can see a full example of his solution here. I tried this back in the application I was building and it worked fine. I noticed that in my PhoneGap application that I received a jQuery object instead, but that simply required me doing a quick check on toPage.attr("id"). Hopefully this makes sense and helps others.