.NET Walker

最近，一本伴隨著許多技術人員從小看到大的資訊期刊決定併刊了，未來技術相關的主要內容將會調整為在線上以電子方式呈現。雖然這個改變不是很令人意外，但多少也讓我覺得有些感慨。 知道這個消息，是在我上個月旅遊的途中。本來打算回來寫篇文紀念一番，但是礙於許多原因，最後沒有提筆，現在寫在這裡，多少也是因為木已成舟，所以留個紀錄而已。 在旅途當中，我不只收到這個消息，另一件事情也讓我頗為感慨的，是一位出版界奮鬥已久、過去的合作夥伴，也在最近準備轉換戰場，我想多多少少，也都跟目前資訊出版市場的狀況有關。 這幾年的出版當然跟過去不可同日而語，就像這幾天看FaceBook中朋友們的留言，提到：『跑電腦現在需要換個場地跑，大家也知道現在 ​電腦不夯了，可能要跑平板之類的...』資訊技術是應用科學，內容隨著時間更迭並不新鮮稀奇，最近幾年的媒體和出版生態丕變，連報社都能一夕之間改弦易轍，或有換老闆經營者，更何況我們這個更加小眾市場的媒體呢? 過去一本資訊圖書的出版，可以帶領許多讀者踏入這個充滿願景的工作領域；或是幫助技術人員建構養成觀念；或是激發開發人員的創意。隨著這幾年網路的盛行、大陸同胞們在資訊技術上的崛起、資訊產品的生命週期縮短、全球化市場競爭的衝擊、技術從業人員的獲利能力也跟著降低。 一層層連鎖反應的影響，出版市場雖是衝擊的末端，但改變卻也來的快速而堅定。 當然，伴隨著資訊環境與電子產品的進步，開發技術的傳遞方式理所當然地也應該走向現今各樣的主流趨勢，以最短的時間將重點透過各樣的手持行動裝置與平台推送給大家，結合社群傳播的力量，以另一種面貌出現在讀者的面前。這個，似乎才是出版從業人員在感嘆之餘得要繼續深思而努力的方向...

用了WP7很長一段時間，隨著手機連續幾次的更新，整個WP7的表現越來越貼近甚至超越我的期待，也因此使用的時間越來越高。 WP7的手機在拍照或錄影之後，都可以隨時自動update到SkyDrive，這是一個相當方便的設計，對於慣於使用網路的用戶來說，相當的便利。 不過，總是有一些時候，我們希望把照片資料同步到PC上，這時候PC的Zune軟體就發揮了功能。但不知道從何時開始，我的 WP7接上Zune的時候，一直有一些問題無法同步，收到底下的錯誤訊息... c00d11e4 (800c000e) 一直不以為意，反正可以從網路上(SkyDrive)再抓下來，但今天心血來潮試著解決這個問題，後來上網搜尋，發現原因似乎是安裝了Ulead的軟體之後，會把底下機碼： HKEY_CLASSES_ROOT\.jpg 的default直改為 PV85.Image 導致無法Sync同步，重新改回jpegfile之後，我的Zune和WP7終於又可以順利地同步照片囉。 jpegfile

這次微軟算是卯上了全力。 最近在測試Mango新的SDK，說真的，有了中文輸入的手機，整個使用起來果真是脫胎換骨，感覺完全不同。再加上7.1增加的API, 讓整台手機如虎添翼。 例如，在API當中增加了BingMapsDirectionsTask，讓開發人員可以不費吹灰之力寫出導航的功能，底下這段影片展示了實際操作的過程，你會發現，導航功能很清楚的引導了使用者每一個轉折點的動向，除了對台灣人來說目前地圖是英文的有點遺憾之外，整個導航功能實在是相當完整了： 而這樣的導航程式要如何寫呢? 就底下這樣： //建立BingMapsDirectionsTask Microsoft.Phone.Tasks.BingMapsDirectionsTask dt = new Microsoft.Phone.Tasks.BingMapsDirectionsTask(); //設定起點(使用當前手機所在位置CurrentCO當作起始座標) dt.Start = new Microsoft.Phone.Tasks.LabeledMapLocation( "Start", CurrentCO); //取得使用者在ListBox中選擇的終點座標 aRock.Google.Location.GeoResult po = this.listBox1.SelectedItem as aRock.Google.Location.GeoResult; //設定終點 dt.End = new Microsoft.Phone.Tasks.LabeledMapLocation("Target", new GeoCoordinate(double.Parse(po.lat), double.Parse(po.lng))); //顯示導航畫面... dt.Show(); 開發人員只需要使用 BingMapsDirectionsTask , 傳入開始和結束的兩個座標點, 調用show()方法，一切搞定，任何人都可以寫出導航功能的手機電子地圖程式了。 而且，這只是WP7.1(Mango)當中的一個小功能，還有其他近千個新的API, 看了這些之後，是不是一掃過去您對Windows Phoen銷量的擔憂? 再加上中文輸入功能，接下來恐怕手機要奇貨可居了。 ...

