I've recieved a lot of emails from many developers who want to get involved with programming version 3 of the GMap.Net Control. My advice is to download the latest SVN code, read Bill Pierce's original Codeproject articles (see links to right) and then look at the task lists and bug tracker on Sourceforge.net. Just make a patch with any code changes you make, and add it to the sourceforge.net patch tracker. You are all welcome to contribute, no effort is too small and every little bit of help is appreciated.

The major bug at the moment is when events are raised by the Google Map API, and pass arguments. These arguments are instances of classes which then need to be converted to a string by the javascript, this string is then passed to the .Net in the callback. The conversion to a string requires a custom 'toString' method, one for each Google Map API class. This 'toString' method needs to ensure all relevant data from the Javascript class is transferred onto the .Net. The .Net side of the control then needs to reconstruct the class given the string.

This would be fairly straightforward, except Google has obfuscated it's Javascript. For example the 'GMap2' class is, I believe, known as class 'j'. If you run the TestWebsite, and click on "GMap.Net for Google Map API version 2" you will see some debugging javascript alert boxes with callback debugging messages. (These debugging calls are coded in the GMap2X.js file). I have created some methods to print out the obfuscated classes onto the page.

I find it much easier to reverse engineer the obfuscated javascript by copy & pasting into a C# IDE environment and commenting it. I've created a C# solution and folder, called "Javascript Reverse Engineering", with my reverse engineering efforts so far. Doing this will allow the developer of the toString methods to accurately transfer the class data from Google Map obfuscated javascript to the .Net in the control.

Things had started to lag a bit, but an email from Tom Luther and his patch a few days later brought a sudden influx of activity. He helped fix some of the events problems, and it now seems to work in the most part - and uncover a couple of other bugs!

The major feature which is missing is the databinding. The original GMap.Net Control had a good method for this, but it was hard wired into the main GMap class, and made for bulky code. I tried to break it down into more of a pattern form, but this hasn't had the desired effect (it doesn't work!), and so we need to keep on debugging it.

I've also started work on creating Unit Tests. Using NUnit I have created empty unit testing classes for all the GMap classes, I just need to now implement testing methods. My work so far has achieved a small 4% code coverage, showing there is still a long way to go. If anyone is contemplating helping out, this would be an excellent place to start.

The control is improving steadily, today I added support for Google Map GControls to the GMap.Net version 2. This is a good step forward, the map is slowly looking better and working as it should.

But I noticed a lot of major bugs/Todo areas:
Databinding does not work - I created a new namespace and classes specifically for creating objects by databinding, but it does not seem to be working at all! This is either due to something wrong with my new databinding methods, or more likely I haven't updated the GXPage/XSL files to accomodate them.

Events are not working either - Using the same methods from GMap.Net version 1, I basically copied and pasted the code to accomodate for the new events in Google Map API v2. Somewhere along the lines it has decided to stop working, I think this is the most frustrating of all the bugs. I had a plan to change the Callback function, and make events a bit more extensible, but I'll put it on hold until I can get the simple function working. I would also like to make the events return 'void' instead of 'string', but again I'll wait until I get the basics working.

XSL - with all the new classes added to GMap2 this file, and all the XmlSerialization need a lot of work done before they will come up to scratch. If I tackle this one class at a time, hopefully it will start showing signs of improvement!

FxCop - I'm trying to make the control as compliant as possible, so I'm continually checking it with FxCop, so I can spot problems with the framework and change it so it behaves as users would expect. When I first ran it when I started work on the project, I got around 600 errors and warnings, now I've whittled that down to 375. As I mentioned above, I would like to change the events to return 'void' instead of 'string'. If we could get that sorted I think FxCop would reduce to about 100!

The latest SVN revison now compiles, runs and displays the Google Map in the test web site. It is very rudimentary at the moment, but at least we have something to look at! The XSL file is still in very poor shape and needs a lot of work, but as I am not too adept at XSLT it might take a while.

I would encourage all developers to update to the latest revision of the trunk. The API key for the Test Web Site included might need to be changed for your own development environment.

Unfortunately (or fortunately) the Google Maps API version 2 has functions which return values, and are not properties. For example the GMap2 function fromLatLngToDivPixel(latlng) returns a GPoint.

There are two options to wrapping this sort of function in the control.

1. Implement the calculation in C#. This requires recreating the functionality of the Google Map API within our control and goes further than merely wrapping the API. A number of functions could easily be implemented in this way, and this should be done in these cases (to reduce overheads associated with the next option I will discuss). But more complex functions may take a lot of understanding of the Google Map API which we do not have access to.


