Finally, I address iPad comics

I wasn't all that concerned about them actually, but my editor asked for an article - Shannon Gallant, John Gallagher, Matt Wuerker and Ann Telnaes ventured opinions for me - In D.C. and Industrywide, Will the iPad Save Comics and Kill Print? by Mike Rhode on Apr. 6, 2010.

Said editor, Jon Fischer, drastically cleaned up this article too and made it much more readable.

PR: KAL returns from Public diplomacy trip to Middle East and releases iPhone App

We noticed he was gone, and now KAL tells us he's back -

Friends and colleagues

I wanted to share with you some recent exciting news. 

I have just returned from a 12 day visit to Amman, Jordan and Beirut, Lebanon as part of a strategic speaker initiative sponsored by the US Embassies in the region. During my visit I addressed a wide variety of groups including University students on six campuses, cartoonists, animators, journalists, and civic leaders. Our discussions centered on  the opportunities and limitations of political cartoons in promoting freedom of expression. There was great interest in the region in the program particularly in light of the controversial Danish cartoons depicting the Prophet Mohammed.

My visit garnered a good bit of media exposure. There were numerous press and television interviews. Links to some of the news stories along with photos and observations from the trip will be available on my blog (www.kaltoons.com/wordpress) in the days ahead.

A also would like to announce the launch of the first KAL iPhone App.  Created in conjunction with RevelMob, the iKal-Book is just $.99 and available at the iTunes store. Please see our press release below.

Best

Kal

Kevin Kallaugher
kal@kaltoons.com
www.Kaltoons.com

KALTOONS GET THE IPHONE TREATMENT

Kevin KAL Kallaugher, the editorial cartoonist for The Economist magazine, launches his first iPhone app  

Baltimore/London: FOR IMMEDIATE RELEASE

If you love fun and witty political cartoons of the highest quality, you will love the new iPhone application by Kevin KAL Kallaugher, the world-renowned editorial cartoonist for The Economist magazine.

Designed for the iPhone, this new application is an impressive collection of KAL's award winning political cartoons, hand-picked by the artist himself.  Browse through 150+ examples of KAL's work, including 29 color covers and illustrations from The Economist magazine. Store them on your iPhone, upload to Facebook or share with friends. 

Kal uses his poison pen to comment on Presidential elections, the War on Terror, American politics and international affairs. 

"Speaking about the iKal Book app, Kevin KAL Kallaugher said:

"iKal Book is more than an assembly of individual cartoons... together, the over 150 images read like a history lesson of recent world events."

"Among the award winning art found in the iKal-book are all the cartoons from my print collection "KAL Draws Criticism"($20.00) but at a fraction of the cost ($.99)"

Roman Grigorjev, Founder and Managing Partner of Revel Mob, comments:

"Cartoons are graphically engaging, instantaneous and fun to share with friends ... making them perfect for mobile devices like smartphones and iPhone in particular"

Revel Mob and KAL are also looking into developing more interactive and engaging applications for KAL in the near future and are welcoming any ideas and contributions as to what you would like to see in the next KAL iPhone application. Make your ideas count - post them on Revel Mob's Facebook Fan page: http://www.facebook.com/pages/RevelMob/296197102796?ref=ts

The iKal Book app is available for $0.99 from the App Store on iPhone and iPod Touch.

Comic Riffs interviews caricaturist Richmond

A new Congressional 'bobblehead' app for your iPhone? MAD artist says Apple won't bite
By Michael Cavna
Washington Post Comic Riffs blog November 12, 2009

Gmail for mobile HTML5 Series - Part 3: Using AppCache to Launch Offline

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. In the last two posts, we covered everything you need to know in order to make effective use of AppCache. This week, we'll be having some fun and trying to disect the inner workings of AppCache by looking at the database it uses to store its resources. Before we start though, I'd like to point out one tip that can be useful while debugging AppCache related problems on the iPhone: how to clear your Application Cache.

There are two steps involved here:

1. Go to Settings->Safari and tap "Clear Cache".
2. Open Safari and terminate it by holding down the home screen button for 10 seconds.

The first step is pretty intuative. The problem is that the browser does not immediately notice that the cache has been cleared, and so needs to be restarted.

Now onto the fun stuff! There is no way to inspect the application cache from within the browser. However, if you are using the iPhone Simulator to develop your webapp, you can find all of the Application Cache resources and metadata in a SQLite3 database located at:

~/Library/Application Support/iPhone Simulator/User/Library/Caches/com.apple.WebAppCache/ApplicationCache.db

Let's have a look at what is contained within this database.

