 |
Технология Клиент-Сервер 2003'3
|
|
|
Microsoft Mobile Internet Toolkit
Андрей Филев
Практически все последние выставки компьютерных технологий с завидным
единством демонстрируют постоянное смещение акцента в сторону мобильности.
Мобильные телефоны и компьютеры наладонного формата приобретают все большую
функциональность. С другой стороны спектра мобильных устройств располагаются
Tablet PC, которые обеспечивают мобильность при бескомпромиссной
функциональности. Очевидно, что мы имеем дело с ярко выраженным направлением
развития индустрии хай-тека. Это тенденция в самом лучшем смысле этого слова.
Это волна, которая несет технологии вперед.
Как известно, у человека, стоящего на пути волны, есть всего два варианта
действий. Либо убежать от волны, либо оседлать ее, и воспользоваться ее
энергией. Пожалуй, большинство IT-специалистов все же попробует воспользоваться
сложившейся ситуацией и принять участие в развитии рынка приложений для
мобильных устройств. Однако для этого им потребуются соответствующие инструменты
и средства разработки. Наша статья посвящена рассмотрению проблем разработки
Web-приложений, которые предназначены для отображения на разного рода мобильных
устройствах, будь то мобильные телефоны, смартфоны, наладонные компьютеры или
Tablet PC.
На данный момент ситуация весьма проста. Предположим, есть некий сайт,
разработанный для владельцев мобильных устройств. Есть некая среда доступа к
нему. И есть набор мобильных устройств. Задача разработчика состоит в том, чтобы
при минимальных затратах времени и сил разработать Web-приложение, которое будет
максимально адекватно отображаться на каждом поддерживаемом мобильном устройстве
и обладать достаточно широким спектром функциональных возможностей.
На пути к этой цели существует множество проблем. Попробуем их кратко
перечислить.
Прежде всего следует отметить, что мобильные устройства имеют различные
форм-факторы. Экран Pocket PC отличается по своим размерам от экрана мобильного
телефона. То же относится и к цветовой глубине экранов. Целевое устройство может
быть оснащено как монохромным экраном, так и полноцветным. То есть устройства,
на которых будет отображаться наш сайт, весьма сильно отличаются друг от друга в
вопросах отображения информации и функциональности.
Следует обратить внимание и на тот факт, что различные классы устройств
поддерживают различные языки разметки страниц. Мобильные телефоны могут
отображать страницы, написанные на WML, наладонники требуют HTML 3.2, а
последние модели Pocket PC спокойно «переваривают» HTML 4.0. То есть Web-сервер,
на котором будет располагаться наш сайт, должен выдавать каждому устройству
страницу именно на том языке, который будет понят устройством.
Следующая проблема — различные браузеры. Почти каждый производитель мобильных
устройств снабжает свои модели собственным браузером. Многие из нас помнят
последствия недавней браузерной войны, когда каждую страницу приходилось
проверять в каждом из трех основных браузеров. Для мобильных устройств браузеров
еще больше.
Кроме этого, далеко не каждое мобильное устройство поддерживает технологию
cookies. В своей работе программисты web-приложений весьма широко их используют,
но в данном случае следует четко осознавать, что многие устройства не
поддерживают cookies в принципе.
Следующая проблема является следствием того, что все устройства имеют
различные форм-факторы. Требуется разбивать содержимое, исходя из того, что у
каждого устройства свой размер экрана, а, следовательно, оптимальный размер
страницы для каждого устройства тоже свой. Вот это — действительно огромная
головная боль. Всегда хотелось бы обойтись без скроллеров, но для этого следует
автоматически разбивать контент сайта на отдельные страницы, опираясь на
возможности конкретного целевого устройства.
И, наконец, стоит помнить, что каждый производитель поставляет собственные
средства разработки для своих устройств. Таким образом, если разработчику
необходимо создавать приложения для нескольких моделей, он должен использовать
для этого различные средства разработки.
Подобная ситуация просто неприемлема. Она требует слишком больших затрат
времени разработчика. Это просто невыгодно. То есть мы имеем дело с классической
проблемой. Но чем хороша компьютерная индустрия, так это своим неподражаемым
свойством рано или поздно решать проблемы. Так и для разработки Web-приложений,
предназначенных для мобильных устройств, был создан отдельный инструментарий.
Имя ему – Microsoft Mobile Internet Toolkit.
Microsoft Mobile Internet Toolkit является неким расширением Visual Studio .NET.
Он позволяет кардинально упростить процесс разработки Web-приложений для
мобильных устройств. Рассмотрим его основные преимущества.
При разработке Web-приложения с помощью Microsoft Mobile Internet Toolkit
разработчик использует “write-once”-концепцию. То есть каждая web-страница
пишется один раз, а затем адекватно отображается на каждом целевом устройстве,
будь то сотовый телефон, наладонник или что-либо еще. За ее отображение отвечает
уже сам Web-сервер, разработчику об этом заботиться не следует.
Сервер также берет на себя выбор языка разметки, на котором будет
базироваться отсылаемая пользователю страница. Разработчику нет нужды создавать
копии каждой страницы на всех используемых языках разметки.
Microsoft Mobile Internet Toolkit является расширяемым и настраиваемым
движком. Как известно, разработчик, использующий ASP.NET, может сам создавать
пользовательские и серверные органы управления. Точно такая же ситуация и с
Microsoft Mobile Internet Toolkit, который, по сути, является расширением
ASP.NET, и унаследовал всю его гибкость.
И, наконец, поскольку Microsoft Mobile Internet Toolkit является частью
Visual Studio .NET, для его использования разработчику не придется изучать новый
язык или средство разработки.
Теперь рассмотрим стандартный способ работы Web-приложения для мобильных
устройств. После разработки приложения и тестирования его на целевых
устройствах, происходит развертывание его на Web-сервере. Для нормального
функционирования на сервере необходимо установить IIS, .NET Framework и сам
Microsoft Mobile Internet Toolkit. Когда пользователь запрашивает Web-страницу,
сервер определяет тип используемого устройства, опираясь на информацию,
передаваемую в составе запроса. Основываясь на полученном типе устройства,
сервер производит рендеринг ASPX-страницы в необходимый язык разметки, а затем
отсылает полученную страницу на устройство пользователя. В список поддерживаемых
устройств входят сотовые телефоны, получающие информацию по протоколу WAP,
смартфоны, Pocket PC, Palm, различные эмуляторы и десктоп-браузеры.
Как уже говорилось, Microsoft Mobile Internet Toolkit является расширением
ASP.NET и привносит в него поддержку новых устройств. Для этого создана
коллекция соответствующих элементов управления под общим названием Mobile Web
Form Controls. Данные органы управления инкапсулируют в себе как общую
функциональность для всех целевых устройств, так и специфичные для каждого типа
мобильных устройств возможности. Но, несмотря на декларируемые различия, Mobile
Web Forms и привычные нам Web Forms абсолютно не отличаются друг от друга в
процессе разработки. В качестве примера можно сравнить объявление формы и
текстового компонента на обычной aspx-странице, и формы с соответствующим
компонентом на странице, предназначенной для отображения на мобильных
устройствах. Обычная форма может объявляться следующим образом:
<Form runat="server">
<asp:Label runat=“server">
Hello, World</asp:Label>
</Form>
«Мобильный» вариант выглядит так:
<mobile:Form runat="server">
<mobile:Label runat=“server">
Hello, Mobile World</mobile:Label>
</mobile:Form>
Как видите, разница невелика, к объявлениям были добавлены только префиксы «mobile».
Также следует обратить внимание на то, что в «мобильном» варианте форма тоже
является органом управления, как и текстовый компонент Label.
Естественно, соответствующий префикс тоже необходимо объявить. Давайте
посмотрим на полный пример страницы, предназначенной для отображения на
мобильном устройстве.
<@%Page language="c#" Inherits="MobileWeb.MobileWebForm1"%>
<@%Register TagPrefix="mobile"
Namespace="System.Web.UI.MobileControls" Assembly="System.Web.Mobile%>
<mobile:Form runat="server">
<mobile:Label runat=“server">
It is mobile dotSITE </mobile:Label>
</mobile:Form>
Как видите, сама директива <@%Page%> ничем не отличается от стандартного
варианта. И это понятно, мы уже упоминали, что Microsoft Mobil Internet Toolkit
является обычным расширением ASP.NET. А вот директива <@%Register> как раз
подключает пространство имен System.Web.UI.MobileControls из соответствующей
сборки, и регистрирует искомый префикс.
Упомянутая сборка содержит необходимые для разработки «мобильных» страниц
органы управления. При работе в Visual Studio.NET эти органы управления
располагаются на вкладке Toolbox’а с наименованием Mobile Web Forms. Правда,
данная вкладка доступна только при работе с проектами типа Mobile Web
Application. Соответствующие органы управления автоматически адаптируют контент
для отображения на различных мобильных устройствах. Причем вывод контента
производится именно на том языке разметки, который будет восприниматься
устройством клиента, запросившего страницу. В состав «мобильных» органов
управления входят как аналоги уже известных нам компонентов, таких, как,
например, label или TextBox, так и компоненты, специально ориентированные на
мобильные устройства. К такой категории можно отнести органы управления
PhoneCall и TextView.
Поскольку органы управления Mobile Web Forms являются обычными органами
управления ASP.NET, они тоже способны запоминать свое состояние между
postback-ами. А так как мобильные приложения являются «родными» для .NET,
мобильные проекты могут использовать в своей работе ранее созданные решения,
используя функциональность обычных .NET-приложений.
Теперь совершим быстрый обзор элементов управления Mobile Web Controls.
Начнем мы с органов управления, ответственных за работу с текстом.
Как известно, текст проще всего отображать при помощи компонента Label.
Создадим тестовое решение типа Mobile Web Application с именем MobileWeb, и
создадим стартовую страницу с наименованием default.aspx. На этой странице
автоматически будет размещен орган управления Form. Следует осознавать, что на
одной aspx-странице можно создать несколько серверных форм. Но сейчас нам
потребуется только одна. На ней мы разместим орган управления Label. Код самой
aspx-страницы будет выглядеть следующим образом:
<%@ Register TagPrefix="mobile" Namespace="System.Web.UI.MobileControls"
Assembly="System.Web.Mobile, Version=1.0.3300.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" %>
<%@ Page language="c#" Codebehind="default.aspx.cs"
Inherits="MobileWeb.MobileWebForm1" AutoEventWireup="false" %>
<meta content="Microsoft Visual Studio 7.0" name=GENERATOR>
<meta content=C# name=CODE_LANGUAGE>
<meta content=http://schemas.microsoft.com/Mobile/Page name=vs_targetSchema>
<body Xmlns:mobile="http://schemas.microsoft.com/Mobile/WebForm">
<mobile:form id=PocketForm runat="server" Paginate="True">
<mobile:Label id=firstLabel runat="server">
</mobile:Label>
</mobile:form>
</body>
Содержимое органа управления Label мы будем формировать при загрузке
страницы. Соответственно, функция Page_Load обретет следующий вид:
private void Page_Load(object sender, System.EventArgs e)
{
firstLabel.Text="Hello, world... It's me again. Current time is "+ System.DateTime.Now.ToShortTimeString();
}
Теперь, когда у нас есть готовое текстовое приложение, самое время увидеть,
как оно будет выглядеть. Если просто запустить приложение на выполнение, оно
будет отображено в обычном браузере IE. Нас же интересует внешний вид на
мобильном устройстве. Поэтому стоит использовать Microsoft Mobile Explorer,
который при установке достаточно хорошо интегрируется в Visual Studio.NET.
Внешний вид нашего приложения при просмотре этим браузером показан на рисунке 1.
Рисунок 1
Как видите, при отображении текста браузер разбил его на строки. Это
естественное поведение всех мобильных браузеров, так как на большинстве целевых
устройств браузеры не поддерживают горизонтальной прокрутки (исключение
составляют браузеры, обитающие в наладонных компьютерах).
Ввод текста производится при помощи органа управления TextBox. Он реализует
стандартное поле текстового ввода, и практически идентичен функционально своему
близнецу из коллекции Web Forms, Правда, «мобильный» вариант TextBox не может
быть многострочным. Но для мобильных устройств этого и не нужно.
Для отображения текста может быть также использован орган управления TextView.
Он предназначен для достаточно больших объемов текста и обладает небольшими
возможностями форматирования. Данный орган управления может автоматически
разбивать отображаемый текст на несколько страниц, учитывая возможности целевого
устройства. Таким образом, текст, который в браузере Pocket PC спокойно
уместится на одной странице, для отображения на маленьком экране сотового
телефона будет разбит на несколько страниц.
Разработчик может включать в отображаемый текст некоторые форматирующие теги.
На разные классы устройств страницы передаются с использованием различных языков
разметки. Но существует небольшое подмножество тегов, которые присутствуют во
всех используемых версиях языков разметки. Именно их можно применять при
оформлении содержимого TextView.
Теперь перейдем к органам управления, реализующим функциональность,
необходимую для отображения списков. Чтобы просто отобразить текстовый список,
стоит использовать орган управления List. Форма отображения информации
варьируется в зависимости от значения свойства Decoration. Если использовать
значение None, установленное по умолчанию, соответствующие элементы списка будут
выведены без какого-либо дополнительного оформления. Если нужно отобразить
маркированный или нумерованный список, следует использовать значения Bulleted и
Numbered соответственно.
Если необходимо не просто отобразить список, но и дать пользователю
возможность выбрать некоторые элементы из него, следует использовать орган
управления SelectionList. Этот орган управления позволяет отображать список в
самых различных вариантах. Внешний вид списка задается значением свойства
SelectType. Значение DropDown отображает список в виде выпадающего меню. ListBox
отображает обычный список в прокручиваемом окне, где пользователь может выбрать
один элемент, а значение Radio создает группу радиокнопок. Перечисленные
варианты позволяют пользователю выбрать только один элемент из списка. Если же
необходимо дать возможность выбора нескольких элементов одновременно, следует
использовать значения MultiSelectListBox и CheckBox. Первое из них создает
обычный список, а второе отображает список в виде группы независимых
переключателей.
Как видно, набор органов управления для «мобильных» web-страниц не так уж
обширен, зато такие органы управления обладают расширенной функциональностью.
Это в полной мере относится к последнему органу управления, предназначенному для
отображения списков. Речь идет об ObjectList. Данный орган управления позволяет
отображать информацию об объектах, каждый из которых обладает набором свойств.
Орган управления ObjectList умеет сам разбивать свое содержимое на несколько
страниц, и позволяет разработчику задавать шаблоны отображения элементов. Этот
орган управления заслуживает отдельного примера. Мы попробуем отобразить
информацию о служащих из базы данных Northwind из поставки Microsoft SQL Server.
Для работы с базой данных мы используем SqlConnection, SqlDataAdapter и DataSet.
Я позволю себе не описывать полностью процедуру установки свойств для этих трех
элементов, так как эти действия каждый разработчик, взаимодействующий с базами
данных, выполняет регулярно. Единственное, на что следует обратить внимание, так
это на свойство SelectCommand для SqlDataAdapter. В этом свойстве хранится текст
SQL-запроса, определяющего структуру результирующего набора данных. В нашем
случае он выглядит следующим образом:
SELECT DISTINCT LastName, FirstName FROM Employees
Итак, мы используем всего два поля. Теперь разместим на форме компонент
ObjectList. Для первого примера мы свойству AutoGenerateFields придадим значение
True. Тем самым мы позволим органу управления самостоятельно создавать список
отображаемых полей. Также следует задать значение свойства LabelField, которое у
ObjectList будет указывать имя поля, выводимого в качестве элементов списка. В
качестве значения мы используем FirstName. Осталось только связать dataset и
ObjectList. Это мы сделаем при загрузке страницы:
private void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostBack)
{
sqlDataAdapter1.Fill(infoDataSet);
MainList.DataSource = infoDataSet;
MainList.DataBind();
}
}
В листинге видно, что мы сначала заполнили DataSet данными, а затем
использовали его в качестве источника данных для ObjectList. Внешний вид
страницы при просмотре с помощью эмулятора показан на рисунке 2.
Рисунок 2
Как показано на рисунке, мы получили список из имен сотрудников. Сами
элементы списка отображены в виде гиперссылок. Активизация гиперссылки переведет
нас на страницу, на которой отображена вся имеющаяся информация о человеке.
Внешний вид подобной страницы показан на рисунке 3.
Рисунок 3
Обратите внимание – на рисунке 2 видно, что весь список не
уместился на экране телефона, и ObjectList самостоятельно отобразил гиперссылку
на следующую страницу. Этот момент хорошо иллюстрирует сказанное ранее об умении
ObjectList разбивать контент на страницы в зависимости от возможностей целевого
устройства.
Однако приведенный пример демонстрирует лишь малую часть
возможностей органа управления ObjectList. Поэтому мы попробуем усложнить наш
пример.
Для начала получим из базы данных чуть больше данных. Наш
запрос будет выглядеть следующим образом:
SELECT DISTINCT LastName, FirstName, BirthDate FROM Employees
Теперь установим свойство AutoGenerateFields в false. Так как
теперь ObjectList не в состоянии сам создавать список полей, нам потребуется
задать их самим. Для этого следует активировать диалоговое окно установки
значения свойства Fields. В нем мы можем указать поля, содержимое которых будет
отображаться на странице с детальной информацией. Для отображения его даты
рождения и детальной информации мы используем отдельную форму. Для этого на
существующую aspx-страницу мы добавим новую форму с именем DetailForm. На новой
форме мы разместим два компонента Label с именами NameLabel и BirthLabel. Теперь
осталось переопределить функцию отображения детальной информации. В нашем случае
она будет выглядеть следующим образом:
private void MainList_ItemCommand(object sender,
System.Web.UI.MobileControls.ObjectListCommandEventArgs e)
{
NameLabel.Text="Name: "+e.ListItem["FirstName"]+" "+e.ListItem["LastName"];
BirthLabel.Text="BirthDate: "+e.ListItem["BirthDate"];
ActiveForm= DetailForm;
}
Теперь, первая страница с нашим списком будет выглядеть так, как показано на
рисунке 4.
Рисунок 4
Ссылки «More» отсылают пользователя на стандартную страничку с детальной
информацией, которая генерируется автоматически. Нажатие на гиперссылки с
именами служащий переадресует пользователя на ту форму, которую подготовили мы.
Внешний вид этой формы при просмотре через эмулятор показан на рисунке 5.
Рисунок 5
Таким образом, мы получаем в свое распоряжение весьма мощный инструмент для
отображения данных.
Но вернемся к остальным органам управления, которые ждут своей очереди.
Пришло время рассмотреть органы управления, которые позволяют осуществлять
перемещение пользователя между отдельными страницами. Первое, что приходит на
ум, это, конечно, гиперссылка. Она реализуется при помощи органа управления Link,
который практически полностью функционально эквивалентен своему близнецу из Web
Forms. Также для этих целей можно использовать орган управления Command, который
реализует функциональность обычной кнопки. Но самым интересным является орган
управления PhoneCall, который предназначен для отображения телефонных номеров. В
обычных мобильных устройствах, которые не могут совершать телефонные звонки,
содержимое этого органа управления отображается просто как текст. Если же
пользователь для просмотра страницы применяет мобильный телефон или Pocket PC
Phone Edition, то при активировании данного номера телефона пользователем будет
совершен звонок на искомый номер.
Для отображения графической информации тоже существуют свои органы
управления. Это, прежде всего Image, который является полным функциональным
двойником своего близнеца из Web Forms. Также в состав органов управления для
«мобильных» web-страниц добавлен AdRotator, предназначенный для показа баннеров.
Честно говоря, трудно представить, что на подобных сайтах кто-то будет
показывать рекламу, но, так или иначе, данный орган управления у нас есть, и при
необходимости мы можем им воспользоваться.
Также вкладка Mobile Web Forms предоставляет в распоряжение разработчика
шесть органов управления, связанных с проверкой данных, По своей
функциональности они схожи с обычными валидаторами, но в организации их работы
есть некоторые отличия. Если обычные валидаторы Web Forms, за исключением
CustomValidator по умолчанию выполняют свою работу на стороне клиента, используя
для этого JavaScript, то валидаторы для мобильных страниц работают только на
сервере. Впрочем, это как раз понятно, так как мобильные версии браузеров чаще
всего не обладают поддержкой JavaScript.
На этом мы можем закончить краткий обзор Microsoft Mobile Internet Toolkit, и
подвести краткие итоги. Итак, разработка Web-приложений для мобильных устройств
с использованием Microsoft Mobile Internet Toolkit полностью лежит в русле
обычных навыков .NET-разработчика. Для осваивания этой технологии ему не
придется учить дополнительного языка программирования и привыкать к иной среде
разработки. Также Microsoft Mobile Internet Toolkit позволяет приложениям
создавать наилучшее форматирование контента в зависимости от используемого
устройства. И, наконец, Microsoft Mobile Internet Toolkit позволяет разработчику
самостоятельно добавлять новые мобильные устройства в поддерживаемый список, еще
больше увеличивая гибкость используемой технологии. Все это — весьма
положительные качества.
Copyright © 1994-2016 ООО "К-Пресс"
Home
Поиск
Издания
Контакты
