Advanced Mobile Control Topics

We've now covered all of the controls and their basic usage. However, there will often be times when you want to display them in better ways, particularly in HTML pages to avoid them looking too bland , or change their default behavior in some way. There are four ways you can achieve this:

• Styling :All the controls give us a degree of influence over the way they look, from basic color schemes to more involved styling.

• Using device capabilities :The controls give us access to many of the capabilities specific to a device, so you can tailor content accordingly .

• Templating :Adding templates to controls allows you to add extra code to output, both HTML and WML.

• Pagination :Splitting lengthy text over several pages

Styling

As mentioned earlier, all the mobile controls have a set of styling attributes you can use. The basic ones are:

Attribute	Description
Alignment	NotSet , Center , Left , or Right “ for text alignment.
BackColor	The background color for the control.
ForeColor	The foreground color for the control.
Font	The font to use for text display. This is split into Font- Name , Font- Size ( Normal , Small , or Large ), Font-Bold ( true or false ), and Font-Italic ( true or false ).
Wrapping	Wrap , or NoWrap . Whether to 'wrap' text, where wrapping text means to place it on multiple lines if possible.

Most of these are self explanatory, but bear in mind that WAP browsers will ignore many of these attributes. As an example, let's look at a very simple <mobile:Label> control with added formatting:

  <mobile:Form runat="server" BackColor="Azure">   <mobile:Label runat="server" ForeColor="BlueViolet" Alignment="Center"   Font-Bold="true" Font-Size="large"   Font-Name="Arial">This is some formatted text.</mobile:Label>   </mobile:Form>  

Figures 21-40 shows the results on various browsers:

Figure 21-40:

The BackColor attribute from the form propagates through to the label. Notice, also, that neither the Nokia 5100 nor the Openwave simulator apply color formatting. This is because they are using the WML version of the output, not the HTML version. Even though the devices support color, it isn't used by the mobile controls in this case.

In addition to the attributes shown in the preceding code, there is one more: StyleReference . This attribute enables you to refer to a separate style, defined in a <mobile:StyleSheet> control by a <Style> element. <mobile:StyleSheet> controls result in no rendering at all, and are not contained in <mobile:Form> controls, but they allow you to specify named collections of style attributes that you can apply to multiple controls in your page. For example, you could rewrite the preceding code as:

  <mobile:StyleSheet runat="server">   <Style Name="textStyle" ForeColor="BlueViolet" Alignment="Center"   Font-Bold="true" Font-Size="large" Font-Name="Arial"   BackColor="Azure"/>   </mobile:StyleSheet>     <mobile:Form runat="server" StyleReference="textStyle">   This is some formatted text.   </mobile:Form>  

You can define as many styles as you want in this way and use them in as many controls as you like.

Using Device Capabilities

In the earlier discussion of <mobile:Image> , we capitalized on the fact that a filter can detect whether a browser supports HTML or WML. The use of <DeviceSpecific> and <Choice> elements along with information added to web.config allowed us to customize the output of mobile controls. In actual fact we've only scratched the surface of what is possible here so far.

If you look in your machine.config you'll see that a large volume of text there applies to mobile controls. Much of this is concerned with determining the capabilities of connecting devices by interrogating the HTTP headers received.

There is no worldwide standard implemented for this. Some browsers such as the Openwave send additional device capability headers to servers. Others, like the Motorola T720, don't. Because of this, many capabilities have been found out manually, and are hard coded in machine.config . The reasoning goes that if you have enough information to identify a device then you can specify its capabilities.

Note

One emerging standard (not yet supported by ASP.NET mobile controls) is to pass a HTTP_X_WAP_PROFILE header specifying a remote XML document specifying device capabilities. The Ericsson T610, for example, directs browsers to http://wap.sonyericsson.com/UAProf/T610R101.xml. This document is a Composite Capabilities/Preferences Profile (CC/PP), which is in turn an application of the Resource Description Framework (RDF). This approach shows a lot of promise, and if you would like to learn more about it see http://www.ccpp. info .

The list of capabilities that is set in machine.config is quite a long one, and I won't reproduce it here. It includes entries as simple as whether a device has a color screen ( isColor ), entries on specific WML rendering characteristics (such as rendersBreaksAfterWmlAnchor ), screen dimensions (including defaultScreenPixelsWidth ), and so on. There are sections for many current devices, for example Nokia, which starts by assigning some general Nokia browser characteristics:

  <!-- Nokia -->   <case match="Nokia.*">   browser = "Nokia"   mobileDeviceManufacturer = "Nokia"   preferredRenderingType = "wml11"   preferredRenderingMime = "text/vnd.wap.wml"   preferredImageMime = "image/vnd.wap.wbmp"   defaultScreenCharactersWidth = "20"   defaultScreenCharactersHeight = "4"   defaultScreenPixelsWidth="90"   defaultScreenPixelsHeight="40"   screenBitDepth = "1"   isColor = "false"   inputType = "telephoneKeypad"   numberOfSoftkeys = "2"   hasBackButton = "false"   rendersWmlDoAcceptsInline = "false"   rendersBreaksAfterWmlInput = "true"   requiresUniqueFilePathSuffix = "true"   maximumRenderedPageSize = "1397"   canInitiateVoiceCall = "true"   requiresPhoneNumbersAsPlainText = "true"   rendersBreaksAfterWmlAnchor = "true"   canRenderOneventAndPrevElementsTogether = "false"   canRenderPostBackCards = "false"   canSendMail = "false"   isMobileDevice="true"  

