Guy Royse

Work. Life. Code. Game. Lather. Rinse. Repeat.

Disconnected HTML5, JavaScript, the iPhone & I

I’ve been working on a simple test case for a disconnected HTML5 application for the iPhone/iTouch off and on for the past couple of weeks. It’s a points calculator for a popular weight loss program who shall remain anonymous. Anyhow, I thought this would be a handy tool for my wife and I and it would be a nice and simple application to test a disconnected HTML5 application from the iPhone.

So, I present to you Puntos. Full source code is available on github but here’s how I wrote it.

Step #1: Write an HTML5 and JavaScript Application

The application I developed is not remarkable. In fact, it is a simple math problem. Peruse the source if you want details on how it works. The important part is that it has the following files:


Just create the files for your application (or copy mine) and make it do what it does. I’m assuming you know how to program in JavaScript and HTML.

Step #2: Make it iPhone Friendly

If you want it to be a cool iPhone HTML5 application, you have to provide an icon from the iPhone desktop. You can do this by creating a file called iphone-icon.png and placing it in the root of you project. This little file is the favicon.ico of the Apple Mobile world. It is a 45 pixel by 45 pixel PNG that your iPhone or iTouch will use if you decided to save a link to a website on your desktop.

So, just create this file with your favorite image editing program (I used Gimp) and save it with the other files.

Step #3: Add the Caching Magic

Here’s where the fun comes in. We can finally make the application disconnected. The magic lies in an attribute on the html tag pointing the browser to a cache.manifest file. This file then tells the browser which files to cache and serve up when there isn’t a network connection.

So, simply add something like this to your HTML file.

<html manifest="cache.manifest">

This tells your browser to load up the file in the manifest attribute. The filename can be anything but I would recommend having it end in .manifest as this makes setting up the content type later much easier.

The cache.manifest is simplicity itself:


It simple contains the words CACHE MANIFEST at the top and lists all the files needed by the application.

You might note that I did not include the index.html and you would be correct. This is because the browser will assume that the file you loaded in the initial request is part of the cache.manifest. No need to specify. However, if you have several HTML files, you will need to specify them all in your cache.manifest as there is no way to know which file you entered the application from.

Step #4: Serving Up text/cache-manifest

It turns out that the cache.manifest file must be served up with a content type of text/cache-manifest. It also turns out that most web servers aren’t configured by default to do this since this is all bleeding edge and stuff.

So, you need to add it yourself. If you are using an apache server you can add the content type to your .htaccess file. Add the following line and you should be golden.

AddType text/cache-manifest .manifest

Step #5: Access the Application from Your iPhone & Troubleshoot

Your application should now work. So go access it. Then turn on Airplane Mode and refresh the application. I should reload gorgeously. If it doesn’t, go back and troubleshoot. But you knew that already.

One caveat though. I had a hell of a time trying to get the application to work disconnected until I rebooted my iTouch (I don’t have an iPhone because I’m lame). So, if everything looks like it should work but isn’t then you might want to try turning off your iPhone by pressing and holding the power button until it shuts down completely.

So, those are the steps I followed to get my first disconnected iPhone application working with HTML5, JavaScript, and some cache.manifest magic. Now go out and write me a game or something.

Also, for more information on HTML5 and disconnected applications check out this fine website.

— February 23, 2011

Fun With Windows

OK. Just spent 3 hours of my life that I will never get back trying to troubleshoot and issue with Windows 7 and USB devices that I was having. Figured it out so I thought I would share the problem and solution.

The Problem

Whenever I would plug a new USB device in, it would not be detected by Windows. Instead I would get a driver not found error and no amount of troubleshooting on Windows’ part would help. This affected a new keyboard and mouse I purchased (Logitech MK520) and an old headset that I had lying around. It was also affecting my iPod but I didn’t realize that until after the fact.

In the case of my mouse and keyboard I would see in Device Manager a device names USB Receiver with an annoyed looking yellow icon resting upon it. No amount of messing with the icon helped.

All very frustrating because the hardware would detect the new keyboard and mouse. When I booted the system and accessed the BIOS menu the keyboard worked. The mouse was listed as detected. Everything seemed fine.


