The concept is simple. These events help promote open government data that can be used within applications that you build to solve everyday problems. So, these organizations provide you with cool data sets to choose from and you have fun building an application around it. Ideas include find the nearest rent-a-bike location, explore local hiking trails and so much more.

Full disclosure, Esri has also graciously offered to provide bountiful cash (yes, cash!) prizes. Other sponsors are offering Rokus, Kinects, and even Big Wheels (yes you also heard that right!). I even have an application in mind that I might try to build when I’m not helping other folks out.

What do you think? Hopefully I’ll see you there.

The challenge with enum usage in JavaScript is global variable leakage can accidentally cause unexpected changes within your application, especially in cases of large, complex applications that may involve your own JavaScript libraries along-side 3rd party libraries. Global variable leakage means two variables can potentially have the same name, and this may not cause an error. Good debuggers help to avoid this problem by using jslint. But, if someone else is using your libraries then you can’t depend on them using best practices. So, variable leakage can cause unexplainable/unpredictable problems and create hard to track bugs. What we need is a coding pattern to protect enums so that we can guarantee that we always get the value expected.

As of today, JavaScript doesn’t have a universally accepted, built-in cross-browser solution for guaranteeing that specific variables can be made immutable. In other words, if we create a statement var BLUE = “blue” there is no way to enforce that something elsewhere in an application, or code that someone else wrote that is running the same application cannot ever change the value of BLUE.

In comparison, strongly typed languages such as C# and Java let you declare constants. If you accidentally try to change them in your code you get a compiler error that prevents the application from running. The compile-time checking can help prevent bugs in your code later on. Here are several examples from Java and C#:

 final int RADIUS = 1000; //Java

 const int RADIUS = 1000; //C#

So here we go. I’ll use six use cases to illustrate a variety of ways to make certain your enums are immutable. This list is not designed to be all inclusive, its intent is to demonstrate patterns that you can use to learn more about JavaScript enums. You can try these out using the following jsfiddle.

USE CASE 1 – Basic public enum function with no namespace protection. This use cases offers the least amount of protection against global variable leakage. I’d only expect to see this type of enum in very small, stand-alone applications.

function basicEnum() {
    var values = {
         BLACK: '#000000',
         RED: '#FF0000',
         GREEN: '#00FF00'
    }

    return values;
}

console.log("test0 " + basicEnum().BLACK); //test0 #000000

USE CASE 2 – Basic public enum that uses an internal, privately scoped namespace in which to define the enum object. This use case offers slightly more protection than Use Case 1, but the public function itself is still not protected within the global namespace. It’s possible there could be two functions with the same name “colorEnum”. And, the larger the application gets the higher probability there is of having accidental name duplication.

function colorEnum() {
    var values = values || {}
    values.colorEnum = {
         BLACK: '#000000',
         RED: '#FF0000',
         GREEN: '#00FF00'
      };

      return values;
};

console.log("test1 " + colorEnum().colorEnum.GREEN); //test1 #00FF00

USE CASE 3 – Public enum with no namespace protection using an anonymous function expression to define the enum. This is a variation of Use Case 2 showing you can define multiple categories of enums. And, like Use Case 2 it still offers zero public/global namespace protection. I’m using the terms public and global to mean the same thing.

DoSomething = (function(){

    var constValues = constValues || {}
    constValues.color = {"BLACK" : "#000000" }
    constValues.error = {"ERROR_TIMEOUT" : "Connection Timeout" }
    return constValues;
});

console.log("test2 " + DoSomething().color.BLACK); //test2 #000000
console.log("test3 " + DoSomething().error.ERROR_TIMEOUT); //test3 Connection Timeout

USE CASE 4 – Public enum with namespace protection using an anonymous function expression and internal (private) namespaces to differentiate multiple categories of custom enum objects. This use case starts to offer better protection against global variable leakage by wrapping the public function in a namespace.

