Blankenblog windows development and other geekery

31 Days of Mango | Day #31: Promoting Your App

This article is Day #31 in a series called 31 Days of Mango.

Getting users to find your application might seem like something that’s out of your hands, but you’re wrong. There are plenty of things you can do to drive awareness of your application. This section focuses on a few best practices you should utilize for every application that you create.

The First Week Is Vital

Unless your app becomes a runaway sensation, it’s highly likely that your app’s first week in the marketplace will also see your highest number of daily downloads. Getting exposure in the New category is a one time opportunity, and you need to make sure that you leverage this in a way that will make your app shine for much longer than a few days. Ultimately, your goal is to catapault from the New category to the Top Apps category. The 4-5 days that you will wait for your application to be approved should be spent executing a specific strategy for making the public aware of your application.

Linking To Your Application

When you first submit your application to the Marketplace, even before the app is approved, you are assigned a deep link that you can use to direct people to your app using a standard web URL. Here’s an example of the deep link to one of my applications, MathMaster:

http://windowsphone.com/s?appid=f08521cd-1cff-df11-9264-00237de2db9e

This link takes you to a webpage that will attempt to launch the Zune software on the user’s machine, and then direct them to the page for your app in the Marketplace. This link will not work until your application is approved. We recommend using this link everywhere you can, especially on the custom website you created for your apps. You were planning on doing that, right?

Creating a Web Portal for Your Apps

An important thing that you should have learned from the Marketplace walkthrough in Day #27 of the original 31 Days of Windows Phone was that your ability to discuss your apps is pretty limited. A few screenshots, and approximately 2,000 characters is all you have. By creating a website for your applications, you create several new opportunities for yourself.

1. You can create real connections with your users. The Windows Phone marketplace doesn’t give you any indication who your users are. A website allows you to interact with your fans.

2. You can provide a rich amount of information about your app, including videos and other promotional content that might make your app more appealing.

3. You can cross-sell your applications. The Marketplace doesn’t always do a great job at promoting your other applications to potential customers, so leverage your website to make that happen.

4. Your app is now discoverable by people that aren’t actively looking for it in the Marketplace.

5. This website doesn’t have to be a website at all. There’s nothing wrong with creating a page on Facebook or another social network that you can customize. The ultimate goal of this process is to provide a destination for your fans, so that they can spread the word about your awesome app.

If you would like an awesome template for building a custom web page for your application, check out the Windows Phone 7 App Site template on CodePlex.  It’s a customizable page that looks great, uses your application screen shots, allows your users to provide feedback, and gives them plenty of ways to learn more about your application.  Here’s a screenshot of the template:

Create A Walkthrough Video of Your App

One of the important features your website should include is a video walkthrough of your app. Screenshots in the marketplace are good, but allowing a user to see the actual experience in a controlled way will always provide them with more information. Our recommendation is to use a video screen capture tool like TechSmith’s Camtasia. Camtasia makes it easy to not only capture the video feed from the emulator, but to edit the results, add background music, and introduction information before and after the video. There are probably plenty of tools that will do this for you, but in our experience, Camtasia is the perfect tool for the job. You can see an example of my MathMaster video on YouTube here:

http://youtu.be/uMlyUn3sgJU

Have fun with it. Your video can add a level of excitement to your app that screenshots can never provide. Now that we’ve focused on websites and videos, let’s discuss the things you can do inside your application to help promote it.

Generating Reviews of Your Application

Reviews can be the deciding factor as to whether or not your application gets the downloads you’re looking for. Unfortunately, there’s not a built-in mechanism for reminding users to review your app. You need to do this yourself. We recommend making it a fun addition to your application rather than an annoyance to your user.

One idea we recommend is to make it an achievement within your app. Litter fun little surprises throughout your application, and you’ll hook an otherwise passive user. Give points for reading the credits of the app. Give more for using the app 10 times. By adding achievements to any application, you’ll find that your users will find themselves coming back again and again. You might also unlock a specific piece of functionality that would otherwise be unavailable when they review your app.