and has additional sections for individual devices, such as the 7110:

  <case   match="Nokia7110/1.0 \((?'versionString'.*)\)">   type = "Nokia 7110"   version = ${versionString}   <filter   with="${versionString}"   match="(?'browserMajorVersion'\w*)(?'browserMinorVersion'\.\w*).*">   majorVersion = ${browserMajorVersion}   minorVersion = ${browserMinorVersion}   </filter>   mobileDeviceModel = "7110"   optimumPageWeight = "800"   screenCharactersWidth="22"   screenCharactersHeight="4"   screenPixelsWidth="96"   screenPixelsHeight="44"   </case>  

Here the match attributes are compared with the HTTP_USER_AGENT header to identify the device, and set the capabilities accordingly.

The important thing to realize here, is that this is an extensible system. There are plenty of devices already in this file, but you can add your own, perhaps including the capabilities of the browser built into your fridge or whatever. You could even add devices that support some odd proprietary format should you wish to.

Note

The ASP.NET mobile controls team at Microsoft also release periodical updates to these device definitions via http://msdn.microsoft.com/vstudio/device/mobilecontrols/aspmobiledrivers.aspx. However, even the latest of these at the time of writing (Device Update 3.0) doesn't include most of the browsers examined in this chapter. This explains one or two of the quirks you have seen, such as the lack of support for color displays. XHTML rendering is one of the features added by this update, shown in Figure 21-41:

Figure 21-41: Figure courtesy Openwave Systems Inc.

Once device capabilities have been set, you have access to them from your code in two ways. The simplest is through the System.Mobile.MobileCapabilities class.

This class has a number of properties that relate to device characteristics, such as the number of characters that can fit in a screen row, whether color is supported, and what markup language is preferred. <Choice> elements can access these properties via their capability attribute, which is how the preferred markup type was chosen earlier. We were actually testing for the value of the preferredRenderingType property of the MobileCapabilities object containing information about the current browser.

You can also access these capabilities programmatically. The following code outputs the value of preferredRenderingType to the screen:

  <mobile:Form runat="server" id="first" OnActivate="first_activate">   <mobile:Label runat="server" id="devCaps"/>   </mobile:Form>     <script runat="server">     Public Sub first_activate(o As Object, e As EventArgs)   devCaps.Text = "preferredRenderingType = " & _   Device.PreferredRenderingType   End Sub     </script>  

This results in the output shown in Figure 21-42:

Figure 21-42:

Using this method you can make dynamic choices in your code based on device capabilities.

The other method is the one you briefly saw earlier, involving setting up filters and using them declaratively in your code. Setting filters involves adding <filter> elements to the <deviceFilters> section, of the <system.web> section, of the web.config file for your application.

The format of these <filter> elements is simple:

  <filter name="filterName" compare="devCap" argument="compareString" />  

Specify a name for the filter with filterName , a device capability (as specified in machine.config ) with devCap , and a string to compare with the string content of the capability. The filters set up earlier are now pretty self-explanatory:

 <deviceFilters>    <filter name="isHTML32" compare="preferredRenderingType"            argument="html32" />    <filter name="isWML11" compare="preferredRenderingType"            argument="wml11" /> </deviceFilters> 

Once you have configured your filters you can use them in any mobile control with <DeviceSpecific> and <Choice> elements. The simplest use of these is to override or provide extra attributes, as with the earlier example:

  <mobile:Image runat="server" AlternateText="Lizard" ImageURL="lizard.bmp">   <DeviceSpecific>   <Choice ImageURL="lizard.wbmp" Filter="isWML11"/>   </DeviceSpecific>   </mobile:Image>  

Here, the only attribute of <Choice> that is specific to the <Choice> element is Filter , all others are applied to the parent control. This means that the ImageUrl attribute is overridden here.

<Choice> elements can also be used to contain templates, which are the subject of the next section.

Templates

Much like the standard ASP.NET controls, it is possible to extend the way mobile controls are displayed using templates. Unlike ASP.NET controls, you can do this on a device-by-device basis using the <DeviceSpecific> and <Choice> elements discussed in the last section.

