本文章是由機器翻譯。

技術最前線

行動網站程式開發，第三篇：傳遞要求

Dino Esposito

往往不一個手機網站是網站的為桌面的觀眾建造更大的子集。桌面使用者經常訪問您的網站使用，例如，一台手提電腦螢幕解析度高和大量的計算能力。此外，使用者依靠穩定的連接，並不是特別關注排水電池。所有這些參數的建築師和開發商的 Web 網站，以及域專家帶來巨大的不同。當它來到移動網站時，最難的地方不是編碼，而弄到代碼的使用案例 — — 在那之前，要有一個手機網站 （或移動應用程式） 的業務案例。

移動網站存在是為了方便使用者去消費最有關的服務，你已經公開通過主要的 Web 網站。現在，讓我們假設我們有明確的一組用例，我們準備好開始編碼和生產一些好的標記。但是，首先，如何做我們到達移動網站呢？

我堅信一個手機網站應該是一個對應于不同的 IIS 應用程式的獨立網站。這大大簡化了開發的經驗。你只專注于移動使用案例。您優化呈現和移動的用例的應用層。你只處理技術和工具有關的移動情況。最後，您測試，更容易。

另一方面，作為使用者，我討厭不必鍵入一個不同的 URL，只是要查看的網站，我感興趣的移動版本。如果您可以只鍵入或書簽 www.contoso.com，讓網站弄清楚你是否來自行動裝置或一台手提電腦，不很好？一旦確定你的起源，網站可能有可能您重定向到移動網站。運用這種戰略可以提供一個很好的經驗，但這需要一些假設和一些機械在的地方。

路由到正確的網站的使用者

讓我們假設有兩個不同的 Web 網站 — — 說，www.contoso.com 和 m.contoso.com。使用者，但是，預計不知道 m 網站 ； 她只知道主要的 Web 網站。所以她進她的行動裝置類型 www.contoso.com。在主網站主辦了一些代碼截獲該請求並檢查使用者代理字串。如果請求來自桌面瀏覽器，什麼也沒發生，並要求照常進行。如果請求的瀏覽器託管在行動裝置上，將使用者重定向到登錄頁，她已要求的完整的網站和移動網站之間作出選擇。圖 1 提供了我我概述的戰略的圖形視圖。

圖 1 路由到最合適的網站的使用者策略

更普遍而言，兩個網站具有攔截，過濾任何傳入的請求重定向到登錄頁，如果請求的設備不相容的網站類型。為了保持事情更簡單，也可以讓筆記本電腦查看移動頁，如果進行顯式請求和主機只有一個登錄頁，主網站從行動裝置的請求時。

這一戰略只解釋到網站的第一次請求做什麼 — — 通常定向到該網頁。對於，使用者可以作為她作品與網站的連續請求，你不想攔截器來再次踢並顯示登錄頁。讓我們看看如何實現這一戰略。

請求路由到 HTTP 模組

在 ASP.NET 中，攔截傳入請求的標準方法安裝 HTTP 模組。對於每個被截取的請求，HTTP 模組將檢查使用者代理字串並確定瀏覽器主辦在行動裝置上。如果行動裝置上運行的瀏覽器，HTTP 模組把使用者重定向到給定的著陸頁 ； 如果不是，它只會讓傳遞，像往常一樣處理該請求。圖 2 顯示為路由到 （移動） 著陸頁的移動請求的示例 HTTP 模組的原始程式碼。

圖 2 移動路由器元件作為 HTTP 模組實現

public class MobileRouterModule : IHttpModule
{
  private const String ForceFullSiteCookieName = "FullSiteMode";
  public void Dispose()
  {
  }
 public void Init(HttpApplication context)
 {
   context.BeginRequest += OnBeginRequest;
 }
 private static void OnBeginRequest(Object sender, EventArgs e)
 {
   var app = sender as HttpApplication;
   if (app == null)
     throw new ArgumentNullException("sender");
   // Check whether it is a mobile site
   var isMobileDevice = IsMobileUserAgent(app);
   // The mobile user confirmed to view the desktop site 
   if (isMobileDevice && ForceFullSite(app))
   {
     app.Response.AppendCookie(new HttpCookie(ForceFullSiteCookieName));
     return;
   }
   // The mobile user is navigating through the desktop site
   if (isMobileDevice && HasFullSiteCookie(app))
     return;
   // The mobile user is attempting to view a desktop page
   if (isMobileDevice)
     ToMobileLandingPage(app);
 }
}

基本上有三種使用案例情形。 一個是當與行動裝置使用者到達一個著陸頁，並證實了她想要查看完整的網站。 另一種情況是當移動使用者請求完整網站上的頁面，因為她是繼中一個整個網站頁面的連結。 把另一種方式，移動使用者收到的登錄頁，證實了她想要查看完整的網站，現在流覽網站。 最後，第三種情況是當移動使用者正試圖在該瀏覽器會話中的首次訪問的完整網站。 在前兩種情況下，HTTP 模組允許傳遞請求。 中最後一種情況，它只是把移動使用者重定向到特設的登錄頁。

著陸頁將移動優化的網頁，向使用者顯示一條消息，提供的桌面網站或移動網站主頁的連結。 圖 3 顯示了一個示例著陸頁。 你可以試試看現場直播通過指向您自己設備到 easycourt.net/contosoen。

圖 3 樣本的登錄頁，一個手機網站

背後的"移動的網站"連結 URL 指向移動網站主頁。 其他連結指向具有額外的查詢字串參數的完整網站的網頁。 名稱與此參數的作用取決於您，但該名稱可能會像下面這樣：HTTP://www.contoso.com?mode=full。

