Abstract: The client was building a downloader tool for customers to get software directly and maintain updates, manage digital rights, and more. The tool also had to incorporate the content of the online store and other online marketing content. It had already been determined that the tool was going to use an embedded browser component for the UI. Now we just had to make it work.
An embedded browser was chosen for the UI layer because they wanted to be able to forward people to the online store and other web-based marketing material without leaving the application. Marketing also wanted to re-use Adobe Flash-based ad banners meant for online ad campaigns. But the tool also needed to act like a desktop application in many ways, including managing installs and modifying registry entries. We couldn't just make it a browser application but we needed to have browser technology at our disposal for the UI.
- Two-way communication between browser and C++ application Since the application needed to run as a privileged install, it was first and foremost a Windows application written in C++. It had to modify registries and launch executables, which a browser can't do. But, some of the user operations (e.g. clicking an HTML button) needed to result in C++ execution, and some of the C++ needed to affect the UI which was all rendered in a browser using HTML and CSS. We needed to have a way for both layers to communicate to each other easily and robustly. It was a wholly different way of thinking about the UI in a browser.
- The two way communication: The browser-to-C++ communication was relatively simple. The application could simply interrupt the navigation event and inspect the URL. We created a new protocol (note?) which the c++ could recognize and upon doing so it would cancel the navigation event and parse arguments from the "URL". For example, if the user action is supposed to initiate a command to the C++ layer, the browser location would be set to a new href that starts with the custom protocal "foo://". The navigate event would be intercepted by the C++ intead of actually navigating to that non-existent URL.
clicks a button to download "Call of Duty" the url for that link would be "foo://action=download&id=1234". This was simple and robust, and easy to expand to cover any kind of message we wanted to send to the C++ layer.
- Internet Explorer memory leaks:
We settled on a robust solution of cacheing DOM constructs and reusing them whenever possible. Each major UI component was set up to utilize a DOM caching service that let it store DOM structures for reuse later. While there was no way to ensure perfect handling of IE memory leak issues, we were able to get it down to acceptable levels for all the use cases we needed to support.
All the technical and design goals were met. The product went live in 2006 and has remained in production through several iterations. We gave a presentation on the project and the technology involved at the October 2006 Ajax Experience conference.
More case studies