將你的網站轉為 Windows App- 使用 Windows App Studio

[感謝微軟學生大使、清華大學計量財務金融學系賴虹安同學,協助翻譯原發佈於 Building Apps for Windows 部落格中的文章:Building Hosted Web Apps with Windows App Studio]

以下則是賴同學在 3 分鐘內,將自己的履歷網站轉為 Windows App 之經驗分享:

將你的網站轉為 Windows App- 使用 Windows App Studio)
如果你已經擁有自己的 Web App ,並且有公開的 URL ,那麼只要使用 Windows App Studio (有中文介面) 裡的 Hosted Web App 範本,你就可以輕易地將它轉移成 Windows 10 的 App 。 Windows App Studio 這個線上服務,能讓無程式基礎的人也能輕鬆地創建 Windows 系統上的 App 。這篇文章將帶各位了解如何建立屬於自己的 Hosted Web App 。

在 Windows App Studio 裡,你可以藉由範本或是空白的網頁畫布( canvas )於瀏覽器中創建原生 Windows 10 App ,接著加入所需資訊、數據、服務及風格設計等等。建立完成後,你就等於建構了一個 Visual Studio Solution 、側載套件( Sideloading Package )或發行套件( Publishing Package )的App,同時也代表著,你將接觸到 Windows Store 中超過 20 億個 Windows 10 裝置的使用者。
在眾多範本中,可讓無障礙網頁( Accessible Websites )及 Web App 發布至 Windows 上的便是 Hosted Web App ( HWA )。它會要求你輸入Web App 的 URL 、新增 App 的圖示( icon )、確認所有設定、並準備發布至 Windows Store 。而這些步驟只會花費你一些時間即可完成。
底下這些生活日常所花費的時間甚至比建一個 HWA 的時間還多呢!例如:
 檢查 E-mail
 微波一袋爆米花
 逛逛百貨
 刷刷牙
 欣賞電視節目中的廣告片段(建 HWA 的最佳時間!)

所以如果你願意花 3 分鐘的時間來學習,那就讓我們開始吧!1_foursteps

步驟 1 :建立專案
如果你還沒用你的 Microsoft 帳號登入 Windows App Studio ,別擔心,這是一項完全免費的服務,成功登入後前往「 Start New Page 」,那裏就會有建立 HWP 的選項。

2_createyourHWA

點選建立 Hosted Web App 後,會有一個彈出視窗,輸入你的Windows App 的名字後點擊「 Start with this one 」,而右側的裝置預覽( device previews )將會展示 App 在各式裝置螢幕上的呈現樣貌。

3_nametheapp

步驟 2 :安裝 App
在建立專案後,你會前往內容編輯( Content )的頁面,在這個頁面你唯一需要做的事情便是輸入你想要轉換的網頁 URL 。

4_themanifest

接著你可以選擇上傳安裝資訊檔( Manifest ),或是你也可以定義新的URL 規則以及旋轉偏好( rotation preference ),但是這些都是非強制性的喔!
在右方預覽的螢幕上,會顯示你的 HWA 在各式裝置螢幕上的顯現效果,如果你沒有預覽成功也不必擔心,這通常代表這個網站不被允許嵌入在iframe 裡,但仍然是可運作的喔!
在輸入 URL 及其他相關資訊後,你可能會想要更新 App 的預設 icon ,只要點擊 Content tab 裡導覽列上的 icon 就可以打開 icon 編輯器了。

5_iconeditor

接著點擊「 App Logo 」下方的圖標,就會打開一個資料夾,在裡頭你可以選擇你想要的 icon 來使用,上傳自己喜歡的 icon 後,這個工具將會自動產生各種 icon 大小供你使用。

最後,點擊「 Settings 」來編輯你的市集( Store )清單細節,例如: App 的描述、語言、市集相關細節、隱私條款,以及其他資訊等。在發布到市集前,你需要填妥市集相關資料,更多詳細發布指示請見文件 (中文)。

6_publishtostore

步驟 3 :建立 App
當你完成安裝設定後,點擊上方灰色「 Finish 」按鈕,你將被導入一個新的頁面,在此頁面你可以瀏覽你的 App 在各式裝置上的新樣貌,而你在這個頁面所需要做的事情,便是點擊上方「 Generate 」大按鈕,接著會打開一個彈出視窗,選擇你所要的產生的套件即可( Visual Studio Solution 通常為預設選項)。
值得注意的一點是,為了能夠產生發行套件,你必須確實完成上述所提的市集相關資訊。

在所有步驟都結束後,按下「 Generate 」,等候一分鐘,你就可以擁有屬於自己的 App 囉!

結論
只要上述這些步驟,就能輕鬆在 Windows App Studio 建立一個 HWA ,是不是非常簡單?
如果你在使用這個工具後有任何意見,我們都非常歡迎你提出與我們分享喔!

App 設計:我該從哪開始?

[感謝微軟學生大使、清華大學計量財務金融學系賴虹安同學,協助翻譯原發佈於 Building Apps for Windows 部落格中的文章:Getting Started With App Design]

在軟體產業裡,我們總是常常聽到設計者和程式開發者在溝通上有代溝,因次希望能藉由本篇文章,介紹大家一些設計 App 的小撇步,幫助大家設計出更吸引人、比別人更成功的 App,同時也能減少工程師和設計者之間的隔閡!

淺顯易懂的設計 Demystifying Design

就跟工程師一樣,「設計」也是需要藉由不停的練習,才能將自身的技能結合想傳達的資訊,完美的傳遞給使用者。一些基本的技能包括:

  • 排版 Typography
  • 色彩學 Color Theory
  • 視覺平衡 Visual Balance
  • 圖像研究 Iconography
  • 導航列設計 Navigation
  • 設計素描 Sketching

當你學會並且時常練習這些基礎功後,你將會發覺許多以往你可能忽略的色彩美學或排版技巧,甚至,你更有可能藉此知道往後該如何修正自己的 App,讓現有的作品擁有更美觀的視覺呈現。

讓我們開始吧!Getting Started!

設計,絕不能等程式開發完的最後一刻才開始動工。做為一個 App 開發者,你可能已經發現 App 的功能和其設計息息相關。舉例來說,一旦你在功能選單放入太多項目,有些重要的功能常常在最後看起來已沒那麼重要;你也有可能發現,在設計完 App 的主視覺、編寫程式後,自己像是擁有兩個 App 而非一個。然而,設計者們卻有不少能力能解決上述這些狀況。

– 這個 App 的重點是什麼?

在開始著手設計前,請先記得了解自己的 App 的用途為何、你希望 App 使用者能夠如何使用。如果你是一個偏好視覺走向的開發者,那麼就想像這裡有一個完全空白的畫布,並且思考你要放什麼內容進去;如果你喜好利用語言、文字來表達,那麼建議你採用清單條列式來呈現。若你不屬於上述二者,那麼就先把所有你覺得你用的到的功能、希望的色彩和選單都先放上去。

接下來的重頭戲便是「簡化」。雖然這可能讓人心煩,尤其是在當你把所有心血都放上去後,但是現代 App 設計最重要也是唯一的大準則便是:化繁為簡。太多的重點和功能會混淆使用者,過多的畫面則會讓使用者難以瀏覽及記住剛剛瀏覽過的項目在哪,所以請開始動手「簡化」吧!

你可以畫一條線刪掉那些其實你並不需要的功能,然後再畫一條線,刪掉那些你覺得你需要但是其實並不適合其他清單上的項目;在反覆此步驟後,你就會發現你已經將你的 App 簡化成它最單純的樣子囉!

– 了解你的消費者

現在你需要了解你的 App 究竟是為誰而設計。

你的 App 是為孩童或是成人而設計?是為繁忙的專業人士還是賦閒在家的人所設計?這個 App 是用來做為科技知識突破所用還是給那些需要協助的人們所用?釐清這些問題將幫助你構思出整體外觀、給人的感覺以及排版設計。舉例來說,繁忙的專業人士沒有太多時間閱讀過多的文字,然而針對那些較少接觸科技的人來說,他們需要較多提示及線索來使用 App;此外,比起仿舊風,孩童大多較喜歡明亮的顏色設計。

2_inspiration

了解你的目標消費者後,起身去和他們聊天吧!不要覺得這個舉動很多此一舉,一旦你付出越多了解你的消費者,往後設計app時你將更得心應手。在和他們談話時,可以徵求他們的同意後,錄下談話時的影片並且觀察他們、詢問他們相關問題,從中發現他們希望從你的 App 中得到什麼樣的幫助或便利。