var my_test = my_test || {}
my_test.DoSomething = (function(){

    var constValues = constValues || {}
    constValues.color = {
        "BLACK" : "#000000",
        "RED" : "#FF0000"
    }
    constValues.error = {
        "ERROR_TIMEOUT" : "Connection Timeout",
        "ERROR_FAULT" : "Connection problem"
    }
    return constValues;
});

console.log("test4 " + my_test.DoSomething().color.BLACK); //test4 #000000
console.log("test5 " + my_test.DoSomething().error.ERROR_TIMEOUT); //test5 Connection Timeout

USE CASE 5 – Namespace protected public anonymous function expression along with an internally (private) scoped function that defines the enum. This is a variation of Use Case 5 showing how to use switch/case statements along with a privately scoped function that are all wrapped inside the anonymous function.

var my_second_test = my_second_test || {};
my_second_test.DoSomething = (function(val){

    var color;

    switch(val)
    {
        case 1:
            color = basicEnum().BLACK;
            break;
        case 2:
            color = basicEnum().RED;
            break;
        case 3:
            color = basicEnum().GREEN;
            break;
    }

    function basicEnum() {
        var values = {
             BLACK: '#000000',
             RED: '#FF0000',
             GREEN: '#00FF00'
        }

        return values;
    }

    return color;
});

console.log("test6 " + my_second_test.DoSomething(2)); //test6 #FF0000

USE CASE 6 – This Use Case shows placing a privately scoped anonymous function expression defining the enum inside a public anonymous function expression, and finally accessed through another prototyped anonymous function expression. Yikes, that was a lot of technical mumbo-jumbo verbiage, right?! It also offers several tests to validate if the enum is immutable or not.

var my_third_test = my_third_test || {};
my_third_test.DoSomething = (function(){

    this.basicEnum = (function() {
        var values = {
             BLACK: '#000000',
             RED: '#FF0000',
             GREEN: '#00FF00'
        }

        return values;
    });

});

my_third_test.DoSomething.prototype.findColor = (function(val){
    var color;

    switch(val)
    {
        case 1:
            color = this.basicEnum().BLACK;
            break;
        case 2:
            color = this.basicEnum().RED;
            break;
        case 3:
            color = this.basicEnum().GREEN;
            break;
    }

    return color;
});

var myColor = new my_third_test.DoSomething();

console.log("test7 " + myColor.findColor(3)); //test7 #00FF00

//The enum properties cannot be changed
myColor.basicEnum().BLACK = "test";

console.log("test8 " + myColor.basicEnum().BLACK); //test8 #000000

try{
    //test that basicEnum() is immutable
    myColor.basicEnum() = "test"; //Throws ERROR!
}
catch(err){
    console.log("test9 " + err);
    //test9 ReferenceError: Invalid left-hand side in assignment
}

Conclusion. So that’s all there is to it. Hopefully these examples help to not only demonstrate some patterns to protect your data, but also give you ideas for saving time while building larger applications.

Reference.

JSFiddle project

Lets start with a look at the minimum required CSS:

html,body,div[data-role ="page"], div[data-role="content"] {
    height: 100%;
    width: 100%;
    margin: 0px;
    padding: 0px;
}

Problem – Using the minimum CSS above, leaves a spacer on the top and left hand sides of the app, and the right hand border and/or bottom border disappears. I noticed the right hand margin extends approximately 9 to 15 pixels (or greater depending on device) beyond the visible view. I verified this behavior on Android 4.1 native browser and Chrome 26, as well as on iPad 3 using Safari and Chrome 25.

Solution – set certain CSS width properties as shown below. This solution has been tested on Android 4.1 native and Chome 26, Android 2.3.2 native, and on iPad Safari and Chrome 25. Just a bit of a warning that if displayed on a desktop browser you will see vertical scrollbars. But, you should be detecting the different between mobile and desktop anyway, right!

