如何：將行動網頁新增至 ASP.NET Web Forms / MVC 應用程式

發行項
01/18/2024

適用於

ASP.NET Web Forms 4.0 版

ASP.NET MVC 3.0 版

摘要

本操作說明從您的 ASP.NET Web Forms/MVC 應用程式為行動裝置優化頁面的各種方式，並建議以各種裝置為目標時要考慮的架構和設計問題。本文件也說明為何從 ASP.NET 2.0 到 3.5 的行動控件 ASP.NET 行動控件現在已過時，並討論一些新式替代方案。

概觀

行動裝置 – 智慧型手機、功能手機和平板電腦 – 以存取網路的方式持續成長。對於許多 Web 開發人員和網頁導向的企業，這表示為使用這些裝置的訪客提供絕佳的瀏覽體驗越來越重要。

舊版 ASP.NET 支援行動瀏覽器的方式

ASP.NET 2.0 到 3.5 版包含在 行動控件 ASP.NET： System.Web.Mobile.dll 元件中的一組行動裝置伺服器控件，以及 System.Web.UI.MobileControls 命名空間。元件仍包含在 ASP.NET 4 中，但已被取代。建議開發人員移轉至更現代化的方法，例如本檔中所述的方法。

ASP.NET 行動控件標示為過時的原因，在於其設計是以 2005 和更早版本為通用的行動電話為導向。控件主要是設計來轉譯 WML 或 cHTML 標記 (，而不是該紀元 WAP 瀏覽器的一般 HTML) 。但是 WAP、WML 和 cHTML 不再與大部分專案相關，因為 HTML 現在已成為行動和桌面瀏覽器的普遍標記語言。

現今支持行動裝置的挑戰

雖然行動瀏覽器現在幾乎全都支援 HTML，但當您的目標是建立絕佳的行動瀏覽體驗時，您仍然面臨許多挑戰：

螢幕大小 - 行動裝置在表單上有很大的差異，而且其螢幕通常比桌面監視器小很多。因此，您可能需要為它們設計完全不同的版面配置。
輸入方法 – 有些裝置有鍵盤，有些裝置有手寫筆，有些則使用觸控。您可能需要考慮多個瀏覽機制和數據輸入法。
標準合規性 – 許多行動瀏覽器不支援最新的 HTML、CSS 或 JavaScript 標準。
帶寬 – 行動數據網路效能會隨著情況而有所不同，而某些終端使用者則處於以 MB 計費的線路上。

沒有一體適用的解決方案;您的應用程式必須根據存取應用程式的裝置，以不同的方式進行外觀和行為。視您想要的行動支援層級而定，相較於桌面「瀏覽器爭用」，對於 Web 開發人員而言，這可能會是更大的挑戰。

第一次處理行動瀏覽器支援的開發人員通常只認為支援最新且最複雜的智慧型手機 (很重要，例如 Windows Phone 7、iPhone 或 Android) ，可能是因為開發人員通常會個人擁有這類裝置。不過，較便宜的手機仍然非常受歡迎，且其擁有者會使用它們來瀏覽網路，特別是在行動電話比寬頻連線更容易取得的國家/地區。您的企業必須考慮其可能的客戶，來決定要支援的裝置範圍。如果您要建置一份用於頂級健康 SPA 的在線折頁冊，您可能會做出商務決策，只以進階智慧型手機為目標，而如果您要為電影建立票證預約系統，您可能需要考慮功能較不強大的手機訪客。

架構選項

在取得 ASP.NET Web Forms 或 MVC 的特定技術詳細數據之前，請注意，Web 開發人員一般有三個主要可能的選項可支援行動瀏覽器：

不執行任何動作 – 您可以直接建立標準、桌面導向的 Web 應用程式，並依賴行動瀏覽器來接受轉譯。
- 優點：這是實作和維護的最便宜選項–沒有額外的工作
- 缺點：提供最差的用戶體驗：
  - 最新的智慧型手機可能會轉譯您的 HTML 以及桌面瀏覽器，但使用者仍會強制以水準和垂直方式縮放，以在小型螢幕上取用您的內容。這離最佳位置還遠。
  - 較舊的裝置和功能手機可能無法以滿意的方式轉譯您的標記。
  - 即使在最新的平板電腦裝置上 (螢幕可以和膝上型電腦螢幕) 一樣大，仍適用不同的互動規則。觸控式輸入最適合使用較大的按鈕和鏈接進一步分散，而且沒有方法可將滑鼠游標停留在飛出功能表上。
