Metro Style App當中的Toast Notification訊息傳遞

Toast Notification是從WP7開始就有的新玩意兒，比起WP7，Metro Style App要送出Toast Notification比過去要來的簡單多了，而且有更多的樣板可以使用，在這段影片當中，我們介紹如何透過方便好用的NotificationsExtensions來送出Toast notification...

Metro Style App當中的資料儲存機制 - ApplicationData

ApplicationData是WinRT當中新的資料儲存機制，類似過去我們在Silverlight與WP7當中的IsolatedStorage，但由於同時又支援了Roaming, Temporary, 因此功能更為強大，在這段影片當中，我們就來看看WinRT當中的ApplicationData機制該如何使用...

Metro Style App與.NET 4.5中的非同步程式設計概念

非同步，是最近這幾年很重要的程式設計與開發概念。

過去，我們在寫程式的時候，總是從上到下一行一行執行，但隨著CPU運算能力越來越強大，且展示層的User Experience要求越來越高，用戶不容許今天我們的程式碼在跑長時間動作(例如開啟一個很大的檔案、或是讀取遠端資料庫或網路上的資料)時，畫面停止回應。

因此，最近這幾年程式設計都轉變成透過非同步的方式來設計，例如底下這樣的Silverlight程式碼：

在DownloadStringAsync的非同步Method呼叫下，返回值並不會立刻取得，而是在相對應的Completed事件當中取得，但這樣導致做一件工作需要拆成兩三段來寫，如果在非同步的呼叫之後，又要再次呼叫非同步方法，就會變成底下這樣：

這導致維護與程式碼閱讀的困難，更讓例外(Exception)處理變得很礙手礙腳。因此，在.NET 4.5和Windows的Metro Style App當中，開始有了新的非同步程式設計方式...

相關的說明與介紹，請參考底下影片：

從Silverlight到Metro的心路歷程

趁有空，用文字整理一下沒能完整在研討會上分享的心情。

從Windows 8的Metro Style Apps開始有消息時，我們就在官方的Slides上，看到了針對Metro Style Apps的開發，寫明了是可以採用多種技術，包含HTML+JavaScript, 包含XAML+C++, 包含了XAML+C#(VB)...

那時候可能很多人覺得疑惑，咦? XAML+C#，那不就是Silverlight(或WPF)嗎? 那為何不乾脆寫Silverlight呢?

我們知道，早在.NET 3.0開始(2006年)，WPF就是用XAML來描繪UI，而Silverlight的出現比WPF晚上了幾個月(2007年)，沒想到在實務(實際使用)上，Silverlight後來比WPF更加的廣泛，同時也成為微軟在RIA上對抗Flash/Flex的利器。

(請回憶一下，在這個時間點， iPhone 才剛剛出現, iPad 還不知道在哪裡咧...)

後來沒多久，Windows Phone被迫出現了(2010年)，我們都知道，Phone/Pad成功的關鍵，與App的多寡有著非常大的關係，因此從現在回頭看，在2010那個時間點，當時要讓App快速出現，最好的方式就是選擇一個可以快速上手，並且已經有著一定數量開發人員的開發技術，這個技術又要支援多媒體效果，又要有現成的開發工具，還能夠很快速地讓Runtime可以Porting到當時Windows Phone所採用的Windows CE上面，在當時時間如此急迫的狀況下，幾乎沒有任何其他的選擇和可能性，因此Silverlight雀屏中選，成為WP7.0和WP7.5的主要開發技術。

好，知道歷史背景之後，我們回頭談XAML+C#, 前面說到, 因為當時Silverlight幾乎可以代表XAML + C#(VB)這一掛的開發技術，所以在我們看到Win8 Metro Style App所採用的主要開發技術是XAML+C#(VB)之後，很自然的覺得，Metro的開發技術可以用XAML+C#，那到底是不是說，Silverlight可以用在Metro Style Apps開發上呢?

現在回頭看，答案揭曉了，答案可以說是也可以說不是。但原因原來如此地簡單，因為：
     Silverlight = XAML+C#(VB)