A second idea is to count the number of times your user has launched your application, and prompt them at the 2^nd, 5^th, and 10^th times to review your application. Ask gently. You don’t want to annoy the user, but you do want their review. You can even use the MarketplaceReviewTask to take them directly to the review page for your application.

Great reviews generate more traffic. Oftentimes, a star review can be just as valuable as a written one. The average star rating (1-5) is displayed everywhere your application is, so a high rating often generates more traffic. Encouraging your users to leave a review will have a positive effect on your application’s download rates.

Cross-Selling Your Applications from Each Other

Within your app, you should provide a place where the user can find information about your company, support contacts, and other data like version number. In this place, or certainly in a more prominent location, you have an opportunity to promote the other applications you’ve created. Use your icons. Use the deep links or the MarketplaceDetailTask launcher. Provide a simple way for your user to find and download your other application offerings.

If you really want to get fancy, create an XML file on your webserver that contains all of the information about your apps, and consume this in your apps to create the list of your applications. This way, when you add a new app to your catalog, you won’t have to update all of your apps just to do this cross-promotion.

Summary

There are plenty of things you need to do in order to get your application ready, after you’ve finished your application. Make sure that you’ve considered your promotion strategy before you push the final Submit button on your app. Building a community around your application will only help to make your audience grow, because enthusiastic users are also powerful evangelists of your efforts.

If you’ve taken the time to create an amazing new application for Windows Phone, you need to be certain that it’s going to have the potential impact you’re hoping for. Focusing on monetizing, promotion, and reviews is almost as important your app.

This is the final post in this series.  I hope you’ve enjoyed it as much as my guest authors and I did writing it.  Thank you for reading all of the posts, and if you haven’t already…

31 Days of Mango | Day #30: Local Database

This article is Day #30 in a series called 31 Days of Mango, and was written by guest author Chris Woodruff.  Chris can be reached on Twitter at @cwoodruff.

What is a Local Database?

In the original version of Windows Phone 7, we could save data but it took either custom code or using third party databases like SterlingDB to have the relational data repository that some applications need. This limited the types of applications some developers could produce for users.

In Windows Phone 7 Mango, developers still have isolated storage to keep data and information stored for their applications but now have SQL CE as a relational storage feature to created even better applications for Windows Phone.

Like other database solutions for the original Windows Phone 7, the native SQL CE database built into Mango has it data stored in the device’s Isolated Storage. You can learn more about Isolated Storage here. Microsoft also did not create new ways to work with the data on the phone and instead implemented LINQ to SQL for all database operations. LINQ to SQL is used to do all functions for the application when dealing with data including creating the data, populating data into the database, getting data and finally saving and deleting data.

A good tutorial for LINQ to SQL is here on MSDN.

Setting up a Local Database for your Mango Application

Like all starting points for Windows Phone 7, we will start with creating the Windows Phone Databound Application project within Visual Studio 2010.

We could have started with just the Windows Phone Application project but I like the additional features that the Databound project gives you to allow your application to have better design patterns like Model-View-ViewModel (MVVM).

Next we will update the MainPage of the project to allow for the data to be added to the database. Our data example will be collecting ideas that we all have and need to remember. We will not go into much detail about the design of the MainPage but here is the XAML to get the look and feel for our Idea collector.

Also to allow for your application to compile and run without doing anything the code below will be added to the MainPage.xaml.cs file inside the MainPage class implementation and after the constructor.

Working with the Data Context

The Data Context is the point that will allow us to work with the database and also the proxy classes that represent our database tables. The data context is also a class and works against a number of “plain old CLR object” (POCO) classes that we will create for this project. The table objects that represent our database tables will contain a collection of entities for each table record stored in the database. Other details about our database are also given to us through the data context such as table keys and association mappings between tables.