解決客戶端上的問題 – 仔細使用 CSS 和漸進式增強功能，您可以建立可適應執行瀏覽器的標記、樣式和腳本。例如，使用 CSS 3 媒體查詢，您可以建立多欄配置，以在畫面比所選閾值窄的裝置上變成單一數據行配置。
- 優點：針對使用中的特定裝置優化轉譯，即使是根據任何螢幕和輸入特性的未知未來裝置
- 優點：輕鬆地讓您跨所有裝置類型共用伺服器端邏輯 – 最少重複的程式代碼或工作
- 缺點：行動裝置與桌面裝置不同，您可能真的希望行動頁面與您的桌面頁面完全不同，顯示不同的資訊。這類變化可能沒有效率或無法單獨透過 CSS 強固達成，特別是考慮較舊裝置解譯 CSS 規則的方式不一致。這特別適用於 CSS 3 屬性。
- 缺點：不支援不同裝置的不同伺服器端邏輯和工作流程。例如，您無法單獨透過 CSS 為行動用戶實作簡化的購物車結帳工作流程。
- 缺點：使用頻寬效率不佳。即使目標裝置只會使用該資訊的子集，您伺服器可能必須傳輸套用至所有可能裝置的標記和樣式。
解決伺服器上的問題 – 如果您的伺服器知道哪個裝置正在存取它，或至少該裝置的特性，例如其螢幕大小和輸入法，以及它是否為行動裝置，它可以執行不同的邏輯並輸出不同的 HTML 標記。
- 優勢： 最大彈性。您可以針對行動裝置變更伺服器端邏輯，或針對所需的裝置特定配置優化標記，並無任何限制。
- 優勢： 有效率的頻寬使用。您只需要傳輸目標裝置將使用的標記和樣式資訊。
- 缺點：有時候會強制重複工作或程式碼 (，例如，讓您建立類似但稍有不同的 Web Form 頁面或MVC檢視複本) 。在可能的情況下，您會將一般邏輯分解成基礎層或服務，但仍可能必須複製 UI 程式代碼或標記的某些部分，然後以平行方式維護。
- 缺點： 裝置偵測並不簡單。它需要已知裝置類型的清單或資料庫及其特性 (，這可能不一定是最新的) ，而且不保證能正確比對每個傳入要求。本檔稍後會說明一些選項及其陷阱。