但
     XAML+C#(VB) 卻不等於(而是大於、是包含) Silverlight

請注意，在今天這個時間點回頭來看，我們很容易理解，XAML+C#(VB)這樣的技術組合，至少有下面這幾種方式：

1.WPF            =    XAML     + C#(VB)  +     Full .NET  Class Library
2.Silverlight     =    XAML     + C#(VB)  +     .NET  Class Library Subset
3.Metro           =    XAML     + C#(VB)  +     WinRT

別忘了，XAML是描述UI的技術，C#(VB)是Programming Language，但光這兩個還不夠，第三個組合(Runtime的Class Library Framework)也是一個重點，XAML只管UI(包含Binding、Animation...etc)而Programming Language就只是寫程式用的語法，早在.NET 3.0從WPF開始我們就在概念上把這兩種東西分開了，這樣的概念就好比是HTML搭配javaScript、或Asp.net的Code Behind概念一般，目的是讓邏輯程式碼與描繪UI的程式碼分離，好處顯而易見，就是降低相依性，讓開發團隊中的UX設計師與程式設計師可以分工，又不會彼此干擾。(這是近代展示層應用程式設計的一大重點)

所以，有了這樣的概念之後，其實我們如果從更宏觀的角度來看Metro/WPF/Silverlight，這幾種開發技術的Programming Model幾乎大同小異，XAML與Programming Language根本上都差不多，唯一的差別是Runtime的Class Library。

所以我在研討會上再次說了『流淚撒種的，必歡呼收割』，過去我們在XAML(Silverlight/WPF)上花的心思，事實上一點都沒有白費。

