Как выполнить: Добавление мобильных страниц в веб-формы или MVC-приложение ASP.NET

Применимо к:

• ASP.NET Web Forms версии 4.0
• ASP.NET MVC версии 3.0

Сводка

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

Содержимое

• Общие сведения
• Параметры архитектуры
• Обнаружение браузеров и устройств
• Как ASP.NET Web Forms приложения могут представлять страницы для мобильных устройств
• Как ASP.NET приложенияХ MVC могут представлять страницы для мобильных устройств
• Дополнительные ресурсы

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

Общие сведения

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

Как более ранние версии ASP.NET поддерживаемые мобильные браузеры

ASP.NET версиях 2.0–3.5 включены ASP.NET Mobile Controls: набор серверных элементов управления для мобильных устройств в сборке System.Web.Mobile.dll и пространство имен System.Web.UI.MobileControls . Сборка по-прежнему включена в ASP.NET 4, но не рекомендуется. Разработчикам рекомендуется перейти на более современные подходы, например описанные в этом документе.

Причина, по которой ASP.NET Mobile Controls были помечены как устаревшие, заключается в том, что их дизайн ориентирован на мобильные телефоны, которые были распространены около 2005 года и ранее. Элементы управления в основном предназначены для отображения разметки WML или cHTML (вместо обычного HTML) для браузеров WAP той эпохи. Но WAP, WML и cHTML больше не актуальны для большинства проектов, так как HTML стал повсеместным языком разметки для мобильных и настольных браузеров.

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

Несмотря на то, что мобильные браузеры теперь почти повсеместно поддерживают HTML, вы по-прежнему столкнелись с множеством проблем при создании отличных мобильных браузеров:

• Размер экрана . Мобильные устройства значительно различаются по форме, и их экраны часто гораздо меньше, чем настольные мониторы. Таким образом, вам может потребоваться разработать совершенно разные макеты страниц для них.
• Методы ввода . На некоторых устройствах есть клавиатуры, на некоторых — стилусы, на других — сенсорный ввод. Может потребоваться рассмотреть несколько механизмов навигации и методов ввода данных.
• Соответствие стандартам . Многие мобильные браузеры не поддерживают последние стандарты HTML, CSS или JavaScript.
• Пропускная способность — производительность сети передачи данных сильно различается, и некоторые конечные пользователи используют тарифы, которые взимаются в мегабайтах.

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

Разработчики, которые впервые обращаются к поддержке мобильных браузеров, часто изначально думают, что важно поддерживать только новейшие и самые сложные смартфоны (например, Windows Phone 7, iPhone или Android), возможно, потому, что разработчики часто лично владеют такими устройствами. Тем не менее, более дешевые телефоны по-прежнему чрезвычайно популярны, и их владельцы используют их для просмотра в Интернете - особенно в странах и регионах, где мобильные телефоны легче получить, чем широкополосное подключение. Вашей компании необходимо решить, какой диапазон устройств следует поддерживать, учитывая вероятных клиентов. Если вы создаете онлайн брошюру для роскошного спа-салона, вы можете принять бизнес-решение только для ориентации на передовые смартфоны, в то время как если вы создаете систему бронирования билетов для кинотеатра, вам, вероятно, нужно учитывать посетителей с менее мощными функциями телефонов.

Параметры архитектуры

Прежде чем мы перейдем к конкретным техническим деталям ASP.NET Web Forms или MVC, обратите внимание, что веб-разработчики в целом имеют три main возможных вариантов поддержки мобильных браузеров:

