The only way to build a mobile tablet app for all versions of Windows 8 will be to use the new Metro application framework, and it’s much different than previous Microsoft platforms. Developing Metro apps for Windows 8 is a combination of leveraging your existing skill sets and learning concepts that are new to the platform.
Following are five things that make developing Metro apps new and different. Food for thought as you dive into new waters and create the next great app that will earn you fame and fortune:
1. Programming language now determines your presentation layer
Previously Windows developers could choose a programming language like C# or VB, and separately choose a presentation layer like WinForms or DirectX.
When developing Metro apps, if you choose C#, VB, or C++ you automatically buy in to XAML as the presentation layer. If you choose Javascript, your destiny is tied to HTML5 and CSS3. There is no mixing of C# and HTML5, and no mixing of Javascript and XAML.
This coupling of language and presentation increases the importance of making the right language decision for your project. Deciding which is better largely depends on what the priority is for your project.
Javascript and HTML5 are a great investment when you want to build skills that can be reused on widely diverse projects. For example Javascript can be used to build Metro apps, HTML pages, native apps for all mobile devices, and even server side systems like NodeJS.
C# and XAML have the advantage of a large number of developers already being experienced with the technology. My sense is that with respect to a Microsoft platform like Metro, more developers know how to animate with XAML than with CSS3. Not having to relearn the basics on a project with a tight schedule can be a lifesaver.
Choose your language strategically based on existing skill sets and what future projects you want to be ready for.
2. NoSQL has a new meaning
Metro apps are unique in that they do not have easy access to a SQL based relational data store. Most existing Microsoft platforms can directly use some flavor of SQL Server such as Express, Compact, or CE, but this is currently not the case in the Metro sandbox.
Even if you downloaded and integrated an open source database like SQLite, there may be problems getting your app approved because of security requirements. Most databases have not yet been designed to run within sandboxed environments.
So how do you manage data in a Metro app? Of course data can be written to the file system and manually managed, and there is also an interface to an ISAM data store (ESE, Jet Blue). However probably the most common approach will be to use one of the semi-structured data storage mechanisms.
Metro apps have access to IE10 local storage technologies such as IndexedDB, which is an emerging standard. It is also very simple to use a cookie style local storage mechanism for key-value pairs. Finally, it’s still possible to call web services that make use of SQL on a separate server, but that doesn’t help with local data storage.
So all is not lost, but this is definitely a different world for developers, plan your data management accordingly.
3. Background tasks work differently
Running code in the background has always had rules. One rule that has always been intuitive to most developers is that once you start a background process it will continue to run until you stop it. This is no longer true.
With Metro, apps that are in the background do not automatically continue to run. Instead they are suspended until the user brings them to the foreground. By default only the foreground Metro app will be running and taking CPU resources at any given time. This is not a limitation; it’s by design and is a new model for app behavior on Windows. The idea is to maximize responsiveness for the user, and to conserve resources for mobile devices.
If this all sounds familiar it’s very similar to the way iOS works. When Apple added multitasking to the iPhone, it only allowed for background tasks to run in very specific scenarios, and so it is with Metro apps on Windows 8. Metro apps can request to run in the background for audio playback, data transfer, and notifications.
This new model is primarily motivated by mobile scenarios, however it is also the model for Metro apps on the desktop.
4. Don’t expect to have all of .NET’s functionality
We’ve come to rely on the greatness of .NET, but in Windows 7 the .NET framework was built using the entire Win32 API. With Metro, everything is built (including .NET libraries) on the new WinRT API. The bottom line is that .NET functionality for Metro will be a subset of all that is available with the full framework.
For example, is WCF supported for Metro apps? Yes and no. The core client scenarios all work, but the WS* specifications like WS-Security are not supported. The MTOM binary attachment encoding is not supported.
The good news is Microsoft has chosen the subsets carefully to maximize what is possible. It’s just a good idea to double check what’s supported if you have specific needs.
5. The new UX is not just new controls
Previously new versions of Windows added new controls (widgets), but the core idioms stayed the same. Windows 1.0 (released in 1985) and Windows 7 both have menu bars, captions, and resizable app windows. Windows 8 Metro apps have none of these. Even the Metro-ish UX on Windows Phone 7 is different, it has things like the panorama control while Windows 8 does not. Our cheese has been moved.
Because of this our job description now includes learning about the new UX idioms in Metro so that we can know when they make sense for our apps. Some of these include the AppBar, Semantic Zoom, Partial Page Docking, and Charms. There is a dedicated MSDN area that covers all of these here.
You probably don’t need all of these new features in your first Metro app. However if you don’t take advantage of the ones that are appropriate it could make for a less than perfect fit with Windows 8.
Onward and upward
Windows 8 is not just about technology changes for change sake. All of the items above are part of a bigger picture to enable better apps and faster development. Visual Studio 11 is the primary tooling for Metro development, and fortunately it retains the title as the best development platform on the planet. Overall Metro is calling us to create the next killer Mobile apps.
---------------------------------------------------------------------------------
目前開發Windows 8平板電腦的移動應用程序只有一條途徑，那就是使用新的Metro應用程序框架，這是一個嶄新的事物，與之前的Microsoft開發平台相比有很大的不同。 為Windows 8開發Metro應用程序需要利用你已掌握的技能，但更需要學習新的平台概念。
以下的5件事，是你在開發Metro應用程序之前必須要了解的，是你深入到新的水域創造讓你名利雙收的第一個偉大的應用程序的精神食糧：
1、現在編程語言將決定你的表示層技術
在此之前，Windows開發人員可以首先選擇一種編程語言（如C＃或VB）然後再選擇一種表示層技術（如WinForms或DirectX）等。
然而開發Metro應用程序時，如果你選擇的是C＃、VB或C ++，系統會自動選用XAML作為表現層。 如果你選擇使用Javascript，你的命運將與HTML5和CSS3聯繫在一起。 不可能將C＃和HTML5混合使用，也不可能將JavaScript和XAML混在一起。
這種編程語言和表示層技術的耦合增加了為你的項目選擇正確編程語言的重要性。 該選用哪個語言很大程度上取決於你的項目優先考慮什麼。
當你想創建可用於多種情景、適用範圍廣的項目時，學習Javascript和HTML5是一個非常值得的投資。 例如JavaScript可被用來構建Metro應用程序、HTML頁面、所有的移動設備的本地應用，甚至是服務器端應用（如NodeJS）。
C＃和XAML的優勢在於，大量的程序員已經非常熟悉這些技術。 我的感覺是，在類似於Metro的微軟平台上，為了在項目開工前減少學習基礎知識的時間，越來越多的開發人員將會掌握如何使用XAML來做動畫，而不是CSS3。
選擇你的編程語言的戰略應當基於你現有的技能和你對未來項目的期待。
2.NoSQL被賦予了新的含義
Metro應用程序的一個獨特之處在於它們不能夠很方便地訪問基於SQL的關係型數據存儲。 而現有的Microsoft平台上可以方便地直接訪問關係型數據庫，如SQL Server Express、Compact或CE版本，但目前在Metro沙盒中不是這種情況。
即使你下載並集成了一個開源的SQLite的數據庫，情況也沒有改善。 你的應用程序可能由於安全性問題而無法通過（Windows應用商店）的發布審批。 大多數數據庫系統目前還無法在Metro沙盒環境中運行。
那麼，你如何管理在Metro應用程序的數據？ 當然你可以將數據寫入到文件系統手動管理，或是使用目前可用的ISAM數據存儲接口（ESE，Jet Blue）。 然而，最實用的方法可能是使用一種半結構化（semi-structured）的數據存儲機制。
Metro應用程序可以訪問IE10的本地存儲技術，如索引型數據庫（IndexedDB），這是一個新興的標準。 這是一種簡單的本地存儲機制，它使用“鍵/值”這種類似cookie的技術訪問數據。 當然，你可以調用一個遠程服務器上Web服務來實現SQL的功能，但這解決不了本地存儲的問題。
雖然你仍然能夠解決問題，但對於程序員來說，如何規劃數據管理絕對是一個不同的事情。
3、後台任務的工作方式不同
在後台運行代碼一直以來是存在規則的。 而大多數開發人員的直覺是，一旦你啟動一個後台進程，那麼它將繼續運行，直到你結束它。 在Windows 8 中，這種直覺不再是真實的。
在Metro中，在後台的應用程序不再自動持續地運行。 相反，在用戶把它們帶到前台之前，它們將一直處於掛起狀態。 默認情況下，只有前台Metro應用程序才能夠在任意時間使用CPU資源。 這並不是一種倒退，而是一種新的Windows應用程序的行為模式。 這種設計是為了最大程度地提高用戶的響應，並為移動設備節約資源。
這些聽起來很熟悉，因為它非常類似iOS的工作方式。 當蘋果公司在iPhone中添加了多任務支持時，它僅允許在非常特殊的情況下運行後台任務，在Windows 8中的Metro應用程序也是如此。 Metro應用程序僅可以申請在後台播放音頻、數據傳輸以及發送通知的權限。
這種新的模式主要是由於移動應用的場景，但它同時也是Metro桌面應用程序的模型。
4、不要指望能夠使用.NET的所有功能
我們已經越來越依賴“偉大”的.NET所提供的功能，但在Windows 7中，.NET框架是在Win32 API的基礎上構建的。 在Metro下，一切（包括.NET庫）都在新的WinRT API基礎上構建。 這裡.NET功能僅僅是Metro完整框架的一個子集。
舉例來說，WCF支持Metro應用程序嗎？ 是，也不是。 核心客戶端方案均支持，但WS系列規範，如WS-Security不被支持。 MTOM二進製附件編碼不被支持。
好消息是，微軟在選擇功能子集時，仔細考慮瞭如何最大限度發揮其作用。 一個實用的建議是，在你選用功能模塊之前，仔細檢查它們都支持哪些功能。
5、新的用戶體驗不止是新的控件（那麼簡單）
此前新版本的Windows中添加了一些新的控件（如窗口小部件），但其核心的使用習慣沒有變化。 （在1985年發布）的Windows 1.0和Windows 7都具有菜單欄、標題欄和可調整大小的應用程序窗口。 而Windows 8的Metro應用程序沒有這些東西。 即使是在類似Metro風格用戶體驗的Windows Phone 7上也不一樣，它類似全景控件（panorama control）的東西Windows 8沒有。 我們（所習慣口味）的奶酪已不再有了。
正因如此，我們的工作將包括學習新的Metro用戶使用習慣，這樣我們才能知道他們對我們應用程序的感受。 這包括應用條（AppBar），語義放大（Semantic Zoom），半屏對接（Partial Page Docking）以及其它Windows 8獨有的魅力。 MSDN社區中有一個獨立的區域，涵蓋了所有這些內容。
在你的第一個Metro應用程序中，你可能並不需要所有的這些新的功能特性。 但是，如果你不適當的利用這些優勢，你可能無法設計出一個完美的Windows 8應用程序。
Onward and upward
Windows 8的確不單純是技術的更新。 上述的每一條，都是讓應用程序更好更快的宏偉藍圖的一部分。 Visual Studio 11是開發Metro應用的主要工具，幸運的是，它仍然沿用了這個地球上最佳開發工具的名號。 總的來講，Metro正在召喚我們去創造下一個殺手級移動應用
