Geolocation with IPInfoDB

Requirements

• jQuery JSON
• jQuery Cookie
• Snoopy PHP

Code and explanations

By placing this at the jQuery level it prevents any page blocking that may occur during loading, and the proxy script prevents any cross site scripting problems.

First, the javascript variables , with a small bit of PHP:

var ip = "<?php print $_SERVER['REMOTE_ADDR'];?>";
var geolocation = "./ip_proxy.php";
var cookiename = 'geo_location';
var cookieoptions = { path: '/', expires: 10 };

These variables setup the path to the proxy script, place the users IP address into a javascript variable, and establish our cookie parameters. Next, we setup our page initialization function:

$(function(){

  fetchlocation();

});

displaylocation = function(location) {
  if (location.Status == 'OK') {
    $('.city').text(location.City);
    $('.zip').text(location.ZipPostalCode);
    if(location.State != '--') {
      $('.state').text(location.State);
    } else {
      $('.state').text(location.RegionName);
    }
  }
}

fetchlocation = function() {
  // look in the cookie for the location data
  cookiedata = $.cookie(cookiename);
  if ('' != cookiedata) {
    locationinfo = $.evalJSON(cookiedata);
    if ((locationinfo != null) && (locationinfo.IP == ip)) {
      displaylocation(locationinfo);
      $.cookie(cookiename, cookiedata, cookieoptions);
      return;
    }
  }
  // it's not in the cookie, so fetch from the server
  $.getJSON(
    geolocation, {
      'timezone' : 'false', // set this to false to save the service 2 queries
      'ip'       : ip
    },
    function(data) {
      data.IP = ip;
      displaylocation(data);
      cookiedata = $.toJSON(data);
      $.cookie(cookiename, cookiedata, cookieoptions);
    }
  );
}

PHP code

The PHP code is well documented within the ip_proxy.php file. It acts as an intermediary between the jQuery script, and the IP producer. Note that the file can restrict based on hosts, and adds an extra State abbreviation variable to the data returned by the IPInfoDB API

You can see the sample at here at There4, and you can see the project page and submit issues at http://plugins.jquery.com/project/animatedborder.

When the user added a new item to the list, the app displayed a spinner, and then faded in the new item from the input box to the list. On the development machines, it was moderately fast. But once it was on the production machines, the ajax was extremely fast – it returned in less than a tenth of a second. This meant that the spinner was displayed for such a short period of time that the users simply didn’t see it. It was never visible to the user.

Because of this, the users didn’t seem to be understanding that the item had become permanent – testing showed that they were actually looking for a “save” button after they had added their items to the app. After some discussion, it became apparent that the speed was confusing them. They believed that web applications have to process for a moment and communicate with a server. Because the process was so snappy, they believed that there was no way it could have been saved on the server, and so they were looking for a submit button to save their items. Because of the speed of the interface, they thought that the changes were only happening locally.

The solution? We added a timer to the application so that the spinner would never show less than three tenths of a second. It was long enough that they felt that the new item had been saved.

jQuery.fn.slideRemove = function(callback) {
  $(this).blur().fadeTo('medium', 0, function() { // fade
  $(this).slideUp('medium', function() {   // slide up
  $(this).remove();                        // remove from DOM
  if (callback) { callback(); }
  });
  });
  return this;
};