2. Send the Javascript to the browser and have the Google Map API return the answer. This could be very messy and I believe requires some sort of method like Reverse Ajax, hence my research and previous blog post. I'll try to explain my ideas more clearly in the following diagram.

The diagram above is meant to represent the server handling a function which requires calls to these Google Map API functions which require returned values. The server starts processing as normal in response to the user, but at some point we need to call one of these value returning API functions. Possibly we inject the javascript for the function into the client browser, alongside some functions which return the value to the server once it is recieved from the API. The server can then use the returned value. I have shown 3 of these requests in the above diagram before the request is finally processed.

After looking at the problem for a while I think it is far too complex a solution and we would be better off going with the implementation in C# - for a start it would be better in the long run to really get real familiar with Google Maps!

My research into Ajax did make me reflect on why the GMap.Net Control uses it's own version of an Ajax implementation, which we have to maintain. It would make more sense to use a ready available framework. I thought as much and so started a branch to incorporate Anthem.Net (it's opensource as well, so you can contribute to that too!) in the GMap.Net Control. The branch can be checked out on SVN. I'll then merge it back in when it works, if it ever gets that far!

Exploring Reverse AJAX

Ajax dramatically improved the usability and interactivity of the web and the hype still goes on. But there is a new technology called Reverse Ajax, which shows a lot of promise in taking that interactivity further.
Ajax allows the user to have an almost seamless user interface, improving usability and interactivity. Reverse Ajax goes further and allows web pages to have real-time content, attracting more users and retaining their attention. Reverse Ajax will possibly open up areas of website development which up to now have not been possible.

Firstly, an introduction to Ajax
There was a time on the Internet when you clicked a button and waited a second or two while the page loaded. It was all a bit slow and stilted, and web applications most certainly did not have the speed or usability of desktop based software. Every time the user clicked they ended up staring at a blank screen for a couple of seconds. Not good.

Then along came AJAX and sped it all up. Asynchronous Javascript And Xml (Ajax) allows users to see a much more seamless web application, almost on a counterpart to desktop speed. But Ajax alone is not the total solution. We still cannot get real-time information arriving instantly into our browser.

The one major problem with Ajax is that the user still has to initiate contact. i.e. the application/website is only doing actions in response to the user. At no point does the server decide to do something and update the user automatically. This is because servers cannot initiate contact with browsers.