Just a reminder that this local database has no connection with SQL Server 2008 R2 that is running locally on your PC or a server in your company or hosting provider and is only to hold data on your device.

There is not much to the DataContext class besides the connection string we are familiar in development and properties to each table that will exist in our database. Think of the DataContext as the “Hub” for your application’s data. The code for the sample application’s DataContext is below.

Note that IdeaItem type will be detailed in the next section covering creating the Database.

Creating the Database

Unlike applications that are run from your PC or on IIS 7, databases in Windows Phone 7 Mango must be created and initialized on the first instance your app runs on the phone. We will first look at creating the classes that will represent our database tables and then look at database initialization.

For each table that we need to be built and exposed through the database on our phone for the application a new POCO needs to be created. Since these classes represent the entities that will be stored in the database let’s call them Entity classes. To begin the Entity class must adhere to the following two interfaces:

· INotifyPropertyChanged -- The INotifyPropertyChanged interface is used to notify clients, typically binding clients that a property value has changed.

· INotifyPropertyChanging -- The INotifyPropertyChanging interface is used to notify clients, typically binding clients that a property value is changing.

These two interfaces will allow each entity to notify the DataContext that is in the process of changing or has changed. This will then be reflected to the XAML views of our application through the binding we have set up.

The Enity class must be annotated as a Table to allow the DataContext to know how to work with it. An Entity classes must also have private and public properties for each Entity property as well as having the private property annotated to give valuable metadata about the Entity property (aka the database column). Remember to have primary key properties for each of your Entity classes.

Below is the IdeaItem Entity class that will be located in the IdeaItems table referenced in the DataContext we created before.

Finally we must create the database is it does not exist. This will be done in the Application class’s constructor. You will find this in the App.xaml.cs file. The code that will be added to the end of the constructor method is as followed.

We now have a database that has been created and initialized in application’s Isolated Storage. One more thing to remember is that local databases in Windows Phone 7 mango cannot be shared directly between apps on the phone due to the sandboxing security set up in the Windows Phone 7 Mango operating system.

LINQ to SQL Support for Windows Phone Mango

Windows Phone 7.1 SDK allows for some but not all features of LINQ to SQL inside the Windows Phone. The following are just a few things to remember when working with data and LINQ to SQL in Windows Phone 7 Mango.

· ExecuteCommand is not supported

· ADO.NET Objects (such as DataReader) are not supported

· Only Microsoft SQL Server Compact Edition (SQL CE) data types are supported

To get more limitations and features of using LINQ to SQL on Mango please read the MSDN page here.

Retrieving Data from a Local Database

To retrieve data or any data related work with the local database, we must first create the DataContext and connect to the database. This will happen in MainPage.xaml.cs through a private variable for the DataContext, an observable collection property for the ideas in the database table and in the MainPage constructor as followed.

To get our ideas located in the local database we will use LINQ to SQL to query and get the collection back from the database via the DataContext.

The ideas are now bound and reflected in the MainPage.xaml.

Storing Data to a Local Database

Finally we will build the saving of our idea data to the local database. We will not send the ideas to the database until we need to increase performance. We will keep all of the ideas in the local observable collection we created as a MainPage property (IdeaItems). The addition of new ideas to the local database will take place on the button click when the new idea is added to the IdeaItems collection.

As mentioned before the ideas collected from the user will not be stored in the database until the application has transitioned from the MainPage either when the user exits the application or the application moves to a new page in the application. The code for the OnNavigateFrom event for the MainPage is below.

Summary

So that’s pretty much it!  You now have a simple way to create, store, and retrieve relational data in your Windows Phone applications.  How are you going to use this?

To download a full Windows Phone project that includes all of the code and concepts from this article, click the Download Code button below.

Tomorrow, in the final article of this series, we will cover the best practices for promoting your Windows Phone applications.  See you then!

31 Days of Mango | Day #29: Globalization

