ПросмотрВеб с мобильных устройств

2015-07-02

Создавайте более эффективные и удобные мобильные решения для просмотра Веб

Стивен Сандерсон

Продукты и технологии:

ASP.NET

В статье рассматриваются:

поддержка мобильных устройств в ASP.NET
распознавание типов браузеров
управление рендерингом страниц в мобильных браузерах
варьирование вывода в зависимости от типа браузера

Кто в наши дни заходит в Веб с мобильных устройств? В 2005 г. средний пользователь мобильного Интернета представлялся эдаким гиком, непременно жителем Запада и, возможно, программистом, способным подключить свой сотовый телефон к медленной сети и выдержать кошмарно неудобное его использование. Другими словами, клинический случай.

Теперь мобильный доступ в Веб вырос до уровня глобального мейнстрима. И я имею в виду не только подростков, студентов и пенсионеров, которые хвалятся друг перед другом своими смартфонами и планшетниками в каждой кофейне по всей Европе и Северной Америке. Сегодня насчитывается примерно миллиард активных подписок на широкополосный мобильный Интернет, т. е. где-то по одной на каждые семь человек на планете (и лишь двое из каждых семи регулярно пользуются Интернетом — неважно каким способом). В ближайшие пять лет мобильные устройства вполне могут стать самым распространенным средством доступа в Веб. В некоторых быстро развивающихся странах, особенно в Индии, мобильные устройства уже стали единственным способом для многих людей выйти в Интернет. Даже в Америке 25% мобильных Веб-пользователей говорят, что они «никогда» или «нечасто» выходят в Интернет с традиционных ПК. (Источники этой информации см. во врезке «Мобильный доступ в Веб».)

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

Чем отличаются мобильные браузеры

Как вы знаете, почти все мобильные браузеры поддерживают ту или иную разновидность HTML. Многие, особенно на высококлассных устройствах вроде iPhone и Windows Phone 7, поддерживают новейшие стандарты HTML, CSS и JavaScript и визуализируют качественные копии того, что вы увидели бы в традиционном браузере на ПК.

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

Дисплеи мобильных устройств невелики Некоторые мобильные браузеры, например Opera Mini, обрабатывают страницы с шириной, рассчитанной на настольные браузеры, и динамически изменяют разметку и стили страниц. Однако конечные страницы редко выглядят так, как задумывал ваш дизайнер. Другие мобильные браузеры вроде Safari для iPhone или Internet Explorer для Windows Phone 7 визуализируют страницы с исходной шириной, а затем вынуждают пользователя увеличивать или уменьшать их масштаб и при чтении проматывать текст в разных направлениях. Это проверка ваших посетителей на терпение.
Мобильные сети зачастую работают медленно Не рассчитывайте, что у ваших мобильных посетителей такое же скоростное соединение, что и у пользователей стационарных широкополосных сетей. Они даже могут платить за каждый мегабайт трафика, поэтому тяжеловесные сайты не будут популярны у мобильных пользователей.
У мобильных устройств нередко отсутствует мышь или клавиатура Привычные для пользователей ПК механизмы взаимодействия не всегда имеют смысл на мобильных устройствах. Например, щелкнуть маленькую ссылку или кнопку может оказаться весьма затруднительным делом на устройствах с сенсорным вводом, а концепция задержки курсора мыши над каким-либо элементом страницы может вообще отсутствовать.

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

Поддержка мобильных устройств в ASP.NET

Существует две основные особенности в поддержке мобильных браузеров.

Распознавание типа устройства, используемого данным посетителем В ASP.NET встроена поддержка распознавания браузеров. В следующем разделе мы обсудим этот механизм и то, как его можно настраивать и расширять.
Формирование вывода, пригодного для отображения на распознанном устройстве Если вы просмотрите предыдущий список проблем, то поймете, что это не те вещи, с которыми ваша технологическая платформа способна справляться автоматически. Мобильная поддержка в основном завязана на удобство использования, а не на разметку. Позже в этой статье я опишу технические средства, позволяющие формировать разный вывод для разных устройств, но проектирование и реализация разных разметок и концепций использования для мобильных устройств все равно лежат на вас.

