Five Things to Know Before You Start Developing Windows 8 Metro Apps
May 15, 2012 7 Comments
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.
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.
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.