This article is Day #29 in a series called 31 Days of Mango, and was written by guest author Matt Eland.  Matt can be reached on Twitter at @integerman.

Globalization versus Localization

People often get confused when discussing globalization and localization. Both deal with presenting content in a user-friendly manner across the world, but the distinction is that globalization deals with formatting elements such as times, dates, currencies and numbers in the way that the user is familiar with whereas localization involves displaying the user’s native language in the user interface. This article will cover using both techniques to build applications that can reach a large audience in the most user-friendly way possible.

We will be building a simple application over the course of this article that supports both globalization and localization. This application quickly generates an e-mail message that lets a contact know you’re running late to an appointment.

Configuring Localization Support

After creating a new C# Windows Phone project, we’ll need to do a few things to configure the application to support localization.

Defining a neutral language for the assembly

Because we’re localizing our application, we need to tell the project what the default locale is. To do this, we’ll go into the properties dialog for the project and click on “Assembly Information…” and then specify the neutral language for our assembly – that is, the language that will be used if no locale-specific resources are defined that matches the user’s locale. For this example, we’ll set our neutral language to English (United States).

Indicating supported culture

Next we need to tell the project what languages are supported. Visual Studio doesn’t currently expose this part of the project information, but we can easily edit it. Make sure you save all changes so any changes to the .csproj file are saved to disk before we edit the file. Next go to the project’s folder on the disk drive by right clicking on the project and selecting “Open folder in Windows Explorer”. Select the .csproj file for your application (be careful not to select the .csproj.user file) and open it with Notepad or your favorite text editor.

Look for the <SupportedCultures></SupportedCultures> element and add the culture codes of the cultures you wish to support separating each culture with a semicolon. This list should not include the neutral language of the assembly. See http://msdn.microsoft.com/en-us/library/hh202918(v=VS.92).aspx for a list of cultures supported by various versions of Windows Phone. For the purposes of this example, we’ll be supporting Spanish, simplified Chinese and French in addition to the default culture of English (United States) so our SupportedCultures node looks like:

<SupportedCultures>es-ES;zh-CN;fr-FR</SupportedCultures>

After making your changes, save the .csproj file and go back to Visual Studio. Click reload when Visual Studio prompts you that the project has changed so the changes to the project file can take effect.

Create a base resource file

Now that we have a default culture and a list of other supported cultures, we can start defining culture-specific resources. We’ll start by adding a file for default resources and move on to adding resources for specific cultures. As a localization best-practice, any user-facing string should be included in these files instead of hard-coded in XAML or a code file.

We need to add a resource file to the project that defines the default language strings for the application. To do this, we’ll right click on our project in the solution explorer and choose “Add -> New Item”. From here, we’ll add a resource file. This file can be called whatever you like, but for this example we will call it Strings.

Adding the file takes us into the resource editor for this resource. The resource editor contains a table with three columns: Name, Value and Comment. Name is the auto-generated code-behind name for the resource and serves as a unique key for identifying a resource. Value is the culture-specific value for this resource and is what we’ll use to store user-facing text. Comment is not used by the application but is helpful for noting what each resource means and where it’s used and can help greatly during translation to other languages. You’ll also see an access modifier at the top of the resource editor. This is internal by default but we need to change this to public so we can bind to these values in XAML later.

Here is our example after adding the appropriate strings and changing the access modifier to public:

Create culture specific resource files

Now that we have our default resources defined, we can begin creating customized resources for the project. We’ll start by defining the Spanish resources for this application. Control-click and drag Strings.resx in solution explorer to create a copy of String.resx then rename “Copy of Strings.resx” to “Strings.es-ES.resx” (es-ES is the culture code for Spanish). It’s important that this new file start with the same name as your previous resource file but have the matching locale at the end of it or this file will not properly map to the intended locale. Once you’ve renamed that file, open up the Strings.es-ES.resx file and modify the Value column for each resource. A good source for translations is Bing Translator, though you should verify translations with someone who understands the language before deploying. It’s important that the Name column matches between resource files so that resources can be appropriately mapped.