Note: this solution doesn’t address the problem with content height, it only looks at width. So, yes, you will notice that the height of my sample is off the page.

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=7,IE=9">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0,user-scalable=no">
    <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

    <title>jQuery Test</title>

    <link rel="stylesheet" href="http://code.jquery.com/mobile/1.3.0/jquery.mobile-1.3.0.min.css" />

    <script type="text/javascript" src="http://code.jquery.com/jquery-2.0.0.js"></script>
    <script type="text/javascript" src="http://code.jquery.com/mobile/1.3.1/jquery.mobile-1.3.1.js"></script>
<style>
        html,body, div[data-role ="page"] {
            height: 100%;
            width: 100%;
            margin: 0px;
            padding: 0px;
        }

         .ui-content{
            height: 100%;
            width: 100%;
            margin: 0px;
            padding: 0px;
            border-style: solid;
            border-color: chartreuse;
            border-width: 5px;
        }

        #map {
            height: 100%;
            width: 100%;
            padding: 0px;
            border-style: solid;
            border-color: crimson;
            border-width: 10px;
        }
</style>
</head>

<body>

<div data-role="page" id="page1" >

    <div data-role="content">
        <div id="map"</div>
    </div>

</div>
</body>

References

Determining the dimensions of an [HTML] element

Check HTML5 Browser Height and Width using Canvas

[Modified April 26, 2013 - fixed code bug]

Many developers I talk to aren’t aware that the read/write speeds of SD memory cards can have a significant affect on performance. This is especially true if you are moving around lots of data between a smartphone and the SD card. The good news is there is quite a bit of information out there to help you maximize performance, and a lot of it comes from high-end, camera aficionados believe it or not.

The most common feedback I get is developers typically buy cards with the most capacity at the lowest price. Depending on what you are doing, cheapest and slower isn’t always better. With little bit of research your read/write performance could get significantly better.

To start with there are four common speed classes: 2, 4, 6 and 10 and they represent an approximate minimum performance rating. You can find this number on the front of your card:

• Class 2 ~ 2 Mbytes/sec
• Class 4 ~ 4 Mbytes/sec
• Class 6 ~ 6 Mbytes/sec
• Class 10 ~ 10 Mbytes/sec

Read/write performance to your phones SD card really depends on HOW your application reads and writes data. You may have to do some testing to find out what works best. It depends on the consideration of multiple factors including:

• Typical file types (e.g. video vs. text vs. image, etc)
• Average file or data transaction size
• Percentage of reads to writes
• Duty cycle (percentage of reads or writes over a fixed time period)
• Usage pattern

Usage pattern deserves a bit more attention and really starts to tell the story of what your application does behind-the-scenes. I think the best way to describe it is through some common use cases:

• Many small reads and writes to/from a local database.
• Occasional small reads and writes to local database.
• Occasional large reads from local database.
• Occasional large reads and writes to/from local database.
• Large read upon application startup and large write upon application shutdown.

Wikipedia has noted that speed can differ significantly depending on what you are writing to the card. The article notes that writing large files versus writing many small files has widely different affects on performance. I’d seen similar observations when I worked on ultra-high performance server systems. So, the concept still remains today and provides excellent hints on how to tweak every extra millisecond of user experience.

If you need maximum performance then consider reformatting or defragging your card on a regular basis. I know Windows disk defragmenter utilities work on most SD cards, not sure about Mac. I have also seen multiple articles talk about bigger capacity is better because of memory fragmentation. With memory fragmentation, the card speed starts to decrease over time as the data becomes more fragmented. It’s the same concept as when you “defrag” the hard drive on your laptop.

References

If you want to learn more here are some helpful links:

SD Association – Bus speed

SD Association – Speed Class

Wikipedia – Secure Digital (See Speed Class Rating section)

Does your camera need a fast SD card? (good insight into SD card speed)

Why should you care?  Any crook with a little bit of knowledge on how to generate header files can use oauth_token and oauth_token_secret and take control of your customers account.

I don’t know why but several of the most popular PHP OAuth libraries don’t mention this as a best practice. So I’m making an effort to shout out that encrypting your cookies is a very good thing to do and it involves the following:

• Encrypt oath_token and oauth_token_secret
• Write encrypted values to cookie
• Read encrypted values when required
• Provide functionality to delete cookie

