Аннотация

В статье даются рекомендации по созданию мобильных Web?приложений и фильтров устройств с помощью набора Microsoft Mobile Internet Toolkit, адаптируемого под дисплеи многих мобильных устройств типа PDA (Personal Digital Assistants), в том числе Pocket PC, сотовых телефонов с поддержкой Web, пейджеров и т. д.

Содержание

Введение
Архитектура и особенности развертывания мобильных приложений
Планирование: цели разработки
Глобализация и локализация
Рендеринг
Ввод данных
Навигация в мобильных приложениях
Вопросы безопасности
Рекомендации по разработке мобильных элементов управления
Ограничения
Параметры отладки
Расширяемость
Портал IBuySpy
Дополнительные сведения о продукте

Введение

Microsoft^® Mobile Internet Toolkit (MIT) предоставляет инструменты для создания приложений, ориентированных на мобильные устройства. Этот инструментальный набор позволяет разработать приложение, способное адаптироваться к дисплеям самых разнообразных мобильных устройств - персональных цифровых помощников (Personal Digital Assistants, PDA), например Pocket PC, сотовых телефонов с поддержкой Web, пейджеров и т. д. Дополнительные средства предоставляет Microsoft .NET, которая упрощает развертывание мобильных приложений на отдельных серверах или больших серверных фермах.

Эти рекомендации помогут вам создавать эффективные фильтры устройств и мобильные Web?приложения, однако их не следует рассматривать как исчерпывающее руководство и как нечто обязательное без учета контекста решаемой вами задачи. Придерживаясь данных рекомендаций, вы сможете создавать мобильные Web?приложения мирового класса.

Архитектура и особенности развертывания мобильных приложений

Мобильными называются приложения, к которым могут обращаться мобильные устройства. Мобильные устройства характеризуются широким разнообразием размеров и качества дисплеев, полос пропускания и поддерживаемых протоколов. Mobile Internet Toolkit снимает с вас большую часть бремени с отображением информации на мобильных устройствах. Однако, помимо проблем с дисплеями, в мобильном приложении нужно учитывать и ряд других факторов, которые отличают его от обычных Web-приложений.

Принимайте во внимание следующие ограничения мобильных устройств и соответствующих сетей.

• Тактовые частоты процессоров. Производительность процессора мобильного устройства может быть крайне невелика. Это замедляет обработку информации и скорость шифрования/дешифрования данных, пересылаемых по защищенным коммуникационным каналам связи.
• Полу- и полнодуплексная радиосвязь. Некоторые устройства не поддерживают полнодуплексный режим, т. е. не могут одновременно передавать и принимать данные. Это увеличивает запаздывание и отражается на восстановлении ошибок.
• Запаздывание. Большинство мобильных устройств использует энергосберегающие протоколы. Кроме того, существуют законодательные ограничения на удельную степень поглощения (Specific Absorption Rate, SAR). SAR - это мера биологического воздействия радиочастотного излучения, характеризующая безопасность сотовых телефонов и других мобильных устройств. Эти ограничения дополнительно увеличивают время запаздывания мобильных устройств.
• Пропускная способность. Хотя мобильные устройства GPRS (General Packet Radio Services) могут работать на теоретически максимальных скоростях 171,2 килобит в секунду (Кбит/с), многие телефоны все еще используют технологии Circuit Switched Data, поддерживающие скорость передачи данных не более 9,6 Кбит/с. Это значит, что мобильные устройства особенно чувствительны к издержкам, связанным с работой протоколов, и к объему передаваемых данных.
• Негарантированная возможность соединений. Мобильное устройство может перемещаться из зоны устойчивого охвата в зону частичного охвата или оказываться там, где вообще нет никакой связи. На качество связи влияют высокие здания, мосты и другие объекты.
  Все эти ограничения следует учитывать при разработке и развертывании мобильных приложений. Для этого придерживайтесь следующих рекомендаций.
• Минимизируйте время отклика вашего приложения. Большие паузы между запросами могут вызвать переход мобильного устройства в режим восстановления ошибок.
• Приложение должно быть совместимо с механизмами восстановления ошибок на мобильных устройствах. Превышение времени ожидания, разрыв соединения и многие другие причины приводят к тому, что мобильное устройство пытается повторно получить страницу от мобильного приложения. Это эквивалентно двухкратному нажатию кнопки Submit для отправки одних и тех же данных в обычном Web?приложении.
  Примечание Шлюзы, как правило, справляются с этой задачей. Соединение между шлюзом и сервером обычно является очень скоростным.
• Правильно определите параметр TTL (Time-to-Live). Для уменьшения времени отклика многие операторы мобильной связи используют прокси-сервисы и кэширование. Поэтому, если параметр TTL для приложения выбран неверно, на вашем сайте могут возникать проблемы.
• Уделяйте особое внимание надежности приложения. Большинство мобильных устройств не приспособлено для отсылки замечаний по качеству работы мобильного приложения. Это значит, что добавление в нижнюю часть каждой страницы кнопки "Contact Us" или специальной ссылки не поможет выявить проблемы в работе приложения. Для выявления и удаления "мертвых" ссылок применяйте соответствующий инструментарий. Анализируйте производительность, чтобы найти и устранить узкие места. Следите за работой своего приложения после его выпуска, чтобы не допускать постепенного снижения его производительности в процессе эксплуатации.
• Переопределяйте стандартные сообщения об ошибках, указывая телефоны службы поддержки или координаты других служб сопровождения пользователей в вашей компании. Можно указать телефонный номер или другое приложение.
• Используйте шифрование Secure Sockets Layer (SSL) для защиты ваших клиентов. Перехватить сообщения мобильных устройств гораздо легче, чем сообщения наземных линий связи.
• Оптимизируйте сайт под определенные устройства. Mobile Internet Toolkit берет на себя большую часть работы по корректному отображению информации на различных мобильных устройствах. Однако с выходом новых устройств и по результатам тестов производительности может выясниться, что в ряде случаев целесообразнее регулировать виды передаваемой информации. Так, передача изображения на телефон с поддержкой WML может занять массу времени из-за ограниченной полосы пропускания. Зачастую лучше вообще исключить передачу такой информации, чтобы повысить скорость отклика приложения. Более подробные сведения о поддерживаемых устройствах и проблемах производительности см. в разделе "Requirements and Supported Devices" документации MIT.