До выхода ASP.NET 2.0 в 2005 г. формирование вывода под мобильные устройства заключалось в основном в подготовке нужной разметки, поскольку распространенные устройства того времени использовали специализированные протоколы и языки разметки, в том числе WAP, WML и cHTML. ASP.NET 2.0 содержала «мобильные элементы управления» для поддержки этих форматов. Однако эти форматы полностью устарели, так как теперь все основные браузеры используют HTML, а это подразумевает и отказ от мобильных элементов управления ASP.NET.

В базовую платформу ASP.NET, которая служит основой как для Web Forms, так и для MVC, встроена поддержка распознавания браузеров.

Распознавание браузера

В базовую платформу ASP.NET, которая служит основой как для Web Forms, так и для Model-View-Controller (MVC), встроена поддержка распознавания браузеров. Вы можете выяснить, использует ли посетитель мобильный браузер, через булево свойство Request.Browser.IsMobileDevice. Однако вы должны понимать, как работает этот механизм распознавания, чтобы представлять возможные ограничения.

ASP.NET определяет, какой браузер выдает запрос и какие возможности он поддерживает (размер экрана, поддержка JavaScript и др.), сравнивая строку заголовка userAgent входящего запроса с набором регулярных выражений в XML-файлах, описывающих распространенные браузеры.

Эти регулярные выражения — и информация о соответствующих возможностях устройств — хранятся в наборе файлов с расширением .browser в папке C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers (или в эквивалентной папке, выбранной вами). Например, стандартный файл iphone.browser включает код, показанный на рис. 1.

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

Рис. 1. Файл iphone.browser