– 靈感啟發

記得主動找尋靈感!無論是蒐集照片、字體、名言佳句、文章、或是任何和你的 App 及消費者相關的設計,甚至是那些你驚鴻一瞥的小事物,把這些材料都拿來當作你設計及程式開發的靈感來源吧!當然,你得在原創作者同意下再把這些元素加入你的 App 裡。此外,你可以觀察其他已開發的同性質 App,同時思考是否有哪些地方是你可以做為借鏡,改善自己的 App。

1_inspiration

同樣重要的是,別忘記繪製草稿!把握所有機會,拿起筆或是蠟筆在紙上畫下 App 的設計草圖,這同時也是幫助你的「設計腦」永保靈活的一項練習。將你所有草圖都保存在安全的地方,並在開發 App 進入尾聲時將當初的草圖們都拿出來溫習,你會很開心能看見這個 App 一路的蛻變。

– 原型開發

不論是畫草圖 (sketch) 還是線框稿 (wireframe),根據消費者給你的意見回饋建構出各種不同的畫面設計,並且,想像消費者在執行任務時所會採用的流程。你可以使用任何對你有利的方法建構原型,假設對你而言在 Visual Studio 或 Blend 上做介面設計是較快速的,那麼就使用這些工具吧!但務必注意,在這個階段你不需要太專業的軟體或是具備非常頂尖的繪畫能力,使用記事本或是繪圖板就可以了。更棒的是,你可以直接在便利貼上設計你的 App,如此一來你就可以更輕易的移動畫面元件來看不同的排列組合所呈現出來的樣貌,你甚至可以在發現排列組合的結果不是你所期望後,輕鬆地把它們放回去。

如果你不確定該從何處下手,建議你可以先看看那些和你的 App 類似的作品並且發現是否有適合你的 App 的設計流程。

3_prototypes

現在,試試看移動畫面上的元件,如果你原本是從上方導覽 (top navigation) 開始,那你可以改試著將導覽從左邊開始;如果你原本設計的介面是擁有大型的文字頁首 (header),那你可以嘗試將他移到畫面的底端;按鈕 (buttons) 和內容儀表板 (content panels) 也可以隨意的移至其他地方;將文字和按鈕分離或是將連結 (links) 和文字分開;透過這些更動,你會在最後找到最適合這個 App 的設計。

4_sketching

– 鼓起你的勇氣

現在去找一些測試者 (至少5人),請他們在看過你的原型 (prototype) 後給予你意見,在此強調,這種易用性測試 (usability testing) 或市場調查 (market research) 比起一般的問答測驗 (QA testing) 來的好。

5_iterate

如果你找不到任何人願意協助你,那麼就試著想像自己是第一次使用這個 App,並思考這個 App給你的第一印象會是什麼?當你看著它是否就能夠猜出它的功能是什麼?是否就能了解下一步該怎麼做?

如果上述問題有任何答案是讓你不滿意的,那就再次拿起你的便利貼,重新尋找最佳的設計方法。先前那些你用來構思草圖的便利貼及付出的時間與心力都需要善加保存與紀錄,這些將協助你找到最終的完美解答。

大功告成 Wrapping Up

在每一步驟開始前審慎思考 App的設計會幫助你判斷程式開發與介面設計相對應的優先順序。按照本篇文章的引導,你將可以更早發現問題並解決,同時避免往後可能面臨之一切重大錯誤。

若想獲得更多資訊,歡迎瀏覽「Plan Your Universal Windows Platform (UWP) App」。

[Windows 10] Extension SDK: 讓同一隻應用程式能在不同裝置上執行的秘密

微軟在今年三月揭示了未來的 Universal Apps,將能在各種不同裝置上執行的願景。這些裝置包含了 PC, Mobile, IoT 裝置, Xbox, Surface Hub, 甚至 HoloLens

Gallo blog 1 v2

那麼,要如何讓同一隻 Universal App 在這些不同的裝置上執行呢? Extension SDK 即是解答之一。

以往的作法是什麼?

我們先檢視一下在 Windows 8/8.1 上,欲同時開發 Windows Store App 及 Windows Phone App 的方法。我們可以將共享的程式碼 (如 Business Logic, Data Model, etc.) 實作於 Shared Projects 中,開發者只需額外處理如螢幕大小等 User Experience 上的不同。

但是,編譯之後將會產出兩份針對不同裝置的 Binary or Package,必需分別上傳至不同的 Store 作審核、也必需在不同的 Dev Center 之中作管理:

image

另一個開發者會面對到的問題是,當有些 API 只適用於某些裝置時,要如何處理呢? 例如 :Windows Phone 手機上的實體 Back 鍵、Xbox One 的遙控器、HoloLens 的互動控制等,都不會出現在 Windows 平板上:

image

常見的處理方式即是 Compilation directives,透過 #if 語法,讓開發工具在編譯 (compile) 期間即決定某功能是否會被引入:

image

小結以上:

  • 現有作法會根據不同的裝置,編譯成數個不同的 Binary,也增加了應用程式管理及維護上的負擔;
  • 同時,#if 的作法是在編譯 (compile) 階段即需決定是否引入某些裝置上的功能,亦即無法在執行 (runtime) 階段動態決定。

簡介 Extension SDK:

Windows 10 的 Extension SDK 即是要達成同一個應用程式 (Binary) 能執行在不同裝置上的解決方案:

  1. 它是既有 UAP (Universal Applications Platform) 的延伸、
  2. 針對不同的裝置,即會有不同的 Extension SDK、
  3. 正因為如此,個別的 Extension 即能各自更新其版本

image

如下圖。不同的裝置上都跑著 Windows Core,提供諸如 File I/O, Drivers 等基礎服務;UAP 則提供了一些通用型的控制項,也就是一群 API 的集合,作為通用型應用程式開發的基礎:

image

而在特定裝置上才提供的 APIs,則以 Extension SDK 的方式來實作,表現在圖中的話,即是以延伸的方式由 UAP 的通用型 APIs 再向外擴展:

image

實作 Extension SDK:

1. 透過 Project > Add Reference > Universal App Platform > Extensions ,即可新增您所需要的 Extension 至專案之中。各位可注意到其後有版本別,亦即可各自分別更新並被引入:

image

2. 接下來,即可於程式中使用 Windows.Foundation.Metadata.ApiInformation 這個 Class,在執行 (runtime) 期間判斷某 API 是否存在:

image

若您只想實作一小部份的 APIs,可以考慮直接使用 ApiInformation.IsTypePresent:

// Note: Cache the value instead of querying it more than once.

bool isHardwareButtonsAPIPresent =

    Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Phone.UI.Input.HardwareButtons");

 

if (isHardwareButtonsAPIPresent)

{

    Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=

        HardwareButtons_CameraPressed;

}

以上程式中,我們只需驗證此裝置是否支援 HardwareButtons 這個 class,若支援,則必定亦包含 CameraPressed 這個事件,我們即可放心的使用它。

當然,除了 IsTypePresent,我們也可使用 IsEventPresent, IsMethodPresent, IsPropertyPresent 測試個別的事件、方法、參數等是否存在:

bool isHardwareButtons_CameraPressedAPIPresent =

    Windows.Foundation.Metadata.ApiInformation.IsEventPresent

        ("Windows.Phone.UI.Input.HardwareButtons", "CameraPressed");

小結:

  • Extension SDK 成為 Windows 10 UAP 的開發架構中,達成同時支援多種不同裝置的一步活棋。由於是以延伸方式向外作擴增,其保有隨著各裝置的進化而各自演進版本的彈性。
  • 對於開發者而言,能夠簡單的在執行階段 (runtime) 判斷特定裝置上的 API 是否存在,方便達到讓同一隻應用程式執行在不同裝置上的目標。
  • 最後,由於可以僅產出一份 Binary,即能達到 One Store + One Dev Center 的目標,減少開發者的後續維護及管理成本。

另請注意,Extension SDK 的目的並非取代 #if 的功能,Compilation directives 的方式仍然是可行的!

註:

若要嘗試這些新功能:

  1. 請加入 Windows Insider Program,取得並安裝 Windows 10 Developer Preview.
  2. 取得並安裝 Visual Studio 2015 CTP. (目前版本為 CTP6)
  3. 新專案中即會出現 Windows 10 Universal App 的範本。