Another gotcha is if you allow someone to log out of your app without deleting the cookie, then it’s possible someone else could come along and get the cookie then use it to generate requests on behalf of your client application.

So here’s a fully working PHP example of how to encrypt cookies. You can also access this project through a github repository.

Step 1: generate your key and initialization vector:

<?php
  session_start();
  require_once('config.php');
  require_once('Encrypt.php');
  header('Content-Type: application/json');

  $test = new Encrypt(null,null,DEFAULT_TIME_ZONE);
  echo "\n\n---------\n\nGenerate Key (Base64): " . $test->get_RandomKey();
  echo "\n\n---------\n\nGenerate IV (Base 64): " . $test->get_IV();

?>

Step 2: setup the config file:

<?php

/**
 * @file
 * A single location to store configuration.
 */

//REQUIRED - Encrypt your cookies
//http://si0.twimg.com/images/dev/oauth_diagram.png
//Create your own unique ENCRYPTION_KEY via Encrypt.get_RandomKey()
define('ENCRYPTION_KEY','Q83dBef2tgmHKZ9T1htFA2Y+jZgdler0szN28rjBf8o=');
//Create your own unique initialization vector via Encrypt.get_IV()
define('IV','C2Oez0DLMQ8rCcgYFJwzCw==');
define('DEFAULT_TIME_ZONE','America/Los_Angeles');

?>

Step 3: test ability to set an encrypted cookie and decrypt it.

<?php
session_start();
require_once('config.php');
require_once('Encrypt.php');

$key = base64_decode(ENCRYPTION_KEY);
$iv = base64_decode(IV);
echo "Key: " . $key;
echo "\n\nIV: ". $iv;
$test = new Encrypt($key,$iv,DEFAULT_TIME_ZONE);

if(isset($_COOKIE["twitterapp"]))
{
    header('Content-Type: application/json');

    $retrieved_cookie =  $_COOKIE["twitterapp"];
    echo "\n\nEncrypted value: " . $retrieved_cookie;
    echo "\n\nActual Value: " . "VodG7slxk+w0INvK66gztp4TOLijNzyiWDzI8Z4IU4PTiBJJkRPdkaEbDtXFYUVkCVU=";
    echo "\n\nDecrypted Value: " . $test->decrypt(base64_decode($retrieved_cookie));

}
else
{
    $fake_cookie_string = "VodG7slxk+w0INvK66gztp4TOLijNzyiWDzI8Z4IU4PTiBJJkRPdkaEbDtXFYUVkCVU=";
    $encrypted_cookie = base64_encode($test->encrypt($fake_cookie_string));
    setcookie("twitterapp", $encrypted_cookie, $cookie_life, '/', OAUTH_COOKIE_DOMAIN);
    header('Location: http://your_domain_name/oauthphp/test.php', true, 302);
    exit;

}
?>

And, here is the Encrypt Class:

<?php
class Encrypt{
	/*
	* Basic encryption Class
	* Version: 1.0
	* Author: Andy Gup
	*/
    private $key;
    private $iv;

    function __construct($encryption_key,$iv,$time_zone) {
        $this->key = $encryption_key;
	$this->iv = $iv;
	date_default_timezone_set($time_zone);
     }

     public function encrypt($value){
          $final = null;
          if($value == null || $this->key == null || $this->iv == null)
          {
               header("HTTP/1.0 400 Error");
               echo "\n\n\nERROR: Null value detected: check your inputs";
               exit;
          }
          else
          {
              try
              {
                   $final = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $this->key, $value, MCRYPT_MODE_CFB,$this->iv);
              }
              catch(Exception $e)
              {
                   header("HTTP/1.0 400 Error");
                   echo "\n\n\nERROR: Failed encryption. " .$e->getMessage();
                   exit;
	      }
          }
          return  $final;
    }

    public function decrypt($value){
        return mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $this->key, $value, MCRYPT_MODE_CFB,$this->iv);
    }

    public function get_RandomKey(){
        $result = openssl_random_pseudo_bytes(32, $secure);
        return base64_encode($result);
    }

    public function get_IV(){
        $size = mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CFB);
        return base64_encode(mcrypt_create_iv($size, MCRYPT_RAND));
    }
}
?>