$ sqlite3 ApplicationCache.db
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .mode column
sqlite> .headers on
sqlite> .tables
CacheEntries        CacheResourceData   CacheWhitelistURLs  FallbackURLs      
CacheGroups         CacheResources      Caches              SchemaVersion     
sqlite> select * from CacheGroups;
id          manifestHostHash  manifestURL                                        newestCache
----------  ----------------  -------------------------------------------------  -----------
1           906983082         http://mail.google.com/mail/s/?v=ma&name=sm        1 

The CacheGroups table holds an overview of what manifests exist. A manifest is identified by its URL and the manifestHostHash is used to track when the contents of a manifest changes.

sqlite> select * from Caches;
id          cacheGroup
----------  ----------
1           1      

Here you can see that I have only one cache in my database. If the Application Cache was in the middle of updating the cache, there would be a second entry listed here for the cache currently being downloaded.

sqlite> select * from CacheEntries limit 1;
cache       type        resource  
----------  ----------  ----------
1           2           1       

The CacheEntries table holds a one-to-many relationship between a cache and resources within it.

sqlite> select * from CacheResources where id=1;
id          url                                          statusCode  responseURL            
----------  -------------------------------------------  ----------  -----------------------
1           http://mail.google.com/mail/s/?v=ma&name=sm  200         http://mail.google.c...

mimeType             textEncodingName  headers data
-------------------  ----------------  --------------
text/cache-manifest  utf-8             


sqlite> .schema CacheResourceData
CREATE TABLE CacheResourceData (id INTEGER PRIMARY KEY AUTOINCREMENT, data BLOB);

This shows what information is stored for each resources listed in a manifest. As you can see the CacheResources and CacheResourceData tables contain everything that is needed in order to simulate a network response to a request for a resource. Let's see exactly what is stored in the database for Mobile Gmail's database.

sqlite> select type,url,mimeType,statusCode from CacheEntries,CacheResources where resource=id;
type        url                                             mimeType             statusCode
----------  ----------------------------------------------  -------------------  ----------
2           http://mail.google.com/mail/s/?v=ma&name=sm     text/cache-manifest  200       
4           http://mail.google.com/mail/images/xls.gif      image/gif            200       
4           http://mail.google.com/mail/images/pdf.gif      image/gif            200       
4           http://mail.google.com/mail/images/ppt.gif      image/gif            200       
4           http://mail.google.com/mail/images/sound.gif    image/gif            200          
4           http://mail.google.com/mail/images/doc.gif      image/gif            200       
4           http://mail.google.com/mail/images/graphic.gif  image/gif            200       
1           http://mail.google.com/mail/s                   text/html            200       
4           http://mail.google.com/mail/images/generic.gif  image/gif            200       
4           http://mail.google.com/mail/images/zip.gif      image/gif            200       
4           http://mail.google.com/mail/images/html2.gif    image/gif            200       
4           http://mail.google.com/mail/images/txt.gif      image/gif            200   

From this list, it is fairly easy to see what the meaning of the type field is. A host page has type 1, a manifest has type 2, and a normal resource has type 4. In order to know whether or not to load a page using AppCache, the browser checks this list to see if there is a URL of type 1 within it.

This concudes our three-part series on HTML5's Application Cache. Stay tuned for the next post where we will explore other areas of how we use HTML5 in Gmail. And just another reminder that we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, looking forward to meeting you in person.

References
The HTML5 working draft: http://dev.w3.org/html5/spec/Overview.html

Apple's MobileSafari documentation: http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html

Webkit Source Code: http://trac.webkit.org/browser/trunk/WebCore/loader/appcache

By Andrew Grieve, Software Engineer, Google Mobile

Gmail for mobile HTML5 Series - Part 2: Using AppCache to Launch Offline

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. Last week we explained how to go about creating a simple manifest file, and how the browser uses it to load a page. This week we will go a bit more in-depth about the subject.

One of the problems we faced in creating our manifest file, was how to update it when our javascript changes. At first we thought that we might have to change one of the URLs each time we wanted to push an update. As it turns out, the URLs listed in the manifest do not have to change at all in order cause an update, changing the whitespace or a comment will also do the trick. For Gmail, we a comment in the manifest that contains a hash of all of the resources listed in the manifest. That way, if any of the resources change, the manifest will also change and cause a background update to occur for all of our clients. An example of what this looks like is shown below.

CACHE MANIFEST
# version: 3f1b9s84
jsfile1.js
... other URLs ...

There are other types of entries that are possible in a manifest, but that the iPhone does not currently support. According to the spec, there are 3 categories of URLs that can be listed in a manifest:

• Cache (what we have dealt with so far),
• Fallback,
• Network