同時:

1. 若您在測試過程中遇到問題:

2. 若您對 API 有任何新功能的需求,則可透過 Windows platform developer UserVoice site 來建議,這網站會在 BUILD 2015 前持續更新,反應最新的 API 功能。

延伸閱讀:

  1. Developer’s Guide to Windows 10 Preview: (04) Extension SDKs (英文教學影片)https://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/04 
  2. Guide to Windows universal apps: https://msdn.microsoft.com/en-us/library/dn894631.aspx 

 

[Windows 10] Inking: 筆跡功能的應用及實作

Windows 10 推出之後將支援許多種的輸入 (input) 方式,包括 Windows Hello 透過臉部特徵或虹膜取代密碼輸入、HoloLens 利用全息虛擬實境技術與人作 3D 互動等等。

本文則將介紹 Windows 10 加強後的筆跡 (Pen & Ink) 技術。 對開發者而言,多了 InkCanvas 控制項與基礎 DirectInk 類別,可以使用您已熟悉的程式語言如: C++、C# 或 Visual Basic 等,在 Windows 10 Apps 中實現更強大的筆跡功能。

比如:

叫出地圖後,用筆(或手指)畫上路線圖:

image

在連線遊戲中,即時紀錄如「狙擊手在右邊建築物屋頂」的筆跡訊息:

image

用原始筆跡回信:

image

或是先轉成文字…

image

image

Windows 10 在 Pen & Ink 的擴充性

要作到以上應用, Windows 10 提供的 InkCanvas 控制項定義了一個用於繪圖以及轉譯筆跡筆觸的重疊區域。此控制項的功能 (輸入、處理和轉譯) 則來自 InkPresenterInkStrokeInkRecognizerInkSynchronizer 等類別。

(目前使用 JavaScript 的 Windows 應用程式不支援這些類別)

也就是說,無論使用者是以「觸控筆」或是「手指」作輸入所得到的 “Ink” 物件,都能以原始筆跡、加上述解或描述 (metadata)、亦或轉譯成文字或圖檔等方式,作進一步創意的實踐。

image

開始實作吧!

假設我想在一個影像 (image) 上面疊一個筆跡畫布,在 XAML 描述中只要多加一個 InkCanvas 即可,非常直覺簡單:

<ScrollViewer>

    <Grid>

        <Image Source="Assets/signature.jpg" />

        <InkCanvas x:Name="myInkCanvas" />

    </Grid>

</ScrollViewer>

執行畫面如以下,各位可注意其中細微的筆觸差異,這些都會被紀錄在 Ink 物件中;同時寫字速度等資訊也會被紀錄下來,可作為進一步 (如筆跡辨認) 的應用。

image

想更進一步了解 Windows 10 在筆跡功能上的應用,請參考以下 10 分鐘的影片: (Developer’s Guide to Windows 10 Preview: (07) Pen & Ink)

https://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/07/player

註:

若要嘗試這些新功能:

  1. 請加入 Windows Insider Program,取得並安裝 Windows 10 Developer Preview.
  2. 取得並安裝 Visual Studio 2015 CTP. (目前版本為 CTP6)
  3. 新專案中即會出現 Windows 10 Universal App 的範本。

同時:

1. 若您在測試過程中遇到問題:

  1. 請先檢視 release notes 以及 known issues with Visual Studio 2015 CTP6,查看是否為已知問題。
  2. 使用 Windows Store 及 Windows Phone Apps 論壇詢問。
  3. 若您發現的確是個 bug,可透過 Windows 10 內建的 Feedback App 來回報協助。

2. 若您對 API 有任何新功能的需求,則可透過 Windows platform developer UserVoice site 來建議,這網站會在 BUILD 2015 前持續更新,反應最新的 API 功能。

[Windows 10] Adaptive UI: 因應不同螢幕大小,動態改變畫面呈現方式 (使用 RelativePanel & VisualStateManager)

 

Gallo blog 1 v2

本文將介紹 2 種全新的 XAML 作法, 來達到 Windows 10 的 UAP 中 “Adaptive User Interface” 的要求。讓我們的 App 在任何螢幕大小的環境之下,都能適切的調整元件的相對位置、或是動態改變元件的呈現方式。

1. RelativePanel:可決定控制項之間的相對位置

<RelativePanel>

  <TextBox x:Name="textBox" Text="我是一段文字我是一段文字我是一段文字" />

  <Button x:Name="yellowBtn" Background="Yellow" Content="黃色按鈕" RelativePanel.RightOf="textBox" />

  <Button x:Name="blueBtn" Background="Blue" Content="藍色按鈕" RelativePanel.RightOf="textBox" RelativePanel.Below="yellowBtn" />

</RelativePanel>

請注意裡面出現了 RelativePanel.RightOf 以及 RelativePanel.Below,望文生義即可理解,App 會把這 3 個控制項的相對位置確認下來,無論螢幕大小如何改變。亦即:
「”yellowBtn” 將位於 “textBox” 的右邊;而 “blueBtn” 不但位於 “textBox” 的右邊,也會位於 “yellowBtn” 的下方。」

image

 

2. VisualStateManager:可根據螢幕的大小動態改變控制項的呈現方式

<TextBlock x:Name="text" Foreground="Azure" HorizontalAlignment="Center" VerticalAlignment="Center"/> 

<VisualStateManager.VisualStateGroups>

 <VisualStateGroup x:Name="SizeStateGroup">

     <VisualState x:Name="Min">

         <VisualState.StateTriggers>

           <AdaptiveTrigger MinWindowWidth="0" />

         </VisualState.StateTriggers>

         <VisualState.Setters>

           <Setter Target="text.Text" Value="喔喔好窄!!!!!" />

         </VisualState.Setters>

     </VisualState>

     <VisualState x:Name="Middle">

         <VisualState.StateTriggers>

           <AdaptiveTrigger MinWindowWidth="651" />

         </VisualState.StateTriggers>

         <VisualState.Setters>

           <Setter Target="text.Text" Value="寬多了啊!!!!!" />

         </VisualState.Setters>

     </VisualState>

     <VisualState x:Name="Wide">

         <VisualState.StateTriggers>

           <AdaptiveTrigger MinWindowWidth="1000" />

         </VisualState.StateTriggers>

         <VisualState.Setters>

           <Setter Target="text.Text" Value="可…以…躺…下…了!!!!!" />

         </VisualState.Setters>

     </VisualState>

 </VisualStateGroup>

</VisualStateManager.VisualStateGroups>

觀察以上的 XAML,我們只要注意兩點:

  • StateTriggers: 是用來定義一個條件臨界值,當螢幕大小滿足條件時,就會作以下 Setter 所描述的變動。
  • Setter: 可在此改變元件的 attributes,如改為 Horizontal、改變 width 等等;可以同時設定多個 Setters。

以白話文說明以上 XAML 描述:

「若 App 寬度至少為 0 pixel 的話,改變文字為 “喔喔好窄!!!!!”;若寬度至少為 651 的話,改為 “寬多了啊!!!!!”,若寬度至少為 1000 的話,改為”可…以…躺…下…了!!!!!”。」

以下是結果,請觀察寬度及文字的關係:

image

image

image

將以上的 RelativePanelVisualStateManager 綜合使用,就可以作到微軟資深技術主管 Kevin Gallo 在 Mobile World Congress 2015 上的 Demo 效果 (約第 30:00 開始約 3 分鐘):

註:

若要嘗試這些新功能:

  1. 請加入 Windows Insider Program,取得並安裝 Windows 10 Developer Preview.
  2. 取得並安裝 Visual Studio 2015 CTP. (目前版本為 CTP6)
  3. 新專案中即會出現 Windows 10 Universal App 的範本。

同時:

1. 若您在測試過程中遇到問題:

  1. 請先檢視 release notes 以及 known issues with Visual Studio 2015 CTP6,查看是否為已知問題。
  2. 使用 Windows Store 及 Windows Phone Apps 論壇詢問。
  3. 若您發現的確是個 bug,可透過 Windows 10 內建的 Feedback App 來回報協助。

2. 若您對 API 有任何新功能的需求,則可透過 Windows platform developer UserVoice site 來建議,這網站會在 BUILD 2015 前持續更新,反應最新的 API 功能。

延伸閱讀:

Guide to Windows universal apps: https://msdn.microsoft.com/library/windows/apps/xaml/dn894631.aspx 