After much searching of the web in frustration. (Did I mention it was frustrating) I finally found some people actually having the same problem. No solutions, mind you, but the same problem. I determined from the gist of all this posts that it was something to do with the USB drivers. Not the mouse drivers or the keyboard drivers or the headset drivers but the core USB drivers from Windows 7.

So I removed them all in Device Manager and rebooted so they could be reinstalled. This worked – briefly. When the drivers were gone the mouse started working. But Windows quickly fixed that and reinstalled the drivers and I was back to a non-functioning mouse and keyboard.

The Solution

Finally I came across some forum posts suggesting that usb.inf and usb.pnf should exist in Windows\inf and if they didn’t that would cause this issue. So, I Googled to find the files and copied them in. Then I removed the annoyed USB Receiver driver and detected new devices.

Voila! It works.

Hope this helps someone else.

— February 03, 2011

The Rules of Code Club

I hereby establish the rules of Code Club.

  1. The first rule of Code Club is, you always write tests first at Code Club.
  2. The second rule of Code Club is, you ALWAYS WRITE TESTS FIRST at Code Club.
  3. If someone says stop, gets stuck, gets bored, the pair switches.
  4. Two coders to a keyboard.
  5. One keyboard at a time.
  6. No mice, no copy and paste.
  7. Coding will go on as long as is has to.
  8. If this is your first time at Code Club, you have to code

Carry on.

— September 14, 2010

Let Him Who Hath Wisdom Reckon the Number of the Beast

My latest project is something that I have written three times: The Antichrist Detector.

The Antichrist Detector was conceived about 10 years ago when I stumbled upon the entertaining idea that Bill Gates was the Antichrist. The idea was simple and ludicrous. If you take the ASCII values of the name Bill Gates (uppercase only please as any good numerologist will tell you) they add up the 663.

“But wait!”, you’re saying, “That doesn’t add up to 666?”

Correct. But Bill Gates full name is William Henry Gates III. So, Bill Gates plus three does equal 666. It’s so obvious. How could you have not seen it?

Anyhow, this whole idea gave me a slightly twisted thought. You could automate this. Write a simple program and feed it the phone book and out pops a list of potential Antichrist. Not having a digitized phonebook handy I had another more practical (in as much as any of this is practical) idea. Why don’t I put up a website any let people enter their own names.

So, in 2000, I did. It was very successful and a lot of fun. It didn’t do much but it generated a healthy amount of traffic and a lot of logs. In fact, reading the logs was probably the best part about it. The emails I got, however, were also very interesting. The vast majority of them were from crackpots who thought I was serious. This greatly surprised but in hindsight, it probably shouldn’t have.

My initial attempt was written in C++ and invoked via CGI. When I started learning C# and .NET I decided to replatform it. So, version 2.0 was born. Later, I moved to new hosting and no longer had .NET so I replatformed it again and used it as an excuse to learn jQuery and PHP. 3.0 was born. In each incarnation I added new features. 2.0 gained statistics. 3.0 gained an RSS feed.

So, I am now staring down the barrel of The Antichrist Detector 4.0. This time, I am using it to learn Ruby, Google Appengine, and more advanced JavaScript techniques. I plan to also add features to this one as well. Most notably, you will now be able to issue Antichrist Detections via Twitter!

Obviously, the Antichrist Detector has turned into a bit of a “Hello World” application for me that I use to learn new technology. But, it’s also fun and I hope that you can enjoy it as well.

I’ll post the link to the new version once it is somewhat available.

— February 23, 2010

Site Update

When I initially launched I vacillated about the content I was creating and writing about. Was this to be a blog about writing and games or writing, games, and coding?

Initially I decided to have it just be about writing and games. I wanted to focus on my creative endeavors and frankly, figured most people wouldn’t care too much about the programming stuff. But, as it turns out, a lot of my creative activity is focused around code and programming. This sort of leaked in a posting I made a couple of months back updating everyone on the status of Corporate Raiders.

So, I’ve decided to cave to my urges and put my code projects on here as well. But, not only will I be including some of my coding project but I will also be sharing some of my thoughts on technology and software engineering. So, if you’re a programmer or other geeky tech person, hopefully you’ll find the additional content enjoyable. And if your not, I won’t be offended if you skip over my more technical posts.

— February 23, 2010