Resources

Github repository

PHP for Windows - the Mcrypt library seems to come with this installation. Mac users may have to install MAMP.

PHP Manual for Mcrypt

OAuth Community

[Modified: April 27, 2013 - added link to github repo.]

But, I do know some folks (who have requested to remain anonymous at risk of being made fun of) who insist that a desktop is the only way to go. Yes you may be shocked and surprised to learn that many non-geeks don’t have the latest, fastest, sleekest, quietest, thinnest, greenest, most powerful, highest resolution, lightest devices. I know that’s crazy, right? Yet, these people do actually exist. So over the last six months I’ve compiled a list of the desktop crowds desires:

1. Need a larger screen
2. Need the full-size keyboard
3. Need a larger hard drive
4. Need more power for processing images and videos
5. Corporate security reasons where they don’t want laptops leaving the building
6. Laptops are significantly more fragile and don’t last as long.

Now let me briefly present some corresponding counter-arguments suggestions.

1. You can always hook up an external monitor to a laptop or some tablets.
2. There are also external USB keyboards that rock.
3. External storage is awesome these days. There are high-performance 128GB thumb drives, for example and even multiple terabyte external drives.
4. Number 4 above might be the only reason for making a concession towards using a desktop. If you are professional or graphic artist that has video or image processing jobs that take currently many hours on a high-performance quad-core desktop, then you might not want to heat up your laptop to that extreme. For everyone else doing Facebook processing there are definitely some high-powered laptops that can crank on image processing.
5. You could always use a permanent security cable like I’ve seen at some hotels and airport lounges.
6. One of the most common causes of laptop death is failure to keep it cool. Make sure it sits on a hard surface like a table and not on top of your puffy down comforter all night. If you have a problem with dropping your laptop get it a protective case.

In conclusion, there are very few reasons where a desktop computer is the only solution. The next question you ask me should be “so, what type of laptop or tablet do you recommend?”!

I’m going to be talking a lot about mobile this year and how to transition from the desktop environment to mobile. Sure there are lots of experts out there building awesome mobile apps, but there are also many, may developers, organizations and companies that are just starting to get their feet wet.

I have four topics this year, so swing on by and say “hi”. Oh, and be sure to bring sun block and hot weather clothes. I hear the temperatures my reach 100F! Here are my sessions:

• Best Practices for HTML5 Geolocation – This will be an A-to-Z overview of the HTML5 Geocation API including the good and the not-so-good. (Tue. 2:30p, Demo Theater 2 and Thur., 1:15pm Mesquite G/H)
• Getting Started with the ArcGIS Runtime SDK for Android – Great session if you are getting ready to start doing native geo-spatial development on Android (Mon. 1pm, Pasadena Rm.)
• Building Mobile Applications with the ArcGIS API for Flex – Apache Flex is an incredibly easy-to-use platform where you can take one code base and compile for native iOS and Android. (Tue. 5:30pm Primrose C/D)
• iOS and Android: Let’s have a hug – this is a fun session where @geeknixta and I get to make fun of each other as well as show off the similarities of our Runtime SDKs on iOS and Android. I’m the Android fanboy, of course. (Wed. 5:30pm, Catalina/Madera)

I’m striving to make this information freely available because adding location to your apps can be fun, and it can also be an important part of the applications that you build. By taking into account these six use cases you will be able to build applications that better meet your requirements and make for a more enjoyable end user experience.

Use Case 1 – Cold Start. Application launches from a completely stopped state. Cached GPS  and Network location values may be unreliable. As a developer you don’t really have any control over this but you need to plan for it. The screenshot from the GPSTester tool below shows a typical cold start where the cached network location has better accuracy than the most recent GPS location. You can see from the timestamps that even though the GPS location is more recent than the network location, it’s the network location that has better accuracy.