Windows 10 開發者預覽的新功能 (What’s new in Windows 10 Developer Preview)

Gallo blog 1 v2

如果您有開發過 Windows Store 或 Windows Phone App 的經驗,以下幫您整理了 Windows 10 Developer Preview (開發者預覽版本) 之新增功能

當然,若要親自嘗試這些新功能:

  1. 請加入 Windows Insider Program,取得並安裝 Windows 10 Developer Preview.
  2. 取得並安裝 Visual Studio 2015 CTP. (目前版本為 CTP6)
  3. 新專案中即會出現 Windows 10 Universal App 的範本。

同時:

1. 若您在測試過程中遇到問題:

  1. 請先檢視 release notes 以及 known issues with Visual Studio 2015 CTP6,查看是否為已知問題。
  2. 請繼續使用 Windows Store 及 Windows Phone Apps 論壇詢問。
  3. 若您發現的確是個 bug,可透過 Windows 10 內建的 Feedback App 來回報協助。

2. 若您對 API 有任何新功能的需求,則可透過 Windows platform developer UserVoice site 來建議,這網站會在 BUILD 2015 前持續更新,反應最新的 API 功能。

以下即重貼來自 Windows 10 開發者預覽的新功能

應用程式模型

檔案總管

新的 Windows.System.Launcher.LaunchFolderAsync 方法可讓您啟動 [檔案總管] 並顯示您指定的資料夾內容。

共用存放裝置

新的 Windows.ApplicationModel.DataTransfer.SharedStorageAccessManager 類別與其方法,可讓您在使用 URI 啟用啟動其他應用程式時,透過傳遞共用權杖來與另一個應用程式共用檔案。目標應用程式會兌換權杖,以取得來源應用程式共用的檔案。

設定

搭配 LaunchUriAsync 方法使用 ms-settings 通訊協定,顯示內建設定頁面。例如,下列程式碼會顯示 Wi-Fi 設定的頁面。

bool result = await Launcher.LaunchUriAsync(new Uri("ms-settings://network/wifi"));

如需您可以顯示之設定頁面的清單,請參閱如何使用 ms-settings 通訊協定顯示內建設定頁面

控制項

WebView 更新

數個完整支援 HTML WebView 控制項的新 API 與事件,包含:

· MSWebViewUnviewableContentIdentified 事件的 MediaType 屬性

· MSWebViewUnsupportedUriSchemeIdentified 事件

· MSWebViewNewWindowRequested 事件

· MSWebViewPermissionRequested 事件,適用於嘗試取得使用者同意以存取地理位置服務的WebView 內容。

使用者輸入的用戶端資料驗證

新的 XAML 控制項屬性可讓您收集和顯示資料驗證錯誤。您可以新增、移除或清除控制項上的ValidationErrors 集合。當 ValidationErrors 計數變成非零,唯讀 ValidationState 屬性就會變更,且控制項會顯示驗證錯誤指示器。

使用預設的指示器樣式,或透過以自訂樣式覆寫 ValidationIndicatorStyle 屬性的方式自訂資料驗證指示器。或者,您可以設定 IsValidationIndicatorEnabled 屬性來啟用或停用指示器。

Windows 核心文字 API

新的 Windows.UI.Text.Core 命名空間提供一個可將鍵盤輸入處理程序集中至單一伺服器的主從式系統。

您可以使用它來管理您自訂文字輸入控制項的編輯緩衝區。文字輸入伺服器可透過應用程式和伺服器之間的非同步通訊通道,確保您的文字輸入控制項內容與其編輯緩衝區的內容一律保持同步。

輸入更新

有了 InkCanvas 控制項與基礎 DirectInk 類別之後,現在可以更容易地使用採用 C++、C# 或 Visual Basic 的 Windows 執行階段應用程式中強大的筆跡功能。

InkCanvas 控制項定義了一個用於繪圖及轉譯筆跡筆觸的重疊區域。這個控制項的功能 (輸入、處理和轉譯) 來自 InkPresenterInkStrokeInkRecognizerInkSynchronizer 類別。

重要 使用 JavaScript 的 Windows 應用程式不支援這些類別。

地圖

已經更新地圖控制項類別,以支援 Windows 10 Technical Preview 通用應用程式。這些 API 現在已屬於通用裝置系列。

裝置

位置

Windows 10 Technical Preview 導入了新方法 RequestAccessAsync,可以詢問使用者是否可存取其位置。

使用者可以利用 [設定] 應用程式中的 [位置隱私權設定],來設定其位置資料的隱私權。您的應用程式只有在下列情況下,才可以存取使用者的位置或位置歷程記錄:

· 定位已開啟 (不適用於 Windows 10 Technical Preview 手機版)

· [讓 Windows 與您選擇的應用程式使用您的位置與位置歷程記錄] 設定已 [開啟]

· 在 [選擇可以使用您的位置的應用程式] 底下,您的應用程式已設定為 [開啟]

請務必先呼叫 RequestAccessAsync,才能存取使用者的位置。此時,您的應用程式必須在前景且RequestAccessAsync 必須從 UI 執行緒呼叫。在使用者授與您的應用程式存取其位置的權限之前,您的應用程式無法存取位置資料。

AllJoyn

Windows.Devices.AllJoyn Windows 執行階段命名空間引進了 Microsoft 的 AllJoyn 開放原始碼軟體架構和服務的實作。這些 API 讓您的通用 Windows 裝置應用程式參與 AllJoyn 驅動、物聯網 (IoT) 案例中的其他裝置得以實現。如需關於 AllJoyn C API 的詳細資料,請下載位於 AllSeen 聯盟的文件。

使用此版本中包含的 AllJoynCodeGen 工具,以產生可用來啟用您裝置應用程式中 AllJoyn 案例的 Windows 元件。

電池

Windows.Devices.Power 命名空間中的電池 API,可以讓應用程式深入了解執行您應用程式之裝置所連接的任何電池。

· 建立電池物件以代表個別的電池控制器,或是所有電池控制器的彙總 (當由 FromIdAsyncAggregateBattery 個別建立時)。

· 使用 GetReport 方法傳回指示相對應電池的充電、容量及狀態的 BatteryReport 物件。

MIDI 裝置

新的 Windows.Devices.Midi 命名空間可讓您建立:

· 可以與外部 MIDI 裝置通訊的應用程式。

· 與 Microsoft GS MIDI 軟體合成器直接通訊的應用程式和外部裝置。

· 多個用戶端同時存取單一 MIDI 連接埠的案例。

自訂的感應器支援

Windows.Devices.Sensors.Custom 命名空間可讓硬體開發人員定義新的自訂感應器類型,例如 CO2 感應器。

圖形和遊戲

DirectX

Windows 10 Technical Preview 中的 DirectX 12 引進了下一版的 Microsoft Direct3D,也就是 DirectX 核心的 3D 圖形 API。Direct3D 12 圖形提高了低階、主控台式 API 的效率和效能。Direct3D 12 比以往更快更有效率。支援更豐富的場景、更多的物件、更複雜的效果,且能夠更有效地使用現代化圖形硬體。

媒體

HTTP 即時串流處理

您可以使用新的 AdaptiveMediaSource 類別,將彈性視訊串流功能新增到您的應用程式。物件已透過將它指向串流處理的資訊清單檔案來初始化。支援的資訊清單格式包含 Http 即時資料流 (HLS)、Dynamic Adaptive Streaming over HTTP (DASH) 與 Smooth Streaming。一旦物件繫結至 XAML 媒體元素,就會開始彈性播放。您可以查詢,並在適當時設定資料流屬性,例如可用、最小與最大位元速率。

適用於 Media Foundation Transforms (MFTs) 的 Media Foundation Transcode Video Processor (XVP) 支援

使用 Media Foundation Transforms (MFTs) 的 Windows 應用程式現在可以使用 Media Foundation Transcode Video Processor (XVP) 轉換、縮放及轉變原始影片資料:

· 新的 MF_XVP_CALLER_ALLOCATES_OUTPUT 屬性支援對呼叫端配置紋理的輸出 (即使在 Microsoft DirectX 視訊加速 (DXVA) 模式中)。

· 新的 IMFVideoProcessorControl2 介面可讓您的應用程式啟用硬體效果、查詢支援的硬體效果,以及覆寫視訊處理器所執行的旋轉作業。

轉碼

新的 MediaProcessingTrigger API 可讓您的應用程式在背景工作中執行媒體轉碼,因此即使終止前景應用程式,轉碼作業仍然可以繼續執行。

