Update Nov 8. 2007: The original solution did not work properly on all devices. Updated version has been tested on E61i, E50, and N95.
Background
In the era of rich Internet applications there is a lot of buzz around widgets and other web technologies that allow developers to create nice looking content rapidly using commonly known techniques such as HTML, CSS and JavaScript. Many S60 developers already know about upcoming S60 Widgets and the WebKit libraries that make them possible in the devices. Also many have used the browser control available since S60 2nd ed. FP X in the platform.
In S60 2nd edition the browser control did not allow creating good looking content, whereas porting of the open source WebKit library to S60 3rd edition changed this completely. However, on S60 3rd ed. the old browser libraries still existed on the device alongside of the new WebKit libraries. In S60 3rd ed. FP 1 the old browser control was removed and the new WebKit based browser control was renamed to have the same name as the old one had previously.
Problem
Renaming the WebKit.dll library created some problems for the developers, because in S60 3rd edition application has to link against WebKit.dll to use the WebKit browser control, whereas in S60 3rd ed. FP 1 there is no WebKit.dll, but only BrowserEngine.dll that has to be used. Obvious solution for this would be to have two different binaries: one for S60 3rd ed. and one for devices using S60 3rd ed. FP 1 and later.
However, having multiple binaries makes the application harder to distribute and also harder for users to install, because the user must know which platform his/her phone has. Also, if S60 3rd ed. FP 1 version would be installed on S60 3rd ed. phone, the old browser control would be used and most of the content probably would not be displayed correctly.
Solution
Solution for the above problem is to load the browser control dynamically from the code during run-time and not link against it at all. Because the WebKit.dll is the preferred one on S60 3rd. ed. and it does not exist on S60 3rd ed. FP 1 at all, it is safe to try to load that one first. In case loading of WebKit.dll fails, the BrowserEngine.dll is loaded instead.
In code loading the correct library would look something like this:
TInt error = iBrowserLibrary.Load(_L("z:\\sys\\bin\\WebKit.dll"));
if (error != KErrNone)
{
User::LeaveIfError(iBrowserLibrary.Load(_L("z:\\sys\\bin\\BrowserEngine.dll")));
}
Using the functions implemented in the dll is as simple as calling them directly. Because all functions in browser control interface are virtual, all function calls are routed through virtual function call mechanism, not statically through dll interface. Only creation of the browser control has to be done through the dll interface:
TCreateBrowserControlFunc FuncL = reinterpret_cast<TCreateBrowserControlFunc>(
iBrowserLibrary.Lookup(KCreateBrowserControlOrdinal));
browserControl = CreateBrowserControlFuncL(... parameters ...);
Because implementing the same dlll loading functionality over and over again for each application is time consuming, I created a browser control factory that hides the details of loading the correct dll and creating the browser control.
The browser factory code is attached and it contains only one class. Remember NOT to link against BrowserEngine.lib or WebKit.lib, because otherwise you will lose the flexibility that this solution offers.
Can you elaborate if any capabilities are required?
Seeing \sys\bin folder makes me a bit jittery.
--Mayur.
No additional capabilities are needed, only the ones that would be needed when using the browser control in traditional way. AllFiles capability is not needed in order to access the \sys\bin folder because contents of the directory are not listed and the file is not explicitly opened by the running application process. The \sys\bin is only used to point RLibrary to the correct binary file, which is then by loaded by the system (which naturally has all the capabilities needed).