Although fallback and network URLs are not yet supported on the iPhone, they are mostly supported in the Webkit Nightly builds. Network URLs are those that are never cached by AppCache, and that are allowed to be satisfied by the network. Fallback URLs are those that are attempted, and then satisfied by by AppCache only if the network attempt fails. Both Network and Fallback URLs are prefix matches. An example of what this looks like is shown below.

CACHE MANIFEST
jsfile1.js

NETWORK:
/images/

FALLBACK:
/thumbnails/ images/missing_thumb.jpg

This manifest tells the browser that GET requests to any URL under /images/ are allowed to hit the server. Without this being listed, GET requests for it would fail immediately. This manifest also tells the browser that URLs under /thumbnails/ are allowed to hit the server, but if they fail, satisfy the request by server missing_thumb.jpg, which will be stored in AppCache.

So far all of the features we've covered about AppCache have not needed any Javascript to use them. This is undoubtedly by design, as it makes it extremely easy to use. However, it is always useful to know what advanced functionality can be unlocked using Javascript. The Application Cache is exposed as a singleton through window.applicationCache. It provides events that can be used to indicate when updates are happening and a status property that can be one of:

• 0 - UNCACHED
• 1 - IDLE
• 2 - CHECKING
• 3 - DOWNLOADING
• 4 - UPDATEREADY

In Gmail, we use the status property to determine if the page was loaded out of AppCache, or if it was loaded from the network. In order to do this, we have the following code run at the very start of page load:

if (window.applicationCache.status == 0) {
  // Page was loaded from the Network.
} else {
  // Page was loaded from AppCache
}

There are also a couple of functions available, swapCache and updateCache, which we'll not go into detail on since we have not found any use for them yet.

Stay tuned for the next post where we will explore how to use the sqlite3 command-line tool to inspect the iPhone Simulator's AppCache database. And just another reminder that we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, looking forward to meeting you in person.

References

The HTML5 working draft:
http://dev.w3.org/html5/spec/Overview.html

WHATWG working draft:
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#appcache

Apple's MobileSafari documentation:
http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html

Webkit Source Code:
http://trac.webkit.org/browser/trunk/WebCore/loader/appcache


By Andrew Grieve, Software Engineer, Google Mobile

Gmail for mobile HTML5 Series: Using AppCache to Launch Offline - Part 1

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and would like to share more of our learnings in a brief series of follow up blog posts.

The HTML5 draft adds a lot of exciting functionality to browsers. Perhaps the most exciting is adding a way for websites to be launched offline. For devices that have a high bandwidth and highly available connection, offline functionality might not be so important. For web applications running on mobile devices however, being able to launch offline can dramatically improve the web application experience.
AppCache support on the iPhone is still under development, but as of firmware 2.2.1, it is usable.

To make use of AppCache, a webpage must provide a "manifest" to the browser that lists all of the URLs that it intends to use. Creating an HTML5 manifest file is extremely simple, as shown by the following example.

CACHE MANIFEST
jsfile1.js
jsfile2.js
styles.css
/images/image1.png
/images/image2.png

It is important to note that it is not necessary to list the URL of the main webpage in the manifest because it is treated as an implicit entry. However, if you have more than one top level URL that you want to be available offline, they must all be listed in the manifest. In addition, they must all set a manifest attribute on the HTML tag that points to the manifest. For example, if the manifest URL was "/sitemanifest", then each page in the site would have an HTML tag that looked like this:

<html manifest="/sitemanifest">

Finally, the manifest must be served using the content type "text/cache-manifest". And that's it!

So now that you know how to create a manifest for your site, it's a good idea to know what's going on during page load. When the page is loaded for the first time, it will load as if there is no application cache associated with it. Once it has finished loading, the browser will fetch the manifest and all resources listed in it that have not already been fetched during page load. From this point on, any GET request that your page makes that is not listed in the manifest will fail, and any GET request that is listed in it will not hit the network, but will be satisfied by the cache. Once your page is loaded into AppCache, the next time the user loads the site, all of the resources will be served out of the cache. The only GET request done on page load will be for the manifest file, in order to see if it has changed. If it has changed, then all of the resources in it are fetched in the background and will be used the next time the user refreshes the page.

Stay tuned for the next post where we will share more about what we know about AppCache and how we use it on the Gmail team. Also, we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, and we look forward to meeting you in person.

References

The HTML5 working draft:
http://dev.w3.org/html5/spec/Overview.html

Apple's MobileSafari documentation: http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html

Webkit Source Code:
http://trac.webkit.org/browser/trunk/WebCore/loader/appcache

By Andrew Grieve, Software Engineer, Google Mobile