Application developers start your engines: Microsoft's Windows Phone 7 is finally on its way. Apps for the new platform can be based on Silverlight and work like classic event-driven Windows applications, or they can be based on XNA and behave like a classic XBox game.
Each app will run in its own sandbox and interact with users through sensors such as the camera, microphone, accelerometer, and multitouch. They'll interact with the outside world via geolocation and notification services, cloud services, and custom Web services.
The layout of a Phone 7 app is based on XAML markup that you create using Visual Studio or Expression Blend. The functionality of a Phone 7 application results from the combination of Silverlight native components and Phone 7-specific components and “launchers” and “choosers” to access contacts, place phone calls, send email and text messages, and launch the built-in media player, Web browser, or search application.
Beneath the specific capabilities of the Phone 7 and Silverlight frameworks, you'll find a subset of the .NET Framework that supports threading, LINQ, text, networking, XML, configuration, security, and reflection. You interact with native Windows Phone 7 applications using either a launcher or chooser task.
A launcher is a fire-and-forget command that the custom application sends to the system. Typical examples: placing a phone call, sending an email, and shooting a picture.
A chooser is a step in which the custom application visually interacts with a native app. Selecting a picture and displaying a Web page are examples. Invoking a launcher or a chooser deactivates your application, and tombstoning — the process where an app is terminated when the user navigates away from it — must be used to preserve state (see informationweek.com/1286/silverlight).
When it comes to tombstoning, Phone 7 lets only one application at a time take full control of the device. To preserve battery life and avoid serious performance hits, custom apps aren't allowed to stay loaded and run in the background. As soon as the user starts a new app, the current one is suspended and added to the journal of applications and pages accessible via the Back button. The application receives proper notification when it's deactivated and activated. It's the developer's responsibility to preserve any useful data when an app is suspended.
Phone 7 offers an in-memory state dictionary that will be automatically restored when an application resumes execution. This dictionary is ideal for retaining transient data. Its content, though, gets lost if the system terminates the app or if the user restarts it. For any persistent state your application may have, you must use isolated storage.
Phone 7 applications must be published to the Windows Phone Marketplace for users to buy and download them. Developers also can install a limited number of applications on a registered device directly using Visual Studio Express for Windows Phone. In January 2011, though, so there may be updates to this aspect of development.
If you're coming from .NET, Phone 7 development isn't hard but requires a strong commitment. If you're new to .NET, my gut feeling is that the learning curve is no steeper than with other mobile platforms. But the success of a mobile platform doesn't come from ease of development; it can only be achieved with appealing devices, nice applications, and rich content.