Планирование: цели разработки

На стадии планирования любого приложения важно правильно определить цели разработки, от которых зависит выбор наиболее эффективной стратегии его развертывания.

Большая часть сведений из документации Microsoft .NET Framework применима и к разработке мобильных приложений.

Разработка мобильного приложения

При распределении задач между клиентом и сервером следует помнить о двух целях. Во-первых, вы должны свести к минимуму обмен данными по HTTP-соединению (Hypertext Transfer Protocol). Каким бы быстрым оно ни было, обработка на клиенте всегда быстрее. Пересылать информацию между клиентом и сервером нужно лишь в случае крайней необходимости.

Во-вторых, клиенту должны быть доступны только те серверные ресурсы, которые абсолютно необходимы ему для выполнения своей задачи. Каждый запрос должен полностью идентифицировать клиент, чтобы серверу не приходилось обращаться к нему за дополнительной информацией, увеличивая число обменов данными по соединению.

Если клиент способен полностью описать свои возможности при запросе к серверу (например, идентифицировать себя как PDA с цветным дисплеем), сервер немедленно отправит ответ, соответствующий возможностям клиента, и не станет запрашивать дополнительные сведения (чтобы, например, выяснить, поддерживает ли дисплей клиента цветные изображения). Эта концепция применима и к разработке Web?приложений, предоставляющих доступ к базе данных. Так, при проверке статуса заказа клиент должен использовать запрос MyDatabase.Recordset, чтобы получать информацию только по данному заказу, а не все записи в таблице заказов.

Определение интерфейса

Создавая приложение, продумайте, какова его целевая аудитория. Если приложение рассчитано на пользователей как настольных компьютеров, так и мобильных устройств, введите в его версию для настольных систем функциональность, позволяющую настраивать мобильную версию.

• Определите, что имеет смысл для мобильного пользователя и что наиболее значимо.
• Позаботьтесь о максимальном удобстве использования приложения:
  • убедитесь, что пользователь может легко вводить и получать информацию;
  • убедитесь, что приложение настраивается под целевое мобильное устройство и настольную систему.
  • По возможности предлагайте для параметров значения по умолчанию. Это повышает удобство работы, уменьшая или исключая необходимость вводить данные.
  • Учитывайте средства навигации и технические характеристики целевого устройства.
• Продумайте дизайн пользовательского интерфейса, учитывая область применения данного приложения.

Создание компонентов пользовательского интерфейса

Пользовательский интерфейс (UI) может содержать меню, а также формы для ввода и отображения информации, которые могут обращаться к наборам данных. Хороший подход - написать детальные сценарии применения приложения (storyboard). Каждый такой сценарий становится формой, а каждый его раздел - страницей. Продумайте следующие компоненты UI:

• Простое или иерархическое меню. Обеспечивает базовую навигацию по вашему сайту.
  • Статические меню. Элемент управления List позволяет выводить статический список элементов. В большинстве случаев оказывается достаточным простой набор элементов управления Link или Command.
  • Динамические меню. Программно модифицируемые меню повышают удобство работы пользователей, но могут повлечь дополнительные издержки. Для динамических меню лучше подходит элемент управления List, связываемый с данными.
• Пользовательский ввод. В мобильных устройствах (особенно телефонах) следует применять пошаговый метод ввода информации и не пользоваться HTML?страницами, отображающими все сразу. Такие страницы предполагают наличие поддержки позиционирования, позволяющего выбирать поля и вводить данные в любом порядке. Для мобильных клиентов требуется более прямолинейный подход. Некоторые устройства просто вынуждают пользователя следовать тому порядку ввода информации, в котором расположены соответствующие элементы управления на странице. Исходная страница может содержать поле для ввода имени и расположенную под ним кнопку поиска. В мобильном приложении поле ввода имени или варианты поиска придется скорее всего разместить в начале последовательности ввода на форме. Более подробную информацию см. в разделе Ввод данных.
• Формы, отображающие данные (рендеринг). Большие объемы текста на форме следует разбивать на страницы.
• Формы для пользовательского ввода. Для разделения нескольких элементов управления вместо разбиения на страницы применяйте элемент управления с поддержкой страниц, например TextView, ObjectList и т. д. В общем случае используйте вместо страниц на формах небольшие блоки данных. Придерживайтесь следующих правил:
  • Если на форме нужно разместить более четырех-пяти элементов управления, подумайте о разбиении операции на несколько этапов.
  • Если на форме пошагового ввода требуется промежуточное обращение к серверу для обработки или проверки введенной порции данных, то в этом месте форму можно разделить на две части.