1. Ничего не делать — Вы можете просто создать стандартное, ориентированное на настольные компьютеры веб-приложение, и положиться на мобильные браузеры, чтобы сделать его приемлемым.

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

   • Недостаток: обеспечивает наихудшее взаимодействие с конечным пользователем:

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

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

   • Преимущество. Оптимизирует отрисовку для конкретного используемого устройства, даже для неизвестных будущих устройств в соответствии с любыми характеристиками экрана и входных данных, которые у них есть.
   • Преимущество: позволяет легко совместно использовать логику на стороне сервера для всех типов устройств, что позволяет с минимальным дублированием кода или усилий
   • Недостаток: мобильные устройства настолько отличаются от настольных устройств, что вы можете действительно захотеть, чтобы мобильные страницы полностью отличались от страниц рабочего стола, отображая другую информацию. Такие варианты могут быть неэффективными или невозможно достичь надежно только с помощью CSS, особенно с учетом того, как несогласованно старые устройства интерпретируют правила CSS. Это особенно касается атрибутов CSS 3.
   • Недостаток: не поддерживает различные серверные логики и рабочие процессы для разных устройств. Например, вы не можете реализовать упрощенный рабочий процесс оформления заказа корзины для мобильных пользователей только с помощью CSS.
   • Недостаток: неэффективное использование пропускной способности. Возможно, вам придется передать разметку и стили, которые применяются ко всем возможным устройствам, даже если целевое устройство будет использовать только подмножество этих сведений.

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

   • Преимущество: Максимальная гибкость. Нет ограничений на то, насколько вы можете изменить логику на стороне сервера для мобильных устройств или оптимизировать разметку для нужного макета для конкретного устройства.
   • Преимущество: Эффективное использование пропускной способности. Вам нужно только передать сведения о разметке и стиле, которые будет использоваться целевым устройством.
   • Недостаток: Иногда принудительное повторение усилий или кода (например, создание похожих, но немного отличающихся копий веб-формы страниц или представлений MVC). Там, где это возможно, вы будете учитывать общую логику в базовом уровне или службе, но тем не менее, некоторые части кода пользовательского интерфейса или разметки, возможно, придется дублировать и затем поддерживать в параллельном режиме.
   • Недостаток: Обнаружение устройств не является тривиальным. Для этого требуется список или база данных известных типов устройств и их характеристик (которые не всегда могут быть полностью актуальными) и не гарантируется точное соответствие каждому входящему запросу. В этом документе описываются некоторые варианты и их подводные камни позже.

Для получения наилучших результатов большинство разработчиков считают, что им нужно сочетать варианты (2) и (3). Незначительные стилистические различия лучше всего учитывать на клиенте с помощью CSS или даже JavaScript, тогда как основные различия в данных, рабочем процессе или разметке наиболее эффективно реализуются в серверном коде.

В этом документе основное внимание уделяется методам на стороне сервера

Так как ASP.NET Web Forms и MVC в основном являются технологиями на стороне сервера, в этом техническом документе основное внимание уделяется методам на стороне сервера, которые позволяют создавать различные разметки и логики для мобильных браузеров. Конечно, вы также можете сочетать это с любой клиентской методикой (например, запросы мультимедиа CSS 3, прогрессивное улучшение JavaScript), но это скорее вопрос веб-дизайна, чем ASP.NET разработки.

Обнаружение браузеров и устройств

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

• Это мобильное устройство?
• Метод ввода (мышь/клавиатура, сенсорный ввод, клавиатура, джойстик, ...)
• Размер экрана (физически и в пикселях)
• Поддерживаемые форматы мультимедиа и данных
• Прочее

Лучше принимать решения на основе характеристик, чем номера модели, так как тогда вы будете лучше подготовлены для обработки будущих устройств.

Использование ASP. Встроенная поддержка обнаружения в браузере NET

разработчики ASP.NET Web Forms и MVC могут сразу же обнаружить важные характеристики браузера, проверяя свойства объекта Request.Browser. Например, см. раздел

• Request.Browser.IsMobileDevice
• Request.Browser.MobileDeviceManufacturer, Request.Browser.MobileDeviceModel
• Request.Browser.ScreenPixelsWidth
• Request.Browser.SupportsXmlHttp
• ...и многие другие

