Blog

Because it is possible to use the XNA libraries within a Silverlight project you can add audio recording in your application using the Microphone class found in the Microsoft.Xna.Framework.Audio namespace. You can test this on the Emulator as it will work with a microphone attached to the host PC.

First add a reference to Microsoft.Xna.Framework.dll to your project.

Next to make life easier add “using Microsoft.Xna.Framework.Audio;” to the top of your code file. You can access the Microphone through the static Microphone.Default property but for ease I created a local variable called m.

Next you need to decide what you are going to do with recorded audio. I built a simple audio memo application which stores the audio data in memory for instant playback. For simplicity I added MemoryStream to my app. I will write audio data to this and then I can easily get a byte array of the entire buffer to pass to the SoundEffect class to playback later. You could also write to a file in Isolated Storage or send to a web service…

In the constructor of my page I added an event handler for the BufferReady event of the Microphone. This is called each time the buffer is full and in the handler I copy the contents to the memory stream.

I created a Record button. I then set the BufferDuration on the Microphone object to 1 second (the maximum value), this is not strictly necessary as you’ll be copying data from the Microphone when it notifies you. Then I call Start to open the Microphone and start recording. Each time the buffer fills it is copied to the memorystream. When a Stop button is pressed I called Stop() on the Microphone to stop recording. Afterwards the MemoryStream is closed and we can now access the underlying buffer for playback.

A third button, you guess it “Play”, uses the SoundEffect class to play back the contents of the buffer. Into the constructor I pass the .ToArray() method of the MemoryStream, the SampleRate from the Microphone and AudioChannels.Mono since we know this is a mono source. You can then either call Play() or if you want to muck about with the sound you can use the overload which accepts volume, pitch and pan values. For example se.Play(0.7f, 0.5f, -1.0f) plays the sound at 70% volume, with pitch raised half an octave and through the left channel. Unless the user is wearing a stereo headset the panning will probably be lost on them. By playing with the pitch property (-1 – one octave lower through to +1 – one octave higher) you can probably find your perfect balance between Brian Blessed and Joe Pasquale…

As Rob Miles noted in his blog there seems to be an issue with pitch values > 0.6 in the current release.

The emulator for Windows Phone 7 includes Internet Explorer so you can test your websites now to see how they are rendered on this device. The emulator gives you a lifesize rendition of the device screen so you can format your pages appropriately. To customise your site for this new device you’ll need to identify it when it hits your server so here are the key facts:-

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone OS 7.0; Trident/3.1; IEMobile/7.0)

I’ve highlighted the items which indicate the platform and the browser. The browser also sends the UA-pixels header which describes the screen. On the emulator this is 480×800 (regardless of the screen orientation in use at the time) and it has been announced that there will also be devices using 320×480 (HVGA)

The Software Input Panel in Windows Phone 7 is entirely new. Unlike previous versions there will be a single SIP provider and device manufacturers will not be able to customise it. This means you can guarantee the same experience across different device types. With Windows Mobile there were some big differences between the input models of Standard Edition (Smartphone) and Professional Edition (Pocket PC) device types. We had the ability on Professional Edition devices to show or hide the sip and select from available input panels but no further control to customise the panel based on the input type required. For example to get a numerical keypad often required faking a screen press to “shift” the keyboard (unless your device had a specific keypad input panel).

Windows Phone 7 has a standard input panel but it does support different input contexts and will adjust accordingly. So if you mark a TextBox as requiring a Phone Number you’ll get a big numerical keypad. There are a number of different contexts supported, the UI guidelines document describes them but has some errors as the names do not match those you’ll see in Visual Studio and there are no examples of how to set them. I’ve tested a number of different InputScopeName values and have listed those below with a description of their behaviour (this effectively replaces the table on page 20 of the UI guidelines).

Along with these contexts there are others defined, most of which are the same or variations of the above. For example there are a number of numerical inputs such as CurrencyWithSymbol which has the QWERTY keyboard shifted to show numerals with common currency symbols (Dollar, Pound, Euro and Yen). All the ones I tried worked except for Xml which threw an unhandled exception. You can set the context easily in your XAML:-

Windows Phone 7 supports two basic themes each with four highlight colours. This gives the system eight possible colour-schemes. If you look at the templates supplied with the current CTP development tools you’ll see that a selection of Colours and Brushes are hard-coded into your App.xaml. This means that even if you change the system theme your app will not follow suit. You may want to test how you application works with both Light (Black text on White background) and Dark (White text on Black background) themes so here is a little trick to help out.

First I am assuming you have an application based on the WindowsPhoneListApplication template (this should hold true for the other template). You need to make a couple of changes to the list template to remove hard-coded values:-

Here you can see we set the BorderBrush of the DataTemplateBorder and the Fill of the DataTemplatePath to the static resource rather than “White”. The simplest way to override the hard coded brush resources from a single location programmatically is to add the following lines in your App.xaml.cs file:-

You can see here the only colour we have changed is foreground as the background seems to react to the system setting. Interestingly in the Dark theme the background is not black but a very dark grey, I haven’t found any explanation for this. Running the application now presents the application correctly using the Light theme, but of course the original Dark theme is broken because the text is now Black on Grey. Using knowledge of WPF I thought we should be able to use a member of the SystemColors class in System.Windows. However I quickly found that these are not implemented and all return RGB values equal to Black. There is also no system event to capture if the theme is changed. If we go to the Start menu while the application is running, access settings and change the Theme, when we return to our application it won’t have updated. Based on all the discussions of multi-tasking support I’m not sure if this scenario will be supported as it seems we will be expected to save state and exit when switching out to another application. This is not the case in the current CTP. At the moment it looks like we’ll just have to wait and see how this takes shape. Ideally the default templates will inherit the system theme with no need for extra coding so we only need to modify our app.xaml etc if we want to override the colours in our application. Some of the “hubs” which have been demonstrated use photographic backgrounds and I don’t think any of the released images show separate Light/Dark behaviour for them…

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.

Location

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).

Device Hardware

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.

Tasks

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

Tiles

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.

System Status

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…

I’ve already had a couple of questions about how to develop applications for Windows Phone 7. At the moment the “developer story” has not been announced but over on the Windows Mobile Developer Blog they have announced that MIX10 will be where they discuss how to develop for Windows Phone 7:-

http://windowsteamblog.com/blogs/wmdev/archive/2010/02/15/windows-phone-7-series-going-big-for-developers-at-mix10.aspx

Attendees will have access to a dedicated Windows Phone track (currently the 12 sessions are unnamed) and access to the Windows Phone 7 developer tools:-

http://live.visitmix.com/News/Exclusive-Windows-Phone-7-Series-Offer-for-MIX10-Attendees-WP7