本來最近實在很忙，沒啥時間測試新東西，況且 Windows Phone 7.1 SDK beta 根本才出來沒多久，beta2會有那些新功能? 不過今天剛好整理機器，想說順手安裝一下，不測還好，測了之後發現不寫一篇Blog紀念一下不行... 首先...Beta2的SDK中，模擬器整個變快了，比起beta時候的速度要快了不少，如果你在MS Developer Day 2011 中，曾經聽過我介紹 WP 7.1 SDK 的模擬器，當時的模擬器坦白說稍微慢了一點， 可能beta2當中做了一些優化，主觀上感覺快很多... 不過...更重要的來了...beta2模擬器中居然開始支援中文手寫輸入, 這讓您有機會一窺Mango中的中文手寫輸入風采...影片在底下...喜歡就按個讚吧~ WP7.1 SDK Beta2 下載位置 分享

在昨天的研討會中，Live Demo的部分，為了節省Key程式碼的時間，我把常用的WP7.1 API部分的功能整理成了Code Snippet(程式碼片段)，這是Visual Studio中非常貼心的設計，讓開發人員的創作速度大增，且相對提高了Coding的正確性。 研討會中Demo的WP7.1的CodeSnippet整理如下：[ 下載 ] 使用方法教學影片:

很感謝大家今天熱情參與微軟 Microsoft Developer Day 2011 ... 今天提到的Mango SDK可從 此處 下載。 今天的投影片可從 此處 下載。 相關的範例展示影片可參考 此頁面 。