В фоновом режиме платформа ASP.NET сопоставляет входящий http-заголовок User-Agent (UA) с регулярными выражениями в наборе XML-файлов определения браузера. По умолчанию платформа включает определения для многих распространенных мобильных устройств, и вы можете добавлять пользовательские файлы определения браузеров для других пользователей, которые вы хотите распознать. Дополнительные сведения см. на странице MSDN ASP.NET веб-серверных элементов управления и возможностей браузера.

Использование базы данных устройств WURFL через 51Degrees.mobi Foundation

Пока ASP. Встроенной поддержки обнаружения в браузере NET будет достаточно для многих приложений. Существует два main случаях, когда этого может быть недостаточно:

• Вы хотите распознать последние устройства (без создания для них файлов определения браузера вручную). Обратите внимание, что файлы определения браузера .NET 4 недостаточно свежи для распознавания Windows Phone 7, телефонов Android, браузеров Opera Mobile или Apple iPad.
• Вам потребуются более подробные сведения о возможностях устройства. Возможно, вам потребуется знать о методе ввода на устройстве (например, сенсорный ввод или клавиатура) или о том, какие форматы звука поддерживает браузер. Эти сведения недоступны в стандартных файлах определения браузера.

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

Отличная новость для разработчиков .NET заключается в том, что ASP. Функция обнаружения браузера NET является расширяемой, поэтому ее можно улучшить, чтобы устранить эти проблемы. Например, можно добавить библиотеку открытый код 51Degrees.mobi Foundation в проект. Это поставщик ASP.NET IHttpModule или browser Capabilities Provider (который можно использовать как в приложениях веб-формы, так и в MVC), который напрямую считывает данные WURFL и подключает их к ASP. Встроенный механизм обнаружения в браузере NET. После установки модуля Request.Browser внезапно будет содержать гораздо более точные и подробные сведения: он правильно распознает многие из упомянутых ранее устройств и перечислит их возможности (включая дополнительные возможности, такие как метод ввода). Дополнительные сведения см. в документации по проекту.

Как веб-формы приложения могут представлять страницы для мобильных устройств

По умолчанию новое приложение веб-формы отображается на распространенных мобильных устройствах:

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

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

Создание страницы master для мобильных устройств

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

Это легко сделать. Например, в веб-форму можно добавить обработчик PreInit следующего вида:

protected void Page_PreInit(object sender, EventArgs e)
{
    if (Request.Browser.IsMobileDevice)
        MasterPageFile = "~/Mobile.Master";
}

Теперь создайте master страницу с именем Mobile.Master в папке верхнего уровня приложения, и она будет использоваться при обнаружении мобильного устройства. При необходимости страница мобильного master может ссылаться на таблицу стилей CSS для мобильных устройств. Посетители компьютеров по-прежнему будут видеть страницу master по умолчанию, а не мобильную.

Создание независимых мобильных веб-формы

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

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

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

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

Часто бывает удобно перенаправлять мобильных посетителей на мобильные страницы только по первому запросу в сеансе просмотра (а не по каждому запросу в сеансе), так как:

• Затем вы можете легко разрешить посетителям мобильных устройств доступ к страницам рабочего стола, если они хотят. Просто поместите ссылку на страницу master, которая переходит в раздел "Классическая версия". Посетитель не будет перенаправляться обратно на страницу мобильного устройства, так как это уже не первый запрос в сеансе.
• Это позволяет избежать риска вмешательства в запросы к любым динамическим ресурсам, совместно используемым между классическими и мобильными частями сайта (например, при наличии общей веб-формы, которая отображается в IFRAME как для настольных, так и мобильных частей сайта, или некоторых обработчиков Ajax).

Для этого можно поместить логику перенаправления в метод Session_Start . Например, добавьте следующий метод в файл Global.asax.cs:

void Session_Start(object sender, EventArgs e)
{
    // Redirect mobile users to the mobile home page
    HttpRequest httpRequest = HttpContext.Current.Request;
    if (httpRequest.Browser.IsMobileDevice)
    {
        string path = httpRequest.Url.PathAndQuery;
        bool isOnMobilePage = path.StartsWith("/Mobile/", 
                               StringComparison.OrdinalIgnoreCase);
        if (!isOnMobilePage)
        {
            string redirectTo = "~/Mobile/";

            // Could also add special logic to redirect from certain 
            // recognized pages to the mobile equivalents of those 
            // pages (where they exist). For example,
            // if (HttpContext.Current.Handler is UserRegistration)
            //     redirectTo = "~/Mobile/Register.aspx";

            HttpContext.Current.Response.Redirect(redirectTo);
        }
    }
}

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

Обратите внимание, что проверка подлинности с помощью форм делает определенные предположения о том, где она может перенаправлять посетителей во время и после процесса проверки подлинности:

• Когда пользователю требуется пройти проверку подлинности, проверка подлинности с помощью форм перенаправит его на страницу входа на рабочий стол независимо от того, является ли пользователь настольным компьютером или мобильным пользователем (так как он имеет только один URL-адрес входа). Если вы хотите изменить стиль страницы входа для мобильных устройств, необходимо улучшить страницу входа на компьютере, чтобы она перенаправляла мобильных пользователей на отдельную страницу входа для мобильных устройств. Например, добавьте следующий код в код программной части страницы входа на рабочем столе :

  public partial class Login : System.Web.UI.Page
  {
      protected void Page_Load(object sender, EventArgs e)
      {
          // Ensure that if Forms Authentication forces a mobile user 
          // to log in, we display the mobile login page
          string returnUrl = Request.QueryString["ReturnUrl"];
          if (!String.IsNullOrEmpty(returnUrl) && returnUrl.StartsWith("/Mobile/",
                                                  StringComparison.OrdinalIgnoreCase)) 
          {
              Response.Redirect("~/Mobile/Account/Login.aspx?ReturnUrl=" 
                                + HttpUtility.UrlEncode(returnUrl));
          }
  
          RegisterHyperLink.NavigateUrl = "Register.aspx?ReturnUrl=" 
                                          + HttpUtility.UrlEncode(returnUrl);
      }
  }
  

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

  public partial class Login : System.Web.UI.Page
  {
      protected void Page_Load(object sender, EventArgs e)
      {
          // Ensure that after logging in, mobile users stay on mobile pages
          string returnUrl = Request.QueryString["ReturnUrl"];
          if (String.IsNullOrEmpty(returnUrl))
          {
              returnUrl = "~/Mobile/";
          }
          LoginUser.DestinationPageUrl = returnUrl;
  
          // (the following line is already present by default)
          RegisterHyperLink.NavigateUrl = "Register.aspx?ReturnUrl=" 
                                          + HttpUtility.UrlEncode(returnUrl);
      }
  }
  

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

Работа с кэшированием выходных данных

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

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

<%@ OutputCache VaryByParam="*" Duration="60" VaryByCustom="isMobileDevice" %>

Затем определите isMobileDevice в качестве настраиваемого параметра кэша, добавив следующее переопределение метода в файл Global.asax.cs:

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    if (string.Equals(custom, "isMobileDevice", StringComparison.OrdinalIgnoreCase))
        return context.Request.Browser.IsMobileDevice.ToString();

    return base.GetVaryByCustomString(context, custom);
}

Это гарантирует, что мобильные посетители страницы не получат выходные данные, ранее помещенные в кэш посетителем рабочего стола.

Рабочий пример

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

Дополнительные советы по оптимизации разметки и CSS для мобильных браузеров см. в разделе "Стилизация страниц мобильных устройств для мобильных браузеров" далее в этом документе.

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

Так как шаблон model-view-Controller отделяет логику приложения (в контроллерах) от логики представления (в представлениях), вы можете выбрать один из следующих подходов к обработке поддержки мобильных устройств в серверном коде:

1. Используйте одни и те же контроллеры и представления для классических и мобильных браузеров, но отрисовка представлений с разными макетами Razor в зависимости от типа устройства. Этот вариант лучше всего подходит, если вы отображаете идентичные данные на всех устройствах, но просто хотите предоставить различные таблицы стилей CSS или изменить несколько элементов HTML верхнего уровня для мобильных устройств.
2. Используйте одни и те же контроллеры для классических и мобильных браузеров, но отрисовка разных представлений зависит от типа устройства. Этот вариант лучше всего подходит, если вы отображаете примерно одинаковые данные и предоставляете те же рабочие процессы для конечных пользователей, но хотите визуализировать очень другую разметку HTML в соответствии с используемым устройством.
3. Создайте отдельные области для классических и мобильных браузеров, реализуя независимые контроллеры и представления для каждого из них. Этот вариант лучше всего подходит, если вы отображаете очень разные экраны, содержащие разные сведения и ведете пользователя через различные рабочие процессы, оптимизированные для типа устройства. Это может означать некоторое повторение кода, но это можно свести к минимуму, разъединяя общую логику в базовом уровне или службе.

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

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

Теперь вы можете создать макет для мобильных устройств с именем _LayoutMobile.cshtml со структурой страницы и правилами CSS, оптимизированными для мобильных устройств.

Если вы хотите использовать второй вариант отрисовки совершенно разных представлений в соответствии с типом устройства посетителя, см. запись в блоге Скотта Хансельмана.

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

Настройка мобильной области в приложении MVC ASP.NET

Вы можете добавить область с именем Mobile в существующее приложение ASP.NET MVC обычным способом: щелкните правой кнопкой мыши имя проекта в Обозреватель решений, а затем выберите Добавить область. Затем можно добавить контроллеры и представления, как и для любой другой области в приложении ASP.NET MVC. Например, добавьте в область "Мобильные устройства" новый контроллер с именем HomeController, который будет выступать в качестве домашней страницы для посетителей мобильных устройств.

Обеспечение того, чтобы URL-адрес /Mobile достиг домашней страницы мобильного устройства

Если вы хотите, чтобы URL-адрес /Mobile достиг действия Индекс в HomeController в вашей области "Мобильные устройства", необходимо внести два небольших изменения в конфигурацию маршрутизации. Сначала обновите класс MobileAreaRegistration, чтобы homeController был контроллером по умолчанию в области мобильных устройств, как показано в следующем коде:

public override void RegisterArea(AreaRegistrationContext context)
{
    // By default there is no "controller" parameter in the following line. 
    // Add one referencing "Home" as shown.
    context.MapRoute(
        "Mobile_default",
        "Mobile/{controller}/{action}/{id}",
        new { controller = "Home", action = "Index", id = UrlParameter.Optional }
    );
}

Это означает, что домашняя страница мобильного устройства теперь будет находиться в папке /Mobile, а не /Mobile/Home, так как "Home" теперь является неявным именем контроллера для мобильных страниц.

Затем обратите внимание, что, добавив в приложение второй HomeController (т. е. мобильный, в дополнение к существующему настольному), вы разорвали обычную домашнюю страницу рабочего стола. Произойдет сбой с ошибкой "Обнаружено несколько типов, которые соответствуют контроллеру с именем Home". Чтобы устранить эту проблему, обновите конфигурацию маршрутизации верхнего уровня (в Global.asax.cs), чтобы указать, что домашний контроллер рабочего стола должен иметь приоритет при возникновении неоднозначности:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default",
        "{controller}/{action}/{id}",
        new { controller = "Home", action = "Index", id = UrlParameter.Optional },
        // Add the namespace of your desktop controllers here
        new[] { "YourApplication.Controllers" } 
    );
}

