Designing Multiplatform Web Applications
Using .NET
Sheikh Tabish Mazhar
M.Sc. Information Systems
Session (2004/2005)
Abstract
As the world has turned into a global village through the use of internet, and most of our day to day business is transforming to World Wide Web by the use of information technology, new devices are joining the show with amazing capabilities and functionalities. These devices are portable, extensible and state of the art. It is every enterprise’s dream to reach world wide to every customer using a networked device. Mobile phones, PDAs, laptops and the future devices are to be accessed by our web applications. This report discusses the possibilities presented by Microsoft .Net to design multiplatform web applications. Discussing the history, existing solutions and then presenting new solution is the scope of this report. This report also takes a real life case study to prove the claims made by the author of this report and hence Microsoft .Net
Acknowledgements
In the name of Allah the Most Beneficent the Most Merciful, I dedicate this report to my parents Sheikh Mazhar Iqbal and Mrs. Shagufta Mazhar, and to my ideal, my grandfather
Sheikh Muhammad Iqbal.
I thank my teachers at University of Leeds for providing me the guidance I required, the knowledge I seek and making me realize the things I couldn’t find on my own. Specially, my project advisor Mr. Owen Johnson and my assessor Professor Jie Xu.
I would also like to thank the members of the focus group Mr. Kevin McKenzie, Miss Asha Parekh and Mr. Imran Muhiyyudin for helping me carrying out the evaluation for the project and providing me their useful feedback.
Chapter 1: Introduction ... 1 1.1.Introduction... 2 1.2.Problem Definition ... 2 1.3.Project Aim ... 3 1.4.Objectives ... 3 1.5.Functional Requirements ... 3 1.6.Deliverables ... 3
1.7.Software Engineering Methodology... 4
1.7.1. Waterfall Model ... 4
1.7.2. Rapid Prototyping Technique ... 4
1.7.3. Spiral Model (proposed methodology) ... 5
1.8.Project Schedule ... 6
Chapter 2: Literature Review ... 7
2.1. Platforms, Capabilities, Issues ... 8
2.1.1 Platforms ... 8
2.1.1.1 Homogeneous or Broad Classification ... 9
2.1.1.2 Hybrid Classification ... 9
2.1.2 Capabilities ... 10
2.1.3 Issues... 11
2.3. Write Once Use Anywhere ... 13
3.1. Microsoft .Net ... 18
3.1.1 Microsoft Smart Device Extension (MSDE) ... 18
3.1.2 Microsoft Asp.Net Mobile Controls ... 18
3.2. Asp.Net Architecture... 19
3.3. Asp.Net Mobile Controls ... 21
Chapter 4: Bradford Home-Hunter: Selected Case Study ... 23
4.1. Introduction... 24
4.2. Existing Solution... 24
4.3. Revised System Requirements... 26
4.4. The Challenge ... 27
Chapter 5: System Implementation & Issues Resolution... 28
5.1. Introduction... 29
5.2. User Interface Issues ... 30
5.2.1 Device Input Issues ... 30
5.2.2 Device Output Issues ... 32
5.2.2.1 Handling Different Screen Sizes... 33
5.2.2.2 Handling Multimedia & Graphics ... 35
5.2.2.3 Handling Other Issues... 37
5.3. Network Capability Issues ... 38
5.4. Security Issues ... 40
5.5. Extensibility Issues ... 42
5.5.1 Extensibility to New Devices ... 42
5.5.2 Writing new Controls for Existing Devices... 44
6.1. Evaluating Project Requirements... 47
6.1.1. Minimum Requirements ... 47
6.1.2. Extensions ... 47
6.2. Evaluating User Requirements ... 48
6.2.1. Application Developers Requirements ... 48
6.2.2. End User Requirements ... 49
6.3. Evaluation of Technology... 50
6.3.1 XSLT ... 50
6.3.2 Java ... 51
6.4. Usability Testing... 52
6.5. Accessibility Testing... 54
6.5.1 Test Case 1: Testing Special Controls ... 54
6.5.2 Test Case 2: Testing & Evaluating Application Security ... 55
6.5.2.1 Cookie-less Sessions... 55
6.5.2.2 Cookie Enabled Sessions ... 56
6.5.2.3 Conclusion ... 56
6.5.3 Test Case 3: Testing & Evaluating Asp.Net Mobile Controls... 57
6.6. Conclusion and Further Work... 58
References ... 59
Appendix A – Personal Reflections
Appendix B – Screen Shots for Bradford Home-Hunter Web Application
Appendix C – Guidelines for multi-platform web application development using .NET Appendix D – List of Devices supported by Asp.Net Mobile Controls
Appendix E – Objectives and Deliverables Form
Chapter 1
1.1. Introduction
As the world has turned into a global village and most of our daily business is transferring to World Wide Web, new devices are connecting to internet with astonishing capabilities and functionalities. These devices are portable, extensible and state of the art. According to a survey [1] carried out in March 2002, the number of wireless internet users is approximately half of the wired internet users in the world. These wireless users access internet through their Mobile Phones, PDAs or Laptops. Figure 1.1 projects that the number of wireless internet users will increase than the wired users by 2007.
Global Internet and Wireless Users
Subscribers 2001 2004 2007
Internet users (millions) 533 945 1,460
Wireless Internet users
as % of all Internet users 16 41.5 56.8
Figure 1.1
The interesting fact is that even when the mobile internet users were about half of the wired users till 2004, yet they belong to diverse backgrounds and age groups and include the people who don’t even utilize a Personal Computer (PC). These facts really attract a solution developer to design their internet web applications into a format which can run on any platform or device and accessible to new potential consumers in the world.
1.2. Problem Definition
The main objective of this project is to overcome the technical challenges associated with multiplatform web application development. This process includes several issues and complexities. The project addresses these technical challenges and to specify how these challenges can be conquered. Although the Project concentrates on Microsoft .Net based
solutions, it also briefly touches existing possibilities and debates why they are insufficient to propose a complete solution.
1.3. Project Aim
To explore the potential of .NET to resolve user interface and architectural issues associated with multiplatform web applications, by implementing a Case Study for Bradford Home-Hunter Housing Trust.
1.4. Objectives
The project has the following objectives:
§ To propose architecture which will support applications running on multiple platforms and which is extensible to new devices.
§ To develop an extensible architecture to support new devices using the .NET framework. § To implement this architecture by extending a prototype for business web application. § To test the architecture on a number of devices and suggest future enhancements
1.5. Functional Requirements
Here is the list of minimum functional requirements for the project:
1. A report outlining the key challenges associated with Multiplatform Web Applications. 2. Proposals for Multiplatform Web Application development using .NET
3. Prototype of a “Bradford Home Hunter” application which can run on at least three platforms for example PDA, Mobile Phone and Personal Computer using World Wide Web.
1.6. Deliverables
Following is a list of deliverables for the project:
1. A project report outlining the key challenges associated with multiplatform web applications.
1.7. Software Engineering Methodology
Software Engineering methodologies are an aid for comprehensive and well documented development of a software project. These methodologies assist the development team to improve project efficiency and quality.
For this project I have decided to employ spiral modeling technique which combines two of the most famous software engineering methodologies i.e. waterfall modeling technique and rapid prototyping technique. Let’s take a brief look at these methodologies:
1.7.1 Waterfall Model
Waterfall model is the classic approach for software development. It divides the system development life cycle into a linear sequence of stages in which each stage must be completed before the next stage begins. These stages are requirements gathering, system analysis, design, implementation and testing. The advantages of waterfall modeling technique are that, it is easier to define and manage a project into well defined milestones [2]. These milestones have a clear deadline which ensures on time delivery of software product. The disadvantages of this scheme are that, it does not allow iterative reviews and it can not cope with changing user requirements [3].
1.7.2 Rapid Prototyping Technique
The Rapid Prototyping Technique (RAD) is suitable for changing user requirements throughout the development of software project and also for quick delivery of solutions. It offers two flavors for project management i.e. Throwaway Prototype and Evolutionary Prototype [4,5]. In
Throwaway Prototyping, a prototype is developed quickly and presented to the clients or users of the system. Once clients and developers agree on functional requirements of the system the prototype is discarded and system is re-developed from scratch using new system requirements. In Evolutionary Prototyping the prototype is not discarded, yet it is modified to save time and meet with tight deadlines [6]. For this reason I chose to employ Evolutionary Prototyping technique to systematically refine my prototype with time.
1.7.3 Spiral Model (proposed methodology)
The Spiral Model combines the features of waterfall model and prototyping technique with an exception of risk analysis before each stage of the cycle [7]. Let’s understand it with the help of Figure 1.2:
Figure 1.2
As we can see in Figure 1.2, the model is divided into four quarters of time namely Planning, Review, Risk Analysis/Prototyping and Engineering. Each cycle of a spiral model refers to the waterfall model of a single prototype and as we go from inner to outer loops of the model the prototype gets specialized to the working system [7].
As my project required me to build a working prototype for Bradford Home-Hunter therefore Spiral Model was the most suitable choice [8] to carry out evolutionary prototyping technique with two iterations.
1.8 Project Schedule
Figure 1.3 shows the Gantt chart for my project schedule:
Figure 1.3
As we can see from Figure 1.3, that the initial parts of the project (stage 1, stage 2) were allocated a longer span of time than the later stages. The reason was as the existing system for the Bradford Home-Hunter case study had to be reverse engineered, analyzed and studied. Stage 3 did get delayed for a week because of extensive system testing as there were multiple solutions to the same problem. Stage 5, 6 and 7 were only delayed by a week which left me with two weeks to finish stage 8.
Only two iterations within spiral model were executed because the prototype was built as a proof of concept and was not to be delivered to an active client. Therefore the most of time was spent in research and testing the system for alternative solutions.
The next chapter presents the relevant literature surveyed during the course of this Project. Some issues related to multiplatform web applications are raised and then critically analyzed in context with existing solutions. Later, the text explains what Microsoft .Net has to offer when it comes to solutions accessible over multiple platforms and devices.
Chapter 2
2.1. Platforms, Capabilities, Issues
Along the years, a lot of devices have been invented to suite our rapidly changing needs. For example, pagers were invented to facilitate rapid delivery of personalized messages, mobile phones to receive calls on a moving destination, laptops for mobility of high performance personal computers and desktop PCs to provide multimedia services. Although their services are similar, yet their hardware and software architectures are quite different. Let’s take an introductory look at these extraordinary devices.
2.1.1 Platforms
Every device requires a particular platform, an architecture which makes it work in optimal condition. A desktop pc can do multi-tasking only if the software architecture supports it, a mobile phone can receive calls anywhere only because of the wireless career which surrounds it and a GPS receiver can predict point of origin only when satellites triangulate its position.
The choice is ours, there might be a single device which can fulfill our every need but the price tag associated with it might not be within the reach of every consumer. Therefore, there are numerous devices, platforms and architectures and we will have to deal with it.
There are many qualities of a device which make it unique from others. The specifications differ in network speed (bandwidth), screen sizes, support for graphics, device input capabilities, memory and processing power. There is no universal classification of these devices still they can be divided into two major categories [9,10,11].
§ HomogeneousClassification which is based on a single property of a device such has screen size, network capacity and so on.
§ HybridClassification which is based on multiple properties.
2.1.1.1 Homogeneous or Broad Classification
The majority of the devices in the world today are classified according to a specific capability of a device for example, the network type supported by the device. Based on this property the major classifications are:
§ Wired or Static Devices, which support network connected through physical cables such as desktop pc, bar code readers and digital (cable) television.
§ Mobile Devices, also called wireless devices, are the ones which can change their position and still are approachable by the network service provider. Some examples of these devices are mobile phones, PDA’s, pagers, GPS receivers and Laptops (remember Laptops and desktop PC’s can both support mobility and static behavior i.e. a Laptop can be connected to a wired or wireless network).
2.1.1.2 Hybrid Classification
The hybrid approach is based on multiple properties of the mobile devices. According to hybrid approach network devices can be classified into three major classes:
§ High performance devices, such as desktop pc and laptops with large screen sizes, processing power and high bandwidth network connectivity.
§ Medium performance devices, such as PDA’s, mobile phones supporting medium screen sizes, high resolution, and high bandwidth enabled networks such as GSM and 3G (3rd Generation).
§ Low performance devices, such as pagers, GPS receivers and other low performance mobile phones. Figure 2.1 shows sample devices belonging to each category.
2.1.2 Capabilities
Let us now discuss the capabilities of various network devices capable of executing web applications. Figure 2.2 lists a set of specifications for various devices belonging to major classes described above.
Homogeneous Classification Hybrid Classification Network Connectivity Screen Size Processing Power
Main Memory Browser
Capabilities High Performance 56 Kbps to 3 MBps 14 inch to 30 inch 500 MHz to 3.2 GHz 16 MB to 2 GB Video Streaming, Chatting, Multiple markup and transport
language support. Medium Performance 19.6 Kbps to 2 Mbps (3G) 5.7 x 5.7 to 6 x 8 cm 16 MHz to 206 MHz 8MB to 32MB Music Streaming, Limited markup language and protocol support. Static Devices
Mobile Devices Low Performance 9.6 Kbps to
14.4 Kbps
3 x 2.5 cm Minimal Minimal or Not-Supported
Not-Supported
Figure 2.2
Figure 2.2 illustrates the specifications of devices according to their classes. Column 1 shows that a large number of static devices fall into high performance devices because of high network performance, screen size and processing power. Similarly only few mobile devices are high performance devices. As we move down to second and third rows in column 2 we compromise on performance and increase the mobility. We can see that a large number of mobile devices are low performance machines which support only necessary call services and few data services such as SMS (short messaging service).
2.1.3. Issues
The whole purpose of World Wide Web (www) is to increase accessibility of web applications to multiple users across the globe. With the passage of time, every vendor has come up with their own set of customized devices to suite a particular group of consumers. This customization makes a huge burden on the shoulders of a web developer who wants to implement an application and make it accessible to a large number of users [12, 13].
These challenges raise some questions and concerns in a web developer’s mind, these concerns are:
§ Will the client browser executing my web application?
For example, if the web application is written using HTML (hyper text markup language), it is inaccessible to a mobile phone which supports only WML (wireless markup language).
§ Will my information be processed equally to all platforms supporting my application?
For example, a page written in HTML might not be processed equally in both Netscape Navigator and Internet Explorer [14]. Consider the following statement:
<tag-x><tag-y><tag-z> some text </tag-y></tag-x></tag-z>
Internet Explorer will make sense of the tags even when ending tags are not in the same order as starting tags. While Netscape Navigator will ignore tags as they are not in the same order, it will only understand the ending tags if they are in reverse order as the starting tags as in:
<tag-x><tag-y><tag-z> some text </tag-z></tag-y></tag-x>
§ Will the target device support the content of my website?
For example, will the target device support video streaming, or *.jpg image format? Will it support large font size or colors?
§ What limits are imposed on my application by the targeted platform?
Every platform has its special needs and constraints which cannot be violated. For example, some mobile phones cannot support web page with size larger than 1.5 Kb (kilobyte). Similarly, few devices have no internal memory hence no support for cookie oriented session management [15, 16].
§ Will my web application be secure on the targeted platform?
Security is one of the major issues for web applications. User authentication, client authorization and asset protection is the first requirement of B2C (business to consumers) applications. Therefore it is absolutely necessary for a web developer to make sure the target device will support the security she wants to implement for her application. For example, does the device support cookie or cookie-less session management?
§ What Input capabilities will be available to the user of the application?
When it comes to scalability of an application to multiple devices, one of the major issues is the ability of a client to enter their information using the device’s input capabilities. For example, a mobile phone provides only a keypad to enter both numbers and digits whereas a PDA provides an On-Screen keyboard. The amount of time it takes for a mobile user to enter information from his keypad might be twice as it takes for a person using laptop or desktop pc. There might not be some special characters available or foreign language support to a mobile phone user as apposed to a desktop user.
§ Are there any special capabilities of a device I can take advantage of?
Sometimes there are some special capabilities in a device which a developer might want to take advantage of; for example, a mobile phone can make a phone call directly to a remote destination. Similarly the ability of a desktop pc to support video streaming through high bandwidth internet connection is not available to a low performance mobile phone user.
All these concerns impose constraints on application development, and in this fast paced world only few have the technical capabilities and time to cope with these challenges. Let us now see
some of the available solutions to these problems. These challenges in general are referred to as
Accessibility Issues [17, 18, 19].
2.2. “Write Once Use Anywhere”
The ideal solution to the accessibility problem would be to achieve device independency (“Access to a unified web from any device in any context by anyone” [20]) i.e. our code can run on any device supporting any network. There are numerous ways to achieve this device-independency. A few of them are:
§ Using Translators: A translator can be used to convert both code and data to the specific format understandable by the device. Gateways are used for translation from one markup language to another such as WAP gateway which is used to translate WAP request from the mobile device into HTTP request and HTTP response from internet to WAP response for the mobile device.
§ Using Device Specific Content: One technique is mostly used for multiplatform web application development is to use device specific versions of the same content. For example, a same website is written in HTML and also in WML to comfort the needs of desktop users and mobile users. XML technologies such as XSL: FO, XSLT, SVG, and others are used to implement device specific filters.
Let us now take a detailed look at various existing solutions which provide device independency.
2.3. Analysis of Existing Solutions
In last few years, various solutions have been proposed to solve accessibility problems for multiplatform web applications. More or less all these solutions belong to on of the categories of solutions described in section 2.2. Let us take a detailed look at some of the most adopted solutions:
The most obvious way to enable a new device support to your application is to translate your existing code into the language understandable by the client device. The developer has several
choices here which can be understood with the help of an example.
Consider an example where our client device is a mobile phone only capable of understanding WML web content. In this case we have two choices here:
§ First, we can re-factor our entire website into WML web content so it can easily run on the client device.
Drawbacks: The drawback of the first approach is the fear of every developer i.e. to write and maintain several versions of the same application. This causes a huge burden on the shoulders of the developer to make sure that business rules are being transformed to the new device and also on the fact that she might have to learn a new set of languages and tools to make her application extensible to the new device.
§ Second, our application server or WAP gateway can translate our HTML web content in WML content at runtime.
Drawbacks: This approach is dangerous because it requires most of the content to be discarded which is not render-able in WML and also resulting in unstable behavior of application and its in-consistent presentation style.
§ Third, to write our application in a language that runs on a virtual layer supported by various client devices. An example of such virtual layer is Java Virtual Machine (JVM) which is largely supported by the major device manufacturer in the world.
Java 2 Micro Edition (J2ME) is the compact version of Java programming language, consisting of a limited set of APIs (application programming interfaces) [21, 22]. The applications (web/desktop) are written as a set of java classes/applets and downloaded to
the client machine. They are then executed on Java Virtual Machine (JVM) which is already installed on the device.
Drawbacks: Although J2ME ensures platform independency by customizing each device with its own JVM but the fact remains that JVM must be pre-installed on the client device [23, 24]. If it is not then the client device will not be able to render java based solutions such as MIDlet (similar to java applet but used for mobile devices). The following FAQ script perfectly defines why J2ME based solution is not a suitable choice for more accessible web applications:
“
Q: Will a Java Virtual Machine (JVM) come pre-installed on all Palm OS devices?
Answer: A Java virtual machine is not a required component of the Palm OS and therefore is not a component PalmSource's licensees are required to support. Additionally, the Palm OS is deployed on a wide variety of devices with different capabilities and focus, not all of which are suitable for a JVM. It is left up to the licensee of the Palm OS to determine whether a JVM is needed for their device given cost constraints, memory limitations, and customer focus. As such, PalmSource cannot guarantee that a JVM will be preinstalled on all Palm OS devices.
”
[23]The script clearly mentions why device vendors cannot guarantee the installation of Java Virtual Machine (JVM) on a device. This condition puts a huge constraint for the developers to launch their applications using J2ME. What if the client device does not have java virtual machine installed on it? What if the feasibility for the application is to use a different vendor’s solution rather then Java (Sun Microsystems) based solution?
Another issue is the type of content the system has to offer, for example the JVM would only be able to render the content written in java programming language. This means that existing solutions will have to be re-developed in java programming language to support accessibility. As the existing solution for Bradford Home-Hunter was developed in Asp.Net therefore the idea was to extend the existing solution for accessibility rather than re-developing it from scratch. The re-development could have been done if sufficient
reasons support this change. But, unfortunately J2ME based solutions are less accessible because of the reason described above.
Although these concerns are there but with the advent of new devices capable of having large memory and processor speed, J2ME based solutions are widely accepted; but the n again our solution will have no backward integration for devices which do not support J2ME.
This chapter highlighted the importance of mobile network devices and on the fact that applications are now accessible to multiple platforms all over the world. Therefore, the web developers of today have to be more careful and dynamic when designing their web applications.
In Chapter 3, we will discuss what Microsoft has to offer when it comes to accessible web applications. We will discuss the architecture of Asp.Net in general and Asp.Net mobile controls in particular.
Chapter 3
Microsoft Asp.Net
Mobile Controls
3.1. Microsoft .Net
As the emphasis of this report is on Microsoft based technologies for designing multiplatform web applications therefore a separate section had to be dedicated to Microsoft based solutions.
Microsoft has two different platforms to support device independent applications [25, 26], these are:
§ Microsoft Smart Device Extension (MSDE)
§ Microsoft Asp.Net Mobile Controls
Let’s take a detailed look at these software platforms.
3.1.1
Microsoft Smart Device Extension (MSDE)
Microsoft SDE is a reply to J2ME i.e. it is a set of essential APIs for application development for various client devices [27]. The content developed by MSDE is executed by Common Language Runtime (CLR) to satisfy client’s request. CLR is a Virtual Machine (VM) or Virtual Layer which is pre-installed on the client device. The application code is either pre-installed or downloaded to the machine. The main difference between MSDE and J2ME is that MSDE is for application development rather than web application (or website) development. As MSDE is similar to J2ME and both cannot be used for web application development because of very limited support therefore the most suitable solution for web applications is something which can execute on a pre-installed web browser rather than a virtual machine like JVM or CLR.
Now we have finally reached to a point where we can discuss the essence of this dissertation i.e. the technology which makes the dream of “Write Once, Use Anywhere” a reality.
3.1.2
Microsoft Asp.Net Mobile Controls
Microsoft Asp.Net mobile controls enable the developers to extend their application to multiple devices and platforms with less effort. MMIT consists of a set of APIs which contain essential
mobile controls for device independent web application development. A mobile control is like any other web control but its quality is that it is rendered differently on different devices by itself. Some examples of mobile controls are a text box control, a button control, a hyperlink
control or a validation mobile control. As mobile controls are additional APIs to Asp.Net therefore to understand mobile controls first we have to understand the architecture of Asp.Net itself.
3.2. Asp.Net Architecture
Discussing the Layered architecture of ASP.Net is not the scope of this report instead how Asp.Net manages to deliver content to multiple devices needs a special attention therefore we will discuss how Asp.Net presents information to multiple devices at the same time.
Asp.Net data presentation (user interface) architecture is based on very well known Model-View-Controller (MVC) design pattern. The Model-Model-View-Controller (MVC) design pattern consists of three essential elements [28,29]:
§ Model, the business logic required to run the application. § View, the customized user interface for each client.
§ Controller, the class which connects model to the view and handles all input/output delegation between them.
Asp.Net provides Code-Behind model to implement MVC into a web application. The mapping between MVC and Code-Behind model is as follows:
§ A web developer implements a View (web page) in asp.net. This page handles the presentation logic of the website i.e. it contains tables, panels and other controls. This page acts as a View in the MVC architecture.
§ The developer then writes the Code Class working behind the presentation layer. This class is responsible for event handling, implementing security and other important features for the View (web page). Multiple Views can have a single class working behind them. This Code Class acts as a Controller in the MVC architecture.
§ The class which implements the business logic for the application acts as a Model in the MVC architecture.
Figure 3.1
§ As we can see from Figure 3.1, that there are multiple views for multiple devices which are supported by a single Code-Behind (Controller) Class. This approach helps a programmer to separate the business, control and presentation logic from each other. The most important point which is to be noted in Figure 3.1 is that Microsoft Asp.Net offers the concept of Default or Generic View which can be seen in the figure on top left corner. This Default View is contender for Automated Rendering
by the Asp.Net compiler.
§ Automated Rendering is the procedure through which the Asp.Net compiler translates source mobile control into a control which can be displayed on the client device. This process is similar to translation but the only difference is the way translation can be done is in the hands of the developer herself rather than the application server or the gateway. How this is achieved shall be discussed shortly.
The task is to experimentally prove that this Default or Generic View is not only accessible to multiple platforms, but also can be specialized for a particular device as well. Let us now learn more about the mobile controls which are used to generate a default or specialized view.
Mobile Phone View1 PDA View2 Desktop PC View3 Code-Behind Class (Controller)
Business Logic Class (Model) Default
3.3. Asp.Net Mobile Controls
Asp.Net offers a basic set of mobile controls which are render-able on major web browsers. These web browsers are supported by over 260 different devices. Asp.Net offers extensibility for new browsers and devices, and also provides mechanisms to write new mobile controls. In this chapter we’ll only outline the basic set of mobile controls offered by Asp.net. In Chapter 5 we will discuss the implementation of these controls in detail. Here is a list of various mobile controls offered by Asp.Net [30, 31, 32, 33]:
Control
Description
Command
A control used to invoke events. Similar to submit button on html forms. Has two versions, can be displayed as button or a link. The link support is for the devices which cannot display buttons.
Form
A container control for other controls. Similar to a web form or a web page. Mobile form control can be composed of many panels containing different controls.
Panel Capable of containing other controls. Panel controls can be contained within a form or other panel controls.
Label, TextBox, TextView
Used to display textual information.
Image Used to display images of various formats e.g. bmp, jpg, wbmp etc.
Validation Controls
Validation controls for input validation. For example:
ValidationSummary, RangeValidator, RegularExpressionValidator, RequireFieldValidator, CustomValidator, CompareValidator.
List, SelectionList These controls are used to display list of items Figure 3.2
These controls are successfully mapped to different controls on the target device. However if used properly they are extensible to new devices and platforms as well which are not supported by Asp.Net at the moment. Chapter 5 will discuss the use of these controls and will show how we can fine tune these controls to bring the best out of them.
Chapter 4
Bradford Home-Hunter
Selected Case Study
4.1. Introduction
Social housing refers to cheap housing provided by local authorities or by non-profit housing associations, for individuals or families who cannot afford to rent houses in the private sector, either due to a low income or because of a large family size. Housing is also provided for special individual needs which cannot be satisfied in the private sector. “Social housing is also referred to as ‘council housing’ ” [34].
The Bradford Home Hunter works in partnership with Bradford Community Housing Trust (BCHT), housing associations and private landlords aimed to provide local residents with information of rented accommodation. It offers the following free services to local clients:
§ Property search
§ Property bidding
§ Member home swap
§ Disability/Health related facilities
§ Garages
Let us now take a look at the existing solution for Bradford Home-Hunter.
4.2. Existing Solutions
The existing web application for Bradford Home-Hunter is an Asp.Net solution having the following functionalities. There are two important parts of the application [35]:
§ Internal website and § External website
The internal website is for the employees of Bradford Home-Hunter. This part includes [35]: § Managing customer accounts
§ Searching Properties based on client’s requirements § Bidding on behalf of client
The external website is visible to general public where they can manage their own account information, search properties or bid on the properties of their choice.
As for my scenario internal website was only accessible by desktop users (i.e. employees using Desktop PCs), therefore I did not had to re-develop the internal site of the application. On the other hand as I had to make sure the accessibility of external website to multiple client devices therefore I chose to re-factor the external website for Bradford Home-Hunter which is accessible to general public.
It is also important to note here that as the existing solution was based on .Net framework therefore there was an obvious temptation for me to choose .Net as a first candidate for my solution. Although this was not the only reason for choosing .Net for my solution but certainly it was one of the major reasons I chose to develop my solution using .Net framework.
Figure 4.1 shows the system architecture for the existing application for Bradford Home-Hunter.
Figure 4.1
Figure 4.1 shows that the system is divided into a 3-tier architecture, in which we have the presentation tier, the business tier and the data tier communicating with the database for the application. The Presentation Tier manages the User Interface in the form of
Model-View-Bidding
View3 Manager Bidding
Property Manager Property View2 Member Manager Member View1 Database
Controller (MVC) Architecture. The Business Tier holds the Business Model Classes such as Member Manager to manage user accounts, Property Manager to manage property information and Bidding Manager to manage bidding rules for property bidding. The Data Tier delegates the request and response between business classes and the company database.
The existing system does satisfy most of the business rules specified by Bradford Home-Hunter yet:
§ Its accessibility is only limited to a particular group of users i.e. device users using average or high bandwidth supported web browsers such has Internet Explorer or Netscape Navigator.
§ It only supports HTML enabled browsers. As Asp.Net content is translated to HTML response by the web server.
§ It supports only those devices capable of rendering HTML content only such as PDAs and Smart Phones but there is no guarantee of how the content will be rendered to the target browser.
§ It has no facility to take advantage of special capabilities of a device, for example, calling or text (SMS – Short Messaging Service [36]) facility of a mobile phone.
4.3. Revised System Requirements
Bradford Home-Hunter wants to revise their existing system. They want their website to accessible by large number of clients. For this reason they have the following set of revised system requirements:
1. The web application should be accessible to multiple platforms so as to extended existing application to new users.
The most important functional requirement for the new solution is that it should be accessible and usable on many devices rather than only desktop PCs or laptops. These new devices should range from PDAs to mobile phones, Digital Televisions to any new device released in future.
2. The extension of existing application should not be at the cost of loosing any presentation experience or business logic from existing solution.
This functional requirement means that the new web application should have an identical user interface as the existing application for the devices which are already supported i.e. Desktop PCs. The user interface for other devices however might differ but the basic look and feel of the application should be the same.
The functional requirement also specifies that the business tier of the application should not be altered to support this change.
3. The application should automatically reconfigure itself according to the capabilities of the client device.
This functional requirement demands that there should be Only One version of the application and that version should automatically re-configure itself to suit the needs of the client device.
4. The researcher should identify and specify some sort of rules or best practices to accomplish multiplatform web application development.
Although this functional requirement is a secondary requirement yet it is important for the extensibility of the application over new platforms and devices. These set of rules will be employed for future releases of the application and for maintenance purposes. The best practices will also be helpful for any new developer who wants to implement their web applications for new platforms.
4.4. The Challenge
Writing a website once and running it anywhere is a challenge itself. However, the challenge further extends while implementing additional features such as handling multimedia content, applying security and taking advantage of device specific features. With the introduction of
functional requirement no. 2 (i.e. to make sure that the new website should look identical to the existing website) the challenge gets more interesting.
Chapter 5
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 " />
<Choicefilter="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
property to true in the web.config configuration file. This example proves how easy it is to extend your existing application security to wireless devices having limited or no memory. Chapter 6 evaluates the use of cookieless security in more detail.
if ( str1 == "Yes" && str2 == "No" ) {
Session["RegisterationManager"] = manager;
Response.Redirect("PersonDetail.aspx"); }
5.5. Extensibility Issues
The whole point of device independence and accessibility is that on every new day, a new peace of hardware comes into the market with internet support on its fingertips. That device might have better and improved capabilities than its competing devices. To reach these users who own such devices asp.net provides its extensibility model.
There are two types of extensibility supported by Asp.Net: § Extensibility of web application to new devices and § Writing new mobile controls for existing devices
Let us understand them in detail under the context of Bradford Home-Hunter prototype.
5.5.1 Extensibility to New Devices
As we know by now that the same mobile control is rendered differently for different devices with the help of adaptive rendering model. The process of adaptive rendering takes help of different device adapters [45,46].
“A device adapter defines a specific set of characteristics for a particular requesting device.” [44]. Device Adapters are defined within web.config or machine.config configuration files.
Machine.config file is similar to web.config but it contains system wide configurations. If a hierarchy (folder) does not contain a web.config file, web.config file of a higher level hierarchy (folder) is applied. However in the absence of any web.config file, machine.config file provides the system wide configurations for the application.
Device Adapters can be created in two ways either by simply copying pasting an existing device adapter within the machine.config file and giving it another name or by writing a device adapter from scratch.
The
first approach works best for similar devices sharing similar functionalities and
capabilities. For example, device adapter for a new model of Pocket PC named RIM957 can becreated simply by copying the device adapter code for an existing model and making the necessary changes.
The second approach is for a totally unknown device which has no existing similarity with an existing device adapter within machine.config. This is rare as Microsoft already provides support for over 260 devices and every new device does follow most of the standards as supported by other devices. This similarity to an existing device makes the job easier for the developer to extend her application to the new device. To make the job even easier for her Microsoft provides frequent device updates which contain device adapters for many new devices.
Figure 5.15 shows device adapter for Pocket PC running Windows CE (compact edition). The code is a sample configuration block from machine.config file:
Figure 5.15
As we can see in Figure 5.15, a device adapter is merely a set of properties or capabilities owned by a device. <case match="WinCE"> mobileDeviceModel = "Pocket PC" platform = "WinCE" inputType = "virtualKeyboard" defaultScreenPixelsWidth = "240" defaultScreenPixelsHeight = "320" defaultScreenCharactersWidth = "30" defaultScreenCharactersHeight = "14" isColor = "true" screenBitDepth = "16" supportsFontSize = "true" supportsFontName = "true" supportsFontColor = "true" supportsDivAlign = "true" supportsItalic = "true" </case>
5.5.2 Writing new Controls for Existing Devices
At present Asp.Net provides a limited set of input and output controls necessary for application development. However, there are some occasions when we want to optimize our website with some special controls such as a movie player control or a 3D graphics player control. Asp.Net elaborates step by step procedures for developers to write new controls for their web applications.
I also wanted to take advantage of this opportunity and to test this functionality offered by Microsoft Asp.Net. I chose to write and use my own mobile control which automatically renders differently to different devices.
The controls I chose to write for my application is the Menu control. Similar to a Menu Bar, the Mobile Menu control can be used within any web page. This control is an example of software and component reusability within my web applications. Here is a small code script from the mobile control declaration file “Menu.ascx”:
Figure 5.16
The first line declares that this mobile control is a user control written in csharp language. The second line imports other mobile controls which are used to compose the Menu control. Rest of
<%@ Control Inherits="System.Web.UI.UserControl" Language="cs" %>
<%@ Register TagPrefix="Mobile" Namespace="System.Web.UI.MobileControls" Assembly="System.Web.Mobile" %>
<mobile:Image runat="server" AlternateText="Homepage"NavigateURL="index.aspx"> <DeviceSpecific>
<Choice filter="isWml" ImageURL="" />
<Choice filter="isHtml" ImageURL="images/buttons/Home.gif" />
</DeviceSpecific>
</mobile:Image>
<mobile:Image runat="server" AlternateText="About"NavigateURL="About.aspx"> <DeviceSpecific>
<Choice filter="isWml" ImageURL="" />
<Choice filter="isHtml" ImageURL="images/buttons/About.gif" />
</DeviceSpecific>
the lines demonstrates the use of Image mobile control to constitute this Menu bar. Image control used in the code itself uses <DeviceSpecific> rendering to render differently to different devices.
5.6. Conclusion
This section concludes the objectives of the chapter. In this chapter we first defined important issues for multiplatform applications such as Usability Issues (input, output issues), Accessibility Issues (page navigation, security) and Extensibility Issues (extending application to new devices, writing new controls). This chapter also presented configurations and code segments produced for Bradford Home-Hunter prototype so it would be easier for the reader to understand and learn by example.
In next chapter we will test and evaluate the Bradford Home-Hunter prototype for usability and accessibility. In Chapter 6 we will also discuss how well we have been able to solve the issues related to multiplatform web applications and which factors are under consideration for future changes. Chapter 6 will also identify some problems or known issues related to asp.net mobile controls so developers can keep these issues in mind while developing there applications using Asp.Net.