<browsers>
  <!-- Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ 
       (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 -->
  <gateway id="IPhone" parentID="Safari">
    <identification>
      <userAgent match="iPhone" />
    </identification>
    <capabilities>
      <capability name="mobileDeviceModel" value="IPhone" />
      <capability name="mobileDeviceManufacturer" value="Apple" />
      <capability name="isMobileDevice" value="true" />
      <capability name="canInitiateVoiceCall" value="true" />
    </capabilities>
  </gateway>
  ...
</browsers>

В этом файле следующий элемент определяет регулярное выражение, с которым выполняется сравнение входящих строк заголовка userAgent:

<userAgent match="iPhone" />

Как только система находит совпадающее с userAgent регулярное выражение, остальные XML-данные указывают тип и возможности устройства.

Ограничение этой системы очевидно: она может распознавать лишь известные мобильные устройства, описанные в этих файлах на момент выпуска ASP.NET 4.0. Увы, в них не входят популярные современные браузеры, такие как Opera Mobile или браузер по умолчанию для Google Android. Для этих браузеров Request.Browser.IsMobileDevice будет неправильно установлен в false.

Настройка и расширение распознавания браузеров

Преодолеть ограничения исходного механизма распознавания браузеров можно двумя основными способами:

предоставить свои файлы .browser, представляющие более новые устройства
использовать стороннюю библиотеку для распознавания браузеров.

Чтобы задействовать первый способ, щелкните правой кнопкой мыши имя проекта в Visual Studio Solution Explorer и выберите Add | Add ASP.NET Folder | App_Browsers. После этого добавьте файлы .browser в эту папку, например скопировав существующий файл из своего каталога C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers, а затем отредактировав его регулярное выражение идентификации и описание возможностей устройства, чтобы представить нужный браузер.

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

В настоящее время я рекомендую библиотеку 51degrees.Mobi Foundation с открытым исходным кодом (лицензия MPL), размещенную на CodePlex по ссылке 51degrees.codeplex.com. Эта библиотека не использует файлы .browser. Вместо этого она идентифицирует устройства по базе данных Wireless Universal Resource File (WURFL), которую разрешается бесплатно использовать как в коммерческих, так и в некоммерческих приложениях. Подробнее о WURFL см. wurfl.sourceforge.net.

Самый простой способ установить 51degrees.Mobi Foundation в проектах Web Forms или MVC — задействовать диспетчер пакетов NuGet. Если вы работаете с ASP.NET MVC 3, у вас уже есть NuGet. В ином случае можно воспользоваться Visual Studio Extension Manager (из меню Tools) для поиска и установки NuGet. Как только вы получите NuGet, пройдите по Tools | Library Package Manager | Package Manager Console, а затем введите следующую команду в консоли:

Install-Package 51Degrees.mobi

В результате в ваш проект будут добавлены:

последняя копия базы данных WURFL по адресу /App_Data/wurfl.xml.gz
ссылка на FiftyOne.Foundation.dll — основную сборку библиотеки
элементы в файл Web.config для поддержки 51degrees.Mobi Foundation

Библиотека 51degrees.Mobi Foundation подключается к стандартному Request.Browser API в ASP.NET и расширяет его. Простой установкой этого пакета вы добьетесь гораздо более точных результатов от Request.Browser.IsMobileDevice, поскольку новейшие версии базы данных WURFL позволяют распознавать все популярные на сегодняшний день мобильные браузеры, в том числе Opera Mobile и Google Android.

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

Заметьте, что параметры Web.config, настраиваемые для 51degrees.Mobi Foundation по умолчанию, также указывают перенаправлять все запросы от мобильных браузеров по URL ~/Mobile/Default.aspx. Во многих случаях — и особенно для приложений ASP.NET MVC — это будет вовсе не тем поведением, которое вам нужно. Вы можете отключить это перенаправление, закомментировав или удалив элемент <redirect />, добавляемый пакетом в ваш файл Web.config, а после этого вы можете удалить и сам файл /Mobile/Default.aspx.

Дизайн для мобильных браузеров

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

Многие современные мобильные браузеры, в том числе Safari для iOS и Internet Explorer для Windows Phone 7, пытаются сделать так, чтобы визуализированные страницы выглядели точно так же, как и в настольных браузерах. Им известно, что большинство страниц проектируются под окна примерно 1000 пикселов шириной и что дизайнер скорее всего не принимал во внимание дисплеи гораздо меньшей ширины.

Чтобы решить эту проблему, мобильные браузеры обычно осуществляют рендеринг страницы на виртуальный холст (canvas), известный под названием «область вывода» («viewport»), ширина которого, как правило, составляет около 1000 виртуальных пикселей. Затем браузер может произвольным образом масштабировать визуальное отображение этого виртуального холста, давая возможность пользователю приближать и отдалять изображение, а также перетаскивать его в любых направлениях. Эту схему иллюстрирует рис. 2.

Рендеринг мобильным браузером «настольной» страницы в виртуальной области вывода

Рис. 2. Рендеринг мобильным браузером «настольной» страницы в виртуальной области вывода

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

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

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

Многие из наиболее популярных мобильных браузеров поддерживают нестандартный мета-тег viewport, позволяющий вам управлять шириной виртуальной области вывода. Например, если вы добавите следующее в раздел <head> страницы, браузер разметит страницу в области вывода шириной 320 пикселей:

<meta name="viewport" content="width=320"/>

Это обычно гораздо лучше подходит для мобильных телефонов.

Учитывайте, что некоторые мобильные устройства имеют экраны с гораздо большим разрешением по горизонтали. Например, в iPhone 4 в каждой строке 640 физических пикселей. Тем не менее имеет смысл по-прежнему использовать виртуальную область вывода около 320 пикселей шириной; иначе полученный текст окажется слишком мал для чтения без увеличения.

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

<meta name="viewport" content="width=device-width"/>

Многие из наиболее популярных мобильных браузеров поддерживают нестандартный мета-тег viewport, позволяющий вам управлять шириной виртуальной области вывода.

Заметьте, что некоторые мобильные устройства не сообщают точную ширину своего дисплея. Они интерпретируют эту величину как «ширину виртуальной области вывода, которая по мнению производителя дает наиболее качественный результат». Поэтому, например, iPhone 4 сообщает о ширине дисплея в 320 пикселей, несмотря на более высокое физическое разрешение.

Архитектурные варианты

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

отображение и скрытие разделов разметки в зависимости от типа браузера;
переключение эталонных страниц (master pages) соответственно типу браузера;
представление совершенно разного контента в зависимости от типа браузера.

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

Отображение и скрытие разметки

Если вам нужно лишь включать или исключать мета-теги и ссылки на CSS-файлы в соответствии с типом браузера, то это делается крайне просто. Например, в эталонной странице Web Forms вы можете добавить выражение if внутри раздела <head>:

<head runat="server">
  <title>My site</title>
  <link href="~/Styles/Site.css" rel="stylesheet" type="text/css" />

  <% if (Request.Browser.IsMobileDevice) { %>
    <meta name="viewport" content="width=device-width"/>
    <link href="~/Styles/MobileSite.css" rel="stylesheet" type="text/css" />
  <% } %>
</head>

Эквивалент для разметки Razor в приложении ASP.NET MVC 3 выглядит так:

<head>
  <title>@ViewBag.Title</title>
  <link href="@Url.Content(
    "~/Content/Site.css")" rel="stylesheet" type="text/css" />
  @if (Request.Browser.IsMobileDevice) {
    <meta name="viewport" content="width=device-width"/>
    <link href="@Url.Content(
      "~/Styles/MobileSite.css")" rel="stylesheet" type="text/css" />
    }
