本文章是由機器翻譯。

現代化應用程式

現代應用程式開發的手機第一次接近

Rachel Appel

Rachel Appel在這個非常時刻,數以百萬計的行動裝置訪問數以百萬計的網站和手機應用程式。根據皮尤研究中心和其他統計,超過 55%的美國人使用智慧手機來訪問互聯網,以及 30%的美國人使用只有一個電話來訪問互聯網。這些數目正在增加,手機變得更便宜和容易使用。如果你能讀寫在牆上的,你知道你應該跟移動第一個設計。

使用者可以在所有設備上有最好的體驗 — — 從臺式電腦到電話 — — 當一個 Web 網站或應用程式設計具有流動性第一次。它很難從大螢幕一個小小的規模。UI 是行不通的。比微軟Windows Mobile6.5 作業系統 (不應該混淆與 Windows Phone) 作為一個主要的例子的萎縮和幾乎沒有可用的桌面 UI 再看看。

然而,您可以縮放從電話到桌面電腦裡沒有拋出窗外的可用性。您可以添加功能的經驗作為你放大,使 UI 過渡平穩。這種技術稱為漸進增強。Web 網站和應用程式受益于這種類型的手機第一發展戰略。

移動第一途徑,快速回應設計

調整內容以適合各種螢幕尺寸是多設備現代應用程式的基本要求。你必須採取兩種方法之一。您可以設計兩個版本的軟體 ; 一個用於桌面機和更大的電腦和一個較小的形式因素。您的其他選擇是設計軟體來調整中賴以所使用的設備回應的使用者介面。