Use Case 2 – Warm Start. Application launches from a minimized state. Cached GPS values may be reliable depending on how much time has passed since application was last running, and the total distance traveled away from when the app was last used. Like the cold start, the user that decides how and when to start the app and you just have to plan for this use case. The screenshot below represents a typical warm start scenario where the cached GPS result has better accuracy than the cached network provider.

Use Case 3 – Minimized. Requirements may call for location listeners to continue to run in the background, or to be shut off when the application is minimized. There is also the option of using what’s called passive listeners which rely on other applications to call location services. Note, if you listen for location changes in  a minimized state you typically won’t benefit from this information until the application is opened again. In my previous posts I’ve stated that if your target demographic uses retail and social media apps this use case may be of benefit if the person uses the device constantly during the day. Many retail and social media apps access location. However, in many commercial use cases using passive location listeners may provide less than desirable results since there is much less of a chance of another application using a location service.

Pros: Running location services while app is minimized can speed up acquisition time when app starts, but only if your requirements call for always-on accuracy at a moment’s notice. If you shut off location then you will save battery life.

Cons: If active location services are left on in a minimized state this can sap the battery without the user really knowing it.

Use Case 4 – Snapshot. Application only needs to hit a minimum level of accuracy before shutting off location services. The screenshot below shows that it took approximately 2 minutes for the device to reach an accuracy of 12 meters. Yep, you heard that right…2 minutes! Also note how much the latitude and longitude of the different providers wandered around the map. The blue dot indicates network locations and the red dot indicates GPS locations. This is just a reminder that consumer-grade Android devices may or may not be accurate enough for your unique requirements.

Pros: Maximizes battery life.

Cons: May cause user interface delays if user needs to refresh the location during a single application session.

Use Case 5 – Continuous duty. Location services need to be constantly on while application is running. The screenshot below shows a use case of the user being in a downtown area with lots of tall buildings, the apps was run for about 10 minutes, then minimized briefly, then opened again for a warm start. The accuracy didn’t change much even after 10 more minutes of testing. As you can see, the GPS provider accuracy has suffered significantly at 153 meters, while the network provider is offering 45 meters of accuracy.

Pros: Best for constant, up-to-date, always on accuracy. Accuracy available instantly (after the device has ‘warmed up’).

Cons: Huge drain on the battery, but you can adjust the minimum distance property needed to trigger a location update.

Use Case 6 – Intermittent duty. GPS is only needed to run at intervals. To test these types of scenarios you can adjust various settings from within the GPSTester Tool’s preferences. Specifically you can modify the GPS and Network properties for minimum update time and distance. This is very powerful as you can easily toggle these settings to test various settings on-the-fly versus have to write custom code.

Pros: Depending on your use cases such as delivery driver tracking application, this can provide a good compromise on battery usage and accuracy.

Cons: You will have to write algorithms to constantly adjust the location service settings to meet the users movement patterns. This may also involve cycling the location services on and off to maximize battery life.

A few comments on testing your use cases. In the GPSTester tool there are a number of settings you can use to adjust how the device will receive location information.

You have full control over which providers are being used whether it’s GPS, Network or Critera.

Location provider indicators on the main screen will show which providers are being used. You can also see which provider is providing the best accuracy as determined by comparing available providers.

There is a list of available providers available on the GPSTester tool as well as table row showing what the device considers to be providing the best accuracy.

References

Android GPS Testing Tool

GPSTest Tool Github Repo

How accurate is Android GPS Part 1 – Understanding location data

How accurate is Android GPS Part 2 – Consuming real-time locations

Costs and geography aside, could you turn off your WiFi completely and generally have a decent connection at your home? At work? At the airport? At the supermarket?

It’s interesting to note that some really big company’s think that internet on mobile devices isn’t as great as it could be. Have you heard of Amazon Silk or Opera Turbo where they incorporate data compression to try and speed things up to overcome limitations of mobile browsers? I’ve even heard that Google is now working on something similar. Are these just attempts to work around current limitations of cellular 3G and 4G? Most likely, yes.