The whole process of asking for and getting a web page, or indeed any other web resource, can be seen more easily in the following diagrams (in the style of Jesse James Garret's original Ajax explanation).

As you can see the client transmits data to the server when the user requests it. While the server is processing and trying to return a new fresh web page to the user, the user is left with a blank screen and a 'still loading' icon in the status bar which is shown in our diagram by the horrible breaks in the user activity line. Ajax gets around this by using Javascript to handle all the background processes, and allows us to have no breaks in the user activity line, translating into a smoother and more aesthetic user experience.
As can be seen, Ajax allows for an altogether smoother experience. It allows client side processes (Javascript functions embedded in the web page) to capture all the user activity and then pass back relevant information to be processed in the background by the server. But notice that again, just like the classic synchronous web application model, all the server processing is done at the request of the user.



An introduction to Reverse Ajax
Despite all the hype, Ajax cannot get real time information directly from the server. If some information arrives after the user has loaded a page they will never see it, unless they refresh the page.

We could easily solve this problem in the traditional way, by having a having a little bit of Javascript in the webpage that automatically refreshes the page every few seconds. But refreshing an entire page every few seconds is overkill. If the millions of users of a large site were to refresh every few seconds it would increase the bandwidth dramatically. The effect on the servers would be similar to a DOS attack!

We really just need the small piece of real time data to be updated on the browser as soon as it arrives in the server. The simplest way would be to have the server tell all the browsers that the data has been updated. But as we discussed in the introduction to Ajax, servers cannot initiate contact with browsers. Hence we need a solution which gets around this problem.



Welcome to Reverse Ajax
Like DHTML, AJAX, LAMP and SPA, Reverse AJAX is not a technology in itself, but a term that refers to the use of a group of technologies together. The term, as Prokata explains, was coined by DWR, the Java open source library. Reverse Ajax is composed of existing technologies for pushing data, which have been used before in other areas of website design. By implementing these technologies in Ajax we have created Reverse Ajax. Reverse Ajax allows servers to push content out to browsers immediately it becomes available. The following is a brief introduction to each of the three technologies.



Polling
Polling is the repeated querying of the server by a client. In an Ajax environment on refreshing only as small section will have to be updated, and not the whole page. Polling could easily be implemented by having a javascript function called by a timer every few seconds. When the function is called it queries (polls) the server.

The above diagram shows the same client-server event model as I used for explaining Ajax, but it also has a "Continuous Server Application". This is meant to represent the continuous process of real-time activity on the server, for example stock market prices being updated or the latest football scores arriving etc.. When real time information arrives on the server it raises an 'event', which is passed to the 'Server Processing'. Server Processing is the area where client requests are handled, processed, by the server.

As you can see from the above diagram, once the page is loaded, the client side javascript polls the server every few seconds. This repetitive polling is shown on the diagram as dashed lines. If the server has no new information it returns an empty response, shown by the returning dashed lines. If the server does have some new data, for example the real time data coming from the "Continuous Server Application", it is stored until the next time a client polls it.

When the next poll occurs its response returns data, shown by the solid returning line, and passes the content up to the client. An interesting point to note, if the client does actually makes some input, then this can be passed to the server as an Ajax application normally would. Shown on the right part of the diagram.

The problem with this is it requires the client to constantly hassle the server every few seconds, and the problem would only grow if millions of users were using the site. The server would have to handle millions of requests from millions of users every few seconds, on top of the normal traffic it would handle. This could lead to overloading on the server and waste valuable bandwidth.



Comet
Apparently Comet is a really old technology for constantly updating a webpage. The technology requires that the connection between the client and server is never closed. Once the client has requested the web page the server returns the data as slowly as possible, trying to maintain an open connection for as long as possible. It is kind of like phoning up and being put on hold, you are still connected but not very much actual talking is going on.

But how does it work if the page is never loaded? Surely a server which never returns a requested page is failing as a server? Well, you would be right. The trick to Comet is to return a page with an IFrame in it. The page is returned as normal, but the contents of the IFrame are returned as slow as possible. The IFrame is hidden from the user, so the user does not notice any difference from a regular website.

In this way the user gets a normal page and a continuously open connection. It is down this connection that the server can send data to the browser, this data can be handled by Javascript on the normally loaded page.

The above diagram shows what can be done with the permanently open connection, all continuously update server side events can be passed up to the browser. There is far more information on Comet on Alex Russell's blog.



Piggyback
The final of the three technologies behind Reverse Ajax is piggyback. As the name suggests, it is the piggy backing of new data on top of an unrelated response to a client's request. When new information arrives at the server it is stored until the client next makes a request to the server. When the server replies to the request it also adds all the new information which was updated.
The above diagram shows piggybacking in the context of a classic web application model for simplicity, but for reverse Ajax it should have another client side Javascript layer. This technique is not as popular as Polling or Comet as it requires the user to do some activity before it can be updated. If the user is doing a time intensive task, such as reading a blog, they may not do any activity for a long time and so the web page would not be updated at the exact time the new content became available.



Ajax and Reverse Ajax - Putting It All Together
Ajax allows the user to have an almost seamless user interface, improving usability and interactivity. Reverse Ajax allows users to have real time content, attracting users and retaining their attention. One final diagram shows the two working together, using the Comet technology to provide Reverse Ajax.
Walking through the diagram from left to right, we see the dashed line representing the initial request for the page by the client to the server. This opens up the Comet event bus, allowing server side events to travel up to the client and update the browser UI. The client can also provide Ajax events, two examples of the 'event' and 'display' are shown. The second also shows the sending of information through to the "Continuous server application" - this itself is real time information which could be used to update other browsers.

Further Reading
Beyond Ajax
Changing the Web Paradigm
Comet Wikipedia Article
Reverse Ajax Wikipedia Article (initially created by this author)
Reverse Ajax on Ajaxian

The GMap.Net control very cleverly handles Google Map API client side Javascript events. The website developer using the code can easily add a delegate to the Event Handler for any Google Map event (I have implemented all the events now, and not just the select few that were available in the first version of the Control - the latest source code is available, as always on Subversion from our project page on SourceForge.Net) This means that any Javascript event can be handled by Server side code - now that is neat.



To aid any custom control developers who may interested in how this happens, I have drawn up an informal flow chart showing what happens when a Google Map event is raised (green blob). The event can also be given a javascript delegate, allowing the website developer the option of client side Javascript event handling (orange dot) or server side ASP.NET event handling (black dot for website code, and red dot where instructions are passed back to the API).

I hope the diagram helps, it certainly got it sorted a little more clearly in my head!



I also upgraded the old method of databinding from a data source to the Google Map API in ASP.NET - I created a whole namespace of helper classes for each of the objects, markers, infowindows etc.. So it is now much easier (or more straightforward) to add any type of information from a data source directly to a Google Map.

I've been using SharpDevelop for editing the XSL and Javascript files, instead of Visual Studio 2005. I found the syntax highlighting and XSL code completion greater on the former (and it's open source/ free). I also added a fantastic little Addin to Sharpdevelop which counts the lines in all the files.
The original GMap.Net Control, written by Bill Pierce for Google Map API v1, has around 2 KLOC (thousand lines of code). My work so far on v2 (and I only properly started 7 days ago!) has brought that up to almost 6 KLOC! Most of that has been very repetitive copying of the Google API, and copying and pasting from v1 so I'm not going to rest on my laurels just yet. Especially as it doesn't work!

