System Implementation and
Issues Resolution
5.1. Introduction
This chapter presents the technical capabilities suggested by Microsoft Asp.Net to deal with issues related to multiplatform web applications. The issues are numerous and presenting their solution in this report is a limitation. However, most of the major issues are resolved for Bradford Home-Hunter prototype and their solution is presented here with reference to the software code used for the prototype.
As discussed earlier, Microsoft presents Asp.Net Mobile Controls which are automatically translated to the target markup (Html Control, Wml Control) language by the Asp.Net compiler [30, 33]. The essential classes for these controls are in System.Web.UI.MobileControls API. These mobile controls are placed in a Mobile Form during development.
The Mobile Form is similar to a Web Form for web browser or Deck Card for mobile browsers. During compilation it gives a hint to the Asp.Net compiler that this page is not an ordinary webpage rather it’s a special mobile webpage so the compiler can handle it differently. The complete life cycle of a mobile form includes Initialization, Event Handling, Device Detection, Rendering and Cleanup. After the developer creates (Initialization) the form with her choice of mobile controls and adds control (event handling) logic to the page, it is the device detection phase where the compiler identifies the client device (e.g. mobile phone, PDA etc) and then follows the rendering procedure. In the rendering procedure the mobile controls are rendered according to the markup supported by the client device. This mechanism is termed as the Adaptive Rendering [32,33,37].
Here is a simple example which illustrates the concept of adaptive rendering. Consider a mobile label control such as:
<mobile:label runat=”server”> This is a Mobile Control <mobile:label>
If this page is requested by a Pocket PC device running Internet Explorer 5.5 web browser the control will be rendered in Html as:
The same page will be rendered in a WML enabled browser running on a mobile phone as: <p> This is a Mobile Control </p>
This conversion from markup to markup is not the headache of the developer anymore she just writes her website using mobile forms containing mobile controls and her website is rendered to many devices and platforms automatically. This means she does not need to learn new languages such as CHTML, HTML or WML to support this change. This takes a huge burden off the shoulders of a web developer.
Let us now jump straight ahead into the actual implementation of the prototype and the way it uses .Net mobile controls to resolve challenges associated with multiplatform web applications.
5.2. User Interface Issues
User interface constitutes the input and output functionality provided to the user of the system [38, 39]. When we talk about multiple devices and platforms the first think strikes our mind is that the devices have variable range of screen sizes and input capabilities. Therefore let us divide this section into more manageable units namely:
§ Device Input Issues and § Device Output Issues
5.2.1 Device Input Issues
Majority of the wireless devices are compact and do not have a keyboard available to the user. Instead a keypad with alpha-numeric keys enable user to enter input. Some input controls work fine for a web browser but cause problems when used on a mobile browser. For example when we use a Selection List to enter user’s date of birth it renders on a web browser as a Drop Down List but on a mobile browser it displays all the elements as a normal list. This problem can be better understood with the help of Figure 5.1:
Web Browser for Desktop PC Mobile Phone Browser Figure 5.1
The problem presented in Figure 5.1 is not a rendering problem by Asp.Net but the reason is the limitation of the mobile device on which the control is to be displayed. This problem would have been the same even for a WML based solution. The good thing is Asp.Net still displays the contents on the mobile device by using proper translation. This example also confirms the translation is done appropriately based on the features supported by the client device i.e. web browser supports drop down list but mobile browser only supports simple list control.
The application’s user interface should also not stress on the use of input characters which are not supported by majority of devices such as zone specific keys like dollar ($) or pound (£).
After Mouse Click Without Mouse Click 1 2 3
The user interface can however take advantage of special keys available to a device to optimize performance of a web application. For example use of Soft keys in a mobile phone for page navigation. Figure 5.2 illustrates the example.
Figure 5.2
Whether a device supports a particular functionality or not can easily be found from the “User Agent” string which is passed from a device when it requests a web page. In the code segment we can test a device for a particular feature and then can modify our web page’s behavior accordingly. For example in Figure 5.3 we can test whether a device supports Soft Keys or not and then we can enable or disable particular features on our web application.
Figure 5.3
5.2.2 Device Output Issues
The device output issues are of greater importance than device input issues. The reason is because there is more information to be displayed than the information actually collected from the user of the application. Therefore, I concentrated on device output or presentation issues in much more detail.
if ( Browser.NumberOfSoftKeys > 0 ) { // means browser supports soft keys
// rest of the code here... }
Here are some of the presentation issues and their solution:
§ Handling Different Screen Sizes § Handling Multimedia & Graphics
§ Handling Other Issues (Colors, Fonts, Special Controls)
5.2.2.1 Handling Different Screen Sizes
The most obvious reason which comes to a developers mind is that how she will manage different screen sizes for different devices. If user interface is not planned properly it can result in un-satisfaction on behalf of user which can result in low usability of our web application.
To solve this problem I utilized the idea of using Panels to specify screen layout. Panel is a mobile control which can be embedded into a form control or other panel controls. Ultimately other mobile controls are placed on panel control. But First, developer should separate the user interface into various sections by categorizing content according to their importance. Figure 5.5 illustrates the idea:
Figure 5.5: Division of interface into Panels
As we can see in Figure 5.5 the screen is divided into 3 panels with each panel containing a particular set of information; such as Panel1 contains the Banner for Bradford Home-Hunter, Panel 2 contains the Menu for the web application and Panel 3 contains textual information and
Panel 3 Panel 1
other controls. The developer then numbers these panels according to their importance with number 1 with the highest importance, such as:
1. Panel 2 (Menu Bar) as menu is of most importance for a homepage of a website. 2. Panel 3 (Main Content)
3. Panel 1 (Banner for Bradford Home-Hunter)
Now the task gets simpler, whenever a request for the page is made from a particular device the code checks which device is trying to access the page. If the client device is a desktop PC with a large screen size all of the panels can be displayed without any problem. However, if the client device is a mobile phone with only 2.5 inch screen we should concentrate on more important content such as Panel 2 (menu bar - in our case as it is a homepage for the website). Figure 5.6 shows the same homepage accessed by three different platforms i.e. a Desktop PC, a PDA and a Mobile Phone.
Web Browser PDA Mobile Phone Figure 5.6
As we can see in the figure the web browser displays all the panels, PDA displays only Menu bar and Main Content whereas the mobile phone displays only the menu bar in the form of links.
This presentation of links instead of images is another property supported by Asp.Net mobile Image control in which we can specify an Alternate Label for the image in case it is not
The code segment which achieves the desired result as illustrated in Figure 5.7 is:
Figure 5.7
The code segment in Figure 5.7 first evaluates the “User Agent” string passed by the client device for the Browser’s name i.e. if the target device is a mobile phone rendering WML content then we don’t need Panel1 (Banner) and Panel3 (Main Content).
5.2.2.2 Handling Multimedia & Graphics
Majority of today’s websites contain an attractive blend of text, images, sound clips, movies and 3D graphics. With the introduction of high bandwidth 3G networks the day is no far when all these media shall be within everybody’s reach. But until then the existing content has to be managed according to the network capacity supported by a device. Therefore we have different image formats (such as bmp, wbmp, jpg etc) and media limitations.
One way to overcome such issues is what I have already suggested earlier i.e. the use of panels to divide content into manageable units. Assume we have a multimedia website capable of audio and video streaming. As it is not possible to make this content available to a wireless device user therefore the audio and video objects can be made unavailable for the wireless device user by simply disposing the associated panels.
If (Request.Browser.Browser == “Pocket IE”) {
Panel1.Dispose(); // if it’s a PDA only dispose panel 1 i.e. the banner. }
else if (Request.Browser.PreferredRenderingType == "wml11") {
Panel1.Dispose(); // if it’s a mobile device supporting WML, dispose panel 1 and 3 Panel3.Dispose();
Some media objects such as images which have smaller size and are accessible to majority of wireless devices should be available to the users. But the issue is which device supports which image format?
There are two ways to resolve this issue.
1. The First way is to test the device capability within our code and then render the image format supported by the device. The code segment in Figure 5.8 illustrates the details:
Figure 5.8
Within first way there are two more ways by which device browser capabilities can be tested. One is by the use of Markup Tags similar to Html or Wml tags and another is by the use of Code Script embedded within the <script> tags within the webpage. Any of the two techniques can be used. Figure 5.8 utilizes the markup approach to specify a different flavor of .Net.
There are number of important things to be noted in Figure 5.8. First is the <mobile:Image> tag which indicates it’s a mobile image control. One level within is the <DeviceSpecific> tag which is a hint for the compiler to render this mobile control differently for different devices according to there capabilities. For example, the first <Choice> tag tests whether the device supports WML or not, if it does then the wireless bitmap image (.wbmp) should be sent to the client device which is small in size and displayable by the device. Similarly, the second <Choice> tag tests if the device is a Pocket PC, if it is true then a relatively medium size image in (.gif) format should be sent to the device and so on.
<mobile:Image runat="server" AlternateText="Homepage" NavigateURL="index.aspx">
<DeviceSpecific>
<Choice filter="isWml" ImageURL="/buttons/Home.wbmp " />
<Choice filter="isPocketPC" ImageURL="images/buttons/Home_small.gif" /> <Choice filter="isHtml" ImageURL="images/buttons/Home.gif" />
</DeviceSpecific>
2. The Second approach is to use off the shore mobile controls which automatically render an image to the format supported by a device. One such control is the Mobile Dynamic Image control [40] with the following markup declaration:
Figure 5.9
With the AutoConvert property set to True, the control automatically converts a bitmap image to the image format supported by the client device such as into a .gif for PDA and .wbmp for mobile phones supporting wml.
5.2.2.3 Handling other Issues
Other issues like does a device supports colors or not? What is the screen width and height of the device? Does a device supports Bold and Italic font styles? can be handled easily with the code script by checking a device browser for a particular functionality. The format is already explained earlier in Figure 5.7. The complete device capabilities list can be found here [41]. However, some of the common capabilities are [41]:
Property General HTML cHTML WML
Browser // Name of the Browser? Yes Yes Yes Yes
IsMobileDevice // Is it a mobile device? Yes Yes Yes Yes
CanInitiateVoiceCall // Can we use voice call? Yes Yes Yes Yes
MobileDeviceModel // What is device model? Yes Yes Yes Yes
ScreenPixelsHeight, ScreenPixelsWidth Yes Yes Yes Yes
SupportsItalic, SupportsBold No Yes Yes No
CanSendMail // Can it send email? Yes Yes Yes Yes
<MobileDynamicImage:DynamicImage id="mimage" runat="server"
5.3. Network Capability Issues
The major distinction between wired and wireless devices is the type of network they support. Wireless devices are limited by a small bandwidth network with slow data transfer rates and poor performance. Therefore special data transfer protocols are being designed to suit the needs of wireless devices. One such example is the Wireless Application Protocol (WAP) supported by the majority of the wireless devices. The packet transfer rate and the packet size used in WAP is a lot smaller as compared to the TCP/IP protocol used for wired devices over internet [42].
This limitation on data transfer makes a developer to consider the size of her webpage. If the size is too large it will not be transferable and render-able to the wireless device and hence will result in unexpected behavior of the application. To overcome this fear of a developer Asp.Net introduces the concept of Pagination, a technique which automatically distributes the content into multiple pages without breaking the logical integrity of the content. Pagination of a webpage is completely in the hands of the developer for example the developer can explicitly specify how many database records should be displayed on a single page. In case a developer does not explicitly specify, auto-pagination is employed by the Asp.Net compiler based on the maximum packet size supported by the device.
Figure 5.11 on next page demonstrates an example of auto-pagination when used for Bradford Home-Hunter Prototype.
Web Browser Mobile Browser Mobile Browser Figure 5.11
Figure 5.11 shows the new user registration page for Bradford Home-Hunter. All the controls on the page are displayed on a single page for a web browser running on desktop PC. However, the same page is rendered into multiple pages for a mobile device when auto-pagination technique was employed. The interesting fact to note is that all this is done with almost no effort on behalf of the web developer. She only has to make a small change when declaring her mobile form (web page). This change is highlighted in Figure 5.12:
Figure 5.12
Such a small price to pay for leveraging your application content to multiple platforms is certainly appreciated by developers.
1
2
3
4
<mobile:Form runat = “server” Paginate = “true” >
<mobile:Label runat = “server” Text = “An Example for Auto-Pagination for Bradford Home-Hunter” />
5.4. Security Issues
Business security is far most the top priority of any company and to maintain user’s information securely is a daunting task. To manage multiple requests securely, the technique of User Sessions is employed. “User Session or simply Session is defined as a series of requests issued by the same client within a certain period of time” [43]. A user session is managed by associating a Session ID for each client. The ID is supplied by the client on each request, either as a cookie or as a special fragment of the request URL.
User parameters (or Session Variables) which constitute a session are stored either on the web server or on the client device in the form of a cookie. Most of the time session variables are stored as cookies on the client device to offload the burden from the web server. However, this technique is certainly not suitable for the wireless devices having limited or no memory at all. Therefore a Cookie-less Session Management technique is used to support all such devices and platforms. In Cookie-less Session Management the session (session variables) are managed on the server side. Once a session is created for a user, the session key is returned to the user along with the URL for the website with the following format;
http://www.bradfordhomehunter.com/SessionID/index.html.
The session id is then extracted from the submitted URL to identify client’s session. This technique however has some consequences on its use. A more detailed discussion of cookie and cookie-less sessions is followed in Chapter 6.
Every folder within a website’s hierarchy can have special configurations (security settings, device filters etc) which are indicated by the web.config file stored in the directory. If a web developer does not provide her web.config configuration file, system provided default settings are used. To enable cookie-less session management for Bradford Home-Hunter, I needed to provide my own web.config file with the following configurations:
<system.web>
<sessionState mode="InProc" cookie-less="true" timeout="20"/>
There are two important points to note in Figure 5.13. First the cookie-less parameter of the sessionState object is set to true which enables session management at the server side. Secondly, the timeout variable is set to 20 minutes i.e. after 20 minutes the session will expire and user will have to re-login into the website to use it.
Asp.Net makes it easier for the developer to enable cookie-less session support without making any change to their existing code. For example consider the following code segment from Bradford Home-Hunter website’s new user registration page:
Figure 5.14
The following code stores a user object into session with the name “RegisterationManager” with the value manager. This [key, value] pair in the session is preserved for all devices without doing any modification to the code. The only modification we need is to set the cookie-less