為了獲得最佳結果，大部分開發人員都發現他們需要結合選項 (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 平臺會比對一組瀏覽器定義 XML 檔案中正則表達式的傳入 User-Agent (UA) HTTP 標頭。根據預設，平臺包含許多常見行動裝置的定義，而且您可以為想要辨識的其他裝置新增自定義瀏覽器定義檔案。如需詳細資訊，請參閱 MSDN 頁面 ASP.NET 網頁伺服器控件和瀏覽器功能。

透過 51Degrees.mobi Foundation 使用 WURFL 裝置資料庫

ASP 時。NET 的內建瀏覽器偵測支援對許多應用程式而言已足夠，但有兩個主要案例可能不夠：

您想要辨識最新的裝置 (，而不需手動為其建立瀏覽器定義檔案) 。請注意，.NET 4 的瀏覽器定義檔案不夠最近，無法辨識 Windows Phone 7、Android 手機、Opera Mobile 瀏覽器或 Apple iPad。
您需要有關裝置功能的詳細資訊。您可能需要知道裝置的輸入法 (例如觸控與鍵盤) ，或瀏覽器支援的音訊格式。標準瀏覽器定義檔案中不提供這項資訊。

無線通用資源檔 (WURFL) 項目會維護目前使用中行動裝置的最新和詳細資訊。

.NET 開發人員的絕佳新聞是 ASP。NET 的瀏覽器偵測功能是可延伸的，因此可以增強以克服這些問題。例如，您可以將 開放原始碼 51Degrees.mobi Foundation 連結庫新增至您的專案。它是 ASP.NET IHttpModule 或 Browser 功能提供者， (可在 Web Form 和 MVC 應用程式) 上使用，直接讀取 WURFL 數據並將其連結至 ASP。NET 的內建瀏覽器偵測機制。安裝模塊之後， Request.Browser 會突然包含更精確且詳細的資訊：它會正確辨識先前提及的許多裝置，並列出其功能， (包括輸入法) 等其他功能。如需詳細資訊，請參閱項目的檔。

Web Form 應用程式如何呈現行動裝置特定頁面

根據預設，以下是一般行動裝置上全新 Web Form 應用程式顯示的方式：

Windows Phone 7 和 Opera Mobile 上顯示兩個 Web Form 應用程式的螢幕快照。

很明顯地，這兩個版面配置看起來都不太適合行動，此頁面是針對大型、橫向導向的監視器所設計，而不是小型直向螢幕。那麼，您可以怎麼做？

如本文稍早所述，有許多方式可針對行動裝置量身打造您的頁面。有些技術是以伺服器為基礎，其他技術則是在用戶端上執行。

建立行動裝置特定主版頁面

根據您的需求，您可能能夠針對所有訪客使用相同的 Web Form，但有兩個不同的主版頁面：一個用於桌面訪客，另一個用於行動訪客。這可讓您彈性地變更 CSS 樣式表單或最上層 HTML 標記以符合行動裝置，而不需要強制複製任何頁面邏輯。

方法很簡單。例如，您可以將 PreInit 處理程式新增至 Web Form：

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

現在，在應用程式的最上層資料夾中建立名為Mobile.Master的主版頁面，並在偵測到行動裝置時使用它。如有需要，您的行動主版頁面可以參考行動裝置特定的 CSS 樣式表單。桌面訪客仍會看到您的預設主版頁面，而不是行動裝置版。

建立獨立的行動裝置特定 Web Form

為了達到最大彈性，您可以進一步瞭解不同裝置類型的個別主版頁面。您可以實作兩組完全個別的 Web Form 頁面 – 一組用於桌面瀏覽器，另一組用於行動裝置。如果您想要將非常不同的資訊或工作流程呈現給行動訪客，這效果最佳。本節的其餘部分會詳細說明此方法。

假設您已經有專為桌面瀏覽器設計的 Web Form 應用程式，最簡單的方式是在專案中建立稱為「行動」的子資料夾，並在該處建置您的行動頁面。您可以使用任何其他 Web Form 應用程式所使用的相同技術，建構整個子網站及其主版頁面、樣式表單和頁面。您不一定需要為桌面網站中的每個頁面產生相當於 的行動 裝置;您可以選擇對行動訪客有意義的功能子集。

如有需要，您的行動頁面可以共用常見的靜態資源 (，例如影像、JavaScript 或 CSS 檔案，) 一般頁面。由於當您的「Mobile」資料夾在 IIS 中裝載時不會標示為個別的應用程式， (它只是 Web Form 頁面的簡單子資料夾) ，它也會共用所有與桌面頁面相同的設定、工作階段資料和其他基礎結構。

注意

由於這種方法通常牽涉到一些重複的程式代碼 (行動頁面可能會與桌面頁面共用一些相似之處) ，因此請務必將任何常見的商業規則或數據存取程式代碼分解成共用基礎層或服務。否則，您將會加倍建立和維護應用程式的工作。

將行動訪客重新導向至您的行動頁面

將行動訪客重新導向至行動頁面，通常只會在其流覽會話 的第一個 要求上 (，而不是在其會話) 的每個要求上，因為：

然後，您可以輕易地允許行動訪客存取您的桌面頁面，只要將連結放在移至「桌面版本」的主版頁面上即可。訪客不會重新導向回行動頁面，因為它不再是其會話中的第一個要求。
這可避免干擾網站桌面與行動元件之間共用之任何動態資源要求的風險 (，例如，如果您有一般 Web 窗體，您的網站桌面和行動元件都會顯示在 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 (導致其輸出快取) ，接著接著接收快取桌面輸出的行動使用者。不論您只是依裝置類型來改變主版頁面，還是針對每個裝置類型實作完全個別 Web Form，都會套用此警告。

若要避免此問題，您可以指示 ASP.NET 根據訪客是否使用行動裝置來變更快取專案。將 VaryByCustom 參數新增至頁面的 OutputCache 宣告，如下所示：

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

接下來，將下列方法覆寫新增至 Global.asax.cs 檔案，將 isMobileDevice 定義為自定義快取參數：

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);
}

