Professional ASP.NET 1.0 Special Edition- P39 pptx

Mobile Controls The Mobile Internet Toolkit is an extension to the controls available in the .NET framework that adds support for mobile devices.. It is a collection of controls that, wh

To decrypt the message, we use the same attribute, but add it to the proxy that the application using our service uses:

<EncryptionExtension(Decrypt=DecryptMode.Request)> _

<SoapDocumentMethodAttribute("http://tempuri.org/SayHello",

Use:=SoapBindingUse.Literal,

ParameterStyle:= SoapParameterStyle.Wrapped)> _

Public Function SayHello() As String

Dim results() As Object = Me.Invoke("SayHello", New Object(0) {})

Return CType(results(0),String)

End Function

Instead of setting an Encrypt property in the EncryptionExtension attribute, we now set a Decrypt property This instructs the EncryptionExtension to decrypt any incoming messages The result is that data is encrypted on the wire

as it's exchanged, and decrypted again by the intended recipient

The ProcessMessage function of EncryptionExtension follows:

public override void ProcessMessage(SoapMessage message) {

private void Encrypt() {

XmlTextReader reader = new XmlTextReader(streamToEncrypt);

XmlDocument dom = new XmlDocument();

byte[] outData = Encrypt(node.InnerText);

StringBuilder s = new StringBuilder();

for(int i=0; i<outData.Length; i++) {

Although this is quite a complex sample, it should provide you with an excellent starting point with which to build more secure Web Services Here are some recommendations:

ƒ Ideally this encryption extension should be using asymmetric encryption, rather than having both the web service and the proxy sharing the same key

ƒ A SOAP header should be used to send additional details about the message relating to the encryption For example, details of the public key (if you were to re-implement this to support asymmetric encoding), as well as

an encrypted timestamp to prevent replay attacks should be sent

ƒ Currently the message exchange only supports clear-text requests (from the proxy) and encrypted results Ideally, the extension should support encrypted requests

These suggestions are beyond the scope of what can be covered in this chapter However, hopefully they will be implemented in the near future and released into the public domain

Summary

We started this chapter by discussing the general problem of finding Web Services that we might want to use To address the problem we looked at Universal Description, Discovery, and Integration (UDDI), and how organizations can use it to find and register Web Services We then stepped through the use of UDDI, using Microsoft's UDDI node, to demonstrate its typical use in discovering SOAP Web Services

After discussing the uses of UDDI, we mentioned that we still needed a way of describing the capabilities of Web Services, such as the protocols they support as well as the data types and XML schemas that may be used To address this problem,

we introduced Web Service Description Language (WSDL)

Thanks to WSDL, we can build software based on the XML blueprint of a web service We discussed the use of both Visual Studio NET, and the command-line tool wsdl.exe to create this proxy software After creating proxies with both of these tools we demonstrated how to use them and stepped through some common scenarios, including setting the timeout value and using HTTP cookies

Following our discussion of building NET proxies for Web Services, we diverted our discussion to HTML screen scraping and how we could use a simple WSDL document and the support for regular expressions in NET to easily turn any web site into a Web Service

Next we mentioned several design decisions for Web Services We looked at handling exceptions and how to use SOAP headers to send out-of-band data (that is, data that doesn't belong as part of the body of the SOAP message)

Finally, we discussed Security - both the options provided by ASP.NET, such as Forms or Windows authentication, and some custom security and encryption options that can be implemented

That completes our coverage of Web Services In the next chapter we'll turn our attention to Mobile Controls

Mobile Controls

The Mobile Internet Toolkit is an extension to the controls available in the NET framework that adds support for mobile devices It is a collection of controls that, when placed in ASP.NET pages, will vary their output depending on the browsing device, and allow for content types other that HTML, such as WML (Wireless Markup Language) and cHTML (Compact HTML)

In this chapter we will detail these controls and give examples of their use We'll start with a tour of the wireless web, with

a look at what is available and a discussion of WAP Next we'll look at the mobile controls, including a reference section

on the controls available Moving on, we'll see some of the more advanced techniques we can use to streamline mobile web applications, before finishing off with a few guesses as to what the future holds for mobile controls, and wireless Internet access

A Summary of the Wireless Web

Recently, there has been a huge surge of interest in wireless Internet access, and indeed in mobile computing in general

As we have become increasingly dependent on the World Wide Web we have developed a desire to access it from anywhere The technology now exists to enable us to do this, although the exact nature of this access is quite different from 'traditional' Internet access

This difference has caused many problems, both for device manufacturers and consumers, as it has frequently been overlooked Often, consumers have expected to get an all-singing, all-dancing, web-surfing gadget, and have been disappointed with what they have ended up with However, the underlying potential of such devices is unquestionable In order to make sense of this we need to look at features inherent in the types of device that can be used for mobile Internet access The most obvious of these features is that the device will be small It follows on from this that:

ƒ Display area is limited, being far smaller than a PC monitor and (at least in the immediate future) likely to lack the associated color capabilities in order to maximize battery life and minimize cost

ƒ Processing power and memory is unlikely to compete with PCs

ƒ Multimedia capabilities will be severely challenged

Already it's obvious that we cannot expect the sort of web experience that we are becoming accustomed to using web browsers on our PC To further illustrate this, consider the Wrox web site displayed on the screen of an Internet capable mobile phone:

I think you'd have a hard time navigating through this site- if you could even read it!

Of course, larger screened devices are available, such as the (significantly more expensive) Personal Digital Assistant (PDA) type devices out there Some of the cutting edge ones even claim to support resolutions up to 640x480 pixels, so perhaps there is hope for viewing complex HTML pages Most standard PDAs with smaller screens are also capable of viewing HTML, although the experience can be quite different from using a traditional web browser

There are also concerns when we consider the 'wireless' aspect of mobile Internet access Put plainly, we can never expect the sort of bandwidth that is possible in hardwired systems Not only that, but the signal quality is likely to be variable-

we might temporarily lose communications; by driving through a tunnel, for example

Current systems allow a data transfer rate of around 9600 baud, which is comparable to the modems of yesteryear, and about six times slower than you might expect on a standard modem line (and orders of magnitude slower than more professional systems) Although many mobile networks will implement systems allowing for faster access in the future, speeds will always be slower than we might achieve on a PC When this is taken into account we can hardly expect streaming multimedia web sites on mobile devices, unless there is some interesting paint drying near you that you can watch while things download

Up till now we've been considering the bad points After reading the foregoing you may well be asking yourself how mobile Internet access has ever got off the ground But, there are many things that are possible with mobile devices that aren't with PCs It is only when we consider these possibilities that the true power becomes clear The key point to remember is that mobile Internet access is mobile It is available anywhere and anytime, without having to lug much hardware around with you In addition, the fact that you carry it with you means that you are likely to be interested in information that pertains to your current situation and position (such as "Where's the closest Indian restaurant?") In theory this kind of 'location-dependent' information should be accessible without actually entering information about where you are After all, the network operator knows more or less where you are from the network cell you are in Unfortunately, this kind of application has yet to appear at the time of writing It seems that network operators aren't too keen on handing out this information yet, although developments are occurring regularly, and I wouldn't be surprised if this was possible by the time you read this

So, we know that mobile Internet access is a good idea, but, in the face of all the problems mentioned earlier, how do we make it work? Luckily, this isn't something we have to work out for ourselves A lot of serious thought has been expended

to come up with standards to get things moving One solution that has taken off in Japan and is starting to spread into the rest of the world is i-Mode This technology uses a cut-down version of HTML known as i-Mode cHTML (similar but not identical to the W3C cHTML standard) The standard that has the greatest prominence in Europe and the United States is the Wireless Application Protocol (WAP)

WAP

If you've had any experience using mobile devices to connect to Internet services, you've more than likely used a WAP-enabled device Not only that, but I'd say it was very likely that you've heard the term 'WAP' on TV, seen it in magazines, and heard how much people seem to hate it However, if you analyze the problems that people have with WAP, such as "It's too slow", "There's no color", "All the WAP sites look rubbish", and so on, you may notice that these can in all cases be explained by the limitations we looked at in the last section- and we weren't even considering WAP there

Even so, it seems perfectly reasonable to wonder why we should bother with WAP at all

In actual fact, WAP does quite a good job of dealing with these limitations, but the end result is still not enough to satisfy the e-generation However, WAP is ready for the next generation of mobile communication networks- without major changes- and is likely to start to become more accepted as bandwidth increases Of course, many people ask whether WAP will be here at all, or whether it will be replaced with something else In order to address this point we need to take

a step back and look at exactly what WAP is, and how it works

The objective of WAP is, logically enough, to get information from the Internet to a mobile client This isn't exactly simple,

not least due to the fact that there is no physical connection between the Internet and the wireless network In addition, building up any communication protocol is a lengthy process (I, for one, wouldn't fancy sitting down and reading through the specifications drawn up for Internet communications, even if I did have a spare month or two) Deciding what form data should take, what security measures should be taken, how data should be compressed and transmitted, etc is by no means simple

This is one thing that we can relax about though, the architects of WAP (the WAP forum) have analyzed the issues involved, and the results work fine To summarize, the gap between the Internet and the wireless network is filled by what is known

as a WAP gateway, which acts primarily as a protocol converter Resources on the Internet are accessed by this gateway

in much the same way as Internet clients do- using HTTP The gateway does this when it receives a request from a WAP enabled device, which is transmitted using WAP protocols Once it has fetched the resource required, the gateway may perform additional processing (such as compressing files to optimize transmission) if necessary, and then will transmit the result back to the mobile client, again using WAP protocols This is illustrated in the figure below:

This leads to a few questions, such as "What form do WAP resources take on the Internet?" and "How is security propagated between the mobile client and the origin server?" Again, these questions have been thought of already, which

is part of the reason why the WAP specification (freely available from www.wapforum.org) is so large and consists of so many sections The latest version of this specification released (in July 2001) was WAP 2.0, but for now most browsers use the older version, 1.1, with a few using version 1.2, last updated June 2000 Version 1.1 is the version we'll concentrate

on here Instead of listing all the documents, I'll just point out the categories to which they belong:

ƒ General WAP technologies- a selection of documents setting out the objectives of the WAP specification, and the various enabling technologies

ƒ The WAP protocol stack and WAP gateways- the means by which information is exchanged with the Internet, optimized to be as efficient as possible in a low bandwidth environment

ƒ WAP language specifications- specifics on the way in which applications may be created for WAP-enabled devices

ƒ The WAP push specification- information on server-initiated WAP exchanges (that is, how information may be transmitted to WAP enabled devices without a direct request for it)

Much of this specification is advanced, certainly more advanced than we want to get into here, but it's reassuring to know that it is there

Consider the WAP language specification section This is the part of the specification that details how resources should be formatted on servers (as well as how they may be compressed for wireless transmission) From the discussion in the last section, it shouldn't be too much of a surprise to find out that HTML isn't the language used by WAP devices HTML is a relatively heavyweight language, containing much functionality that just doesn't fit in with the idea of quick mobile Internet access It makes far more sense to create something new for the bulk of cheap mobile devices, something relatively simple, optimized for the considerations we looked at earlier, and lightweight Something, in fact, like WML- the Wireless Markup Language We'll take a look at this in the next section

Note that more complex devices, such as PDAs, don't suffer from quite such strict limitations when it comes to Internet content Since they typically have larger screens than WAP enabled mobile phones they are more suited to HTML - or at least very simple HTML to avoid the low bandwidth problem Other options include cHTML, a variant of which is used in i-Mode as noted earlier, and the new XHTML standard used in WAP version 2.0

In case you are worried that omitting a full discussion of the new XHTML dialect is not 'future proofing' you, rest assured that enough of the key concepts and structure of WML survives Learning WML will stand you in good stead for later XHTML devices Also, as we will discuss later, using the mobile controls is to some extent language independent, so there's even less to worry about

After looking at all this, I hope I can convince you that WAP is here to stay So many technical challenges have been overcome, and so much groundwork is in place, that launching a new and completely different means of wireless Internet access would be like reinventing the wheel Of course, there are places where improvements may be made, but WAP is much more likely to evolve than to die

WML

The Wireless Markup Language (WML) is the WAP forum's solution to the problem of formatting content for display on WAP browsers It is an XML application and shares some features with HTML, although comparisons between these languages aren't that simple to draw As we saw earlier, a web 'page' (taken here as the atomic unit of a web site) isn't

an obvious choice for a fragment of a WAP site For a start many web pages contain far more information than would be usable on a mobile device, and the concept of separate frames containing extra information is also not easily translatable

A single WML file is often called a deck, and contains one or more cards Each card can be thought of as a screen-full of information, complete with text, graphics, hyperlinks, etc Depending on the characteristics of the browser, and the device used to display a given card, this 'screen' may fit completely into the device display area, be accessible via scrolling keys, or require other modes of user intervention to navigate through Navigation between cards may be within a single deck, or between decks:

Owing to the limitations detailed earlier, a size restriction has been placed on WML decks A compiled WML deck may be

no larger than 1,440 bytes This is quite a small limit, and means that complete WML applications will rarely fit into a single

deck, unless they are very simple

Also, as is apparent from the diagram in the last section, WML files may be stored on any existing web server, such as IIS,

PWS, Apache, etc All that is required in order to do this is to configure the MIME types for WML and compiled WML files

When doing this it is worth adding the other MIME types that are used by WAP, as shown in the table below:

Description MIME Type Associated Extension

Compiled WML file application/vnd.wap.wmlc wmlc

Compiled WMLScript file application/vnd.wap.wmlscriptc wmlsc

WAP browsers may then access WML files using standard URL format

Let's look at an example of a WML deck This file can be found in the downloadable code for this chapter with the filename

example1.wml:

is freely available at http://forum.nokia.com/ if you register for it, and comes with all the documentation necessary to set

up and use the device simulators included (for brevity I won't cover this aspect here) Upon loading the example deck into the simulator we see the content of the first card:

Here we have two choices- we can follow the highlighted Continue link by pressing the default selection button on the device (on the simulator this involves clicking the mouse on it) or select Options by pressing the button beneath this text

A labeled button such as Options is called a softkey If we follow the Continue link we'll reach the next card in the deck:

This card has no hyperlink but contains text content and an additional softkey- Back This softkey will take us one place back in the history stack, and return us to the first card

Now let's look at the code that achieved this The code starts with the standard XML declaration necessary for any XML file:

<?xml version="1.0"?>

Next we have the DOCTYPE for the XML file, that is, the resource that specifies the WML 1.1 syntax and enables validation:

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

<card id="first" title="First Card">

of behavior in more detail later, in the section on device interoperability

Next we'll look at each card in turn, starting with the one with the id attribute of "first" This card contains two elements: <p>, a paragraph element that contains (among other things) text to display, and <do>, which defines a softkey:

The paragraph element contains the simple text "Welcome!", a line break using the <br/> empty element (note that we need the trailing slash here to signify that the element is empty, unlike the similar <br> tag in HTML), and a hyperlink WML hyperlinks use either the <anchor> element or the slightly less versatile <a> element Here we use the <a> element,

as this is all that is required for simple navigation Enclosed in the element is the text that we want to display for the link,

Continue, and the navigation itself is detailed by the element attributes The only attribute used here, href, contains the destination for the link This link is meant to provide navigation to the other card in the deck, which has an id of second,

so this is what we use for the attribute value Note that we use a '#' symbol here, which is essentially XML fragment syntax, and points the browser at a specified card within a deck We could use a fully qualified URL here, such as

http://www.somewhere.com/somedeck.wml#card1 If we point at a separate deck in this way then the card specifying section ("#card1") is optional, if omitted then the first card contained in the target deck will be navigated to

The <do>; element is a versatile one, and allows several different types of softkey to be created, the type being chosen

by the type attribute Here the type "accept" is used, which means this is a simple "press to activate" type key The label attribute is used when displaying the softkey The Nokia 7110 browser requires the user to access the Options

menu to accept type softkeys, where they are placed along with built in device options:

The Next softkey is shown highlighted in the above list

The functionality of this softkey is determined by the content of the <do> element In this case the element contains a

<go> element, which specifies navigation This code uses the same destination for the softkey as for the #secondhyperlink and so we have two ways of navigating to the other card in the deck If there were more text contained in the

<p> element, so that the Continue hyperlink didn't appear without scrolling down, this softkey provides an alternative and possibly quicker method of getting to the second card

The second card contains another <p> element, this time containing just some simple text, and another <do> element:

<p>

Now into content

</p>

<do type="prev">

<prev/>

</do>

This time the <do> element is of type prev and contains a simple empty element, <prev/> This is a quick way of adding

a Back link to a card, and is worth using a lot!

That completes our brief WML example, which although it only scratches the surface of what is possible does show us the basics, and gives a general idea of the structures used If you want to learn more about the WML language you can find

a more in-depth treatment in Beginning WAP, WML & WMLScript, ISBN1-861004-58-3, also by Wrox Press This book also details the client-side scripting language detailed in the WAP specification We won't cover this in our chapter to save space, but for completeness I'll say that it is a language similar to JavaScript (it is in fact a subset of ECMAScript) and enables simple client-side calculations This can save round trips to the server (important in the low-bandwidth WAP world), and can be useful for simple user input validation, for example

However, this knowledge isn't essential to use the techniques found in the rest of this chapter, although it may be useful

to get a wider understanding of wireless Internet access

In addition, many devices have certain quirks that may be exploited to enhance usability, but the syntax for these varies greatly In particular, devices equipped with the Openwave (the new name for Phone.com) Browser may use a proprietary

set of WML extensions, requiring a different DTD file (DOCTYPE) If files using these are loaded into other browsers they

will likely fail to work at all

As a simple demonstration, let's look at an example from the last section on the Openwave Simulator (also available free

of charge, from http://developer.phone.com/download/index.html, and comes with full instructions for use) The most recent version at the time of writing is version 5.0 However, this version uses a graphical display that is (for the moment)

a little more advanced than that currently in devices The screenshots in this chapter are taken from the version 4.1 toolkit, which more accurately reflects current devices If we load our deck into this browser we will see that the first card looks

like this:

Image Courtesy of Openwave Systems Inc

Copyright © 2001 Openwave Systems Inc

The first thing to realize here is that the title attribute for the <card> element isn't displayed In fact, the WAP specification says that this attribute is optional, and only intended as a suggestion to the browser to be used for display purposes if it chooses This can cause problems, however, if you've only tested a WAP application on a browser that displays these titles, and use them as an important source of information for the user This is an example of a common pitfall to avoid when developing in WML- you must test code on multiple browsers!

Going back to the screenshot, we also see a Link softkey This appears because the Continue link is selected, and the Link

softkey enables us to follow this link With this browser we can specify the text that should be displayed for this softkey using the title attribute of the <a>; element that specifies that link- another example of an attribute whose value may

or may not be used by a browser We should also note that the softkey defined by the <do>; element is not displayed However, if we look at how the screen looks when the hyperlink isn't selected:

We see that a Next softkey appears- which is the one specified by our <do> element accept type <do> elements on this browser are overridden by, among other things, softkeys created to follow hyperlinks

Let's look at the other card in the deck:

The Back softkey here acts as a back link However, this is shown regardless of whether a prev type <do> element appears in the code- it is the default display for the left softkey on this browser Also, devices equipped with this browser are expected to have a button for going back (an example of which can be seen in the first screenshot in this section), meaning that this functionality is always available

The above browser comparison is a very basic one, but does illustrate some of the differences that often occur between browsers (although not fatal ones in this case) There are many more of these, but a more in depth discussion of the situation is beyond the scope of this chapter

There are several solutions to this problem The simplest, but also the highest maintenance, is to provide different WML files for different devices It is possible to detect the browser type by examining the HTTP_USER_AGENT header and then redirect the browser accordingly

Slightly more advanced is the technique of generating WML dynamically, using ASP.NET or any other code generation technology However, this can be tricky to implement, as many minor things can need changing, which can make the code very confusing This may also result in you creating more work for yourself as different decks may end up with quite different processing

Another strategy is to make use of the fact that WML is an XML application and transform raw data with XSLT, using different stylesheets for different browsers I have used this to good effect, although it is tricky to get started and requires

a great deal of foresight to structure your stylesheets in an appropriate fashion

Finally, you can use ASP.NET mobile controls These may not allow as much versatility as other methods, but certainly seem to work OK and require much less effort on your part As well as being able to generate WML they also cater for HTML and i-Mode browsers, making them suitable for sites that should work on WAP enabled devices, HTML browsers on PDAs, and i-Mode handsets In theory this means that knowledge of WML is unnecessary, although I feel that a basic knowledge of the structure of WML pages can help you to design mobile web forms in a better way We'll spend the rest

of this chapter examining these controls

Introduction to Mobile Controls

Mobile controls are the ASP.NET solution to creating web applications that are usable by multiple platforms The current release supports HTML 3.2, WML 1.1, and cHTML browsers, and allows third party customization for other types of output (such that the controls could be extended to cover whatever odd Internet access technologies might appear in the future) The motivation behind this is to create a set of controls that will perform equally well on multiple devices and yet be programmable using device independent syntax

The mobile controls are part of an SDK known as the Microsoft Mobile Internet Toolkit, available from

http://msdn.microsoft.com/downloads/ If you expand the Software Development Kits entry from the table of contents on the left and then do the same for the Microsoft Mobile Internet Toolkit entry you should see the versions of this SDK that are currently available. Simply download and install the most up to date version of the SDK and you're ready to use the examples in this chapter

The techniques for using mobile controls are similar to those required for other ASP.NET controls, so much of the code may look familiar to you, particularly that required for event handling, etc However, there are differences in the way we need to structure our pages to contain mobile web controls, many of which are due to the limitations of mobile devices as discussed earlier In particular, multiple forms can be contained within a single mobile control web page, necessary to create a system analogous to multiple WML cards in a single deck

As is often the case when trying to explain a new programming paradigm, it is easiest to start with an example to show the basic operation of mobile controls in action

Simple Example

For this example we'll create a mobile controls page similar to the simple example we used earlier in the chapter The code, example1.aspx, is as follows:

<%@ Page Inherits="System.Web.UI.MobileControls.MobilePage" Language="VB" %>

<%@ Register TagPrefix="mobile" Namespace="System.Web.UI.MobileControls"