In the mobile world, we are coming across different varieties of mobile devices. Some mobiles are capable of rendering rich graphics, a few are able to render even low quality graphics and others are capable of displaying text only. Developing application targeting these devices had been a nightmare (prior to .NET mobile development facilities), developers were writing additional code to render the same application for different devices and it was not so easy to do. Now .NET mobile development facilities make the work easier and relax developers from understanding the target mobile device capability and give guarantee to run the same application under different mobile platforms without writing any additional code. But again the question is "How is it possible?" Well the short answer is everything is possible in .NET and the long answer is you need to understand the rendering process and the flow of communication between the web application and the mobile devices.
This article gives you a clear idea of how the same web application (.NET based) renders differently based on device capability. For example, consider a mobile web page (let's call it a “birthday tracker”) that contains a calendar control to track birthdays. If your mobile device is capable of displaying high-end graphics, then you will see the calendar control in your mobile screen or if not the same control will be displayed according to the device's capability (may be in a text format). The interesting point is developers are freed from the task of writing additional code to make the application compatible across various target devices. Checking the type of the target mobile device, its capability and making the application compatible for the mobile device is the responsibility of .NET; developers need to focus only on the functionality. Let's explore how .NET detects the device, converts the data and renders based on the device capability.
The main advantage of .NET mobile application controls (placed on web page) are that they render themselves automatically based on the mobile device capability. This process involves two major components:
- ASP.NET Mobile Control: These controls are very much familiar to normal controls like button, textbox, etc. and are specially designed to work with mobile devices.
- Device Adapter: The prime job of the adapter is to generate output from the controls and map to a markup language which the device can understand such as HTML, cHTML, WML and XHTML.
These two components work together to render the same application’s data across multiple devices. At present, .NET supports 200+ mobile devices. The configuration of these devices are define in the machine.config file.
Now examine a case study of how it works when you are requesting a web page from a Pocket PC (PDA). Pocket PC will communicate with a web server through an HTTP request. This request will be processed in three stages. The first stage involves identifying the type of the device, in this case a Pocket PC, and its capability like image and browser capability and the types of markup languages supported. The information about device capability is configured in the Machine.config file and the web application refers machine.config to identify the device capability and other information about the device. If we look at the HTTP request coming from a mobile device, it contains three major sections: the URL, User Agent and Header information, as illustrated below:
[Figure 1: Process involved in browsing a web page from a Pocket PC]
The User Agent string contains the device info and this string will be used to machine.config to identify the details about the requesting mobile device. The URL section contains the requested page. Once the page identifies the application, the server looks for the instance of the requested page. If the requested page is not yet instantiated, then the requested web page (.aspx) will first be parsed, then compiled by the compiler, and then the compiled page is stored in the assembly cache and finally the server will create a new instance of the cached page. The parsing and compiling process is a one time activity, all subsequent requests for the same page will be instantiated from the cache irrespective of the mobile device requesting it. This process leverages the performance of accessing a mobile web page.
The second stage involves the page rendering process. Once the page has instantiated the controls (mobile controls), the execution process starts based on the user’s inputs. After the execution, the data has to be rendered based on the device capability. This is taken care of by the device adapters associated with the device and controls. The device adapters generate a markup language compatible with the device for the output, in this scenario, HTML output, and send it to the device (Pocket PC).
Now let's examine another case study of how it works when you request a page from a cell phone. In this scenario, the cell phone mobile browser sends the WAP request to a WAP gateway. This gateway is provided by the cell phone service providers as illustrated below:
[Figure 2: Process involved in browsing a web page from a cell phone]
Now the WAP gateway translates this into an HTTP request and passes it to the web server over the internet. The HTTP request contains the URL, the User Agent and Header Information. The process of execution of the page is the same as we discussed earlier in our case study for Pocket PC. The main point is, instead of generating an HTML output now, it generates a WML output because cell phone mobile browsers can understand only WML. Once the WML output has been generated, the web server sends the output as HTTP response to the WAP gateway and the WAP gateway translates it to a WAP response and passes it to the cell phone.
This is how mobile web applications work across different mobile devices. The .NET mobile development facilities make our work very flexible and leverage productivity. Microsoft is doing lots of enhancements to its mobile development facilities because a lot of today’s businesses run on mobile devices. I am going to update you all more about mobile development in my coming articles.
- 27th September, 2005: Initial post