Noam Lampert's blog

SVG on iPhone !!

2010-11-10T11:35:00.001-08:00

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?

2010-02-06T22:07:00.000-08:00

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

Outlook New Explorer Hook

2009-09-21T07:13:00.000-07:00

When developing our add-in, we tried to add a callback on the creation of a new Explorer. Something like:

Application.Explorers.NewExplorer += new ExplorersEvents_NewExplorerEventHandler(Explorers_NewExplorer);

Unfortunatly, after a new explorer or two were created, our callback was no longer called by outlook.

What made this more consistent was:

Application.Explorers.NewExplorer += new ExplorersEvents_NewExplorerEventHandler(Explorers_NewExplorer);

GC.Collect();

Now, the NewExplorer callback was never called !!

The workaround: Create a global reference to the Explorers object, such as

Explorers explorers;

void Startup()

{

explorers = Application.Explorers;

explorers.NewExplorer += new ExplorersEvents_NewExplorerEventHandler(Explorers_NewExplorer);

....

}

It seems that without this reference, the Explorers object, together with my callback, were all collected by the GC.

This would be a good opportunity to thank my co-worker Arina for figuring this out.

Outlook Add-Ins can be tricky

2009-09-10T06:52:00.000-07:00

Lately I have been doing some development of an outlook add-in, and I learned that this can be challenging. I would like to share on this blog some of my experiences during this development.

So here is one of the more "fun" experiences:

As you probably know, it is possible in outlook to open more than one explorer window (the one with list of mail items, or the calendar, etc).

Another feature of outlook is that when you exit while there are unsent items in the outbox, you get a message box notifying you, and asking if you want to exit without sending, or send and then exit.

I had a bug: When the add-in is installed, and the user exits outlook, and there are unsent items in the outbox, the user gets asked if he really wants to exit not once, but several times, as many as the number of explorers that were ever opened in the session.

This is an annoying bug. It also doesn't seem connectd to what my add-in was doing, and this was weird. I scrambled to figure out the source of the bug by cutting out code from the add-in until I came to a simple addin reproducing the bug and containing these lines only:

private void SidebarAddIn_Startup(object sender, System.EventArgs e)

{

foreach (Explorer explorer in Application.Explorers)

{

}

A puzzlement indeed.

After a lot of pondering I came to the conclusion that the foreach() generates Explorer objects that are COM wrappers, and contain reference to the underlying Explorer objects. This keeps COM Explorer objects roaming around, and is probably the cause of this bug. And a simple workaround:

private void SidebarAddIn_Startup(object sender, System.EventArgs e)

{

foreach (Explorer explorer in Application.Explorers)

{

}

GC.Collect();

}

and the bug is solved.

Of course in my add-in, this did not actually work. It turns out there are more operations that leak managed Explorer objects. One of them is adding a CustomTaskPane to an explorer and removing it.

Good luck to all Outlook add-in developers....

Noam

Stub Generator project

2008-06-15T07:00:00.000-07:00

I just published a stub generator utility on CodePlex : http://www.codeplex.com/StubGenerator

The stub generator reads a DLL using Cecil and generates C# stubs for the DLL.

We have tested it on some complex DLLs, and although it is not bug free it pretty much works.

If someone wants to write a cool U/I this would be greatly appreciated.

Syndication - RSS 2.0 working !

2008-06-11T04:29:00.000-07:00

The RSS 2.0 syndication sample in MSDN now works in Mono's latest bits.
I believe it is now possible to write a WCF service that consumes and exposes RSS feeds.

Give it a try and let me know how things work out.

Syndication - RSS 2.0 (almost) working !

2008-06-04T04:25:00.000-07:00

I have been working in the past few days on getting the basic RSS feed sample from MSDN to work in Mono.

The sample is at the bottom of this page: http://msdn.microsoft.com/en-us/library/bb412174.aspx

I haven't committed all the fixes yet, but the status is that a valid RSS feed is generated. The part that consumes the RSS feed is not working yet.

There is also an additional small bug discovered that I did not fix yet in the following code:
Uri baseAddress = new Uri("http://localhost:8000/BlogService");
WebServiceHost svcHost = new WebServiceHost(typeof(Service), baseAddress);
svcHost.open();

The host does not listen on the base address. The workaround is to add an additional Endpoint before penning the host, like this:
svcHost.AddServiceEndpoint (typeof (IService), new WebHttpBinding (), baseAddress);

I will update when the entire sample is working.

Noam

Serialization of byte[]

2008-06-04T04:23:00.000-07:00

Across .NET now also works.

Before it was serialized differently than .NET, so Mono<->Mono worked but .NET<->Mono did not.

WCF work environment

2008-05-29T09:49:00.001-07:00

I wanted to share the work environment in which I debug Mono's WCF.

The idea is to run on .NET using the .NET tools and runtime, but taking specific libraries from Mono. The main advantage of this environment is the usage of the visual studio debugger greatly increasing productivity.

Step 1: Skip public key validation of (some) .NET assemblies
> sn -Vr System.ServiceModel,B77A5C561934E089
> sn -Vr System.Runtime.Serialization,B77A5C561934E089

Step 2: Place Mono assemblies in the GAC
The visual studio project files of System.ServiceModel and System.Runtime.Serialization have post build steps that do this. The comitted versions are remarked, so you want to remove the remark.

At this point you want to build the assemblies in VS2008 in order to place them in the GAC.

Step 3: Run your app
You can place breakpoints in Visual Studio. Very productive environment.

Step 4: Revert back to .NET
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe" /i "c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.ServiceModel.dll"
> "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe" /i "c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.Runtime.Serialization.dll"

Good luck,

Noam

Dual contracts works

2008-05-29T08:49:00.001-07:00

I just fixed a bug or two in Mono's WCF with regard to services that implement more than one contract. A simple test now works.

Enjoy.

Mono's WCF

2008-05-25T06:18:00.000-07:00

Welcome to my blog.

Since I have recently spent quite some time working on Mono's WCF implementation, I thought it might be a good idea to open a blog and share the experience during this development.

I will tag all the WCF related posts with WCF tag. I think that this group of posts will be useful for people who are using, considering using, or contributing to Mono's WCF implementation.

I work at Mainsoft, managing the development team of Grasshopper. We are interested in supporting WCF in our Grasshopper at some time in the future, and thus my personal interest in WCF at Mono.

Anyway, what I wanted to mention is that recently over the past couple of weeks, I have seen some usage of WCF on the olive dev list. For instance:
http://groups.google.com/group/mono-olive/browse_thread/thread/1e68bc3aa7bca05c
http://groups.google.com/group/mono-olive/browse_thread/thread/7519b0f91a47cc11

My point is that although the status of WCF is still initial, bugs in WCF - especially within the constraints of basicHttpBinding - are treated at a fairly high priority. If you can explain the bug you are having, it is likely we will fix it fairly quickly.

Noam