mobile application
TRANSCRIPT
Handheld devices and mobile phones all now include Internet browsers
ASP.NET developers need to be able to use their skill to create mobile versions of key enterprise applications.
This chapter presents mobile Web applications to build Web applications that need to be displayed on compact screens across a vast array of devices
You will learn how to :
Use the mobile web controls built into ASP.NET
Set up an emulator. Emulators display the mobile Web application as it would appear on the hardware device.
Create a mobile application that can be rendered on a variety of devices.
Mobile Web controls were first introduced in ASP.NET 1.0.
These controls used to be known as the Microsoft Mobile Internet Toolkit.
They are now referred to as ASP.NET Mobile and consist of the mobile Web controls that ship with ASP.NET inside System.Web.UI.MobileControls and the features exposed by System.Web.Mobile.
Starting with ASP.NET 2.0, the mobile Web controls were updated to allow the controls to use a new adapter-based architecture.
These were device-specific adapter files.
Then they started moving to a broader, standards-driven approach focused on markup-compliant rendering of HTML, Compact HTML (cHTML), Wireless Markup Language (WML), and Extensible Hypertext Markup Language (XHTML).
This helps ensure support for different browsers on these devices.
Early .NET Framework versions had built-in support for mobile Web applications.
There were application templates for mobile Web applications and item templates for mobile Web forms, mobile Web user controls, and more.
This allowed to build mobile Web applications using a designer, toolbox and design-time layout support.
They are missing from Visual Studio 2008.
Instead, you use the standard ASP.NET templates and modify them accordingly.
A mobile Web application has a similar programming model to that of any ASP.NET Web site.
To start creating a mobile Web application, you simply create an ASP.NET Web site.
You can even mix mobile pages with non mobile pages.
Like standard Web forms, the mobile Web form is an .aspx page that is accessible by a Uniform Resource Locator (URL) and can optionally have a code-behind page.
The difference is that a mobile Web form inherits from System.Web.UI.MobileControls.MobilePage instead of System.Web.UI.Page.
public partial class Default : System.Web.UI.MobileControls.MobilePage
{
protected void Page_Load(object sender, EventArgs e)
{
}
}
Next, you register the MobileControls namespace and assembly with your page.
Doing so will give you IntelliSense access to the mobile controls inside Source view for your Web page.
The following markup should be added to your page after the @ Page directive to accomplish this:
<%@ Register TagPrefix="mobile"
Namespace="System.Web.UI.MobileControls"
Assembly="System.Web.Mobile" %>
The last step is to replace the markup with mobile-like markup.
This means adding a <mobile:Form> control to the <body> tag.
<html xmlns="http://www.w3.org/1999/xhtml" >
<body>
<mobile:Form id="Form1" runat="server">
</mobile:Form>
</body>
</html>
Visual Studio 2008 does not provide designer support for mobile forms.
Unlike the standard Web form that can only contain one form declaration, the mobile Web form can contain many <mobile:Form> controls.
The <mobile:Form> control is actually a group or container for other mobile controls.
The <mobile:Form> control is of the type MobileControls.Form.
You can switch from one <mobile:Form> to another by setting the ActiveForm property of the mobile Web form in code.
You add mobile controls to a mobile form through markup. There is no real Toolbox support.
However, if you have the MobileControls namespace registered, you will get IntelliSense support in Source view.
There are a number of mobile controls you can add to a page.
Controls added to a mobile Web form must all have a unique ID regardless of their form grouping.
If you have two <mobile:TextBox> controls on a page, for example, you must give them unique ID values even if they are in different form controls
You can view a mobile Web form using a Web browser.
Many of the mobile device manufacturers provide emulators that can be used to test mobile Web applications.
Emulators display the mobile Web application as it would appear on the hardware device.
There are multiple device emulators out there.
You can find a list of some of the more common ones at http://www.asp.net/mobile/device-simulators/.
One of the more common cell phone emulator providers is OpenWave
You can download the latest phone emulators from http://developer.openwave.com.
OpenWave also provides skins for many popular phones.
The Microsoft device emulator installs with Microsoft Visual Studio
To access the emulator, in Visual Studio, from the Tools menu, select Device Emulator Manager.
Here you can see the emulators that are installed.
You can also select an emulator, right-click it, and select Connect to launch it.
There are basic controls for user input such as Calendar, TextBox, Image, Label, Command (button-like behavior), and List.
There are also a set of validation controls that work in a manner similar to those used by regular Web forms.
In addition to control familiarity, developers should expect a similar event model.
The mobile controls each provide Init, Load, Prerender, and Unload events. There are also control specific events such as OnClick for Command.
You intercept these events in your code-behind file for any server-side event. The data-binding techniques are similar, too.
Many mobile devices, such as most cell phones, don’t accept cookies.
This causes problems with maintaining session state.
The solution is to enable cookieless sessions.
Add the following to the Web.config file inside the system.web element:
<sessionState cookieless="true" />
<mobileControlscookielessDataDictionaryType="System.Web.Mobile.CookielessData" />
A mobile form with many controls can be displayed broken apart, so it’s important to focus on grouping controls that should be kept together.
Pagination : Pagination is disabled by default but can be enabled by setting the Paginate property of each mobile form control to true. Pagination is best suited for mobile form controls that display lots of read-only data to keep a device from running out of memory.
Panels : Panels are container controls that can be used to provide further grouping of controls for the purpose of enabling, disabling, hiding, and showing controls as a single group
Styles can be used to change the visual appearance of a control.
Implement styles by using the StyleSheet control or by using the <style> tag.
Only one StyleSheet control can be assigned to a mobile Web form.
When assigning styles, you can assign them directly to a property of the control, or assign the StyleReference property to a control.
Adaptive rendering is the act of rendering a control differently based on the browser that requested the Web page. For example a mobile Calendar control is placed on a mobile Web form, displayed differently on a cell phone or a SmartPhone as shown below.
When a browser requests a Web page, it sends an HTTP header called the User-Agent, which is a string that is used to identify the browser.
The runtime uses the User-Agent string to look up the browser’s capabilities. The capability settings for each browser can be viewed and set in the browserCaps element in the config files.
In ASP.NET, browserCaps relies on XML files that contain a hierarchal structure of browser definitions. The default location of the XML files is as follows:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers\
Each of the XML files has a .browser extension; these files are used to build a class called HttpBrowserCapabilities, which is a factory class that creates an instance of HttpBrowser-Capabilities and populates its properties based on the browser type.
You can modify the existing .browser files and create new .browser files. The HttpBrowserCapabilities class is in an assembly called ASP.BrowserCapsFactory.dll that is installed in the global assembly cache.
To regenerate the ASP.BrowserCapsFactory.dll assembly and its HttpBrowserCapabilities class based on changes to the .browser files, run the aspnet_regbrowsers command-line tool in the .NET Command Prompt window using the –i switch (install).
Device-specific rendering is the ability to specify rendering for a control based on a device type.
One way to use device-specific rendering is to query the various Request.Browser properties and perform actions based on the browser type.
public partial class LabelTest :System.Web.UI.MobileControls.MobilePage{protected void Page_Load(object sender, EventArgs e){if (Request.Browser.IsMobileDevice){Label1.Text = "A mobile device";}else{Label1.Text = "Not a mobile device";}}}
Another way to perform device-specific rendering is to use the DeviceSpecific control.
A single DeviceSpecific control can be nested inside any mobile control or in the <mobile:Form> element to provide custom behavior based on a filter.
A filter simply identifies a device.
You add entries in the Web.config file for your site to define filters.
Once configured, you can then use the filter as a choice inside the DeviceSpecific control.
If the control to be rendered has a DeviceSpecific filter, the filter gets applied before the response is sent back to the device.
Provide a separate desktop presentation
Keep page content as simple as possible
Instead of sending a complete result set to the user, only send the data record that the user is interested in.
Test adaptive controls with several devices
Present the user with default values whenever possible.
Evaluate ViewState
Use caching
Combine many forms on a page
Use cookieless sessions
Using hyperlinks to a form
Minimize image usage