A given template will specify markup to use for display purposes, which, for example, might be as simple as specifying a section of HTML that is always output prior to the standard HTML output of a mobile control in a Web browser, or might be more complex.

There are five mobile controls that allow templating: <mobile:Form> , <mobile:Panel> , <mobile:Image> , <mobile:List> , and <mobile:ObjectList> . There are eight available templates:

• ContentTemplate : Markup for replacing entire control output

• HeaderTemplate : Markup to place before the control

• FooterTemplate : Markup to place after the control

• LabelTemplate : Markup to use for rendering the label of an item in an ObjectList

• ItemTemplate : Markup to use for each item contained in the control

• AlternatingItemTemplate : Markup to use for every other item contained in the control

• ItemDetailsTemplate : Markup to use for rendering the details for an item in an ObjectList

• SeparatorTemplate : Markup to place between each item contained in the control

These apply to the templatable controls as shown in the following table.

Templates are specified within elements having the same name as the template in question, and contain markup to use.

The clever part here is that these elements are contained within <Choice> elements, allowing you to provide different templates for different devices (in much the same way as different images were used in the <mobile:Image> control), for example:

  <mobile:Form runat="server" id="first" title="Back to Front">     <DeviceSpecific>   <Choice Filter="isHTML32">   <HeaderTemplate>   <table width="100%" cellpadding="4" cellspacing="2"   bgcolor="black">   <tr>   <td align="center" colspan="2" bgcolor="blanchedalmond">   <font face="Arial Black" size="5" color="black">   Back to Front   </font>   </td>   <tr>   <td width="25%" bgcolor="Gold" valign="top">   <font face="Verdana, sans-serif" size="2"><b>   <a href="/index.aspx">Home</a><br>   <a href="/links.aspx">Links</a><br>   <a href="/about.aspx">About</a><br>   <a href="/discuss.aspx">Discuss</a><br>   <a href="/contact.aspx">Contact</a>   </b></font>   </td>   <td bgcolor="coral" valign="top">   </HeaderTemplate>   <FooterTemplate>   </td>   <tr>     </table>   </FooterTemplate>   </Choice>   </DeviceSpecific>     The site that talks about what you don't want to hear about in a way that   makes it too confusing to follow anyway!     </mobile:Form>  

This code uses the header and footer templates to customize form layout. It requires the following filter in web.config :

  <filter name="isHTML32" compare="preferredRenderingType"   argument="html32" />  

On a WML browser the HTML template is ignored as shown in Figure 21-43:

Figure 21-43:

However, on an HTML browser such as the Pocket PC you can make better use of the available capabilities, as shown in Figure 21-44:

Figure 21-44:

The other templates when used with lists, can also be used to create excellent results, but an example of this isn't given here as their use is identical to formatting lists using the standard ASP.NET controls (although using a structure like the previous example's).

Templates can also be placed in stylesheets such that they can be reused in multiple forms. The template used in the last example is a good candidate for this, as it provides a structure for containing body text that might apply well to several forms.

Pagination

Pagination is specified and controlled from <mobile:Form> controls. In most cases the pagination functionality supplied by default is enough for us, so Paginate is set to off'. It can be turned on as follows :

  <mobile:Form runat="server" id="first" Paginate="True">   ...   </mobile:Form>  

Any text you specify in the form will then be split across screens where appropriate. For example:

 <mobile:Form runat="server" id="first" Paginate="true">  Tyger! Tyger! burning bright<br/>   In the forest of the night<br/>   What immortal hand or eye<br/>   Could frame thy fearful symmetry?<br/>   <br/>   In what distant deeps or skies<br/>   Burnt the fire of thine eyes?<br/>   On what wings dare he aspire?<br/>   What the hand dare seize the fire?<br/>   <br/>   And what shoulder, and what art,<br/>   Could twist the sinews of thy heart?<br/>   And when thy heart began to beat,<br/>   What dread hand? and what dread feet?<br/>   <br/>   What the hammer? what the chain?<br/>   In what furnace was thy brain?<br/>   What the anvil? what dread grasp<br/>   Dare its deadly terrors clasp?<br/>   <br/>   When the stars threw down their spears,<br/>   And watered heaven with their tears,<br/>   Did he smile his work to see?<br/>   Did he who made the lamb make thee?<br/>   <br/>   Tyger! Tyger! burning bright<br/>   In the forests of the night,<br/>   What immortal hand or eye<br/>   Dare frame thy fearful symmetry?<br/>   </mobile:Form>  

This text is rendered over several pages on the Openwave, Nokia, and Ericsson browsers, with Next and Previous links added automatically., as shown in Figure 21-45:

Figure 21-45:

The Pocket PC fits all this on one page as shown in Figure 21-46:

Figure 21-46:

This device does support pagination, but can fit more text in one page. In fact, it will fit another two paragraphs on the end of the Blake poem I've used here.