As you could have seen in the previous posts, ASP.NET provides an extensible device-specific rendering framework for different browsers and mobile devices. Now we should examine how exactly a control (mobile or standard) renders itself, and how does it know the capabilities of the requesting browser. The magic that make them work is in the browser files. These files live in the C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers directory. If you open it, you’ll see a bunch of predefined browser files to use. These files are simple XML files, with the following markup:
<browser id="browser name" parentID="parent browser name" refID="reference ID">
<capability name="capability name" value="capability value" />
<controlAdapters markupTextWriterType="type name">
<adapter adapterType="name of adapter class" controlType="name of control class" />
Mobile web controls differ from their traditional counterparts in many ways. The most important is that they are simplified greatly, to ensure that they can work in a low-memory environment. First lets consider how to set up a web page to use mobile controls on it!
Normal ASP.NET web pages inherit from System.Web.UI.Page. Mobile pages aren’t, you should change the inheritance to System.Web.UI.MobileControls.MobilePage. Then you should register the mobile control assembly in your page, with the following syntax:
<%@ Register Namespace="System.Web.UI.MobileControls" Assembly="System.Web.Mobile" TagPrefix="mobile" %>
You can control the appearance of your mobile controls by using the DeviceSpecific class. Within it you can set multiple Filters, by which you intend the filtering. As we reviewed in the post before, ASP.NET comes with a predefined dictionary of mobile capabilities (as well as browser capabilities). These capabilities are listed in your machine.config file, and you can extend them in the web.config of your application. We’ve also learned to implement a custom filter.
What needs to be told is that there are two different type of device filters. The first one is based on a method, and has the following signature:
<filter name=”isIE” type=”Namespace.Class, Assembly” method=”methodName”/>
Where methodName is a name of a static method returning a Boolean value and taking a MobileCapabilities and a string argument. The other type of filter is based on comparsion, and defined like this:
You can identify the capabilities of a mobile device like any other browser’s capabilities. In fact, you use the exact same class for this purpose (HttpBrowserCapabilities). You should cast this class into a MobileCapabilities class, and query the result, as the following syntax:
Notice that the HasCapability method takes two arguments, capabilityName, which is a named stored in a dictionary, and optionalArgument, which may help the evaluation process.
You can also create your own custom capabilities. You should use the following syntax:
public static bool IsGPSEnabled (MobileCapabilities capabilities, string optArg)
//Your code here.
Be aware of that your method must return a Boolean value, and take two arguments, a strongly typed MobileCapabilities and a string. After defining your method, you must include the following markup in your web.config:
<filter name=”GPSEnabled” type=”Namespace.ClassName, AssemblyName” method=”IsGPSEnabled” />
Then you can query your device’s capabilities with the topmost code. MobileCapabilities class exposes the same strongly typed properties as the Request.Browser class. However, there is another way to enquire browser capabilities. You can also use the following syntax:
These enquires always require string or null values, so watch out to cast them into proper format.
Mobile Device Capabilities