As you may already know, Extended property tests require a round trip between the browser and your web server to gather the information about the visitor's browser and system capabilities.
The time it takes to perform most extended property tests is often so fast that the test is transparent to your visitors. Other tests however, such as ConnectionSpeed and various Java tests, can take a few seconds to execute.
Often times you'll want to use BrowserHawk's test results from multiple pages on your site. For instance, you may need to know on three different pages whether a user has Flash 8 or higher. This raises an interesting dilemma, however, because you certainly do not want to perform extended property tests for the same user over and over as they move around your site (due to the round trip required).
The solution that comes to mind is to store the BrowserHawk results into variables in the user's session object. While this can be done, the code to implement this is often cumbersome to work with, and requires additional coding time and attention on your part. In addition, session objects are not strongly typed and therefore prone to potential coding issues.
To make the process of caching BrowserHawk results to the user's session seamless and transparent to you, BrowserHawk provides Automatic Session Caching (ASC). ASC completely eliminates all code that would be necessary otherwise to manage, store and retrieve cached results from the user's session.
Note: Automatic Session Caching (ASC) is only available with the .NET and Java version of BrowserHawk. In order for ASC to function you must have sessions enabled for your web site.
To use ASC, you simply set the CacheToken property of the ExtendedOptions class to a session variable name of your choice, prior to calling the GetExtendedBrowser method. When a CacheToken is set, the GetExtendedBrowser method first looks to the user's session for a cached ExtendedBrowserObj object stored in the session variable name specified in the CacheToken property.
The first time your extended property test runs for a user during their session, the ExtendedBrowserObj object with their test results will not yet exist in the user's session. Therefore BrowserHawk will proceed to perform the actual extended property test, and return the resulting ExtendedBrowserObj object back to your page. At the same time, it also stores a copy of this object in the user's session under the variable name you specified in the CacheToken property.
Later, when the visitor hits that same page again, or when they hit another page on the site that specifies that same CacheToken, BrowserHawk will recognize that the ExtendedBrowserObj object already exists in the user's session. A that point BrowserHawk instantly returns the cached version of the ExtendedBrowserObj object to your code, without performing any extended property testing on the browser or incurring any overhead from a round trip. This process is extremely fast and efficient.
Again it is important to note that even though you are actually calling GetExtendedBrowser, this method will not actually perform any tests if it already has the answers in the cache.
Let's examine a few examples to illustrate how ASC works and its advantages over manually managing BrowserHawk results yourself in session variables.
Example 1: Managing BrowserHawk results in the session manually
In this example the developer does not use ASC. Rather, they use their own code to prevent running extended property checks multiple times for the same user during their session:
<%
// This example does not use ASC, so you must manage the session information manually…
// See if we've already tested the browser
if (Session["bhTestedFlag"] == null) {
// not yet tested, so perform the test
ExtendedOptions options = new ExtendedOptions();
options.AddProperties("Plugin_Flash, Plugin_Acrobat,Width,Height,Broadband");
ExtendedBrowserObj extBrow = BrowserObj.GetExtendedBrowser(options);
// now store the results individually in the session object
Session["flashVer"] = extBrow.Plugin_Flash;
Session["acrobat"] = extBrow.Plugin_Acrobat;
Session["width"] = extBrow.Width;
Session["height"] = extBrow.Height;
Session["Broadband"] = extBrow.Broadband;
Session["bhTestedFlag"] = "YES";
}
// … then later in your code you have to check the BH results through the session variables
// Let's check for Flash…
if (Session["flashVer"] != null && (int) Session["flashVer"] >= 7)
Response.Write("Your Flash is 7 or higher.");
else
Response.Write("You don't have Flash 7 or higher.");
%>
As you can see from the above example, there is a lot of manual code involved to track the session information manually. This can be difficult to maintain and is prone to errors.
Now in this next example we perform the same exact BrowserHawk tests, except we put BrowserHawk in charge of caching the information using Automatic Session Caching.
Example 2: Managing BrowserHawk results using ASC
In this example the developer uses BrowserHawk's built in ASC feature to automatically store and retrieve extended property test results from the user's session:
<%
// This example uses ASC, so there is no need to perform any session management yourself
ExtendedOptions options = new ExtendedOptions();
options.AddProperties("Plugin_Flash, Plugin_Acrobat,Width,Height,Broadband");
// Tell BrowserHawk to use ASC and store the cached results into the session var named "bhawk_results"
options.CacheToken = "bhawk_results";
ExtendedBrowserObj extBrow = BrowserObj.GetExtendedBrowser(options);
// … then later in your code you simply check the BH results you need through extBrow variable as usual
// Let's check for Flash…
if (extBrow.Plugin_Flash >= 7)
Response.Write("Your Flash is 7 or higher.");
else
Response.Write("You don't have Flash 7 or higher.");
%>
As you can see, using BrowserHawk's ASC feature saves you coding time, reduces the complexity of your code, and is not prone to errors the way manually storing this information with session variables is.
Note: Automatic Session Caching is not used by default. To have BrowserHawk cache a user's test results, you must set the CacheToken property of the ExtendedOptions class prior to calling GetExtendedBrowser.
Caution: Do not attempt to access the cached ExtendedBrowserObj directly through the user's session. To get a cached ExtendedBrowserObj just call GetExtendedBrowser as usual, and if a cached version exists BrowserHawk will return it to you. Or, for more advanced usage, there is a GetFromCache method that returns the cached ExtendedBrowserObj object to you – this method may be handy if you are writing special dispatchers or handlers such as from HttpModules.
Note that you are not limited to having just one set of cached results for a user. In fact, there may be times where it is advantageous to maintain multiple sets of Extended property results for the same user.
For instance, assume that on most pages of your site you need to know whether the user has Flash installed and what their screen size is. Further assume that a certain section of your site requires Java, so if a user ventures into that area of the site, you'll also need to ensure their Java settings meet your requirements.
In the above scenario, you could simply test the user for Flash, screen size, and the Java settings when they first enter the site. However, this approach is not very efficient because the Java tests can take a few seconds to perform, and yet every user would be tested for Java even in cases where the Java results are not needed.
Instead, you could implement BrowserHawk so that it performs only the Flash and screen size tests when the user first enters the site. Then only later once they attempt to access the area of your site that requires Java do you perform the Java tests.
You can maintain multiple sets of Extended property test results for the same user simply by specifying different CacheToken values for each test. The following examples demonstrate this:
<%
// general.aspx
// This page performs only the Extended property tests needed for most pages on the site with no Java tests
ExtendedOptions options = new ExtendedOptions();
options.AddProperties("Plugin_Flash, Width, Height");
// Tell BrowserHawk to use ASC and store the cached results into the session var named "bhawk_results"
options.CacheToken = "bhawk_general_results";
ExtendedBrowserObj extBrow = BrowserObj.GetExtendedBrowser (options);
%>
<%
// needsjava.aspx
// This page performs all Extended property tests we need including Java. This test is performed once the
// user requests the section of the site which requires Java.
ExtendedOptions options = new ExtendedOptions();
options.AddProperties("Plugin_Flash, Width, Height, JavaVendor, JavaVersion, Plugin_JavaVer");
// Note that we now use a value for CacheToken that is different than what was used previously
options.CacheToken = "bhawk_full_results";
ExtendedBrowserObj extBrow = BrowserObj.GetExtendedBrowser(options);
%>
In the above scenario, BrowserHawk now maintains two sets of Extended property results in the user's session. Note how we repeated the Flash and screen size tests in the second example. This is because the cached results are not shared between multiple result tests. As pointed out above, it is not mandatory to break your testing into different result sets. However if you prefer this for maximum efficiency, you can create multiple cached results sets as demonstrated above.
There may be situations where you want to force BrowserHawk to retest a browser, even though the information is already in the cache.
For example, let's say you test a browser for a required screen size and the user's screen size is too small. You then provide the user with information on how to increase their screen size and provide a link for them to retry the test to confirm their new settings are correct.
If you do not force a clear of the cached information, BrowserHawk will continue to return their original screen size test results from the cache. Therefore, in such situations, you will want to force BrowserHawk to retest the browser.
To force BrowserHawk to clear the cache for a particular user so that their browser is retested, simply set the CacheForceRefresh property to true prior to calling GetExtendedBrowser. This instructs BrowserHawk to retest the browser even if cached information is already available. The new results from the retest are then returned by BrowserHawk and stored again in the cache for reuse.
Note: In the event the user's session is lost for any reason, such as from inactivity or closing and restarting their browser, BrowserHawk will automatically take care of retesting their browser and storing the results back into the cache. Therefore no special handling is needed on your part for such cases.
There may be situations where you would like to know whether the Extended property results returned by GetExtendedBrowser came from the cache. You can obtain this information by checking the IsFromCache property of the ExtendedBrowserObj object.
Tip: See the popular.aspx sample distributed with BrowserHawk for a working demonstrate of Automatic Session Caching in action.
See Also:
CacheForceRefresh Property (.NET)