Once you’ve finished with this, follow the same procedure for any additional locales you wish to support being careful that all resource files have an access modifier of Public, keep the same name, and contain the appropriate culture code. It’s also important to note that the resource editor may not display certain foreign character sets correctly when copying and pasting from Bing Translator to the resource editor, but these characters should look fine on the actual device and the emulator.

Building the non-localized user interface

Now that we have a set of localized strings, we’d better build a user interface that can use them. Our sample application will have a few fields, an application bar and a standard header. Because we want to include dates in this example to demonstrate globalization, we will be referencing the Silverlight Toolkit for Windows Phone and using the TimePicker control contained in that assembly. This article won’t go into detail on downloading, installing and referencing the toolkit, but the toolkit is freely available and help is available online.

Our non-localized MainPage.xaml looks like:

Obviously this XAML contains a number of hardcoded strings which is not what we want for a localizable application. We need to get the user interface to take advantage of our resource strings.

Retrieving Resource Strings in XAML

Luckily, the resource designer we’ve been working with has already automatically generated classes for accessing these resources. Unfortunately, we can’t easily bind to these in XAML because the auto-generated Strings class has an internal constructor and static properties so we’ll need to create a resources wrapper object that exposes these in a way we can bind to.

Add a new code file to the solution called StringProvider.cs and include the following code:

Now go into your App.xaml file and add a new resource to the application with an appropriate xmlns qualifier. This resource will be available across the entire application and will provide easy access to string localization. When done, our App.xaml will look like:

Now that we’ve defined our StringProvider as a resource, we can bind to it in the main page. In this case we’re binding to a sub-property on the Resources property representing the name of the resource as we defined it earlier in the resources collection and using the application StringProvider object as a binding source. For example, our page title TextBlock becomes:

Both Blend and Visual Studio’s design surfaces should recognize this binding and display the neutral language string (the value in Strings.resx) in the designer if the project has been rebuilt since the resource was added.

When building localizable applications, be aware that in many languages resource strings will be longer than in the default locale. Because of this, it’s important that you set TextWrapping="Wrap" where applicable and use flexible layout structures such as ScrollViewers and StackPanels that can adapt to multi-line content when needed. Due to potentially long resource strings, setting SupportedOrientations="PortraitOrLandscape" on the page element is recommended where appropriate.

It’s also important to be aware that not all locales support different fonts. Your best bet for application localization is to avoid manually specifying fonts or font weights and instead relying on the built-in styles. See http://msdn.microsoft.com/en-us/library/hh202920(v=VS.92).aspx for more information.

Referring to localized strings in code behind

This approach will work for most of the strings, but Metro design guidelines require the application title at the top of the page to be in all caps and our string in the resource file uses initial caps. We could define a new resource just for the title label or write a custom to uppercase value converter for the binding, but instead we’ll just set the title in the code behind so we can demonstrate accessing localized resources from code by adding the following line to the MainPage’s constructor:

ApplicationTitle.Text = Strings.AppTitle.ToUpper(CultureInfo.CurrentCulture);

Localizing application bars

Application bar elements do not presently support binding since they’re not truly customizable Silverlight content. Instead, we’ll have to manually set the text of our ApplicationBarIconButton in the code behind by referring to the auto-generated property for our resource name on the Strings resource as follows:

We now have a localized application. Testing the application in the emulator using French language settings results in the following:

Supporting Globalization

Now that we have a localizable application, let’s get into the globalization side of things. Since globalization deals with respecting a user’s cultural settings, it’s important to provide the correct IFormatProvider to various string formatting methods whenever appropriate. Thankfully, .NET provides CultureInfo.CurrentCulture which represents the user’s current cultural settings and can be used for formatting strings for the user interface. When doing standard comparisons or dealing with serialization or other non-user-facing operations, it’s important to use CultureInfo.InvariantCulture to ensure your app works properly in all culture settings.