• Наборы. Продуманное управление наборами данных и доступ к ним гарантирует удобство работы пользователей. Наборы представляют собой еще один подход к отображению большого объема данных на форме. Таким образом, к ним применимы те же правила: разделяйте форму на страницы и структурируйте ее, чтобы сначала показывать более краткие сводки (summaries). Придерживайтесь следующих рекомендаций.
• Если вы используете элементы управления List и ObjectList с большим количеством элементов в них, разбивайте списки на страницы вручную, а не автоматически, чтобы группировать элементы наилучшим образом.
• Поддерживайте таблицы данных, организуя поля их так, чтобы предельно упростить восприятие информации.
• При размещении данных и средств управления ими на формах стремитесь свести к минимуму число запросов к базе данных и ограничивайте размер возвращаемых результатов.
• Для ограничения числа извлекаемых элементов используйте собственную разбивку на страницы.

Другие методы доступа к данным

Еще один метод доступа к данным - отключить состояние отображения (view state) и сохранять локальную копию данных. Тогда при каждом запросе данные связываются с локальной копией. Например, в папке входящей почты могут храниться локальные копии писем.

Во многих сценариях доступа к данным используется кэширование. Как разработчик, вы можете организовать пользовательский кэш. Например, это позволяет полностью обрабатывать лишь первый запрос на текущие новости. Все последующие запросы перенаправляются локальному кэшу.

Интеграция с сайтами, рассчитанными на взаимодействие с настольными системами

Перенаправляйте пользователей с одной страницы Web Forms на другую, более подходящую для браузера данного пользователя. Предположим, у вас есть сайт, предназначенный для взаимодейсвтия с настольными системами (desktop site), и вы хотите создать его мобильную версию с тем же URL. Для этого можно создать мобильный .aspx?файл и поместить в обработчик загрузки страницы следующий код:

if (Device.IsMobileDevice)
  RedirectToMobilePage("MyMobilePage.aspx");
else
  Response.Redirect("MyDesktopPage.aspx");