Теперь ошибка уйдет, и URL-адрес http:// вашайт/ перейдет на домашнюю страницу рабочего стола, а http:// вашайт/mobile/ перейдет на домашнюю страницу мобильного устройства.

Перенаправление мобильных посетителей в вашу мобильную область

В ASP.NET MVC существует множество различных точек расширяемости, поэтому существует множество возможных способов внедрения логики перенаправления. Одним из вариантов является создание атрибута фильтра [RedirectMobileDevicesToMobileArea], который выполняет перенаправление при соблюдении следующих условий:

1. Это первый запрос в сеансе пользователя (т. е. Session.IsNewSession равен true).
2. Запрос поступает из мобильного браузера (т. е. Request.Browser.IsMobileDevice равно true).
3. Пользователь еще не запрашивает ресурс в мобильной области (т. е. путь URL-адреса не начинается с /Mobile).

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

Так как это фильтр, вы можете применить его к определенным контроллерам и действиям, например

public class HomeController : Controller
{
    [RedirectMobileDevicesToMobileArea] // Applies just to this action
    public ActionResult Index()
    {
        // ...
    }
}

… Или его можно применить ко всем контроллерам и действиям в качестве глобального фильтра MVC 3 в файле Global.asax.cs:

protected void Application_Start()
{
    // (rest of method unchanged)

    // Using "order" value 1 means it will run after unordered filters
    // associated with specific controllers or actions, so the redirection 
    // location can be overridden for specific actions
    GlobalFilters.Filters.Add(new RedirectMobileDevicesToMobileAreaAttribute(), 1);
}

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

• Зарегистрируйте глобальный фильтр, как показано выше, который по умолчанию отправляет мобильных посетителей на домашнюю страницу мобильного устройства.
• Кроме того, примените специальный фильтр [RedirectMobileDevicesToMobileProductPage] к действию "просмотреть продукт", которое переносит посетителей мобильных устройств на мобильную версию любой запрошенной страницы продукта.
• Кроме того, примените другие специальные подклассы фильтра к определенным действиям, перенаправляя посетителей мобильных устройств на эквивалентную мобильную страницу.

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

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

Чтобы избежать этой проблемы, добавьте логику в действие входа в систему на рабочем столе, чтобы оно перенаправляло мобильных пользователей на мобильное действие "вход". Если вы используете шаблон приложения MVC по умолчанию ASP.NET, обновите действие LogOn AccountController следующим образом:

public ActionResult LogOn()
{
    string returnUrl = Request.QueryString["ReturnUrl"];
    if ((returnUrl != null) && returnUrl.StartsWith("/Mobile/", 
                               StringComparison.OrdinalIgnoreCase)) 
    {
        return RedirectToAction("LogOn", "Account", 
                                new { Area = "Mobile", ReturnUrl = returnUrl });
    }
    return View();
}

… а затем реализуйте подходящее действие входа для мобильных устройств на контроллере AccountController в вашей области "Мобильное устройство".

Работа с кэшированием выходных данных

Если вы используете фильтр [OutputCache], необходимо принудительно изменить запись кэша в зависимости от типа устройства. Например, напишите:

[OutputCache(Duration = 60, VaryByParam = "*", VaryByCustom = "isMobileDevice")]

Затем добавьте следующий метод в файл Global.asax.cs:

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    if (string.Equals(custom, "isMobileDevice", StringComparison.OrdinalIgnoreCase))
        return context.Request.Browser.IsMobileDevice.ToString();

    return base.GetVaryByCustomString(context, custom);
}

Это гарантирует, что мобильные посетители страницы не получат выходные данные, ранее помещенные в кэш посетителем рабочего стола.

Рабочий пример

Чтобы увидеть эти методы в действии, скачайте примеры кода в этом техническом документе. Пример включает в себя приложение ASP.NET MVC 3 (релиз-кандидат), расширенное для поддержки мобильных устройств с помощью описанных выше методов.

Дополнительные рекомендации и рекомендации