Unlike localization, you don’t have to do anything to support a particular culture and the .NET framework will take care of most culture formatting operations for you. It is still a best practice to provide the appropriate format strings and specify CultureInfo.CurrentCulture as an IFormatProvider where appropriate.

For example, the code our application uses to generate an e-mail makes explicit use of the CurrentCulture and format strings:

Since globalization is separate from localization, running the app in a language without locale-specific strings will result in properly globalized values such as these German settings in the image below:

Specifying format strings in XAML

Occasionally you’ll want to be able to specify a format string in XAML either as a parameter to a value converter or as a property on a built in control. In our example we’ll explicitly set the format string of our TimePicker to the short time format for the current culture (“t”). To do this, we prefix our format string with a pair of braces as shown here:

It’s also possible to set this in code behind either as

or, more concisely:

Testing for different cultures

By this point we’ve built a fully functional app that supports globalization and localization. You may be wondering how to test applications for different locales. Actual Windows Phone devices may not allow you to change your phone’s display language, but thankfully Microsoft provided this capability in the emulator.

To access these settings, go into the emulator’s applications menu on the start screen and choose the settings app. From there click on region+language on the system pivot item.

The region & language screen allows you to customize the display language on the phone by setting the Display language picker box to the language you want to test and then clicking on the “tap here to accept changes” hyperlink. Doing so will reboot the emulator’s image of the Windows Phone operating system and apply the language and globalization settings you’ve chosen. It can be confusing to use the settings pages in a language you don’t know to change regional settings so it’s a good idea to study the layout of the screen before applying your changes. Once the emulator reboots, launching your application in the emulator will allow you to verify that the app respects the user’s language and cultural settings.

Deployment Considerations

When deploying an application that supports different languages and cultures, be sure to opt-in to distribution in the markets you support either by selecting worldwide distribution when publishing your app and setting the prices or by selecting the individual locales that you explicitly intend to support.

Summary

You now know how to create an application from start to finish that will offer the best experience by providing a properly globalized and localized application to the global audience that uses Windows Phone.

To download a full Windows Phone project that uses all of the code and examples from above, click the Download Code button below.

Tomorrow, we are going back to data, and we’re going to cover how to use a local database in your application.  See you then!

31 Days of Mango | Day #28: Media Library

This article is Day #28 in a series called 31 Days of Mango, and was written by guest author Jeff Fansler. Jeff can be reached on Twitter at @fanzoo.

Today we are going to take a look at the MediaLibrary class that is part of the Microsoft.Xna.Framework.Media namespace. As the name suggests, this class gives us access into the users Media Library. A Media Library on Windows Phone stores pictures and music. By using the Media Library you can integrate this content into your own applications. There are several reasons a developer may want to do this. Here are a few ideas:

• To show the user a list of songs and let them select the background music while using your app.
• To allow the user to download their images from a service (i.e. Flickr) and add them to the Media Library.
• To use music artist or genre data from the Media Library to make suggestions on other similar content the user may be interested in.

In order to show how to use the Media Library I’ve created a sample application. This app will list all the songs that are in the user’s Media Library, play a song when the user selects a song, and allow the user to select an image from the Media Library to use as the background. The app uses the Media Library to get a list of songs and it also saves an image to the Media Library for the user.

Saving an Image to the Media Library

In the sample app I have added image1.jpg as a resource. It’s an awesome image and I’m sure all of the users are going to want it so we are going to save this image to the Media Library. The sample app saves this image in the Application_Launching method in the App.xaml.cs. Here is the code that does this work:

Most of this code is simply working with loading the image. There are a few important lines here that are using the Media Library. Let’s take a closer look at a few of these lines.

This line creates a new MediaLibrary class. This is what will give you access to the Media Library properties and methods.