</head>

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

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

Переключение эталонных страниц

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

public class PageBase : Page
    {
      protected override void OnPreInit(EventArgs e)
      {
        if (Request.Browser.IsMobileDevice)
            MasterPageFile = "~/Mobile.Master";
      }
    }

Затем для любой страницы, разметка которой должна варьироваться в зависимости от типа устройства, делайте так, чтобы ее класс отделенного кода наследовал от PageBase вместо обычногоSystem.Web.UI.Page. После этого можно создать эталонную страницу в /Mobile.Master, разметка и CSS-стили которой оптимизированы для мобильных устройств.

Это даже легче для разработчиков приложений ASP.NET MVC 3, использующих синтаксис Razor: все представления могут динамически переключать разметку, если в файл /Views/Shared/_Layout.cshtml внести следующие изменения:

@{
  Layout = Request.Browser.IsMobileDevice 
             ? "~/Views/Shared/_MobileLayout.cshtml"
             : "~/Views/Shared/_Layout.cshtml";
}

Потом добавьте новый файл с разметкой Razor в /Views/Shared/_MobileLayout.cshtml и модифицируйте его структуру и CSS-стили так, чтобы они подходили мобильным устройствам.

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

Представление разного контента

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

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

В любом случае здесь придется использовать совершенно разную логику и разметку для устройств разных типов. Недостаток в том, что вам потребуется поддерживать две версии, а главное преимущество — поведение этих версий можно варьировать независимо. Разработчики, использующие Web Forms, обычно создают набор специфичных для мобильных устройств ASPX-страниц, а MVC-разработчики, как правило, — новую область для контроллеров и представлений, специфичных для мобильных устройств. Так или иначе, вам понадобится какая-то логика для перенаправления мобильного посетителя на страницу, подходящую для его типа устройств.

Примеры кода, демонстрирующие способы реализации логики перенаправления, совместимые как с кешированием вывода, так и с аутентификацией на основе форм в Web Forms и MVC, см. в документе по ссылке bit.ly/gHT3Ap.

Заключительные рекомендации

В этой статье вы узнали:

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

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

Давайте возможность мобильным пользователям переключаться на обычное «настольное» представление Как правило, это подразумевает размещение ссылки вверху страниц с текстом наподобие «Switch to desktop view». Как именно реализуется переключение, зависит от архитектуры вашего приложения; это может быть простая ссылка на настольную версию по заданному URL или замена файла cookie, который переопределяет ваш обычный механизм распознавания браузеров.

Эта возможность особенно важна, если на ваших «мобильных» страницах показывается меньше информации, чем на настольных.

Главная рекомендация заключается в том, что во главу угла нужно ставить удобство использования и тестирование.

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

Проверяйте свою реализацию, используя настоящие устройства или эмуляторы Ваша разметка, CSS и мета-теги могут не на всех устройствах обрабатываться так, как вы ожидали. Вы должны тестировать мобильную версию на настоящих устройствах или в эмуляторах. Список эмуляторов популярных мобильных устройств см. по ссылке asp.net/mobile/device-simulators.

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

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

Мобильный доступ в Веб

Глобальная статистика по доступу в Интернет от International Telecom Union (itu.int/ITU-D/ict/statistics/at_glance/KeyTelecom.html).
Население земного шара составляет 6,9 миллиарда человек согласно данным U.S. Census Bureau (census.gov/ipc/www/popclockworld.html).
Отчет о трендах в Интернете от Morgan Stanley за декабрь 2010 г.
(morganstanley.com/institutional/techresearch/pdfs/Internet_Trends_041210.pdf).
Исследования OnDevice (slideshare.net/OnDevice/the-mobile-only-internet-generation).

Стивен Сандерсон (Steven Sanderson) работает в Microsoft в должности менеджера программ в группе, которая разработала для вас ASP.NET MVC, Web Forms, NuGet и другие полезные Веб-технологии.

Выражаю благодарность за рецензирование статьи эксперту Скотту Хантеру (Scott Hunter).