Still, it's a great little feature on SharpDevelop.

Today's coding hasn't gone as great as the other days. Having spent a while away from the computer screen I began thinking more clearly and came up with a large list of mistakes and wrong assumptions I had made about the GMap.Net Control, and a list of instructions next to it on how to correct them. After quickly running through the easy corrections, and flagging the rest up in the comments, I found a file with no license in it (the code is licensed under the Mozilla GPL 1.1) and the words "thank you M$"!! I deleted that file and started afresh, so as not to fall afoul of copyright laws if any! I found more or less the exact same function in the Mono project, so a big thank you to all at Mono for the code I borrowed. The file is licensed under the MIT license, so all is good!

I have now implemented the majority of C# properties in the classes, and have started on the 'void' methods, as these are quickly changed to return a string of javascript. I did get absolutely stumped on how to implement functions which return something other than 'void'. Beats me, something else for the TODO list!


For the critical classes I began altering the javascript and XSL files to take account of the new API methods. I now hate XSL, very very much - I'm not very good at it and I seem to be going in circles!

A quick status report

I've been through the entire Google Maps API version 2 and created all the classes, methods and events which have to be wrapped by the GMaps.NET Control. Everything has been documented quite thoroughly but the code inside still has to be written, which is the hard part!

Development for the moment is concentrating on making sure the main part of the control, the GMap2 class, javascript file and XSL stylesheet; are implemented. Once this goal is reached we can create a test website to check for bugs and other such problems. A number of the remaining classes are quite small, or do not have that many changes, and are already implemented. Hopefully advancing on from this goal to a beta version shouldn't be too arduous. (We can only hope! ;) )

Work has started again on developing the excellent GMaps.Net Control, originally developed in October 2005 by Bill Pierce. The GMaps.Net Control is "a custom server control wrapper for the Google Maps API. Developed for ASP.Net using C#, JavaScript, and XSL. The GMap control makes using Google Maps easy for .Net developers; allowing them to interact with Google Maps using standard .Net language."

What does it do?
If you are a web developer who makes ASP.NET web pages, you might have been tempted to add Google Maps to your website. But that means messing about with Javascript and other such Client side code. But what happens if you want to link it in with some of you ASP.NET code?
Things start to get a little messy, and this is where GMaps.Net Control arrives on the scene.
It allows you to simple add Google Maps by using a control, like you would do with a button to your webpage. It's as easy as that!

The Story So Far
The original control was created by Bill Pierce and published alongside his excellent articles on Code Project in October 2005. The articles describe how to use the control and explaining some of the inner workings in slightly more detail. The article is in 4 parts and can be found on these pages:
part 1 part 2 part 3 part 4

The articles were published in October 2005, and at that time the control worked with the original (version 1) Google Map API. In the meantime the Google rolled out version 2 and created a lot of changes, which effectively made the Control obsolete.

We believe the control is an extremely useful tool for .Net developers, and felt that it should be worked on by the Open Source Community. (The control was originally released under a Mozilla GPL v.1.1).

As of 17th August 2006, the original code was released on Sourceforge.net as the "GMaps .Net Control" project : http://sourceforge.net/projects/gmapdotnetctl

The Road Ahead
So now we need to upgrade the control to work with version 2 of the API. This means adding a lot of new functionality to the original control, and we have a very long road ahead. At the moment there is a lot of work to be done and the upgrade is just in it's infancy, and we would be appreciative of any C# developers who would like to add their support!

There is a constantly updated version on Subversion, on the sourceforge project page and we will soon be releasing some files on SourceForge soon (most likely just the original version), but we'll keep you posted.