SVG on iPhone !!

We at Kontera are beginning to develop an iPhone version of our application.

Since our current version is based on flash, it obviously needs a redesign to support this exciting platform. During investigation I decided to try out SVG. I would like to share this interesting experience with you all.

SVG has quite a few advantages as a graphic engine. Here are some:

1. SVG is programmable quite easily. I can take an SVG file that I know has an element called 'buttonX', and place an onclick callback that closes the app. I don't really care where this button is situated or how it looks like.

2. Our creative department can handle SVG quite well. This means that I can receive creative assets and incorporate them right into the new code.

The alternative - pure HTML - would have a hard time achieving these advantages. I am also guessing that since SVG is better defined than HTML, the amount of cross browser issues will be smaller (when going past iphone).

However, there were some challenging issues:

1. Cross domain - since our SVG is not from the domain of the site owner (we are more like a library or plugin) - when we tried to access the SVG contents from our javascript we received cross domain issues.

2. <embed> and transparency - there is a bug in Safari (and Chrome, and probably other WebKit based browsers) that when you <embed> an SVG file, the stage can not be transparent. This was somewhat of a disappointment to our design team. This bug does not happen in Firefox.

Our initial workaround was to place the SVG in an iframe (which has a source in our domain). We were figuring we would solve the cross-iframe issues using postmessage, but this is only takes you so far. For instance, if you want to open a new window from the iframe during a user click without having the popup blocker block you, this can be a problem. We also had JSON serialization issues, and in short the iframe was starting to become a can of worms.

On further exploration, we noticed that if you create the SVG dynamically (using document.createElementNS, element.setAttribute) instead of embedding a static XML file, both problems disappear. The cross domain issues are gone, and also the stage can be transparent.

Obvious asking our creative department to work this way was not going to work. Instead, we wrote a cute little tool in ruby that reads the XML file, and generates the appropriate JavaScript code to re-create this XML structure at runtime. The generated code looks something like:

function createLayer(_parent) {

var svgns='http://www.w3.org/2000/svg';

var node0=document.createElementNS(svgns, 'svg');

node0.setAttribute('xmlns:xlink','http://www.w3.org/1999/xlink');

node0.setAttribute('ontouchmove','event.preventDefault()');

node0.setAttribute('height','178');

node0.setAttribute('xmlns','http://www.w3.org/2000/svg');

node0.setAttribute('width','286');

var node1=document.createElementNS(svgns, 'g');

node1.setAttribute('id','main_group');

var node2=document.createElementNS(svgns, 'title');

node2.appendChild(document.createTextNode('Layer 1'));

node1.appendChild(node2);

.....

_parent.append(node0);

return node0;

}

This did place some limitations on the SVG. We have some problems working with <defs> , but the easiest workaround was to remove them from the SVG and move on. So far, all is well. Hoping to release soon so you can all see it on your iphones ;-)

Noam

Why does Safari/Flash always crash?

On a personal note, I have started a new job at Kontera, involving much more web-related development than I have ever done. I will continue posting experiences from this job I find interesting and worthy of sharing.

Safari users may have noticed often crashes when visiting sites that contain Flash. I certainly have. This is not related to a specific OS - it happens both on Windows and on Mac (I personally use a Mac). I noticed this when developing a web component that includes also some Flash, and easily reproduced quite frequent crashes on Safari 4.0.4 and Flash 2010.

Interestingly enough, Chrome which is based on the same engine does not have these crashes.

From examining the stack of Safari (and also knowing the behavior of my flash app ;-), I think that the crash happens when Safari is trying to do something while Flash is calling JavaScript code via ExternalInterface.call(). Reducing the number of calls from Flash to JavaScript and reducing the time spent in the JavaScript calls causes the probability of a crash to be reduced dramatically. The simplest technique is to modify the JavaScript callback to wrap it in a setTimeout(...) as such:

function foo(param1, param2) { .....}

should be replaced with:

function foo(param1, param2, afterTimeout) {

if (!afterTimeout) {

setTimeout(function() { foo(param1, param2, true) }, 20);

}

.... // the original code

}

The flash code does not need to be modified at all.

Happy hacking,

Noam