I’d give my general usage internet connection in my home area a 7 rating on a scale from 0 (no internet) to 10 (always incredible). By home area I mean the geographic location where I spend 98% of my time between home, work, shopping and visiting friends. When not developing apps on my phone, it’s primarily used for email, social media and occasional web browsing. Tethering is a different story. For tethering when I travel I’d give it a 4 rating overall. Tethering uses the bandwidth a lot more strenuously than my home area use case. And because of that it exposes any weaknesses in the internet connectivity a lot sooner and makes them much more noticeable. The typical situation I want to avoid when I travel is having to pay for a hotel internet connection. Besides, hotel internet connections in the U.S. are almost always awful in terms of download speeds, especially if you are in a hotel during a large conference.

If you are wondering if there’s anything you can do about bad cellular internet the answer is YES. First, call your provider and explain the situation in as much detail as possible. Simply calling up and saying “my internet connection is terrible” isn’t going to help. But telling them the geographic location, time of day, frequency of the problem, etc. will help immensely. And, you can always follow-up if the problem persists. Sometimes the problems are equipment malfunctions, sometimes cell towers need to be upgraded. Other times it could be the terrain, buildings and heavy foliage. All of these can degrade signals. As you can see there are many reasons why your smartphone internet could be less than desirable.

If you consistently see internet outages and other major problems and you can’t get a solid answer from your provider then you can also contact the FCC or file a public comment.

References:

FCC Online Complaint form

FCC 3G and 4G Wireless

Amazon Silk

Opera Turbo

If you aren’t familiar with them, a Base64 image is a picture file, such as a PNG, whose binary content has been translated into an ASCII String. And, once you have that string then copy-and-paste into your JavaScript code. Here’s an example of what that looks like:

<html>
<body onload="onload()">
	<img id="test"/>
	<script type="text/javascript">
		var html5BadgeBase64 = "iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAYAAACqaXH…";
		function onload(){
			var image = document.getElementById("test");
			image.src = "data:image/png;base64," + html5BadgeBase64;
		}
	</script>
</body>
</html>

There are other ways of doing this that I’m not covering in this post such as using server-side code to convert images on the fly, passing Base64 strings in URLs, etc.

The most commonly cited advantage is that including a Base64 string in your JavaScript code will save you one round-trip HTTP request. There is absolutely no argument on this subject. The real questions in my mind are: what are the optimal number and size for Base64 images? And, is there a way to quantify how much if any they help with performance?

Size? Base64 image strings will always be larger than their native counterparts. Take the following example using a copy of the relatively small HTML5 logo and a decent sized screenshot. As you can see the text equivalent is 33% and 31% greater, respectively.

Html5.png  = 1.27KB (64×64 pixels)
Html5base64.txt = 1.69KB (1738 characters)
% Difference =  +33%

Screenshot.png = 19KB (503×386 pixels 24bit)
ScreenshotBase64.txt = 24.9KB (25584 characters)
% Difference = +31%

In comparison, when working with <img> tags you’ll be working with an ID that points to the actual image file stored in memory.

Convenience? As you can see, the length of your base64 strings can get quite long. The simple HTML5 logo in the previous example becomes a 1738 character long string and that’s only 1.69KBs worth of image.

Can you imagine having a dozen of images similar in size to the 19KB Screenshot example? That would create over 300,000 ASCII characters. Let’s put that into the perspective of a Word document. Using 1” margins all the way around, this would create a document approximately seven and a quarter pages long!

I assert that Base64 is best for static images, ones that don’t change much at all over time. The bigger the image the more time consuming it can become convert it, copy-and-paste it into your code and then test it. Any time you make a change to the image you’ll have to repeat the same steps. If you accidentally inject a typo into a Base64 string you have to reconvert the image. That’s simply the best approach from a productivity perspective.