Следующее обсуждение относится как к веб-формы, так и к разработчикам MVC, которые используют методы, описанные в этом документе.

Улучшение логики перенаправления с помощью 51Degrees.mobi Foundation

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

Вы уже узнали, как открытый код 51Degrees.mobi Foundation может повысить точность ASP. Обнаружение браузера NET. Он также имеет встроенную возможность перенаправлять мобильных посетителей в определенные расположения, настроенные в Web.config. Он может работать без зависимости от ASP.NET сеансов (и, следовательно, файлов cookie), сохраняя временный журнал хэшей http-заголовков и IP-адресов посетителей, поэтому он знает, является ли каждый запрос первым из данного вистора.

Следующий элемент, добавленный в раздел fiftyOne файла web.config, перенаправляет первый запрос с обнаруженного мобильного устройства на страницу ~/Mobile/Default.aspx. Все запросы к страницам в папке Mobile не будут перенаправляться независимо от типа устройства. Если мобильное устройство неактивно в течение 20 минут или более, оно будет забыто, а последующие запросы будут рассматриваться как новые для целей перенаправления.

<redirect firstRequestOnly="true"
          mobileHomePageUrl="~/Mobile/Default.aspx"
          timeout="20"
          devicesFile="~/App_Data/Devices.dat"
          mobilePagesRegex="/Mobile/" />

Дополнительные сведения см. в документации по 51degrees.mobi Foundation.

Отключение транскодеров и прокси-серверов

Операторы мобильной сети имеют две широкие цели в своем подходе к мобильному Интернету:

1. Предоставьте как можно больше релевантного содержимого
2. Максимальное число клиентов, которые могут использовать ограниченную пропускную способность радиосети

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

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

Response.Cache.SetNoTransforms();

Или для контроллера MVC ASP.NET можно добавить следующее переопределение метода, чтобы оно применялось ко всем действиям на этом контроллере:

protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
    filterContext.HttpContext.Response.Cache.SetNoTransforms();
}

Полученное http-сообщение уведомляет совместимые с W3C транскодеры и прокси-серверы не изменять содержимое. Конечно, нет никакой гарантии, что операторы мобильной сети будут уважать это сообщение.

Стилизация страниц мобильных устройств для мобильных браузеров

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

Некоторые современные мобильные браузеры, отображая веб-страницы, предназначенные для настольных мониторов, отрисовывали страницу на виртуальном холсте, также называемом "окно просмотра" (например, виртуальная область просмотра имеет ширину 980 пикселей на iPhone и 850 пикселей в ширину в Opera Mobile по умолчанию), а затем масштабируйте результат в соответствии с физическими пикселями экрана. Затем пользователь может увеличить масштаб и сдвиг вокруг этого окна просмотра. Это имеет преимущество в том, что он позволяет браузеру отображать страницу в предполагаемом макете, но он также имеет недостаток в том, что он принудительно масштабирует и сдвиг, что неудобно для пользователя. Если вы разрабатываете для мобильных устройств, лучше проектировать для узкого экрана, чтобы не было необходимости в масштабировании или горизонтальной прокрутке.

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

<meta name="viewport" content="width=480">

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

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

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

Чтобы это работало правильно, не следует явно принудительно принуждать элементы к превышению этой ширины (например, с помощью атрибута width или свойства CSS), в противном случае браузер будет вынужден использовать большее окно просмотра независимо от того. См. также: дополнительные сведения о теге нестандартного окна просмотра.

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

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

<meta name="MobileOptimized" content="width" />
<meta name="HandheldFriendly" content="true" />

Дополнительные ресурсы

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

Благодарности

• Основной автор: Стивен Сандерсон
• Рецензенты и дополнительные авторы контента: Джеймс Роузуэлл (James Rosewell), Микаэль Сёдерстрём (Mikael Söderström), Скотт Хансельман (Scott Hanselman), Скотт Хантер (Scott Hunter)