過去我們(公司、我個人、和我的學生、夥伴們)花了不少時間在XAML(Silverlight)上，今天不管在Silvelight(應用在Internet/Intranet、Windows Phone)，在WPF(應用在Desktop)，在Metro(應用在Windows 8、Windows Phone)，都可以得心應手，你過去熟悉的開發技術(XAML/C#(VB))其實並沒有改變，你用這套開發技術在微軟的世界中，可以橫跨 Web / Desktop / Phone / Pad 這幾種不同的平台(當然，我指的是在微軟的設備上)，也因為如此，很多人擔心的Silverlight是否還會活著的問題，其實或許並不存在。

我們剛才說了，Silverlight是XAML+Programming Language(C#/VB)+Run Time Class Libraries的集合， 如果你可以更宏觀的看，如今的Metro Style App開發技術，與Silverlight不僅僅是系出同門，更可以說是攣生兄弟。

那這樣是否代表著兩者完全相同? 當然也不是，即便是攣生兄弟，在不同的環境下長大，也需要面對不同的生活環境， Metro / Silverlight / WPF 之間的差異大致上就是這樣，因為這三種同父同母、系出同門的開發技術，在應用上Metro是要面對平板、智慧型手機，Silverlight是要面對Web環境、WPF是要面對Desktop，自然會衍生出不同的個性。(也因此，我會在後面陸續慢慢分享一些Silverlight與Metro Style App開發之間的差異與相同之處，你會慢慢發現，其實你累積下來的經驗比你想像的還有用)

在分工比較細的公司或專案團隊，我們大概不會要求開發人員Metro/Silverlight/WPF三種都會，但很抱歉，你在台灣，你是全能Developer，而我們過去也都受過這種全能開發人員的養成教育，所以我得說如果你是.NET Developer，那Metro/Silverlight/WPF三種通吃針對你來說應該也是很自然的狀況才對。

更嚴格地說起來，Metro/Silverlight/WPF三種開發技術從某個角度來說，根本就是一種(而不該當成三種來看)。

這也是我在研討會上，特別提醒開發人員，不要只看到改變，要多看看你留下來的經驗，你才會發現，其實過去的經驗很有價值。同時，在這個多變的時代，你擁有或掌握的學習能力與經驗，價值遠勝於你擁有或掌握的技術。技術是會變的，但你的學習能力與經驗，則是可以累積並且重用的。

至此，我可以說，Silverlight有沒有死去，開始不是一個問題，(如果你堅持要討論，我會說我覺得還早)，不僅如此，熟悉XAML( WPF/Silverlight )的開發人員，比起傳統的開發人員來說，有著更廣泛的發展空間，對於未來的專業領域生涯規劃，也將有著相當大的可能性。

我在討論這件事情的時候有沒有立場? 我要說：『或許有』! 公不公道? 『我想可能有些人覺得不一定!』 但至於這個判斷正不正確? 就由讀者來決定囉 :)

端午佳節將至，建議各位放鬆心情，吃飽粽子之後，我們再回來繼續衝刺。
~祝大家 佳節愉快~

[研討會] Microsoft Developer day 2012 - 從C# Developer的角度看MetroApp的開發

颱風天，很謝謝大家特別來參加今天Microsoft Developer Day 2012的議程，我的場次投影片位於：http://arock.blob.core.windows.net/msdevday2012/DevDayCS2Metro-public.7z


範例和影片會陸續放上來，也請同步關於底下FB社團中的訊息：
Win8 Metro App Asia Developers

在這個展示當中，示範了如何建立一個簡單的Metro Style App, 如何透過Metro上的UserInformation類別抓取用戶資訊，顯示照片與名稱, 以及如何在頁面中進行切換...等基本的Metro功能，讓C#開發人員輕鬆的進入Windows 8 Metro Style App 設計的世界...

分享，是現在行動裝置上非常有趣的設計。過去在App與App之間要分享資料似乎有些麻煩，然而現在在Windows 8 Metro Style App當中，我們可以輕鬆的利用OS本身提供的Share Contract，讓兩個App之間迅速便利的分享資料，更重要的是，這樣的功能很好設計...

過去在Silveright或WP7當中，想要寫程式抓取專案中的影片或檔案，還需要費點功夫, 且XAML與C#程式碼當中的寫法又有點不同，現在Metro Style App, 可以讓我們直接用ms-appx:///就可以存取專案中的檔案囉...



FilePicker有分為Open或Save, 和過去的FileDialog很像，但不同的是，在Metro當中，可以直接透過App與App之間的合作，直接讓我們寫程式透過FilePicker存取用戶的Skyd­rive, 也就是說, 他整合了本地端與雲端的檔案存取系統, 在現在無所不雲的時代, 有其跨時代的意義與價值...

可以用來替代WP7中的Panorama或Pivot, 適合觸控也是和滑鼠操作, 是Metro中非常典型的應用。(影片中有一段錄音口誤，將Metro Style App誤說成WP7, 請容我有空再改吧...)
  

如何啟動MSDN Ultimate訂閱免費的Windows Azure雲端服務

隨著Windows Azure開始正式在台灣開放，我們現在可以用台灣了Live ID申請囉，跟著我來做申請步驟吧。

如果你的Windows Live ID帳號有訂閱MSDN(例如BizSpark, MVP, 公司買的, 路上撿到的...etc)，那你用這個帳號登入之後，請進入MSDN訂閱網站，會看到底下畫面：

請點選其中的『啟用Windows Azure』，接著出現底下畫面：

立刻按下→鈕，進入下一步。

可能是因為我在申請該Live ID的時候，已經輸入過電話了(如果要進行電話驗證，請輸入你的手機，選擇簡訊驗證，會收到簡訊代碼，填入後即可)，所以跳過了第二步驟的電話驗證，直接進入第三步驟的信用卡驗證：

按下『下一步』，就完成了，會被直接導入到Azure站台：

您可以選擇『帳戶』：

會看到你的Azure訂閱帳戶，MSDN免費贈送的帳號有相當多的時數(1500hr/m)，足夠你建立一個具有Load Balance的中小型網站了。如果你怕不小心超過時數信用卡會被扣款，請不要開啟消費限制。

要開始上雲端了嗎，你只需要點選『管理』：

就可以進入後端管理站台了(新版Portal也開放囉)：

Enjoy it...