MediaElement

在 Windows 10 上,MediaElement 可播放包含多個串流的內容,即使其中一個串流發生解碼錯誤,只要媒體內容包含至少一個有效串流,便可繼續播放。例如,如果內容中的視訊串流包含音訊,而視訊串流失敗,則 MediaElement 仍然會播放音訊串流。PartialMediaFailureDetected 會通知您無法解碼串流中的一個串流。它也會讓您知道失敗串流的類型,以便在 UI 中反映該資訊。如果媒體串流中的所有串流皆失敗,就會引發 MediaFailed 事件。

傳統型應用程式的媒體傳輸控制項

ISystemMediaTransportControls 介面和相關的 API 可讓傳統型應用程式與內建系統媒體傳輸控制項互動。這包括使用傳輸控制項按鈕回應使用者互動,以及更新傳輸控制項顯示,以顯示目前播放媒體內容的中繼資料。

隨機存取 JPEG 編碼和解碼

新的 WIC 方法 IWICJpegFrameEncodeIWICJpegFrameDecode 可編碼和解碼 JPEG 影像。您現在也可以為影像資料編製索引,以提高大型影像隨機存取的效率,但是會耗用較多記憶體。

媒體組合的重疊

新的 MediaOverlayMediaOverlayLayer API 可以讓您輕鬆地將多層靜態或動態媒體內容新增到媒體組合。每層可各自調整不透明度、位置和時間,您甚至可以為輸入層自行實作自訂的組合器。

新的效果架構

Windows.Media.Effects 命名空間提供簡單且直覺的架構,可為音訊和視訊串流新增效果。此架構包含基本的介面,可實作以建立自訂的音訊和視訊效果,並將之插入媒體管線。

網路功能

通訊端

通訊端更新包括:

· 通訊端代理程式。通訊端代理程式可以代表處於應用程式週期中任何狀態的應用程式來建立及關閉通訊端連線。這可以讓應用程式和應用程式提供的服務更容易被找到。例如,透過通訊端代理程式,Win32 服務甚至在未執行時仍可接受連入通訊端連線。

· 改進輸送量。通訊端輸送量已針對使用 Windows.Networking.Sockets 命名空間的應用程式最佳化。

背景傳輸後續處理工作

Windows.Networking.BackgroundTransfer 命名空間中新的 API 可讓您註冊後續處理工作的群組。因此,即使您的應用程式不在前景,也可在背景傳輸成功或失敗時立即採取動作,而不是等到下次使用者繼續執行應用程式時才採取動作。

廣告的藍牙支援

有了 Windows.Devices.Bluetooth.Advertisement 命名空間,您的應用程式可以透過藍牙 LE 連線傳送、接收與篩選廣告。

Wi-Fi Direct API 更新

裝置代理程式已更新,可在不離開應用程式的情況下啟用裝置配對功能。Windows.Devices.WiFiDirect 命名空間的新增項目可讓裝置成為可供其他裝置搜尋的裝置,並讓裝置接聽連入連線通知。

注意 此版本中,Wi-Fi Direct 增強功能並未內建到 UX 中,且它們只支援一鍵配對。此外,此版本只支援一個使用中的連線。

JSON 支援改良功能

Windows.Data.Json 命名空間現在在偵錯工作階段期間轉換 JSON 物件時,對於現有的標準定義和開發人員體驗提供較好的支援。

安全性

ECC 加密

Windows.Security.Cryptography 命名空間中新的 API 支援了橢圓曲線加密法 (ECC),這是以有限體上橢圓曲線為基礎的公開金鑰密碼編譯實作。ECC 演算方式比 RSA 更複雜,提供較小的金鑰大小、減少記憶體耗用量,並改善效能。它提供了 Microsoft 服務與客戶一種 RSA 金鑰和 NIST 核准曲線參數的替代方法。

系統服務

電源

現在在執行或停止執行省電模式時,會通知您的 Windows 傳統型應用程式。藉由回應電源條件變更,您的應用程式有機會可以協助延長電池使用時間。

· GUID_POWER_SAVING_STATUS: 使用這個新的 GUID 與 PowerSettingRegisterNotification 函式,即可在執行或停止執行省電模式時收到通知。

· SYSTEM_POWER_STATUS: 這個結構已經更新,以支援省電模式。第四個成員 SystemStatusFlag(先前稱為 Reserved1) 現在可指示省電模式是否已經執行。使用 GetSystemPowerStatus 函式來抓取這個結構的指標。

版本

您可以使用 Version Helper 函式判斷作業系統版本。針對 Windows 10,這些 Helper 函式包含新的函式IsWindows10OrGreater。當您想要判斷系統版本時,您應該使用 Helper 函式,而不是已過時的GetVersionExGetVersion 函式。如需如何取得系統版本的相關詳細資訊,請參閱取得系統版本

如果您是使用已過時的 GetVersionExGetVersion 函式來取得 OSVERSIONINFOEXOSVERSIONINFO結構中的版本資訊,請注意這些結構包含的版本號碼會從 6.3 (適用於 Windows 8.1 與 Windows Server 2012 R2) 增加到 10.0 (適用於 Windows 10 Technical Preview)。如需作業系統版本號碼的相關詳細資訊,請參閱作業系統版本

在您的應用程式中,您也需要特別以 Windows 8.1 或 Windows 10 為目標,以取得這些利用 GetVersionExGetVersion 函式取得之版本的正確版本資訊。如需如何將您的應用程式以這些 Windows 版本為目標的相關資訊,請參閱將您的應用程式以 Windows 為目標

儲存空間

可供 Windows Phone 使用的檔案搜尋 API

身為應用程式發行者,您可以新增延伸項目至應用程式資訊清單,以便註冊應用程式將儲存資料夾與您發行的其他應用程式共用。然後呼叫 Windows.Storage.ApplicationData.GetPublisherCacheFolder 方法取得共用的儲存位置。

Windows 執行階段應用程式的增強式安全性模型通常會防止應用程式彼此之間分享資料。但是,對於來自相同發行者的應用程式,在以每個使用者為基礎的方式下共用檔案和設定而言很有用。

工具與效能

屬性變更通知

Windows.UI.Xaml 命名空間現在定義了數個支援變更通知的 API,以控制識別為 DependencyObject 的屬性。

通知的運作方式類似於事件,但實際上會公開為回呼。回呼會像事件處理常式一樣接受傳送者引數,但不接受事件引數。相反地,只會傳遞屬性識別碼來指示屬性。您的應用程式可以利用此項資訊,為多個屬性通知定義單一處理常式。如需詳細資訊,請參閱 RegisterPropertyChangedCallback

追蹤記錄

追蹤記錄是適用於使用者模式應用程式與核心模式驅動程式的新事件追蹤 API;它是建置在 Windows 事件追蹤 (ETW) 上。這個 API 提供簡化的方式來檢測程式碼,並包括含有事件的結構化資料,而不需要個別的檢測資訊清單 XML 檔案。

WinRT、.NET 與 C/C++ TraceLogging API 可用來為不同的開發人員對象提供服務。

使用者經驗

清單捲動虛擬化

XAML ListViewGridView 控制項具有新的 ListViewBase.ChooseItemContainer 事件,可在資料集合中發生變更時,改善控制項的效能。

相對於執行清單的完整重設 (這會重播進入動畫),系統現在會保持目前檢視中的項目,以及焦點和選取的狀態;檢視區中新的項目和移除的項目會以動畫流暢地顯示進出。在資料集合中 (其中的容器未受到破壞) 進行變更後,應用程式可以快速地將任何「舊」項目與先前的容器比對,並跳過容器週期覆寫方法的進一步處理。只有「新」項目會被處理,並與回收的或新的容器產生關聯。

不同的應用程式平台之間的拖放功能

新的 Windows.ApplicationModel.DataTransfer.DragDrop 命名空間將拖放功能帶入 Windows 執行階段應用程式。目前來說,一般的傳統型程式拖放案例 (例如將資料夾中的文件拖曳到 Outlook 電子郵件訊息中以附加檔案) 在 Windows 執行階段應用程式是不可能的。使用這些新的 API,您的應用程式可讓使用者輕易地在不同的 Windows 執行階段應用程式和桌面之間移動資料。這絕對是比以往更好且更直覺化的應用程式經驗。

按鍵輸入瀏覽鍵盤快速鍵的支援