Примеры совмещения мобильных и "настольных" сайтов см. на Web?сайте IBuySpy (http://www.ibuyspy.com/).

Настраиваемые представления

Возможность настройки внешнего вида приложения повышает удобство работы пользователей, не мешая рендерингу по умолчанию. Как правило, при создании настраиваемых представлений не следует использовать элементы, нарушающие модель UI. Вместо этого:

• для добавления кнопок Home или других навигационных элементов применяйте шаблоны Header. Шаблоны позволяют настраивать внешний вид и свойства элементов управления для различных типов оборудования;
• для вставки статических описаний (например, разделителей) применяйте шаблоны Content;
• в элементах управления ObjectList используйте шаблон Details;
• создавайте меню и наборы из элементов List и ObjectList;
• расширяйте возможности настройки при помощи шаблонов. Так, шаблон Alternate Item позволяет отображать альтернативные элементы (например, изображения другого размера и разрешения);
• стандартные шаблоны верхнего и нижнего колонтитулов (header and footer templates) помогут придать формам общий стиль оформления. Таблицы стилей в шаблонах задают стандартные или альтернативные параметры для каждого устройства;
• используйте переопределение свойств для адаптации UI под устройства с ограниченными техническими характеристиками (например, с малым дисплеем).

Производительность

При создании адаптируемых UI разработчики должны принимать во внимание те же параметры, что и для обычных Web?приложений:

• число запросов в секунду;
• Time To First Byte (TTFB) и Time to Last Byte (TTLB);
• нагрузка на процессор;
• масштабируемость с учетом числа клиентов и процессоров;
• число байтов в ответе.

Более подробную информацию см. в разделе Collecting Performance Data на Duwamish Online.

Универсальные способы повышения производительности

Повысить производительность приложения можно следующими способами.

• Избавьте пользователя от лишних действий (например, не показывайте такую страницу, как Welcome). Старайтесь сделать так, чтобы пользователь мог работать максимально легко и эффективно.
• Удаляйте WML-заголовки - они приводят к выводу лишней строки при рендеринге.
• В элементах управления ObjectList:
  • используйте несколько табличных полей (например, размещайте name/qty в одной строке);
  • отключите перенос слов (wrapping); для подсказок, связанных с автозавершением текста (text completion hints) применяйте короткие метки;
  • установите значение BreakAfter = "false", чтобы разместить поле name и связанное с ним текстовое поле на одной строке. Отредактируйте исходный HTML?код, добавив в него нужное число пробелов.
• Применяйте элемент управления Panel как контейнер для динамически создаваемых элементов управления. Если WML-заголовков нет, после вставки элемента Panel добавляйте ссылку (link) для разделения.

Возможности тестирования

Разрабатывая адаптируемые UI для мобильных устройств, всегда включайте поддержку просмотра "наименьшего общего знаменателя" ("lowest common denominator" browsing capability), чтобы вы могли контролировать внешний вид своего приложения.

По-настоящему протестировать свое приложение вы можете лишь на реальных устройствах, на которые оно рассчитано. Список устройств приведен в разделе "Requirements and Supported Devices" онлайновой документации.

По возможности опубликуйте приложение в Интернете, чтобы на практике проверить его взаимодействие с мобильными устройствами.

Глобализация и локализация

Глобализованное приложение поддерживает локализованные UI и региональные стандарты.

Возможно, вам потребуется настраивать кодировку по умолчанию для определенных устройств и языковые параметры. Основной способ задать тип кодировки - настроить параметры в разделе <globalization> файла machine.config. Два главных параметра, позволяющих изменять кодировку по умолчанию:

• requestEncoding - ожидаемая кодировка запроса (строки запроса и данных формы);
• responseEncoding - кодировка контента, отправляемого клиенту.

Вот пример установки этих параметров в machine.config:

<globalization
  requestEncoding="utf-8"
  responseEncoding="utf-8"
/>

Эти параметры влияют на весь компьютер. Если вы хотите модифицировать их только для одного Web?приложения, внесите изменения в раздел <globalization> конфигурационного файла (web.config), который находится в корневом каталоге приложения.

Более подробную информацию о разработке глобальных приложений см. в разделе Building .NET Framework Applications в Microsoft .NET Framework Developer's Guide.

Рендеринг

Подробное описание рендеринга средствами Mobile Internet Toolkit приводится в онлайновой документации и может быть затронуто в будущих документах. А здесь даются рекомендации по кэшированию вывода и рендерингу на разных устройствах.

Кэширование вывода

Страницы Web Forms в Microsoft ASP.NET включают автоматическую поддержку кэширования вывода. Страница кэшируется директивой @OutputCache.

В мобильных страницах Web Forms содержимое кэша вывода нужно варьировать в зависимости от целевого устройства. Например, если страница запрашивается устройством с Microsoft Internet Explorer для Pocket PC, то получаемая информация должна помещаться в кэш и передаваться только другим устройствам с Internet Explorer для Pocket PC.

По умолчанию содержимое кэша мобильных страниц Web Forms различается по строке HTTP?агента пользователя. Однако некоторые устройства могут отличаться дополнительными свойствами вывода. Так, устройство с единственной строкой агента пользователя может обладать различными свойствами отображения и размера экрана, каждое из которых способно влиять на выводимую информацию. Чтобы учесть эти различия, адаптер страницы должен переопределять свойство CacheVaryByHeaders.

Элементы управления Web Forms в ASP.NET также поддерживают директиву OutputCache для независимого кэширования их вывода. Этот механизм называется раздельным кэшированием (partial caching). Однако пользовательские элементы управления в мобильных страницах Web Forms не поддерживают эту директиву. Мобильные страницы Web Forms не поддерживают раздельное кэширование, поскольку вывод от пользовательского элемента управления может варьироваться в зависимости от содержимого остальной части страницы.

Аппаратно-зависимый рендеринг

Хотя мобильные страницы Web Forms способны автоматически выполнять рендеринг под разные устройства, они предоставляют массу средств для настройки отображения контента под конкретное устройство или класс устройств, что позволяет разработчику задействовать преимущества специфической функциональности данного устройства.

Рекомендации по фильтрам устройств

При создании и управлении фильтрами устройств учитывайте следующее.

• Mobile Internet Toolkit различает фильтры устройств по имени и значению аргумента каждого фильтра. Поэтому у двух фильтров может быть одно и то же имя, если значения их аргументов различны.
  Примечание Это правило применимо к фильтрам устройств, предоставляемым через Mobile Internet Designer.
• Фильтр устройства с именем Default всегда дает успешную оценку. Он блокирует любые другие фильтры, расположенные в списке ниже его. Поэтому этот фильтр имеет смысл размещать последним в списке Applied Device Filters. Однако фильтр Default можно использовать в приложении для отбора всех устройств, не подходящих под критерии предшествующих фильтров из списка, т. е. для создания фильтра, который не ссылается на любые другие фильтры, определенные в конфигурационном файле приложения.
• Будьте особенно осторожны, переименовывая фильтры, уже примененные к какому-либо элементу управления. Переименование таких фильтров не приводит к переименованию соответствующего определения в web.config или в файле с кодом страницы (code-behind file) и разрывает логическую связь между ними.
• Имена фильтров чувствительны к регистру букв.

Ввод данных

Проектируя ввод данных, подумайте над способами эффективного и интеллектуального ввода/выбора данных.

В мобильных устройствах (особенно телефонах) следует применять пошаговый метод ввода информации и не пользоваться HTML?страницами, отображающими все поля ввода сразу. Такие страницы предполагают наличие у пользователя позиционирующего устройства, позволяющего выбирать поля и вводить данные в любом порядке. Для мобильных клиентов требуется более прямолинейный подход. На исходной странице может быть поле для ввода имени, а под ним - кнопка поиска. В мобильном приложении может понадобиться разместить такое поле или элементы управления поиском на первой из серии форм ввода.

Также не забывайте о том, что объем данных на странице влиет на число обращений к серверу.

Для организации ввода данных используйте элемент управления SelectionList следующим способом.

• Там, где это возможно, указывайте значения по умолчанию, такие как текущая дата. Организуйте автоматический ввод текста, например текущих новостей или новостных выдержек.
• Разбейте весь ввод на несколько этапов, используя серию форм.
• Поскольку поддержка сценариев на мобильных устройствах, как правило, отсутствует, возможно, вам придется включить в форму команду Next, заставляющую сервер активизировать следующую форму.
• Продумайте промежуточные этапы. Максимально упрощайте каждую форму.
• Используйте методы show/hide, чтобы отображать и скрывать различные элементы управления на форме (создавая эффект использования нескольких форм).
• WML не поддерживается для обратной совместимости.
• Некоторые формы требуют выполнения кода на серверной стороне (для определения региональных параметров и доступности).
• Обращение к серверу почти всегда занимает больше времени, чем собственно обработка данных на сервере. Поэтому издержки любого обращения к серверной базе данных намного превосходят издержки, связанные с рендерингом. Рендеринг оказывается на втором месте по издержкам.
• Для вывода информации из базы данных в табличном виде применяйте элемент управления ObjectList.

Навигация в мобильных приложениях

В этом разделе описываются ограничения и особенности навигации в приложениях для мобильных устройств, а также рекомендации по адаптации существующих приложений к этим требованиям.

Например, при адаптации существующего HTML?приложения возникает соблазн преобразовать каждую кнопку панели инструментов (toolbar) в ссылки на форме. Но лучше создать элемент управления List и представить каждую такую кнопку как ссылку в этом списке.

При пролистывании многостраничного списка используйте свойство Form.CurrentPage, чтобы помечать нужную страницу и переходить на нее.

Вопросы безопасности

.NET Framework предоставляет модель защиты по правам доступа кода (code access security model), позволяющую администраторам настраивать политику безопасности в соответствии с потребностями. Неправильная политика безопасности может привести к появлению уязвимых мест. Более подробную информацию см. в разделе Code Access Security Model в Microsoft .NET Framework Developer's Guide.

Элементы управления Mobile Web Forms зависят от .NET Framework и могут оказаться непригодными из-за каких-либо изменений в .NET Framework. Поэтому версия мобильных элементов управления и версия .NET Framework должны совпадать.

Защита ресурсов

Убедитесь, что в сеансах не используются cookie. Они не годятся для управления сеансами на мобильных устройствах просто потому, что не все такие устройства их поддерживают. На Web?фермах применяйте состояние сеанса SQL (SQL session state), если только вы не используете состояние отображения и состояния сеанса.

Всегда используйте MobileFormsAuthentication.RedirectFromLoginPage вместо FormsAuthentication.RedirectFromLoginPage и MobileFormsAuthentication.SignOut вместо FormsAuthentication.SignOut. В случае неверной сигнатуры вы не сможете работать с устройствами, не поддерживающими cookie и использующими UP.Link.

MobileFormsAuthentication взаимодействует с FormsAuthentication из ASP.NET. Для аутентификации пользователей можно задействовать раздел <credentials> в web.config или организовать нестандартную аутентификацию.

Например, можно аутентифицировать пользователей по именам и паролям из базы данных или при помощи службы каталогов Microsoft Active Directory™. После аутентификации следует вызвать метод FormsAuthentication.SetAuthCookie, помещающий аутентификационный cookie в набор HttpResponse.Cookies. Затем вызовите MobileFormsAuthentication.RedirectFromLoginPage. Если устройство не поддерживает перенаправление через cookie, MobileFormsAuthentication удалит соответствующий набор. В обоих случаях cookie аутентификации добавляется к URL как строковая переменная запроса. При последующих запросах с предоставлением cookie аутентификации MobileFormsAuthentication больше не добавляет этот cookie к URL. А если cookie не предоставляется (устройство не поддерживает cookie), он всегда добавляется к URL.

Ниже приведены примеры конфигурационных файлов и кода для выполнения аутентификации через MobileFormsAuthentication.

web.config

   <authentication mode="Forms">
      <forms loginUrl="login.aspx" name="nameOfAuthCookie" timeout="60"
                     path="/" >
         <credentials passwordFormat="Clear">
            <user name="username" password="password"/>
         </credentials>
      </forms>
   </authentication>

login.aspx

<%@ Page Inherits="System.Web.UI.MobileControls.MobilePage"
                     Language="c#" %>
<%@ Register TagPrefix="Mobile"
                     Namespace="System.Web.UI.MobileControls"
                     Assembly="System.Web.Mobile" %>
<%@ Import Namespace="System.Web.Security" %>
<%@ Import Namespace="System.Web.Mobile" %>

<Mobile:Form id="formA" runat=server Paginate="True">
   <Mobile:Label runat="server">Enter username</Mobile:Label>
   <Mobile:TextBox id="txtUsername" runat="Server" Text="username" />
   <Mobile:Label runat="server">Enter password</Mobile:Label>
   <Mobile:TextBox id="txtPassword" runat="Server" Text="password" />
   <Mobile:Command runat="Server" OnClick="Login_Click"
                     SoftkeyLabel="Login" ID="Command1"
                     NAME="Command1">Go</Mobile:Command>
   <Mobile:Label runat="server" id="lblError" />
</Mobile:Form>

<script language="c#" runat=server>
void Login_Click(Object sender, EventArgs e)
{
   if(IsAuthenticated(txtUsername.Text, txtPassword.Text))
   {
      FormsAuthentication.SetAuthCookie(txtPassword.Text, false);
      MobileFormsAuthentication.RedirectFromLoginPage(txtPassword.Text,true);
   }
   else
   {
      lblError.Text = "Please check your credentials";
   }
}

bool IsAuthenticated(String user, String password)
{// Проверка аутентификации

   if(FormsAuthentication.Authenticate(user, password))
   {
      return true;
   }
   else
   {
      return false;
    }
}

</script>

Page1.aspx

<%@ Register TagPrefix="mobile"
                     Namespace="System.Web.UI.MobileControls"
                     Assembly="System.Web.Mobile" %>
<%@ Page language="c#"
                     Inherits="System.Web.UI.MobileControls.MobilePage"
                     AutoEventWireup="true" %>

<mobile:Form id=Form1 runat="server">
   <mobile:Label id=label1 runat="server"
                     Text="Authenticated!"></mobile:Label>
</mobile:Form>

Добавьте эти три файла к IIS?приложению и откройте страницу Page1.aspx. Вы будете перенаправлены на страницу Login.aspx для регистрации. После успешной регистрации вы вернетесь на страницу Page1.aspx.

Документы на смежную тематику

Прежде чем продолжить чтение этого документа, рекомендуется прочитать:

• Microsoft .NET Passport SDK
• ASP.Net Web Application Security

Рекомендации по разработке мобильных элементов управления

При разработке мобильных элементов управления придерживайтесь следующих рекомендаций.

• Объединяйте сходные мобильные Web?формы на одной странице. Это облегчает разделение данных между формами, сводит к минимуму необходимость передачи данных между страницами и позволяет эффективнее использовать технологию. Если же вы попытаетесь разместить на одной странице вообще все формы, то производительность упадет. Поэтому группируйте сходные формы и размещайте их на одной странице, разбивая независимые группы на отдельные страницы. Помните, что каждый запрос требует повторного чтения всей страницы и воссоздания всех элементов управления.
• Для устройств, не поддерживающих cookie, нужно управлять состоянием без применения cookie.
• Для экономии ресурсов тщательно выбирайте тип данных, чтобы не использовать переменные слишком большого размера.
• Как можно быстрее уничтожайте переменные, представляющие ограниченный ресурс с конкурентным доступом вроде соединений с базой данных.
• Максимально ограничивайте область действия переменных, чтобы не запутаться в них и чтобы облегчить сопровождение кода. Кроме того, минимизация области действия переменных предотвращает случайное внесение ошибок в другие блоки кода.
• Используйте только один механизм управления транзакциями, например Microsoft Transaction Server (MTS) или Microsoft SQL Server™, и ограничивайте область действия и длительность транзакций.
• Избегайте переменных ASP?сеансов в среде Web?ферм. Или хотя бы не размещайте объекты в таких переменных, поскольку информация о состоянии сеанса хранится на одном и том же компьютере. Подумайте о сохранении этой информации в базе данных.
• Для повышения масштабируемости и производительности предпочтительнее применять компоненты, не поддерживающие состояния (stateless). Проектируйте компоненты так, чтобы все нужные значения передавались их методам как входные параметры, а не записывались в свойства. Такой подход исключает необходимость сохранять состояние объекта между вызовами методов. А если сохранять состояние все же требуется, рассмотрите альтернативные способы вроде использования базы данных.
• Не устанавливайте соединение с базой данных по учетной записи конкретного пользователя. Такие соединения нельзя включать в пул и использовать повторно.

Универсальные процедуры и рекомендации по использованию дизайнера

При разработке приложения с помощью Mobile Internet Designer придерживайтесь следующих рекомендаций.

• Поскольку дизайнер не выполняет рендеринг страниц в том виде, в каком они появляются на конкретном устройстве, он игнорирует свойство ItemsPerPage. Страница Mobile Web Forms в дизайнере не разбивается на несколько страниц. Однако это свойство учитывается в период выполнения приложения.
• Заданные стили действуют на всю страницу, но только в ее пределах. Чтобы определить стиль для нескольких мобильных страниц Web Forms, создайте внешнюю таблицу стилей.
• Редактирование шаблонов в режиме Design поддерживается только для HTML-шаблонов. Для редактирования других шаблонов нужно переключиться в режим разметки HTML. Однако в режиме Design можно подготовить элемент управления для внесения в шаблон при помощи диалога Templating Options.
• Информация, указанная в поле Markup Schema, является внутренней информацией дизайнера и игнорируется в период выполнения приложения. Она нужна для корректной работы Microsoft IntelliSense^® и проверки синтаксиса в режиме разметки HTML при наборе содержимого шаблона.

Общие рекомендации

Также при разработке учитывайте следующее.

• По возможности не вносите элементы управления в шаблон и применяйте их ко всей форме.
• Для адаптации свойств к конкретному мобильному устройству переопределяйте свойства внутри шаблонов.
• По возможности используйте связывание данных через сценарии.

При размещении элементов управления в шаблонах любые свойства этих элементов могут быть связаны с какой-либо структурой в сценарии, что позволяет манипулировать элементом не напрямую, а через эту структуру.

Однако связывание с данными не решает проблемы программного управления страницей. Вы можете упростить решение и его сопровождение, используя метод HasCapability, поскольку он является частью реализации элемента <DeviceSpecific>.

Для WML-браузеров и устройств, способных работать с несколькими формами в разметке, можно объединять формы в группу и не обращаться к серверу для запроса каждой формы отдельно. Форма, содержащая навигационные элементы, которые активизируют другую форму без обращения к серверу, называется связанной (linked form).

Например, форма B связана с формой A, если выполняются следующие условия:

• форма A содержит элемент управления Link, вызывающий форму B;
• у формы A нет обработчика события OnDeactivate;
• у формы B нет обработчика события OnActivate.

Если элемент управления содержит ссылку формата #form1, метод ResolveFormReference ищет форму по значению свойства id формы form1 из пользовательского элемента управления. Если форма не найдена, метод ResolveFormReference просматривает вложенные элементы управления по цепочке вверх и ищет форму на странице.

Информация по синтаксису

Область действия распространяется вверх, а не вниз по иерархии. Если вы хотите сослаться на форму, которая содержится в пользовательском элементе управления, идентифицируйте ее так:

#mc1:form4

В этом выражении mc1 - идентификатор пользовательского элемента управления. Двоеточие отделяет ссылку на форму.

Примечание Анкеры элементов (URL типа page.aspx#element) не поддерживаются, если page не является текущей страницей.

Оптимизация состояния отображения для мобильных приложений

Для мобильных страниц Web Forms важно учитывать следующие аспекты.

Сохранение состояния отображения в сеансе высоко оптимизировано. Если информации для записи нет, ничего не сохраняется, и никакого идентификатора клиенту не отсылается. Но если вам не нужен механизм управления сеансами или если вы хотите создавать страницы с высокой пропускной способностью, подумайте о полном отказе от использования состояния отображения. Во многих случаях (например, при рендеринге страницы форматированного текста) состояние отображения не нужно, и его лучше отключить.

Кроме состояния отображения, существуют и другие виды информации о состоянии страницы, сохраняемой в мобильной странице Web Forms. В ее состав могут входить сведения об активной форме или о разбиении формы на страницы. Такая информация не хранится на сервере, а всегда отправляется клиенту и, как правило, оптимизируется. Например, если активна первая форма или отображается первая страница формы, соответствующая информация не сохраняется, поскольку это состояние по умолчанию. Подобная информация называется частным состоянием отображения (private view state). Все элементы управления могут переопределять методы LoadPrivateViewState и SavePrivateViewState для чтения и записи частного состояния отображения.

Ограничения

В этом разделе рассказывается об ограничениях Mobile Internet Toolkit.

Ограничения среды

Интегрированная среда разработки (IDE) Mobile Internet Designer для Microsoft Visual Studio^® .NET накладывает несколько ограничений на манипуляции с элементами управления. Они проявляются, если вы, например, по ошибке поместите элемент в недопустимое место или неверно напишете слово в директиве @Register.

Ограничения элементов управления

Дизайнер не предотвращает неверного размещения элементов управления, а лишь выводит сообщение об ошибке. Чтобы избежать таких ошибок, придерживайтесь следующих рекомендаций.

Всегда:

• помещайте мобильные элементы управления на мобильные страницы Web Forms, а не на страницы ASP.NET Web Forms;
• размещайте все элементы, кроме Form и StyleSheet, в контейнерах или мобильных пользовательских элементах управления;
• соблюдайте правила вложения элементов управления;
• при редактировании директивы @Register следите за правильным синтаксисом.

Никогда:

• не помещайте мобильные элементы управления Web Forms на немобильные страницы (например, на обычные страницы Web Forms);
• не помещайте элементы управления Web Forms или серверные элементы HTML на мобильную страницу (исключение составляет только шаблон HTML);
• не добавляйте элемент данного типа, если их количество на странице или в контейнере достигло максимума (например, на одной странице не может быть несколько элементов StyleSheet);
• не удаляйте директивы @Register из мобильных страниц Web Forms.

Ошибки, связанные со страницами

Такие ошибки возникают при загрузке мобильной страницы Web Forms с мобильными элементами управления Web Forms в Visual Studio .NET IDE, если директива @Register отсутствует или некорректна.

Если в среду Visual Studio .NET загружается страница с мобильными элементами управления и правильной директивой @Register, но сама страница не принадлежит к типу MobilePage, отображается следующее сообщение об ошибке:

"This control only works in pages of type MobilePage."

Нарушение правил размещения

Если поместить элемент управления ASP.NET Web Forms на мобильную страницу Web Forms за пределами шаблона, появляется сообщение об ошибке:

"This page can only support non-mobile controls in templates. Please delete this control or move it into a template." ("Немобильные элементы управления могут быть размещены на этой странице только в пределах шаблона. Пожалуйста, удалите этот элемент или перенесите его в шаблон.")

Чтобы устранить эту ошибку, переместите или удалите данный элемент управления.

Ограничения контейнеров также запрещают размещать:

• элемент управления Form не на верхнем уровне страницы;
• элемент Panel за пределами элемента Form или шаблона;
• элемент DeviceSpecific за пределами элементов Form или Panel;
• элемент StyleSheet не на верхнем уровне страницы;
• любые мобильные элементы управления за пределами шаблонов либо элементов Form или Panel.

Ограничения по количеству

Если на страницу добавляется несколько элементов StyleSheet, второй элемент StyleSheet отключается, и при рендеринге выдается сообщение об ошибке. Если первый элемент StyleSheet удаляется, активным становится второй.

Если в контейнере размещается несколько элементов DeviceSpecific, второй элемент отключается, и при рендеринге выдается сообщение об ошибке. Если первый элемент удаляется, активным становится второй.

Параметры отладки

В этом разделе описываются разделы конфигурационного файла приложения (web.config), предназначенные для отладки. В основном вам не придется их изменять, но эта информация пригодится для настройки среды отладки.

Динамическая отладочная компиляция

Для отладки .aspx?файлов установите параметр <compilation debug="true"/>:

<compilation defaultlanguage="c#" debug="true" />

Присвоение ему значения false повышает производительность приложения. Этим параметром можно управлять индивидуально для каждой страницы, помещая в нее директиву @Page:

<%@ Page ..... Debug="True" %>

Нестандартные сообщения об ошибках

Вы можете определить набор страниц для сообщений об ошибках. При возникновении ошибки ASP.NET определяет, настроено ли приложение на отображение собственных сообщений об ошибках и существует ли страница для данной ошибки. Если такая страница есть, ASP.NET заменяет стандартное сообщение об ошибке данной страницей, передавая ей параметр с исходным URL.

Если вы разрешаете вывод нестандартных сообщений об ошибках, но не предоставляете страницы со своими сообщениями, Mobile Internet Controls Runtime передает клиентским WML-устройствам реальную ошибку. Чтобы страницы с сообщениями об ошибках корректно работали на таких устройствах, добавьте в раздел system.web файла web.config следующий код:

<configuration>
   <system.web>
      <customErrors> defaultRedirect="genericerror.aspx"
                  mode="RemoteOnly">
         <error statusCode="500" redirect="InternalError.aspx"/>
      </customErrors>
   </system.web>
</configuration>

Для мобильных устройств, не поддерживающих перенаправленные ответы без полного URL, установите параметр useFullyQualifiedRedirectUrl="true" (например, его требуется устанавливать для устройств i-mode):

<configuration>
    <system.web>
        <httpRuntime
            useFullyQualifiedRedirectUrl="true"
        />
    </system.web>
</configuration>

Протоколирование трассировки на уровне приложения

При трассировке на уровне приложения для каждой страницы в приложении ведется журнал. Чтобы включить протоколирование трассировки установите параметр trace enabled="true". Если установлен параметр pageOutput="true", информация о трассировке отображается внизу каждой страницы. При использовании этого метода отладки необходимо, чтобы браузером по умолчанию в Visual Studio .NET был внутренний браузер.

Если в процессе трассировки вы хотите просмотреть страницу на эмуляторе, установите параметр trace enabled = "true", как показано ранее:

<trace enabled="false" requestLimit="0" pageOutput="false" />

или

<trace enabled="true" requestLimit="40" pageOutput="true" />
traceMode="SortByTime" />

Для просмотра журнала трассировки откройте в Internet Explorer файл trace.axd из корневого каталога вашего Web?приложения.

Примечание В проектах Microsoft Visual C#^®, по умолчанию включен параметр Unmanaged Debugging, а в проектах Microsoft Visual Basic^® - параметр Managed Only Debugging.

Примечание Вам может потребоваться добавить в переменную окружения DEVPATH путь к связываемым библиотекам (link libraries).

Расширяемость

Mobile Web Forms и мобильные элементы управления Web Forms обладают той же расширяемостью, что и ASP.NET, но помимо этого поддерживают работу со многими устройствами. Поддерживаются следующие механизмы расширяемости.

• Вы можете создавать и использовать на мобильных страницах Web Forms новые мобильные элементы управления. Новые элементы управления могут наследовать или включать существующие элементы.
• Простые мобильные элементы управления можно создавать из пользовательских элементов ASP.NET декларативно.
• Вывод любого элемента управления можно адаптировать к определенному устройству, добавив для этого элемента новый адаптер.
• За счет расширяемости адаптера можно вводить поддержку новых устройств, не изменяя сами приложения.

Портал и магазин IBuySpy

IBuySpy Portal Solution Starter Kit находится по адресу www.IBuySpy.com/portal и демонстрирует, как создавать интранет? и Интернет?порталы при помощи ASP.NET и .NET Framework. IBuySpy предоставляет всю функциональность типичных порталов, включая:

• десять базовых модулей портала для стандартных типов контента (информационного наполнения);
• инфраструктуру "плагинов", к которой легко подключаются дополнительные модули портала;
• онлайновое администрирование структуры портала, его контента и безопасности;
• защиту на основе ролей при просмотра и редактировании контента, а также при администрировании портала.

Весь код портала IBuySpy из комплекта для скачивания разрешено бесплатно использовать в собственных приложениях. Но портал можно создать и без единой строчки кода. Он предоставляет административные страницы для настройки собственного портала, наполнения его информацией и установки правил безопасности.

Кроме того, на портале IBuySpy размещено множество модулей, разработанных при помощи Mobile Internet Toolkit и представляющих функциональность порталов для мобильных устройств. Фактически на www.IBuySpy.com/portal размещена и мобильная версия портала для устройств, совместимых с Mobile Internet Toolkit.

Детали реализации IBuySpy Portal

Страница Default.aspx выполняет простую проверку типа браузера и перенаправляет запрос к "настольной" или мобильной версии главной страницы:

public void Page_Load(Object sender, EventArgs e)
{
     if (Request.Browser["IsMobileDevice"] == "true" ) {
         Response.Redirect("MobileDefault.aspx");
     }
     else {
         Response.Redirect("DesktopDefault.aspx");
     }
}

Главная страница (default page) - в основном, статическая: большая часть работы выполняется другими компонентами. Так, заголовок, меню, и список "popular items" реализованы отдельными элементами управления, а на страницу помещены лишь ссылки на них.

Сама главная страница состоит всего из нескольких строк кода для проверки регистрации пользователя. Если пользователь зарегистрирован, появляется приветствие, которое можно персонализировать. Персонализация осуществляется в методе?обработчике Page_Load. Событие (Load) инициируется на сервере при каждом обращении браузера к странице. Оно дает удобный способ структурирования серверной логики, которую следует выполнять при доступе к странице. Ниже приведен код главной страницы.

      
        void Page_Load(Object sender, EventArgs e) {
       
            // Настроить приветственное сообщение, если есть
            // соответствующий cookie
            if (Request.Cookies["IBuySpy_FullName"] != null) {
                WelcomeMsg.Text = "Welcome " +
                     Request.Cookies["IBuySpy_FullName"].Value;
            }
       
        }

Приветственное сообщение генерируется при получении от клиента cookie (хранящегося на клиенте в страницах Login.aspx и Register.aspx). Если cookie обнаружен, из него извлекается имя пользователя и отображается через серверный элемент управления. Для подробного ознакомления с генерацией такого cookie изучите страницу Login.aspx.

Замечания по производительности

Поскольку эта страница является стартовой для приложения IBuySpy Store и используется чаще всего, ее производительности уделено особое внимание. Мы решили не помещать в кэш всю страницу (в отличие от страниц ProductDetails и ProductsList), поскольку хотели сохранить возможность подстройки страницы под конкретного пользователя.

Для большей производительности были исключены обращения к базе данных при каждом запросе. Вместо этого мы сохраняем всю персональную информацию (в данном случае - имя пользователя) в необязательном cookie, хранящемся на клиенте.

Пользовательские элементы управления Menu и PopularItems, напротив, извлекают информацию из базы данных. Но они используют раздельное кэширование вывода для хранения этой информации и обновляют данные всего один раз в час.

Дополнительные сведения о продукте

Для повышения производительности информация со страницы размещается в кэше. Для этого служит директива @OutputCache в начале страницы.

<%@ OutputCache Duration="60" VaryByParam="ProductID" %>

В данном случае мы решили установить период обновления кэша равным одной минуте (60 секундам). ASP.NET автоматически сохраняет отдельные элементы кэша для каждого значения строки запроса и извлекает информацию для каждого из последующих запросов.

Названия реальных компаний и продуктов, упомянутые в документе, могут быть товарными знаками соответствующих владельцев.