此參數將檢查由 HTTP 模組通過中提到的職能之一圖 2，如下所示：

private static Boolean ForceFullSite(HttpApplication app)
{
  var full = app.Context.Request.QueryString["mode"];
  if (!String.IsNullOrEmpty(full))
    return String.Equals(full, "full", 
      StringComparison.InvariantCultureIgnoreCase);
  return false;
}

你看到在圖 2 ，使用者的選擇存儲在 cookie 中。 這意味著明確選擇以導航到完整的網站與行動裝置的使用者不會困擾不再著陸頁，只要該 cookie 是可用。

在討論中更詳細地著陸頁的結構之前，讓我指定的 HTTP 模組如何理解是否使用者按一下以查看完整的網站，或者通過全面的網站中導航。 在圖 2 您看看下面的代碼用於檢查是否找到該 cookie 用於查看完整的網站：

private static Boolean HasFullSiteCookie(HttpApplication app)
{
  var cookie = app.Context.Request.Cookies[FullSiteModeCookie];
  return cookie != null;
}

如果有無 cookie 並沒有查詢字串參數，從行動裝置訪問桌面網站的使用者只是重定向到登錄頁：

private static void ToMobileLandingPage(HttpApplication app)
{
  var landingPage = ConfigurationManager.AppSettings["MobileLandingPage"];
  if (!String.IsNullOrEmpty(landingPage))
    app.Context.Response.Redirect(landingPage);
}

關鍵的一點是將使用者可能定向到登錄頁只有她試圖從行動裝置訪問給定的桌面網站第一次。 從這點上，任何進一步的請求有防止 HTTP 模組將重定向的額外資訊。

檢測的行動裝置

在中看到的所有代碼圖 2，只有一塊有待充分解釋：您如何檢測到請求的設備是否為行動裝置。 這可以實現的是以不同的方式和具有不同級別的可靠性。 例如，您可以只依靠一些中所示的代碼圖 4。 它嘗試查詢一些只移動的關鍵字的使用者代理字串。

圖 4 只移動關鍵字查詢的使用者代理字串

private static Boolean HasAnyMobileKeyword(String userAgent)
{
  string ua = userAgent.ToLower();
  return (ua.Contains("midp") ||
    ua.Contains("mobile") ||
    ua.Contains("android") ||
    ua.Contains("samsung") ||
    ua.Contains("nokia") ||
    ua.Contains("phone") ||
    ua.Contains("opera mini") ||
    ua.Contains("opera mobi") ||
    ua.Contains("blackberry") ||
    ua.Contains("symbian") ||
    ua.Contains("j2me") ||
    ua.Contains("windows ce") ||
    ua.Contains("vodafone") ||
    ua.Contains("ipad;") ||
    ua.Contains("maemo") ||
    ua.Contains("palm") ||
    ua.Contains("fennec") ||
    ua.Contains("wireless") ||
    ua.Contains("htc") ||
    ua.Contains("nintendo") ||
    ua.Contains("zunewp7") ||
    ua.Contains("silk");
}

關鍵字清單不是詳盡無遺，但它相當具有代表性的移動的宇宙。此代碼可能會延長，以使它更好地工作和更好的新設備的顯示，以及更多手機使用者開始訪問您的網站。但這是精確的點。你是否願意不斷更新這段代碼？無需修改此類代碼只是一個設備描述存儲庫 （復員方案） 提供的好處。復員方案是建立在一個資料庫，其中包含使用者代理字串一個庫。所有 DDR 不會是解析使用者代理，並返回的已知功能清單。我說"已知"不"檢測"因為這是正是如此。DDR 頻繁更新的資料庫從靜態地獲取資訊。它不會檢測到該設備的能力。不過，這是 DDR 的解決方案，而不是限制的優勢 ！DDR 的背後有的人為干預，和人類的工作建立一個給定的設備是否具有給定的能力。某些功能可以通過演算法，檢測到，但返回的值並不一定完全可靠。一些其他功能 — — 大多數，其實 — — 不能通過演算法檢測到，但可以用來瞭解智慧地決定要為給定設備的標記。

流行 Ddr 的 ASP.NET 空間是無線通用的資源檔，或 WURFL 和 51degrees，在我以前的專欄文章中討論 (msdn.microsoft.com/magazine/jj190798)。因為這些框架都是有限的 （而大多是基於雲計算） 使用的免費產品，您可能想要挑選其中之一，即使您只需要確定設備是否移動或不。至少你保存你自己負擔的經常更新您的 IsMobile 函數，以跟上新的設備和角例。

針對不同的設備進行優化

接近尾聲了，我相信網站應該提供優化的一組頁面到不同的設備，無論他們是智慧手機、 平板電腦或手提電腦。如果你可以提供不同的 Web 網站或至少物理上不同的視圖，您可以管理並分別保持最佳實現此操作。然而，這種分離總是應該對網站的訪問者是透明的。網站應該可以訪問通過唯一的 URL。你不讓做神奇的理解的設備的類型和切換到最合適的視圖的基礎平臺。在我的下一篇專欄中，我將使用 Ddr 來討論執行不同的意見，為不同的設備。

Dino Esposito  是"構建移動解決方案的企業"（微軟出版社，2012年） 的作者和"程式設計 ASP.NET MVC 3"（微軟出版社，2011年），並散佈"Microsoft.net：構建企業應用程式"（微軟出版社，2008年）。總部設在義大利，埃斯波西托是在全球範圍內的行業活動頻繁的演講者。跟隨他在 Twitter 上 twitter.com/despos。

由於下面的技術專家，檢討這篇文章： Pranav Rastogi