新的 Windows.UI.Xaml.KeyAccelerator 類別可讓您為您的 XAML 標記頁面宣告鍵盤快速鍵。鍵盤快速鍵會在按下特定按鍵 (以及選用的輔助按鍵) 時叫用指定的事件處理常式。您也可以使用 x:Uid 屬性與您的KeyAccelerator 來進行當地語系化。

網頁

Internet Explorer

Internet Explorer 引進了「邊緣」模式:一種新的動態文件模式,針對搭配其他現代化瀏覽器和網頁內容最大互通性所設計。這個實驗模式已透過漸進方式提供給一組隨機選取的 Windows 開發人員預覽使用者。您可以透過新的 IE about:flags 機制手動啟用或停用邊緣模式。如需詳細資訊,請參閱:

· 使用邊緣 – 我們協助網路運作的下一步是正確的

· Windows 10 的 Internet Explorer 開發人員指南

 

延伸閱讀:

1. Windows 10 對於開發者的意義在哪?

2. 初窺 Windows 10 的通用應用程式平台 (Universal App Platform)

初步了解 .NET 2015

感謝成功大學資訊工程研究所陳顥文同學協助翻譯微軟公司資深高階主管 Bath Messi 於 2015/2/25 發表的文章:

Understanding .NET 2015

文中主要提示了即將發佈的 .NET 2015 在各種角度上的改變,包括對各平台的支援、走向開放等等。

在進入本文之前,她的結論提到身為多年的微軟人,親身經歷 .NET 走向開源的過程及感想,說出了許多人,尤其是長期關注微軟技術者的心聲,在此轉述如下:

對微軟來說,開放原始碼並不是新的舉動,但對 .NET Runtime 函式庫卻是。這對一個超過 15 年的老專案是個非常重大的決定,對許多內部的員工來說,這開放的不是單單只有程式碼而已,而是將整個工程都開放出去。改變是需要時間的。所以這是為甚麼 .NET 小組剛開始只能釋出一小部分的物件函式庫。我們在未來需要有更長更遠的路要走。從決定開放也至於現今的成果,可以讓我們這個團隊學到這些舉動激起的漣漪、以及產生的貢獻,這些都讓我們自嘆不如。”

.NET 2015 – 主要架構

clip_image002

其中,針對 .NET Core 有以下三個主要的投資及改變:

1. .NET Innovation-微軟已將許多語言的編譯器重新設計、改良,以符合新一代開發者的需求,包括底層物件函式庫 (BCL: Base Class Libraries)、應用程式模型(App Models)、執行階段 (Runtimes) 及相關工具。

2. Open Source (開放原始碼)-微軟已將開發流程透過開源社群公開,也透過開源社群得到進一步的支援及協助,經由這樣與全世界開發者間的互動,一起培育 .NET 的生態系統。

3. Cross Platform (跨平台)-使用者的執行平台及環境越來越多樣,有鑑於此,讓 .NET 跨平台相容至 Linux, Mac 等平台上當然也是必需的。

.NET 2015 的主要元件
Frameworks and Runtimes

.NET Framework 持續提供一個受控管的執行環境,於其上提供各種服務讓應用程式使用。.NET Framework 主要由兩個元件組成:其一是通用語言執行庫 (CLR),CLR掌管並且提供應用程式的執行引擎;另一個元件是 .NET Framework 物件函式庫,是一組穩定且可重複使用使用的現成程式庫,讓他們能夠在自己的應用程式中呼叫使用。

.NET Framework 4.6 建立於 4.5.2 版之上,加入了許多新的 API,並且強化了事件追蹤 (Event tracing) 並修復了許多的Bug,這將會是下一個完整的.NET Framework! .NET Framework 4.6 也將會包含於 Windows 10 之中。先前的作業系統也可以透過 Windows Update 來取得最新的.NET Framework! (Vista 含以上的版本)

更多有關於.NET Framework 4.6的詳細資訊參考 .NET Framework 2015 Preview

.NET Core 5 是一個提供多種功能、模組化的設計框架 (framework),能在橫跨多種平台的環境中使用,且為開放原始碼,將會支援Windows、Linux、Mac OSX。.NET Core 5 的內部架構包含底層物件函式庫 (corefx) 以及 Rutime (coreclr),包括 JIT 編譯器 (RyuJIT),.NET 回收機制 (GC),原生語言互通性 (Native Interop),以及其他.NET Rumtime 元件。

.NET Core 5 目前可運行在 Windows 上面,微軟也即將加入 Linux 以及 Mac 支援,讓 .NET 的主要元件能運行在這兩個平台上。

更多有關於 .NET Core 的詳細資訊請參考 Introducing .NET Core 以及 CoreCLR is now Open Source.

如果以上兩個詳細資訊您只想選一個來看,那我會推薦看 Introducing .NET Core,這會讓您瞭解為何我們需要 .NET Core,以及適合在那裡使用。

Compilers (編譯器)

.NET 編譯器平台 (“Roslyn”) 提供開放原始碼 C# 以及 Visual Basic 的編譯器,並提供豐富的程式碼分析以及 API、並提供了程式碼分析工具。

為 .NET 2015 量身打造的 Roslyn,其平台與核心、框架皆使用獨立的中繼語言(IL) 所完成。在 .NET 2015 釋出之時,整個 .NET Framework 將都會是由 Roslyn 所編譯完成的。除此之中,在 C#、VB 甚至 F# 語言本身都將有重大的革新。

Roslyn 的專案已開放原始碼放置在 Roslyn on GitHub

“RyuJIT” 是 .NET 在 64 位元平台上的全新預設 JUST-IN-TIME(JIT) 編譯器。於執行期間,JIT編譯器將使用中繼語言 (IL),即時編譯於目標機器中執行。

在桌上型電腦以及伺服器的執行情境裡,RyuJIT 更新了先前 64 位元的 JIT 編譯器,顯著減少了啟動所花費的時間。RyuJIT 也支援 SIMD (單指令流多資料流, Single Instruction, Multiple Data),這代表能夠同時平行執行大量的數學運算。將讓使用到向量運算的應用程式得到顯著的效能提升!

更多關於下一代 JIT 編譯器的訊息,請參考 The next-generation JIT compiler for .NET

.NET Native 將 C# 直接編譯為為原生機器碼,如同 C++ 一樣。亦即,開發者能夠在享受 .NET Framework 高生產力的同時,還能得到優異的執行效能。一般情形下,.NET 所編譯的應用程式會先被轉換成中繼語言 (IL),在執行時期再透過JUST-IN-TIME(JIT) 編譯器將中繼語言 (IL) 轉換成原生機器碼。

而 .NET Native 則是一種提前編譯器 (ahead-of-time compiler),會先把應用程式直接編譯成原生程式碼,並且包含最小的通用語言執行庫 Runtime (CLR Runtime) 以降低套件大小。如此一來,能讓使用 .NET Native 編譯的 Windows Store Apps 再啟動的速度加快 60%,並且減少 15~20% 的記憶體。Universal Windows apps 都將會運行在 .NET Native 上(包括 ARM, X86, X64 的 CPU 架構)

有關於 App 使用 .NET Native 編譯的詳細資訊參考Compiling Apps with .NET Native.

App Models

在 .NET Framework 4.6 以及 .NET Core 5 中,延伸了先前的通用函式庫以及應用程式模型,例如 Windows Forms、WPF、ASP.NET Web Forms、MVC 5 等等。您所熟悉的應用程式模型在 .NET Framework 中將會加入許多新功能,能夠與全新的程式語言和 Roslyn 編譯器、RyuJIT 作完美的整合。在 .NET 4.6 中新增了許多有趣的東西! 請參考 ASP.NET Overview – What about Web Forms?The Roadmap for WPF.NET Framework 2015 Preview.

附帶一提,新的應用程式模型也為 .NET Core 5 做了設計的優化。

ASP.NET 5 使用現代的 .NET 應用程式模型來設計 Web 應用程式。透過已優化的開發框架打造雲端或者本地端的網頁應用程式。透過 ASP.NET 5 模組化的元件以最小的資源耗費打造出有彈性的專案,ASP.NET 5 可以運行於 .NET Framework 4.6 或者 .NET Core 5 之上。現在 ASP.NET 5 已可以透過 Mono runtime 執行在 Linux 以及 Mac 上面。

從 .NET Core 開始支援 Linux 以及 Mac 後,ASP.NET 5 將會計畫透過 .NET Core在這些平台運行。