In comparison when using a regular old PNG file, you create the new version, copy it out on the web server, flush your browser cache, run a quick test with no need to change any code and bang you’re ready to go have a cup of coffee.

Caching? It depends on your header caching settings, browser settings and web server settings. I’ll just say that typically base64 images will be cached either in your main HTML file or in a separate JavaScript library.

Bandwidth? Using base64 images will increase the amount of bandwidth used by your website. Compare the size of your HTML file with Base64 images to the size of the same file simply using <img> tags. You can do some basic math if you add up the size of a particular page and multiple it by the number of visits. Better to err on the side of caution, because there really isn’t a good way to tell which images and JavaScript files are getting catched in your visitors browsers and for how often. Here’s an example where you have a 30GB bandwidth limit per month, and simply converted all of your PNG images to Base64 could very easily push you over the limit:

100,000 page hits/ month (main.html) x 256KB = 25.6 GB (incls. 75KB of standard PNG images)

100,000 page hits/month (main.html) x 293.5KB =  29.4 GB (incls. 97.5KB Base64 images)

Also, some providers give you decent tools that you can use to experiment with Base64 images versus regular images and test that against your bandwidth consumption.

Latency? This variable doesn’t really apply directly to Base64 images. There are many factors that determine latency that I’m not going to discuss here. There are some more advanced networking tools that let you figure out average latency on your own web servers. Every request will be unique based on network speed, the number of hops between the client and the web server, how the HTTP request was routed over the internet, TCP traffic over the various hops, load on the web server, etc.

A few quick performance tests.

What would a Base64 blog post be without a few tests? I devised four simple tests. One in which I referenced a JavaScript file containing Base64 images. One which contained five <img> tags and then I re-ran the tests again to view the cached performance.

These tests were performed on a Chrome Browser over a CenturyLink DSL with a download speed of 9.23MB/sec and an upload speed of 0.68MB/sec. Several tracert(s) of TCP requests from my machine to the web server showed more than 30 hops with no significant delays or reroutes. The web server is a hosted machine.

Test 1 – JavaScript file with Base64 images.This test consists of an uncached basic HTML file that references a 125KB JavaScript library containing five base64 images.

Time to load 1.9KB HTML file: 455ms

Time to load 125KB JavaScript file: 1.14s

Total load time: 1.64s

Test 2 – Cached JavaScript file with Base64 images. This test consists of reloading Test 1 in the browser

Time to load cached HTML file: 293ms

Time to load cached JavaScript file: 132ms

Total load time: 460ms

Test 3 – using <img> tags to request PNG images. This test consists of an uncached HTML file that contains five <img> tags pointing to five remotely hosted 20KB PNG files.

Time to load 1KB HTML file: 304ms:

Time to load five images: 776 ms

Total load time: 1.08s

Test 4 – cached html file using <img> tags to request PNG images. This consists of reloading Test 3 in the browser

Time to load cached HTML file: 281ms

Time to load five cached images: 16ms

Total load time: 297ms

Conclusions

It’s not 100.0000% true that multiple HTTP requests results in slower application performance in comparison to embedding Base64 images. In fact, I’ve seen anecdotal evidence of this before on production apps, so it was fun to do a some quick testing even if my tests were not completely conclusive beyond a doubt.

My goal was to spark conversation and brainstorm on ideas. I know some of you will say that thousands of tests need to be run an statistically analyzed. My argument is that these tests represented actual results that I could see with my own eyes rather than being lumped into some average or medium statistic.

Note that I’m just posting a snapshot of the tests I ran. I didn’t have enough time to draw up a significant battery of tests to cover as many contingencies as possible. However, the test numbers I’ve posted were fairly consistent in the favor of the multiple PNG requests loading faster than a single .js file containing five Base64 images. Obviously more significant testing is needed to sort out other real-world variables, such as image file sizes versus application size and under a variety of conditions and different browsers.

Resources

JavaScript library with five Base64 images

HTML file that reference JavaScript library of five Base64 images

HTML file with five <img> tags

[Edited 2/26/13: fixed a few typos]