怎麼建立移動頁面應用程序

概述

移動設備 — — 智能手機、 功能手機和平板電腦 — — 繼續流行的手段來訪問網站的方式。對於許多 web 開發人員和麪向 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年及更早版本。控件是主要設計來呈現 cHTML 或 WML 標記 (而不是普通的 HTML) 爲 WAP 瀏覽器的那個時代。但 WAP、 WML 和 cHTML 再也不是目前大多數項目，由於 HTML 現已成爲移動和桌面瀏覽器同樣的無處不在的標記語言。

今天支持移動設備的挑戰

即便移動瀏覽器如今幾乎廣泛支持 HTML，你將仍然面臨許多挑戰，致力於創造偉大的移動瀏覽體驗的時候:

• 屏幕大小-移動設備不一樣的形式，和他們的屏幕每每遠遠小於桌面顯示器。所以，您可能須要爲他們設計徹底不一樣的頁面佈局。
• 輸入方法— — 某些設備有鍵盤、 一些有鐵筆，其餘人使用觸摸。你可能須要考慮多個導航機制和數據輸入的方法。
• 標準法規聽從性— — 許多移動瀏覽器不支持最新的 HTML，CSS 或 JavaScript 標準。
• 帶寬— — 手機網絡性能差異很是大，並且國內一些運營商最終以兆字節來收費。所以沒有萬能的解決方案;你的應用程序將不得不考慮根據不能的訪問設備來定義行爲和其外觀

一般最初接近第一次的移動瀏覽器支持的開發者認爲它只須要支持最新和最早進的智能手機 (例如，Windows Phone 十、 iPhone 或安卓系統)，也許，由於開發人員常常親自持有此類設備。然而，低端的移動設備仍然是很是受歡迎，和它們的用戶使用低端來瀏覽網頁，您的業務將須要決定哪些範圍的設備支持，考慮其可能的客戶。若是您正在構建豪華健康水療在線手冊，你可能決定業務只針對高端智能手機產品，而若是您正在建立一家電影院門票的預訂系統，你可能須要考慮爲遊客提供更強大的功能手機。

常見的解決方案

咱們到達 ASP.NET Web 窗體或 MVC 的具體技術細節以前，請注意，web 開發人員通常有三個主要的選項用來支持移動瀏覽器:

1. 什麼也不作只需建立一個標準的、 面向桌面的 web 應用程序，便可依靠移動瀏覽器，使其能夠接受。

• 優點: 它是最便宜的選擇，實現和維護 — — 無需額外工做
• 缺點: 給出了最糟糕的最終用戶體驗:
  • 最新的智能手機可能呈現和桌面瀏覽器同樣的html展示效果，但用戶仍將被迫，縮放和滾動水平並垂直操做您在小屏幕上的內容。這是遠遠不是理想的操做。
  • 較舊的設備和功能手機可能沒法使人滿意的方式呈現您的標記。
  • 即便是在最新的平板電腦設備 (其屏幕能夠與筆記本電腦屏幕同樣大)，也存在二者徹底不相同的操做交互方式。觸摸式輸入最適用於較大的按鈕，那裏是沒有辦法將鼠標光標懸停在飛出菜單。

1. 解決客戶端的問題— —如今能夠當心使用 CSS 和漸進加強您能夠建立標記、 樣式和適應不管瀏覽器運行它們的腳本。例如，用 CSS3 媒體查詢，您能夠建立在設備屏幕的窄比選定的閾值變成一個單一列布局的多列布局。

• 優點:
  • 優化渲染爲特定設備在使用中，即便對於未知的將來設備根據他們不管屏幕和輸入的特徵有
  • 很容易讓你在全部設備類型 — — 最小重複代碼共享服務器端邏輯
• 缺點:
  • 移動設備有別於桌面設備，您可能真的但願移動頁必須徹底不一樣於你桌面的頁面，顯示不一樣的信息。這種變化可能效率不高或不可能實現經過 CSS單獨操做，尤爲考慮到如何不一致舊設備對CSS規則的解釋，特別是 CSS 3 屬性。
  • 沒有提供的不一樣的服務器端邏輯和工做爲不一樣的設備支持。例如，不能經過單純的css實現一個簡單的購物車提供給移動用戶使用
  • 低效帶寬使用。你的服務器可能須要傳輸的標記和樣式應用到全部可能的設備，即便目標設備只會使用該信息的子集。

1. 解決服務器上的問題— —若是您的服務器知道什麼設備正在訪問它 — — 或是該設備的屬性，如：屏幕大小和輸入方式 等特性，不管是移動設備 — — 它能夠運行不一樣的邏輯和輸出不一樣的 HTML 標記，經過服務端視圖渲染的方式

• 優點:
  • 最大的靈活性。有沒有限制多少，你能夠改變你的服務器端邏輯的手機或優化您的標記所需的，特定於設備的佈局。
  • 高效的帶寬使用。你只須要傳送的標記和樣式信息的目標設備將使用。
• 缺點:
  • 代碼的重複（如，讓你建立你的 Web Forms pages或 MVC views類似，但略有不一樣的副本）。在可能的狀況，你會分解出公共邏輯進入下一層或服務，但你的UI代碼或HTML標籤某些部分可能必須被複制，而後保持平行。
  • 設備檢測是有可能出現沒法識別的狀況。它須要將列表或數據庫的已知的設備類型及特徵 (但它不會老是最新的完美數據)，也不能保證準確地匹配每一個傳入的請求。本文檔稍後介紹一些選項和易犯的錯誤。

爲了得到最佳效果，大多數開發者發現他們須要結合選項（2）和（3）。在客戶端上使用CSS或JavaScript的甚至輕微的文體差別最好容納，而在數據主要區別，工做流程，或標記是最有效在服務器端代碼執行。