2012年6月28日 星期四

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

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


2012年6月26日 星期二

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

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

2012年6月25日 星期一

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

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

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

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

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

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

相關的說明與介紹,請參考底下影片:


2012年6月22日 星期五

從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 )的開發人員,比起傳統的開發人員來說,有著更廣泛的發展空間,對於未來的專業領域生涯規劃,也將有著相當大的可能性。

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

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

2012年6月20日 星期三

[研討會] 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, 請容我有空再改吧...)
  

2012年6月8日 星期五

如何啟動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...