如果你和我一樣，過去是寫了很多年的VB開發人員(雖然現在多半寫C#, 但我還是很熱愛VB)，你應該很熟悉兩個hot key, Shift-F2(跳入特定的Method), 以及Ctrl-Shift-F2(返回原位置)，這兩個Hot key對於程式開發的效率有著莫大的幫助。 到了C#開發環境，這兩個Hot-Key不見了，找了一陣子，終於發現這兩個HotKey分別是 Edit.GoToDefinition： 與View.NavigateBackward， 透過VS2010的Option->Environment->Keyboard就可以設定了。

由於最近我們公司，配合下半年度平板電腦的火熱上市，整個將透過Silverlight開發的產品或功能都一律加上Gesture的支援。這讓Silverlight所開發出來的App，跑在目前坊間的Win7平板上所呈現出的效果比起iPad或Android上的App一點都不遜色且有過之而無不及。 然而Silverlight 4不像WP7那麼好命，每一個ListBox或具有卷軸的控制項(例如ScrollViewer)都內建支援Gesture的功能，因此即便跑在平板電腦上，ListBox都需要用卷軸拖曳的方式來捲動，但明明Silverlight就支援Gesture，不能用手勢捲動ListItem似乎有些遜色。 因此我在網路上找到了這組好用的Behavoir... http://lighttouch.codeplex.com/ 下載之後，在你的專案中引用底下幾個.dll即可。 Wintellect.Touch.dll System.Windows.Interactivity.dll System.Windows.Input.Manipulations.dll 如果你想要將ListBox加上Gesture功能，只需要把ListBoxTouchScrollBehavior拖曳到ListBox上： 接著，幫ListBox設計一個ItemPanel，例如(關鍵在GestureListener)，完成後大致如下： 最後，幫ListBox的設計一個包含GestureListener Behavior的ItemTemplate即可： 你可以從底下這邊看到預覽的效果： blog.studyhost.com/BlogData/20110611/SilverlightApplication9TestPage.html   你會發現，如果你有支援Multi-Touch的顯示器或是Win7平板電腦，整個手勢拖曳的動作非常順暢，即便你沒有多點觸控設備，這個.dll也支援用滑鼠模擬Gesture，算是挺不錯的設計。 完整的範例程式碼可參考 這裡 。 分享

新的Mango，有許多好用的新功能，當然，承襲著Windows Phone 7獨樹一格的UI設計，動態磚早已深受好評，而Mango SDK中動態磚的控制功能當然就是開發人員期待已久的。 過去動態磚之所以這麼命名，就是因為他能動，但過去要能動，似乎要耍點特權，我們第三方應用程式，不僅動態磚非得配合Notification，而且還沒有那種很炫的動態效果，似乎有點差強人意。 在這個版本， 終於，我們可以寫出會動的方塊磚了，而且，還可以一次產生多個，我們甚至可以讓每一個動態磚，在被點選的時候帶入不同的參數到我們所撰寫的程式中： 怎麼做的呢? 主要的API在Microsoft.Phone.Shell命名空間，開發人員可以透過底下的程式碼來建立自己的方塊磚： //方塊磚資料 StandardTileData NewTileData = new StandardTileData { BackgroundImage = new Uri("/Images/People.png", UriKind.Relative), Title = "方塊磚", Count = int.Parse(textBox2.Text), BackTitle = "參數是" + this.textBox1.Text, BackContent = "方塊磚的背面", BackBackgroundImage = new Uri("/Images/PeopleSay.png", UriKind.Relative) }; // 建立方塊磚 ShellTile.Create(new Uri("/MainPage.xaml?TileID="+this.textBox1.Text, UriKind.Relative), NewTileData); 方塊磚依照Create()方...

故事是這樣的... 我們公司寫的Silverlight應用程式在正式上線後，客戶用得很開心，對於這個技術和開發人員的努力頗有好評，正當我們被客戶讚的輕飄飄，準備明天跟客戶端的老大demo的時候，前線傳來一個令人錯愕的消息... 用我們寫應用程式的電腦會當...在客戶端3台不同的電腦測試，就像機器得了機瘟一樣，早上還OK，突然間下午全當了，只要進入某一個畫面之後, IE就當給你看，Chrome也死給你看，FireFox就懶得測了。 Demo在即，碰到這種事情，非出面不可了...詭異的是，在家裡連到客戶端的網站，一切OK，我們公司沒有一台機器有問題，都算是很順，只好去客戶那邊看看。到了客戶端，正如客戶所說，沒有一台電腦能夠正常執行，而且客戶強調，早上還OK，就到下午，全不能動了...>_< 這...也太誇張了吧。 測試結果正如客戶所說，很清楚明顯的Run Silverlight的瀏覽器就是卡在那邊不動。 那...到底在run什麼呢? 看不太出來，因為我們知道程式碼只是call一個WCF Services，並且把一堆字串傳到用戶端。當然，我們懷疑過字串的大小，但經過測試，其實才幾十k，比圖片小多了。況且早上都還OK，怎麼下午就不能動了，碰到網路傳輸瓶頸也不會這樣才對。 更詭異的是，如果有資料傳輸的瓶頸，那為何在我們公司OK呢? CPU / RAM / GPU / intranet performance 都測過之後，突然間想到，似乎客戶端所有的PC都是XP，而我們公司所有的PC都是Win7... 果然，在客戶端換了Win7之後，一切正常，回公司換了XP之後，IE當掉。同樣的一段code，怎麼會這樣呢?到底是什麼code有這麼大的魔力...答案如下： if(arg.Result.IndexOf("Info")==0) return; arg.Result是一個string, 如果有經驗的Silverlight developer應該猜的到，這是WCF Services的回傳值，很單純，內容就是字串。 那為何會讓XP當掉呢?又為何Win7沒事呢...答案是...我也不知道...不過好在我不是第一個碰到這個問題的人...請參考底下... http://connect.microsoft.com/Visua...