這可確保頁面的行動訪客不會收到先前由桌面訪客放入快取中的輸出。

運作中的範例

若要查看這些技術的運作方式，請下載此白皮書的程式代碼範例。 Web Form 範例應用程式會自動將行動使用者重新導向至名為Mobile的子資料夾中的一組行動特定頁面。這些頁面的標記和樣式更適合行動瀏覽器，如下列螢幕快照所示：

兩個行動裝置 Web Form 應用程式的螢幕快照，如 Windows Phone 7 和 Opera Mobile 上所示。

如需優化行動瀏覽器標記和 CSS 的更多秘訣，請參閱本檔稍後的一節。

ASP.NET MVC應用程式如何呈現行動裝置特定頁面

由於 Model-View-Controller 模式會將控制器中的應用程式邏輯) (與檢視) 中的呈現邏輯 (分離，因此您可以從下列任何方法來處理伺服器端程式代碼中的行動支援：

針對桌面和行動瀏覽器使用相同的控制器和檢視，但視裝置類型而定，使用不同的Razor配置來轉譯檢視。如果您在所有裝置上顯示相同的數據，但只是想要提供不同的 CSS 樣式表單，或變更行動裝置的幾個最上層 HTML 元素，此選項最適合。
針對桌面和行動瀏覽器使用相同的控制器，但會根據裝置類型轉譯不同的檢視。如果您要顯示大致相同的數據，併為終端使用者提供相同的工作流程，但想要轉譯非常不同的 HTML 標記，以符合所使用的裝置，則此選項最適合。
為桌面和行動瀏覽器建立不同的區域，為每個瀏覽器實作獨立的控制器和檢視。如果您要顯示非常不同的畫面，其中包含不同的資訊，並引導使用者透過針對其裝置類型優化的不同工作流程，此選項最適合。這可能表示程式代碼重複，但您可以將一般邏輯分解成基礎層或服務，將它最小化。

如果您想要採用第一個選項，並只針對每個裝置類型變更Razor配置，則很容易。只要修改您的 _ViewStart.cshtml 檔案，如下所示：

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

現在，您可以使用針對行動裝置優化的頁面結構和 CSS 規則，建立稱為 _LayoutMobile.cshtml 的行動裝置特定版面配置。

如果您想要採用第二個選項，根據訪客的裝置類型轉譯完全不同的檢視，請參閱 Scott Hanselman 的部落格文章。

本文的其餘部分著重於第三個選項– 為行動裝置建立個別的控制器和檢視，因此您可以確切控制行動訪客所提供的功能子集。

在 ASP.NET MVC 應用程式中設定行動裝置區域

您可以正常方式將名為「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) 中的最上層路由設定 (，以指定您的桌面 HomeController 在發生模棱兩可時應優先：

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:// yoursite/ 會觸達桌面首頁，而 http:// 您的site/mobile/ 會觸達行動首頁。

將行動訪客重新導向至您的行動區域

ASP.NET MVC 中有許多不同的擴充點，因此有許多可能的插入重新導向邏輯方式。其中一個整齊選項是建立篩選屬性 [RedirectMobileDevicesToMobileArea]，如果符合下列條件，則會執行重新導向：

這是用戶會話中的第一個要求 (，也就是 Session.IsNewSession 等於 true)
要求來自行動瀏覽器 (亦即 Request.Browser.IsMobileDevice 等於 true)
使用者尚未要求行動區域中的資源 (亦即 URL 的路徑 部分不是以 /Mobile)

本白皮書隨附的可下載範例包含此邏輯的實作。它實作為授權篩選器，衍生自 AuthorizationAttribute，這表示即使您使用輸出快取 (正常運作，否則，如果桌面訪客第一次存取特定 URL，桌面輸出可能會快取，然後提供給後續的行動訪客) 。

身為篩選條件，您可以選擇將其套用至特定控制器和動作，例如

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

… 或者，您可以將它套用至 Global.asax.cs 檔案中作為 MVC 3 全域篩選 的所有控制器和動作：

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。這表示行動使用者可能會重新導向至您的桌面「登入」動作。

若要避免這個問題，請將邏輯新增至桌面的「登入」動作，讓它再次將行動使用者重新導向至行動裝置「登入」動作。如果您使用預設 ASP.NET MVC 應用程式範本，請更新 AccountController 的 LogOn 動作，如下所示：

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 (候選版) 應用程式，以使用上述方法支援行動裝置。

進一步指引和建議

下列討論適用於使用本文件所涵蓋技術 Web Form 和MVC開發人員。

使用 51Degrees.mobi Foundation 增強重新導向邏輯

本檔中所示的重新導向邏輯可能完全適合您的應用程式，但如果您需要停用會話，或是使用拒絕 Cookie 的行動瀏覽器， (這些無法) 會話，因為它不知道指定的要求是否為該訪客的第一個會話。

您已瞭解開放原始碼 51Degrees.mobi Foundation 如何改善 ASP 的正確性。NET 的瀏覽器偵測。它也具有將行動訪客重新導向至 Web.config 中設定的特定位置的內建功能。它不需要依賴 ASP.NET 會話 (運作，因此，藉由儲存訪客 HTTP 標頭和 IP 位址哈希的暫存記錄來) Cookie，因此它知道每個要求是否都是來自指定 vistor 的第一個要求。

下列新增至 web.config 檔案第 51 個區段的元素會將第一個要求從偵測到的行動裝置重新導向至 ~/Mobile/Default.aspx 頁面。無論裝置類型為何 ，都不會重新 導向行動資料夾下頁面的任何要求。如果行動裝置在 20 分鐘以上的期間內處於非作用中狀態，則會忘記裝置，且後續要求將視為新的要求，以供重新導向之用。

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

如需詳細資訊，請參閱 51degrees.mobi Foundation 檔。

注意

您可以在 ASP.NET MVC 應用程式上使用 51Degrees.mobi Foundation 的重新導向功能，但您必須以純 URL 定義重新導向組態，而不是在路由參數方面，或藉由將 MVC 篩選條件放在動作上。這是因為在撰寫) 51Degrees.mobi Foundation 時 (無法辨識篩選或路由。

停用轉碼器和 Proxy 伺服器

行動網路操作員在其行動因特網方法中有兩個廣泛的目標：

盡可能提供相關的內容
最大化可共用有限無線電網路頻寬的客戶數目

由於大部分網頁都是針對大型桌面大小的螢幕和快速固定線路寬頻連線所設計，因此許多操作員會使用動態改變 Web 內容的 轉碼器 或 Proxy 伺服器 。它們可能會修改您的 HTML 標記或 CSS，以符合較小的螢幕 (，特別是針對缺少處理複雜版面配置) 的「功能手機」，而且可能會重新壓縮您的影像， (大幅減少其品質) 以改善頁面傳遞速度。

但是，如果您已努力產生網站的行動優化版本，您可能不想讓網路操作員進一步干擾。您可以在任何 ASP.NET Web Form 中，將下列這一行新增至 Page_Load 事件：

Response.Cache.SetNoTransforms();

或者，對於 ASP.NET MVC 控制器，您可以新增下列方法覆寫，使其套用至該控制器上的所有動作：

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

產生的 HTTP 訊息會通知 W3C 相容的轉碼器和 Proxy，不要改變內容。當然，不保證行動網路操作員會遵守此訊息。

設定行動瀏覽器的行動頁面樣式

這份檔的範圍超出此範圍，更詳細地說明哪些 HTML 標記能正確運作，或哪些 Web 設計技術可最大化特定裝置的可用性。您必須先找到相當簡單的版面配置，針對行動裝置大小的螢幕進行優化，而不需使用不可靠的 HTML 或 CSS 定位技巧。不過，值得注意的其中一個重要技術是 檢視區中繼標記。

某些新式行動瀏覽器在努力顯示適用於桌面監視器的網頁、在虛擬畫布上轉譯頁面，也稱為「檢視區」 (例如，虛擬檢視區在 iPhone 上為 980 像素寬，依預設會在 Opera Mobile 上) 縮放 850 像素，然後縮小結果以符合螢幕的實體圖元。然後，使用者可以放大並移動瀏覽該檢視區。這有一個優點，它可讓瀏覽器在其預期的版面配置中顯示頁面，但它也有其強制縮放和移動瀏覽的缺點，這對使用者而言並不方便。如果您要針對行動裝置進行設計，最好是針對窄螢幕進行設計，因此不需要縮放或水平捲動。

告訴行動瀏覽器檢視區應該透過非標準 檢視區 中繼標記的檢視區寬度。例如，如果您將下列內容新增至頁面的 HEAD 區段，

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

… 接著，支援智慧型手機瀏覽器會在 480 像素的全虛擬畫布上配置頁面。這表示，如果您的 HTML 元素以百分比方式定義其寬度，則會根據這個 480 像素寬度來解譯百分比，而不是預設的檢視區寬度。因此，使用者不太可能水平縮放和移動流覽 –大幅改善行動瀏覽體驗。

如果您想要讓檢視區寬度符合裝置的實體圖元，您可以指定下列專案：

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

若要正確運作，您不得明確強制元素超過該寬度 (，例如使用 width 屬性或 CSS 屬性) ，否則瀏覽器將強制使用較大的檢視區。另請參閱：有關非標準檢視區卷標的詳細資訊。

大部分的新式智慧型手機都支援 雙重方向：它們可保留於直向或橫向模式中。因此，請務必不要假設螢幕寬度以像素為單位。請勿甚至假設螢幕寬度是固定的，因為用戶可以在頁面上重新設定其裝置的方向。

舊版 Windows 行動裝置和 Blackberry 裝置也可以接受頁面標頭中的下列中繼標記，以通知它們內容已針對行動裝置進行優化，因此不應轉換。

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

其他資源

如需可用來測試行動裝置 ASP.NET Web 應用程式的行動裝置模擬器和模擬器清單，請參閱模擬熱門行動裝置進行測試頁面。

學分

主要作者：Foundation Sanderson
檢閱者/ 其他內容寫入器：James Rosewell、Mikael Söderström、Scott Hanselman、Scott Hunter

Share via

如何：將行動網頁新增至 ASP.NET Web Forms / MVC 應用程式

目錄

概觀

舊版 ASP.NET 支援行動瀏覽器的方式

現今支持行動裝置的挑戰

架構選項

本檔著重於伺服器端技術

瀏覽器和裝置偵測

使用 ASP。NET 的內建瀏覽器偵測支援

透過 51Degrees.mobi Foundation 使用 WURFL 裝置資料庫

Web Form 應用程式如何呈現行動裝置特定頁面

建立行動裝置特定主版頁面

建立獨立的行動裝置特定 Web Form

將行動訪客重新導向至您的行動頁面

設定窗體驗證以遵守您的行動頁面

使用輸出快取

運作中的範例

ASP.NET MVC應用程式如何呈現行動裝置特定頁面

在 ASP.NET MVC 應用程式中設定行動裝置區域

確保 URL /Mobile 到達行動首頁

將行動訪客重新導向至您的行動區域

設定窗體驗證以遵守您的行動頁面

使用輸出快取

工作範例

進一步指引和建議

使用 51Degrees.mobi Foundation 增強重新導向邏輯

停用轉碼器和 Proxy 伺服器

設定行動瀏覽器的行動頁面樣式

其他資源

學分

意見反應

意見反應

其他資源