關於ASP.NET5 的詳細內容可以參考ASP.NET 5 Overview以及Introducing ASP.NET 5

Universal Windows App (通用型應用程式) 是一個能夠讓您在 Windows Phone 及 Windows apps 上互相共用程式碼,並能部署到 Windows Store 的一個應用程式模型。通用型應用程式將會以 .NET Native 運行,將中繼語言編譯成原生機器碼,並包含執行所需要最小的通用函式庫`。

更多關於 Universal Windows App  以及如何使用 .NET Native 開發可以參考Building universal Windows apps for all Windows devices 以及 Getting Started with .NET Native

讓我們再複習一下.NET Core

.NET Core 5 是一個泛用途、模組化,且因為重構並使用底層物件函式庫(corefx)以及Rutime(coreclr),因此具備跨平台特性的 Framework。

.NET Core 在不同的應用程式模型使用相同的底層物件函式庫(BCL),或許這些 API 看起來不太一樣,但其實它們分享同一種實作方式。大部分的 API 都擁有高度模組化且易於重構、並獨立於作業系統的平台之外的特性。

clip_image004

.NET Core 的開發之路
我想在學習新的技術時,有個心智圖會比較好理解這些東西將會怎麼運作。

下圖是當您在使用 .NET Core 開發應用程式時的簡化圖。從撰寫程式碼/建置/除錯的循環,及至於部署並執行的過程。請注意在部署執行階段,會根據最後的執行平台,以不同的應用程式模組去編譯您的程式。

clip_image006

在您撰寫程式碼中,會參照許多位於底層物件函式庫 (BCL) 內的參考。Roslyn 編譯器會將您的程式碼轉換成獨立於平台的中繼語言 (IL)。除此之外,編譯器擁有豐富的 API,讓您能夠做各式各樣的程式碼分析工作。如果您正在使用Visual Studio,將會有許多的新功能應用這些 API,讓您在撰寫程式的過程中更有效率。

如果您正在打造通用型 Windows 應用程式,可以利用 .NET Native tool chain將 您的程式建置為原生碼,且包含執行最小需求的通用函式庫。

而如果您在開發 ASP.NET 5 ,將可參照使用您部署伺服器端的 CoreCLR,同時利用 JIT 彙整程式碼後,由 RyuJIT 建置。

另外一提,ASP.NET 5 允許您在執行階段更改並儲存程式碼,之後只要重整您的瀏覽器而不需要在執行重新建置。Visual Studio 使用 Roslyn 的動態編譯,讓您擁有強大的開發框架,更能提供您更流暢更像直譯式語言的開發。

附記:如果您要使用 .NET Framework 4.6 為建置的目標,您仍然能夠使用這些全新的功能以及 Roslyn 編譯器。應用程式部署將不會因為目標改變而有變化,這必須要依賴於您編譯該應用程序系統的 Framework 版本。但在執行階段則會使用JIT彙整並且編譯利用 RyuJIT 執行。

到底有哪些開放了?

在 .NET 2015 底下,有許多部份是開放原始碼且由 .NET Foundation 管理。我們正在將這些專案一一的開放給開源社群們使用。

clip_image008

您可以在 .NET Foundation 的 GitHub 上面看到所有可供使用的開源專案:http://dotnet.github.io/

以下有幾個不錯的代碼庫,能夠透過以下連結來得到不同專案的原始碼及專案檔:

值得一提的是,完整的 .NET Framework 是 ”source open”,這代表我們不是全然的將程式碼開放並且也不是全然的遵守 OSI 授權 (譯註:OSI 為 Open Source License),但您仍然可以瀏覽所有的原始碼: http://referencesource.microsoft.com/

敞開心胸

對微軟來說,開放原始碼並不是新的舉動,但對 .NET Runtime & 函式庫卻是。這對一個超過 15 年的老專案是個非常重大的決定,對許多內部的員工來說,這開放的不是單單只有程式碼而已,而是將整個工程都開放出去。改變是需要時間的。所以這是為甚麼 .NET 小組剛開始只能釋出一小部分的物件函式庫。我們在未來需要有更長更遠的路要走。從決定開放也至於現今的成果,可以讓我們這個團隊學到這些舉動激起的漣漪、以及產生的貢獻,這些都讓我們自嘆不如。

您或許會問自己,「我沒有足夠的時間打造我自己的應用程式,但至少我還能寫一點 code 來貢獻 CLR!」。您的想法沒錯,我們將會與您一起努力,您可以自由選擇您要用甚麼方式來參與我們,您也可以不成為寫程式碼的貢獻者,可以選整理問題提供一些您的意見、或者回答問題,或者只是到處看看社群努力的成果

您又或許會想「我不想要失去簡單好用以及有一定品質的 .NET Framework…」,別擔心!我們的等級跟品質還有服務會跟以前一樣好,我們所做的只是單純開放我們的工程成果。純粹將先前我們所在內部做開放,同時也會保持我們軟體上面的品質。

我對 .NET 以及 .NET 小組迎接的新文化感到興奮!

初窺 Windows 10 的通用應用程式平台 (Universal App Platform)

在「Windows 10 對於開發者的意義在哪?」文中提到,4/29~5/2 的 BUILD 大會中,才會有進一步針對 Windows 10, Cortana, Xbox, Surface Hub, 以及 HoloLens 上開發應用程式的完整訊息。那麼在這之前,開發者可以怎麼準備呢?

首先,即是先開始熟悉 Universal Windows Apps 了!

image

同時,在三月初於巴賽隆納舉辦的 Mobiel World Congress 上,微軟又進一步公佈了未來 Windows 10 的通用應用程式平台 (Universal App Platform):

A first look at the Windows 10 universal app platform

Gallo blog 1 v2

這張圖的上方提示了 Universal Apps 將橫跨多種不同裝置;下面的部份則可細項來看其說明:

As we built the universal app platform, we set out to ensure that all Windows developers would equally benefit from this one core. The platform enables a new class of Windows universal apps – apps that are truly written once, with one set of business logic and one UI. Apps that are delivered to one Store within one package. Apps that are able to reach every Windows 10 device the developer wants to reach. Apps that feel consistent and familiar to the customer on all devices, while also contextually appropriate to each device’s input model and screen size. The new universal app platform completes our developer platform convergence by providing you with the ability to finally create one app that can run on mobile, desktop, console, holographic, and even IoT devices.

Adaptive UX: enables your app’s user interface to fluidly adapt at runtime based on how the customer is interacting with your app and the available device capabilities – rendering an experience that is contextually appropriate.

  • Screen layout: In addition to base app model improvements, we have improved the ViewStateManager to make it easier to create more adaptive experiences. This means that your universal app projects no longer require separate project heads or UI definitions for small and large screens, although we will still provide the option of separate UI definitions should you prefer it.
  • User controls: Windows 10 will determine, at runtime, how the customer is interacting with your app and render the appropriate user experience (e.g. on a laptop with a touch-screen, an app fly-out control will provide larger touch-targets if tapped with touch, as opposed to clicked with a mouse).

Natural user inputs: Windows 10 helps you build an app experience that is more personal and more human, by making it easy to incorporate natural user inputs into your app, such as natural speech, inking, gestures, and user gaze. Because Windows handles all of these inputs, we free you from needing to worry about how to parse the input for meaning – you only need to worry about which inputs are appropriate for your app and we’ll determine if they are present and parse the intent for you.

Cloud-based Services: Windows provides a number of services for use in your apps, such as Windows Notification Services (WNS), Windows roaming data and the Windows Credential Locker. With Windows 10, we are making more Windows services available to developers, including an expanded Cortana AI, OneDrive, and Application Insights. Beyond Windows, we continue to make it easier to take advantage of Microsoft Azure using services like Azure Mobile Services and the Azure Notification Hub.

最後,則是再次提醒大家:

1. 歡迎參加 Windows Insider Program,提早取得並體驗 Windows 10,同時還能率先得到開發工具預覽的通知。

2. 開始學習 Universl Windows Apps 開發!

Windows 10 對於開發者的意義在哪?

Windows 10, Cortana, Xbox, Surface Hub, 以及最炫的 HoloLens,這些都是微軟在 1/21 日的重大發表。那麼對於開發者而言 (包含學生及新創公司),要如何預備 Windows 10 的到來呢?

最大的重點即是:Universal Windows Apps (通用應用程式)!

image

重點僅止於此? 當然不只! 官方部落格 Building Apps for Windows  整理了一篇文章,讓開發者可進一步了解各相關資訊。在此特別感謝成功大學資訊工程研究所的陳顥文同學 (台灣微軟技術實習生) 協助翻譯為中文,請大家參考!

Windows 10 is empowering developers to dream again

Terry在發表會上展示了最新具備能夠橫跨多個裝置,可用於平板、手機、以及個人電腦上的作業系統,Windows 10。以及展示了微軟 Surface Hub,和世界第一個全息影像計算平台:Microsoft HoloLens。

Windows 10 將會搭配全新的人工智慧:Cortana,以及全新的瀏覽器:Project Spartan。並且更緊密的結合 Xbox 遊戲體驗。還有新的全息影像技術 (holographic) 及其相關裝置。當然也改良新增了幾個內建的 Universal App,例如”人際網路及訊息”、”相片”、”影片”、”音樂”,以及”地圖”的應用程式,這些 App 也成為 Universal App 在多個平台開發的成果。

全新設計的 Windows 10 將提供創新的服務與功能給 15 億用戶們使用,微軟將提供 Windows 10 免費升級。在 Windows 10 正式發行之後,原有的 Windows 7、Windows 8、Windows 8.1,以及 Windows Phone 8、Windows Phone 8.1 使用者,將得到免費升級的機會。*

現在,我們來與 Windows 開發者們談談這個新系統會即將帶來的機會與變化。

去年 4 月的 Build 2014 大會中,我們討論過 Windows 平台開發的設計思維。在 Windows 10,我們進一步簡化了建議遵守的設計規則:

橫跨多個裝置,讓應用程式擴及的人數增加

微軟盡力統一 Windows 10 上的開發流程,讓您的應用程式設計可適用於多個平台例如手機、平板、個人電腦及 Xbox、甚至是物聯網裝置(IoT devices),以及全新發表的 Surface Hub 以及 HoloLens。也就是說,您所開發的應用程式能夠讓更多的消費者使用。

統一的操作體驗

微軟期願讓人們使用科技的方式盡可能的單純及簡單,我們也在這一塊做了極大的努力及改變,在不停提供新科技的同時,也希望能夠讓人們與電腦互動的方式能夠更加的自然。在Windows 10,開發者們將可以運用人工智慧助理 ”Cortana” 所提供的語言辨識、觸控、音效、影像、全息影像等技術,加入到您所開發的應用程式中,這些在 Windows 10 不只是夢想,而是有可以被實現的!

節省開發者的時間

我們將繼續的新增學習資源、工具,以及範例程式碼,也能協助開發者們更快更簡單的完成具備跨平台特性的應用程式。

擴增應用程式使用者的規模

我們將會持續讓更多的使用者採用 Windows 10,讓每個開發者所開發出的應用程式能夠擴及到更多的消費者。最近開發者在軟體開發上遇到的一大問題,就是需要更對更多元的各類型裝置,而必須要花費相當大的功夫,才能保持不同裝置上的應用程式能夠有一致的功能。Windows 10 將會改善這些開發上所遭遇到的”碎片化挑戰”。

首先第一個改變,各位將可以發現 Windows 10 開始跟使用者有全新的關係,Windows 10 就像一個服務,將提供經常性的自動更新,這樣可以確保大部分的使用者維持在最新的版本,能夠讓大部分的使用者使用到您開發的應用程序所需最新的作業系統功能。這個自動更新的程序對一般使用者而言是免費的。因為有這個特點,Windows 將可以讓開發者們放心使用最新的技術做應用程式開發,而不需要擔心使用者的作業系統版本及需求是否符合。

我們也在遊戲類型 App 做了一點改變,讓遊戲 App 的操作體驗以及畫面的呈現在各個裝置上能夠保持統一。Windows 10 平台也能夠透過通用型的 Windows App 框架 (Framework),讓舊有的Windows 8.1 應用程序只需要一點修改,就能加入 Windows 10 應用程式的新功能。

帶來獨特的體驗

在發表會上,Windows 10 提供了數個新的功能,使用 HoloLens 全息影像技術,讓開發者能夠透過全息影像裝置讓實體世界與數位世界接軌,能讓人們在全息的擴增實境裏頭作互動。另外,許多人可能已經在手機上體驗過的Cortana,很快的 Windows 10 上的 Cortana 將會有更多的功能及變化出現。

我們也發布了在 Windows 10 中網頁瀏覽的新體驗,”Project Spartan”,讓使用者用更快速簡易的方式來瀏覽網頁。Spartan帶來了新的渲染引擎 (rendering engine),這個全新的引擎將針對新一代的網頁提供更好的互動及操作性。在 Web 開發小組的部落格可以找到更詳細關於 Spartan 的詳細介紹。

極大化您的投資

在每次作業系統進行更新變動時,我們總是確保著先前已經存在的應用程式能夠如期的正常運作。

但是我們不僅只保持舊有的程式碼能夠繼續運作,而是保障開發者們花費數年時間學習的開發技術也能夠繼續地運用在 Windows 10 平台間的應用程式開發上。在 Windows 10 您將能繼續透過 Visual Studio 開發工具,使用多樣的、以及您早已熟悉的程式語言來做開發,並且也可以靈活運用來自 Azure 所提供的雲端服務來加強您的應用程式體驗。

降低要達到跨平台的投資成本,也是我們致力做到的目標。我們知道開發者需要花費非常多的時間投資在學習開發不同的平台上。因此我們把跨平台開發這件事情變得更加容易,並且能夠將其他平台的專案能夠帶來 Windows 上面部屬及開發。

回到去年的 Build 大會,我們發表了基於開放原始碼授權的跨平台語言:Win JS (可以參考:http://dev.windows.com/zh-tw/develop/winjs 以及 http://try.winjs.com)。我們在去年9月也繼續的更新改善WinJS,並發表Win JS 3.0。

接著我們也發表Xamarin (http://xamarin.com) 以及Unity (http://unity3d.com),能夠讓開發者使用 Visual Studio 透過 C# 開發行動裝置應用程式並且部署到蘋果 iOS 以及 Google 的 Android 裝置上 (就像開發Windows平台應用程式一樣容易)。而在最近發表的 Visual Studio 2015 預覽版本中,我們也內建了Apache Cordova,以及能透過 Visual Studio 2015 開發建置 shared libraries 的 Andorid應用程式,還包含了完整的 Android 模擬器,最後,針對原生的 C++ 開發者,也可以透過 Android NDK 開發 Android 應用程式。

接下來呢?

無論你的使用者在哪裡、使用什麼樣的裝置、執行什麼樣的作業系統,我們將會持續的讓您的開發成品能夠盡量的讓更多的使用者使用。

在 Windows 10 正式發表前,最好的準備方式就是從現在開始使用 Universal Windows App 打造 Windows 8.1 的應用程式!

官方文件
其他線上學習資源
  • 透過C#/XAML開發Universal Windows Apps 入門(英文無字幕,包含真實的設計案例教學)
  • 如果您現在是 Windows Phone Silverlight 的開發者,這是您大好的機會來學習如何使用 Windows XAML 開發,因為這會使您的應用程式能夠設計成為 Universal Windows Apps. 我們提供如何將 Windows Phone Silverlight 的 App 轉換成 Windows XAML 執行階段的 App,在未來 Windows 10 開發Universal App的一些影片及建議在這裡(英文)。
  • 在即將來到的 Build 2015 我們將會分享更多 Windows 10 開發者所需要知道的相關資訊。若您需要有關於 Build 2015 的詳細資訊,可以參考http://buildwindows.com (目前的票已售罄,若您想親自前去,我們鼓勵您在該連結內登入候補行列)。您也可以從 Steven Guggenheimer 的文章(英文)得到更多的Build大會詳細的內容。
  • 我們知道有許多使用者及開發者會加入Windows Insider 計畫,透過這個計畫您將能取得最新版本的 Windows 10。但必須注意的是這是測試版的作業系統,您有可能會在測試版的作業系統遭遇到多個問題,建議不要當作主要的開發環境做使用。
  • 在 Windows Insider 計畫中,除了作業系統之外,也包含幾個工具以及 SDK,如果您想要提早的取的這些預覽版本,請盡速加入這個計畫。

*硬體及軟體有額外需求,不需要額外花費,在不同的裝置可能有功能受限,有些版本可能不適用。更多的細節請參考 http://www.windows.com.