你會面對很多不同類型的設備。有些你可能穿的衣服,有些可能是在你的身邊。你很快就會考慮物聯網 (物聯網) 設備作為應用程式開發的設計要求的一部分。物聯網設備 (比如 Fitbit 或者微軟帶是兩個跟蹤使用者的活動的可穿戴設備。

物聯網設備的其他例子包括 (如鳥巢) 的智慧調溫器、 智慧門鎖或軟體在一輛新車。很多的物聯網設備和移動第一個 Web 網站或應用程式中,如智慧的咖啡機一起工作。隨著電腦變得更小、 更便宜,更強物聯網設備將市場上充斥著更多的方法來使用它們。

要移動第一也意味著考慮平臺的影響。本機應用程式有不同的發展,建築和有時比 Web 應用程式的業務需求。以下是一些移動第一個應用程式的設計注意事項:

  • 反應靈敏的使用者介面
  • 瀏覽
  • 清單和網格的專案和內容格式
  • 存儲,包括離線存儲區
  • 支援觸摸、 鋼筆或可選的輸入
  • 管理資源和性能

我會考慮這些的更多詳細資訊。Web 網站、 混合和單一頁面架構 (SPA) 的應用程式使用 CSS 實現快速回應設計。XAML 的應用程式和應用程式在 Android、 iOS 平臺有不同的專有的方式來創建一個回應的使用者介面。例如,XAML 使用一個稱為資源包含的樣式資訊的物件。您可以對 XAML 控制項自動呈現有利和回應的方式,根據設備的螢幕大小應用資源。

在 HTML 應用程式 (Web 或本機如 JavaScript [WinJS] Windows 庫),您可以使用 CSS 定義樣式和美學。CSS 媒體查詢的概念用於創建一個回應的使用者介面。媒體查詢是回應不同媒體類型的 CSS 規則。這些媒體類型代表不同的螢幕大小,列印或電視,布萊葉盲文、 螢幕方向和其他功能。當你創建一個媒體查詢時,您指定的 CSS 規則,為該設備的受支援的功能,如下面的代碼所示:

@media only screen and (min-device-width : 320px) and (max-device-width : 480px) {
/* style rules */
}
@media only screen and (min-width : 321px) {
/* style rules */
}
@media only screen and (max-width : 320px) {
/* style rules */
}
@media only screen and (min-device-width : 768px) and (max-device-width : 1024px) {
/* style rules */
}
@media only screen  and (min-width : 1224px) {
/* style rules */
}

這裡的 CSS 工作在兩個縱向和橫向模式下,智慧手機和 Ipad 在縱向和橫向模式下,以及最後,較大的設備,例如可擕式電腦或桌上型電腦。閱讀更多關於使用 CSS 為本機 Windows 應用程式,請參閱"建造回應及現代 UI 使用 CSS 為 WinJS 應用程式"在 msdn.microsoft.com/magazine/dn451447

設計良好、 反應迅速、 移動第一併不針對特定的裝置類型在您的代碼中。你永遠無法跟上的數十個可用。一直的目標螢幕尺寸範圍。例如,您可能希望目標 3-4 英寸的設備、 5-8 英寸設備、 10-13 英寸平板電腦,和比 13 英寸筆記本電腦和桌上型電腦。這種方式你可以創建一個使用者介面以適合盡可能多的受眾。集中在幾個常見的電話大小。此代碼將繼續以維護隨著時間的推移,新的設備進入市場,因為你已經按大小範圍的目標他們。

簡單的方法做到這一點,並設計一個專案,可以從智慧手機擴展到桌面是在Visual Studio為 Windows 應用商店和 Windows Phone 中選擇一種通用的應用程式專案類型。通用程式有所有的代碼和結構,以應對不同的用戶端。您可以使用 XAML 或 HTML 打造一個通用的應用程式。這些應用程式共用他們的代碼,很大一部分,所以您可以重用大量的代碼。如果您需要重新溫習通用程式,查閱"建立通用應用程式的 Windows 平臺"(msdn.microsoft.com/magazine/dn781364)。

在 Web 網站和應用程式開發人員通常會顯示資料以表格或清單格式。在手機上的小型清單將在更大的螢幕,做工精細,雖然會有浪費的空間。逐步增強的使用者介面將添加並設置格式的螢幕大小隨著更多的內容。它將做反向,以及 — — 刪除和重新格式化螢幕在較小的設備上顯示較少的內容。

正如你可能期望,手機的應用程式往往顯示只有最重要的內容,以及智慧手機的小空間是有限的。手機應用程式通常穿過糠。雖然有廣告,它們小,通常位於同一個地方。因為哪怕是最小的桌上型電腦上有這麼多的空間,你會看到廣告和並不總是與網頁主題相關的內容。因此當您添加內容,使相關和有意義這樣它就不會在使用者的方式。您添加的內容可能是有關內容本身、 相關的廣告或甚至一些快速連結的側邊欄。

移動第一導航

有一種使用方便、 直觀的導航方案很重要。導航是與應用程式本身進行交互的一種方法。它也是一種方法訪問所需的內容。每個應用程式都有導航 ; 不幸的是,大量的應用程式有差的導航。

本機的桌面軟體,如 Windows 表單,傾向于使用傳統的級聯功能表作為導航。Web 網站經常這樣做。事實上,Web 網站常常使用可怕的一名外科醫生的精度要求的 JavaScript 下拉式功能表。幸運的,這種做法迅速衰落。很明顯這些類型的功能表,只是不工作在智慧手機上。什麼不在智慧手機上工作了若干特定的導航技術:

  • 大圖塊:正方形或長方形,多像 Windows 8。
  • 觸控式螢幕友好清單:又寬又高,夠所有的手指和拇指大小的矩形。
  • Swipeable 選項卡:這些讓使用者刷總之水準運動,一個偉大的方式來呈現特定類別或功能的選項功能表。
  • 停靠的應用程式欄:選項位於一條橫跨頂部或底部的螢幕。你可以隱藏應用程式欄,顯示它當使用者刷,要求它。

您還可以使用組合導航技術,如 swipeable 選項卡與一個不錯的觸控式螢幕友好的選項清單。通常情況下,這些類型的導航功能表是內容本身,如讓你點擊文本的標題,讀這篇文章的消息應用程式的一部分。無論您選擇,確保使用者可以導航落後,以及。一個突出的後退按鈕工作正常。

在 Windows 應用商店應用程式中導航范式使用 Windows 網格系統來顯示資料,並允許使用者按一下或點擊導航到當前網格專案的詳細資訊。也是突出後退按鈕,以便使用者可以始終背完一系列的導航步驟。或者,應用程式可以提供充分的導航選擇應用程式欄。

資料存儲和離線功能

很難找到一個應用程式,不會受益于一些離線支援。即使航空公司登機牌,航空公司將作為超連結通過短信發送都只是不會顯示如果您沒有連接到的 Web 頁。一個品質的應用程式必須支援離線功能。

許多應用程式並不存儲本地內容。他們調用 Web 服務,或使遠端調用以檢索資料,並將資料保存在遠端。當然,還有一點點,你需要將本機存放區的資料,無論如何,例如應用程式或使用者設置和首選項。存儲才有意義,將存儲在本地,如電子書閱讀器、 一場遊戲或應用程式的主題顏色中的當前位置的事情。

這裡的地方存儲要求取決於平臺不同你的目標。在 HTML 用戶端應用程式,您可以使用域物件模型 (DOM) 存儲或 IndexedDB。在本機 XAML 應用程式,您可以使用本地的應用程式設定或一個 StorageFile 物件。

  • DOM 存儲 (HTML5 本機存放區):這是一個羽量級容器中 HTML 應用程式的本地資料。
  • IndexedDB:該檔存儲大量的資料進行本地。使用 HTML 應用程式和存儲關聯式或 BLOB 資料的鍵/值對中的 IndexedDB。
  • 應用程式設定:XAML 和 HTML Windows 應用商店和 Windows Phone 應用程式可以訪問應用程式設定的資料結構。應用程式可以將資料存儲在這些小的物件。它們通常包含日誌的名稱、 主題顏色或其他設置的設置。
  • 存儲檔:這些都是好的老式的檔,但 Windows API 存儲為與 Windows Phone XAML 或 HTML 的應用程式。

你可以在唯讀模式的 ApplicationDataContainer 物件中保存應用程式設定。您將與應用程式資料 localSettings 屬性來訪問。下面的代碼檢索本地和漫遊應用程式設定和它們的資料夾:

var localSettings = applicationData.localSettings;
var roamingFolder = applicationData.roamingFolder;
var roamingSettings = applicationData.roamingSettings;

本地設置,當然,只是本地可用上協會­不等式的設備,而漫遊設置可從多個設備或位置進行訪問。在 Windows 應用商店應用程式中資料存儲的詳細資訊,請參閱"資料訪問和存儲選項在 Windows 應用商店應用程式"(msdn.microsoft.com/magazine/jj991982)。

移動第一體系結構和開發

要移動第一重要的事是你實際上可確保您正在創建的軟體工程在行動裝置上第一次。它是規模大於較小的螢幕和體驗的時候更加容易您總是可以添加資訊作為螢幕大小增加。

性能是非常重要的一部手機。人們支付昂貴但往往有限的通話方案。他們不想等待,花錢下載 Web 頁或應用程式。如果你覺得日子一去不復返了長時間有的地方管理和囤積每比特和位元組,你是在你的思想不成熟。管理記憶體和資源是在流動發展的大問題。

今天的手機和物聯網設備在過去他們大桌面對應的技術熟練程度相若。很多的物聯網設備仍有小於 1 GB 的 RAM,即使存儲容量增長至天文水準。別忘了電池的壽命,也。使用者將轉儲您快速的應用程式,如果它耗盡電池。你想要盡可能多盡可能相同的代碼庫的跨平臺使用。移動第一個方法為 Web 網站和應用程式工作。請記住,它不是只是螢幕的大小。

作為一個移動第一體系結構的一部分,首先確定你會產生什麼樣的移動應用程式。它是一個移動的 Web 網站嗎?也許這是一個本機應用程式。你必須支援多少種平臺?如果你有一個現有的動員的網站,並且想要快速進入應用程式商店,也許混合動力就是要走的路。

如果您需要幫助確定可供選擇,讀"手機網站 vs。 本機應用程式 vs。 混合應用程式"在 msdn.microsoft.com/magazine/dn818502。一旦你有一個清晰的能造出什麼願景下, 一步是說明應用程式的體系結構。有關如何規劃您的移動 Web 網站或應用程式的更多詳細資訊,請查閱我的專欄,"設計跨平臺現代應用程式體系結構,"在 msdn.microsoft.com/magazine/dn683800

目標應用程式商店的獨立開發的思考移動第一。他們的部署目標是最頻繁的一個或多個應用程式商店。企業開發人員傾向于將部署到其內部網路上或者在他們的私有雲的位置。

在企業發展中,JavaScript 取得了極大的吸引力。開發人員甚至在伺服器上運行它。現在,它是很可能最流行的世界。喜歡與否,開發人員使用 JavaScript 作為交付形式的 Web 應用程式的跨平臺軟體的最簡單方法。甚至企業開發人員使用更多的 JavaScript 來增強商務應用程式的使用者介面。工人進入工作場所到處購物車他們的 Ipad,表面和智慧手機,這是隨著帶來您自己的設備 (BYOD) 運動在企業中,尤其如此。

如果你在寫企業的 JavaScript 代碼或水療中心的應用程式,您可能會考慮使用列印稿。打字稿已為其開發人員正耐心地等待,如繼承,以及一組類型的所有 ECMAScript 6 要求、 物件導向和其他功能,可説明您生成更好的代碼、 檔和專案組織。它是一個好主意,讓自己熟悉 UI 設計模式和發展模式。他們都説明更有條理的專案結構。在您的企業 JavaScript 專案中使用打字稿之前, 在看到"用列印稿在現代應用程式" msdn.microsoft.com/magazine/dn201754

總結

這裡最重要的要點建立軟體與移動首先在頭腦中會容易規模更大。教科文組織統計研究所逐步設計往往意味著一種更加模組化的體系結構。本質上,這使得代碼更易維護和添加新的功能。還有,使用者肯定很欣賞圓滑和精心設計的使用者介面。移動-­第一種策略迫使你把重點放在最重要的資料和功能。這些相同的功能是使獲得高收視率,而且在應用程式商店中添加更多的銷售。


Rachel Appel 是 20 多年的經驗,在 IT 行業顧問、 作者、 導師和前微軟員工。她說話在一流的行業會議,如Visual Studio活 !,DevConnections,混合和更多。她的專長在於內開發對齊業務和技術集中在微軟開發堆疊上,打開 Web 的解決方案。阿佩爾的更多資訊,請訪問她的網址 rachelappel.com

感謝以下的微軟技術專家對本文的審閱:FrankLa 墓葬