Building Pages for Small-Screen and Mobile Devices
| In Chapter 10, you saw a brief mention of the ASP.NET Mobile Controls that are part of the standard ASP.NET installation. In this section, you will see more details of these controls and how you can use them to create pages and sites that work on a range of mobile devices. Page Design and Device SupportAs you discovered in Chapter 10, the controls from the System.Web.UI.MobileControls namespace automatically change the markup and output they create to suit the type of device accessing the page. They can produce a range of different markup types, including HTML, Wireless Markup Language (WML), and other special compact forms of HTML such as cHTML that are used by some mobile devices. So does this mean that you can now build pages and even complete Web sites or applications that will work on any device? The answer is "yes," butin most casesyou probably will not want to. The reason has to do with the design of the page and how well it matches the devices on which it will be viewed. Although 2.5G and 3G cellular phones are appearing that have increased bandwidth and screen size compared to older GPRS phones, the fundamental issues relate more to the actual rendered page size versus the available screen size and to the input devices available on the client. For example, a common design for pages aimed at the traditional Web browser is multiple columns, separate navigation bars at the top or left, and a multitude of small text links or clickable images. This kind of page generally depends on the use of a mouse to navigate. On the latest cellular phones, there is generally no mouse, though there may be some kind of navigation pad. However, the majority of compact mobile phone devices can display only simple text, perhaps up to 20 characters per line over six lines, and may not even be able to display images. So, while the mobile Label, Command, or TextBox control can modify its behavior to suit the device and the markup language required, there is no real possibility of designing the layout of the entire page so that it "works" (in the usability sense) on all devices. In addition, this is not the aim of the Mobile Controls. Instead, they allow you to build pages using the same techniques, tools, and programming model; but you will generally have to implement different versions of your Web applications to suit the different major categories of devices you want to supportprobably one version for ordinary Web browsers and one version for mobile devices. Creating Pages for Mobile DevicesVisual Studio provides excellent support for developing Web sites and Web pages aimed at mobile devices. When you create a new site, or add pages to an existing site, you can select a range of items specific to mobile device development. The Visual Studio Toolbox also contains the full range of mobile controls that are ready to drag and drop onto your pages just as when you are building ordinary HTML Web pages. Figure 14.16 shows a mobile page under construction in Visual Studio, and you can see the range of mobile controls in the Toolbox in this screenshot. Figure 14.16. Creating a Mobile Device application in Visual Studio Notice that there is a major difference between a mobile page and an ordinary HTML page. Mobile pages allow you to add more than one server-side <form> to the page as long as you use the Form control from the Mobile Web Forms section of the Toolbox. This is because the way that mobile device pages work is quite different from normal HTML pages. Mobile devices generally have only limited memory capacity and processing power, as well as small screens, and so they work best when displaying only a few controls at a time. However, instead of creating multiple small pages, each with one screen of information, each mobile form acts as a single screen. In WML terminology, each form is a "card," and the set of screens that make up the mobile page is called (not surprisingly) a "deck." You then use server-side code within the page to specify the card to display, and you can switch between them as required to display them in an order that implements the equivalent of navigating between separate Web pages. The server holds the entire deck (page) in memory and sends to the device the appropriate card (form) on each postback. Issues to Consider with Mobile Device Web FormsThere are some important issues to consider when building Mobile Web Form pages. To conserve device memory, ASP.NET does not store viewstate in the card it sends to the client. Instead, it uses a key to store and retrieve the viewstate data from the user's session. This means that you must ensure that session support is available, andbecause many devices do not support cookiesyou will generally have to use cookie-less sessions for your mobile device pages. To enable cookie-less session support, you use the <session-State> element in the <system.web> section of web.config: <sessionState cookieless="true" /> Because the client makes multiple requests to view the cards in a page as they navigate between them, it is worth storing data you need in a separate card (mobile form) on the page. All the controls in all of the cards on the page maintain their values as inter-card navigation takes place, so you can use this "extra" card to store values and just not provide any route for the user to view it. The Mobile Web Forms Control SetThe comprehensive set of controls in the Mobile Web Forms control set provides all the features you are likely to need for building pages aimed at small-screen and mobile devices. The class MobilePage is the base class for all mobile pages, and it acts as the "deck." The basic form controls for displaying text and data, and collecting user input, are:
There is also a set of list controls that work much like those in the Web Forms control set, supporting data binding as well as the use of the declarative <asp:ListItem> approach:
There are some special controls for styling, generating rich output, or performing phone-specific tasks:
The mobile control set also includes a full set of validation controls that work in exactly the same way as the standard Web Forms equivalents:
All of these controls work in fundamentally the same way as the ASP.NET Web Forms equivalents, though with a limited number of propertiessome specific to mobile devices. Writing code to manipulate the controls is just like writing ordinary Web Forms code, and you use event handlers and the postback and event-driven architecture of ASP.NET in just the same way. Mobile Device FiltersMobile device pages are usually simple and contain very little in the way of formatting or device-specific output beyond that created by the controls themselves. This is because, if you place an element such as a horizontal rule <hr /> in a mobile page, it will be delivered to every device accessing the page. Many of the WML-based or other specialist devices will not recognize this element, and it will cause an error. Instead, you rely on the controls themselves to generate appropriate output. However, this does not mean you cannot add some of your own devicespecific output as long as you make sure that it is only sent to devices that recognize it. One way to do this is with device filters. You can define filters based on any of the properties exposed by the HttpBrowserCapabilities class, or the more specific MobileDeviceCapabilties class. For example, Listing 14.15 shows a web.config file that declares four device filters, using the Browser and PreferredRenderingType properties.
When multiple browser definitions or device filters match the current client, the one that specifies the device with the most precision is chosen, though the settings specified in definitions from which this one inherits are also available if not overridden. For example, an Ericsson T86 phone will expose all the properties defined for a browser definition named Ericsson T86 plus any that are not overridden here from a general definition aimed at all Ericsson devices, as well as any that are exposed from the WmlBrowsers definition. Listing 14.16 shows one way you can use device filters like those declared in Listing 14.15. When delivering an image to a mobile device, you must ensure that it is of the correct formatmost mobile phones that accept WML require a two-color image in the special WBMP format. The Image control in Listing 14.16 uses a DeviceSpecific control to select the correct image file at runtime, depending on the filter that applies to the current device. The AlternateText attribute specifies the text that the device will display if it does not support images. Listing 14.15. A web.config file That Declares Device Filters for Different Device Types
Listing 14.16. Using a DeviceSpecific Control with the Device Filters
Mobile Device StylesheetsA second technique for adding device-specific content to the output is with a StyleSheet control. You declare one or more <mobile:Style> sections within the StyleSheet control, each identified by a unique Name. Within each <mobile:Style> section, you can use DeviceSpecific controls to specify the output depending on filters declared in your web.config file. Listing 14.17 shows an example of this approach, which uses templates to add some bold text and a series of <font> elements to the head of every page and then closes the <font> element at the foot of every page when the client is a normal HTML-supporting device. For other devices, it just outputs the text "Dave and Al" within a standard <p> element, which all devices recognize. Listing 14.17. A StyleSheet Control Containing Device-Specific Content
You can then apply this stylesheet to any of the cards in the deck by specifying the Name of the stylesheet as the StyleReference attribute of the mobile form element that implements the card: <mobile:Form runat="server" StyleReference="styMenu"> . . . </mobile:Form> A Simple Mobile Web Forms ExampleAs an introduction to the mobile controls, this simple example uses a selection of the controls to create an application with three cards or forms. Listing 14.18 shows the page directives that specify this is a mobile page and then import the required assembly. Visual Studio adds these automatically when you create a new Mobile Web Forms page. Following this are the opening <html> and <body> tags, and the first form. By default, the first form is the one shown when you first load the page. This form contains an Image element with a nested DeviceSpecific element, as discussed earlier in this section, which sets the appropriate value for the ImageUrl property of the Image control. Following the Image are a Label and a TextBox control, and a Command with the caption Next that executes the server-side routine named cmdName_Click. Listing 14.18. The Page Directives and the First Form in the Example
The other two forms on the page, shown in Listing 14.19, contain a Label and Calendar control, and a List and two Link controls. Selecting a date in the Calendar will execute the server-side routine named Calendar1_SelectionChanged. The List control declaration is empty, because code will populate it at runtime. The first Link controls point to the first form (with the caption Home), by using the familiar URL syntax of a hash followed by the name of the target form as #Form1. The second Link control points to an external Web site. The page also contains the StyleSheet you saw in Listing 14.17. Listing 14.19. The Remaining Two Forms and Stylesheet in the Example
Listing 14.20 shows the complete server-side code for this example. The event handlers for the TextBox on the first form, and the Calendar on the second form, simply activate the next form by setting the ActiveForm property of the default MobilePage class. The final method handles the Page_Load event of the third form. As you can see, it uses the same class file as in the previous section on accessibility (An Example of an Accessible Page) to get a DataSet containing a list of languages and a count of the number of visitors for a fictitious Web site. However, in small-screen devices, you often cannot display data in a table. One way around this is to concatenate the values in each row as single text strings and then display them in a suitable list control. In this example, the code adds a new column to the table in the DataSet and sets an expression for the column that combines the language name and the number of visitors into a text string. Then the code binds the List control to the table, specifying that it should display the contents of the new column (named DisplayText). Listing 14.20. The Code for the Mobile Web Forms Example Page
You can see the results of this example in Figure 14.17. A reduced-size Internet Explorer browser window gives you a good idea what the page will look like in a Pocket PC device, and you can see that the content looks much the same as normal Web pages built as a Web Forms application. Figure 14.17. The application viewed in an HTML device, such as a Pocket PC However, if you view the same page in a mobile phone emulator, the result is very different (see Figure 14.18). The two-color image appears this time, and all navigation is through links. The behavior of a TextBox control is entirely different (depending on the device type), and the Calendar control uses a multistep process to collect the date, because it cannot display it as a table. Finally, the list of languages and visitors shows as a series of text strings, as created by the expression in the new column of the DataTable. Figure 14.18. The same page viewed in a mobile phone emulator It is interesting to look at the code that the mobile controls actually create when the client is a WML-enabled device such as a mobile phone or emulator. The code varies depending on the type of device and the features it supports, but Listing 14.21 shows a typical example. Notice that the <html> and <body> elements in the original source of the page (required in Visual Studio) are automatically removed and replaced by the <wml> and <card> elements. You can also see that ASP.NET only sends the current card to the device, minimizing the memory requirements. Listing 14.21. The WML Code Generated by the Page for a Mobile Phone
Mobile Browser EmulatorsVisual Studio includes some device emulators that you can use to view your pages. However, the selection is limited to Pocket PC devices designed for use with the Compact Framework, and a few SmartPhone emulators. All of these expect to receive HTML, and so you will not see the output as it appears for WML devices. If you do not have a mobile device to test your pages, you can use one of several other emulators to simulate a mobile phone, including the following:
Using one of these emulators allows you easily to test how well your pages work on a WML-enabled device. Of course, mobile devices include PDAs and phones based on Windows Pocket PC. Although these devices feature a version of Internet Explorer, you still face the problems of a small screen size, so you need to adjust and test your pages accordingly. Find out more about Microsoft Mobile Support at http://www.microsoft.com/windowsmobile/. |
EAN: 2147483647
Pages: 147