We have heard over the last couple of days how the Silverlight development model in Windows Phone 7 means that all developers are now mobile developers. However what does the platform offer beyond the standard Silverlight classes and functionality. Where possible I’ll try to compare this with the .NETCF Windows Mobile approach where applicable.
Windows Phone 7 inherits the System.Device.Location namespace introduced in .NET 4.0. On a desktop machine this supports the new location API in Windows 7 (these classes are non-functional on older versions of Windows). This provides a single location API which can wrap the GPS, WiFi and cell-triangulation support of the phone. The API is incredibly simple to get started with and it is good to see that there is consistency with the full framework object-model. As a side note yesterday we released a new version of Mobile In The Hand (4.1) which adds InTheHand.Device.Location.dll. This exposes the exact same object model as .NET 4.0 and currently works on all devices which expose the GPS Intermediate Driver (Windows Mobile 5.0 and later and Windows Embedded CE 6.0).
Windows Phone 7 devices must support a standard range of features which were previously optional, for example an Accelerometer. There is now a standard API to access this from your code in the Microsoft.Devices.Sensors.dll. There is no direct equivalent in the .NETCF world as previously these APIs if available were specific to the hardware vendor. There is a Codeplex project which attempts to provide a unified API over these device specific sensors and that goes beyond just the accelerometer. On the new Windows Phone documentation published to MSDN it looks like the sensor support will improve before release “A variety of sensors will return data that can be consumed by developers. For example, multi-touch input, accelerometer, and microphone sensors will all be accessible by APIs.”
For user feedback Windows Phone 7 devices include vibration, it appears that the device spec doesn’t allow for notification LEDs at all. The Microsoft.Devices.dll contains the VibrateController class which allows simple on/off control of vibration up to a maximum of 5 seconds at a time. There is no equivalent .NETCF functionality although it was possible to P/Invoke either the Vibrate or LED APIs depending on whether the device was Standard or Professional Edition. Mobile In The Hand has offered the InTheHand.WindowsMobile.Forms.Vibrate class for the past couple of versions and it has a similar object model. Your application cannot intercept or override the hardware buttons on the device which include power button, volume, camera and the standard three buttons on the front of the device (Back, Home and Search). You can reference the Xna assemblies from a Silverlight project in order to take advantage of Microphone input and SoundEffect output.
There are very few hooks to allow your application to integrate with the built in applications. Windows Phone offers a number of tasks – reusable components which kick off specific actions on the phone. These are a bit like common dialogs in the traditional .NET world. Currently all that I have tried in the emulator fail with a COMException, however here is the list of these exposed from Microsoft.Phone.Tasks.dll
|Class Name||Windows Mobile Equivalent|
The old Home Screen and Today Screen models of Windows Mobile Standard and Professional editions are completely replaced. The new shell allows you to create tiles which effectively fill their place. These support not just a method to launch your application but also a method to show status updates (obvious examples are number of messages, missed phone calls etc). The current SDK doesn’t seem to expose this yet. There is a Microsoft.Phone.Shell.ShellEntryPoint class which the documentation indicates is used for this purpose but no details on its usage.
What appears to be missing entirely (at this point anyway) is some equivalent to the excellent State and Notifications Broker in Windows Mobile. That provides easy access to numerous system properties – Battery, Network connectivity etc with change notifications. There is a certain assumption with Silverlight applications that power is never an issue and you have permanent fast network connectivity (how else did you get to the website hosting a silverlight application). A well designed mobile application will have to behave well under a variety of conditions and perform a certain level of local caching of data rather than just being reliant on a web service to pull back live data. There is no System.Data namespace and no SQL CE database engine to program against so you will be responsible for serializing and deserializing your own data into isolated storage.
To Be Continued
Like most people I’ve only had a day or so to play around with the Windows Phone 7 tools and as noted above there are some gaps in the current CTP release. I’ll be adding more Windows Phone 7 posts over the next few months…