This line searches the library for any pictures that are saved with the imageName. If that image exists already, the code does not save it again.

This line saves the BitmapImage to the library. You may notice that a BitmapImage doesn’t normally have a ToStream method. I think it should so I’ve used an extension method to add it. The extension class doesn’t have anything to do with the Media Library but here it is so you know how it works:

After that code is executed, the image will be accessible in the Media Library. To show this in our sample app you can click the gear icon in the app tray and the new image will be available to be selected using a PhotoChooserTask.

Getting a List of Songs

In the sample app the screen shows a list of the songs that are in the user’s Media Library. The list is a ListBox. A DataTemplate is defined that binds the Text property of two TextBlock’s. One displays the song title and the other displays the artist. Here is what the XAML looks like for the ListBox:

Setting the ItemsSource to the list of songs is quite simple:

What Else Is There?

There are a few other properties off of the MediaLibrary class to take a look at:

Albums - This is similar to the Songs collection but lists albums instead.

Artists - Just like the Albums collection, this collection lists the artists of the songs.

Genres – This collection lists the genres of the songs.

Playlists – This collection lists the playlists that the user has added to their library.

Summary

As you can see, using the Media Library is quite easy. Most of the code in the sample app is written to use the content, not to access it from the library. I talked about how to access the Songs collection and how to save an image to the library. I discussed a few ways to use the library in your own apps. I’m sure there are many other ways to use this content. Have fun and I can’t wait to see your apps.

To download a full Windows Phone project that includes all of the code and concepts from this article, click the Download Code button below.

Tomorrow, we will cover globalization/localization in the article, and show you how easy it is to include this in your Windows Phone project.  See you then!

31 Days of Mango | Day #27: Microphone API

This article is Day #27 in a series called 31 Days of Mango, and was written by guest author Parag Joshi. Parag can be reached on Twitter at @ilovethexbox.

Introduction

Speech recognition or taking notes is a very common practice depending on your profession or usage. For e.g. it is understood that today's mobile devices offer some kind of speech recognition and application control, whether it is directions or dialing a number or the other most common usage, playing music.

Note taking is another feature that is useful in recording findings in the field for later reference.

The very first step to all of these applications is to be able to capture the audio via the microphone and process it as needed.

So today we will look at the microphone API provided in Mango and we will put together a very simple sample to get you started.

What is involved?

At the very minimum, we need to record the audio and save it for playback. This gives the user the very basic ability to take notes.

The following key points should be noted:

1. Microphone class: This is the class provided by the Microsoft.Xna.Framework.Audio namespace that allows us access to the microphone api.
2. public event EventHandler<EventArgs> BufferReady: This is an event provided when the microphone is ready to release the buffered audio. We need to handle this event and store the audio for playback.
3. Microphone.Start: As the name suggests, we call this to start recording.
4. Microphone.Stop: We call this to stop recording. One key point to note here is that calling Microphone.Stop immediately clears out the buffer.

As you will see in the application, we don't call stop immediately when the user toggles the microphone or clicks the play button. Instead we let the microphone raise the buffer ready event at the selected buffer duration to capture the last bit of audio data before stopping recording.

using Microsoft.Xna.Framework-> As you must have guessed from the microphone namespace, we require a reference to the XNA framework. The microphone API is part of the XNA framework and requires simulating the XNA game loop. If you are not familiar with XNA, XNA is a rich framework provided by Microsoft for game and graphics based applications.

Understanding the sample

Prerequisites: Install the Mango tools from http://create.msdn.com. This should give you Visual Studio Express 2010 and the Windows Phone SDK that you need to develop applications for Windows Phone.

1. Launch Visual Studio and browse to the solution file and open it. The application is built using the Silverlight "Windows Phone Application" template. Run the project and deploy to the emulator. You will see the following screen when the application finishes loading:

2. Screen element:

a. The microphone button is a toggle which starts and stops the microphone.

b. The play button is used to playback the recorded sound.

c. There are three slider controls to adjust the volume, pitch and pan of the sound being played back. These properties can be adjusted only before starting playback.

3. How it works:

a. Touch the microphone to start recording. You can stop recording by touching the microphone again or alternatively touching the play button.

b. Adjust the volume , pitch and pan one by one and test the effect of the change by playing the recorded sound.

Understanding the code

Declarations: Here is a screenshot of the declarations.

We will be using an object of the SoundEffectInstance class to playback the recorded audio. We could also have used a SoundEffect however using the SoundEffectInstance class allows us to track the state (playing or stopped).

The other declaration here is for a MemoryStream object. The microphone buffer is constantly written to a memorystream until playback is desired. At that time,we submit the contents of the memorystream to the SoundEffectInstance object to play.

Initialization:

The key point to note here is the game loop we have created using the DispatcherTimer. This loop is essential to capturing the audio from the microphone.

We set the image for the play icon based on the light or dark theme used in the phone.

At this point we also set up the microphone defaults for our application as follows:

The buffer duration is set to 1/2 second and then we use a method GetSampleSizeInBytes and pass the buffer duration to get the right buffer size. This is important to ensure smooth audio capture.

We wire up the buffer ready event and set the default stopped microphone image.

We are ready to start recording!

Recording Audio:

When the user clicks the microphone button the following code is called:

There are a few things happening here:

1. Microphone is stopped: If the microphone is stopped we need to start it to begin recording. We set the background of the microphone button. Then we reset to MemoryStream to clear out previously recorded audio. We check and stop the recorded sound from playing.

Fairly straightforward steps. At a minimum we need to call Microphone.Start(). The rest of the steps are based on the UI and application design.

2. Microphone is recording: At a minimum we have to stop recording. If you recall the note from above, we cannot call Microphone.Stop immediately as all recorded data has not been flushed to the MemoryStream. So we use boolean varibles to keep track and defer the stop action to DispatchTimer event.

Two things need to happen here. First, we need to let the microphone bufer ready event fire first so we can read the last bit of audio and then we need to trigger playback. We handle it as follows:

In the buffer ready event, we check if recording has been stopped using our boolean variables and then we call Stream.Flush(). This flushes the remaining data to the MemoryStream. Then we stop the microphone.

However we cannot trigger playback in this event. That is handled by the DispatchTimer tick event as follows:

The tick event is called every 33ms. So it will trigger fairly close to the user selecting playback with relatively no indication of a lag. The advantage ofcourse is that we can playback the entire audio rather than letting it get cut off.

We check if it is time to play the recording and whether the stream has been flushed. If so we start a new thread for audio playback. This is an important point to note here.

We are triggering audio playback on a different thread to allow the UI to update. This means any code inside our playback routine that chooses to update UI elements has to do it by calling Dispatch.BeginInvoke as shown below.

Playback:

We create an object of the SoundEffectInstance class by feeding it the captured audio stream, the sample rate of the microphone and the audio channel.

Since we wish to use the sliders to adjust volume, pitch and pan we have to use Dispatcher.BeginInvoke as they are on a different thread.

Finally we call Play.

Summary

So, its fairly simple to create an application to record audio. We can extend this application to save the recorded audio to isolated storage and give it a title chosen by the user. We can add a listview of the recordings from isolated storage and turn this into a note taking application.

The basic steps to record audio are

a) Wire an event to the default microphone to capture the audio.

b) Write the audio to a stream.

c) When the user stops recording, flush the stream and store it or playback.

We can also extend this sample by taking the recorded audio and sending it to a speech translation service and capture commands.

To download a full Windows Phone application that uses all of the code and examples from above, click the Download Code button below.

Tomorrow, Jeff Fansler will be covering the Media Library class, and how we can use it to learn more about a user’s music library on their phone.  See you then!