[download the application complete source code from your Telerik account ]

This is part 2 of the series on Building an Exchange Client For Windows Phone. See part1.

Microsoft has invested a lot into building managed API for accessing Exchange Web Services (EWS). This gives us the opportunity to do virtually everything from code, that an end user can do using the Microsoft Outlook client.

The API allows us to add/edit/delete mail massages, appointments, contacts, tasks, etc. In this example we will show you how to access user appointments, but working with the rest of the assets can be done in the similar way.

Setting up the infrastructure

The managed API for accessing the EWS is dependent on .NET 4. This means that we cannot reference and use the libraries from a windows phone application directly. In this case our solution was to create a separate WCF web service which references the EWS libraries. The Windows Phone client application references this web services and uses it as a proxy to access the Exchange data. Here is how the solution looks like:

As you can see we have 3 projects:

1. ExchangeClient – this is the Windows Phone client application
2. ExchangeWebService – this is a WCF web service which references the Microsoft.Exchange.WebServices libraries, which is .Net4 dependent
3. Models – this is a portable library project which contains the models that are used in the communication between the client application and the web service.

Authentication with EWS

The first step to consume a EWS service is to authenticate the user with the service. To authenticate with the web service we need the following info:

• Email
• Username
• Password
• Domain
• Exchange server Url

With this information we can authenticate the user using the following code (located in $ExchangeWebService/ExchangeWebService.svc.cs):

If we don’t know the Service Url we can try to use the Autodiscovery feature of the Exchange Services to find it. In order this to work the Autodiscovery option should be turned on by the Exchange administrators.

Here is how to use the auto-discovery:

If the Autodiscovery option is not turned on, we need to set the service URL manually. Here is the code:

Now after we are authorized we can Bind to a specific Exchange Folder. For example the Calendar folder:

In the sample solution you will see that the authorization code is in a try-catch statement. This is because there are many reasons for the authorization to fail. We want to catch the specific exceptions and to show a friendly message to the users telling what exactly is wrong in the exchange setting so they can fix it.

In the sample implementation you will also see this line of code:

This setting is useful for scenarios when the Exchange server do not have a valid trusted ssl license. Please do not enable it for commercial applications without the permission of the user. More information about this setting can be found here.

Getting data from Exchange Server

Now that we are authenticated comes the easiest part of the application – to get the appointment data from the Exchange server.
In Exchange server the data is organized in folders. There are several “known” folders like:

• CalendaFolder
• TaskFolder
• InboxFolder
• Etc..

Here is a sample code that binds to the Calendar folder and inspects its contents:

It is as simple as that!

First we bind to the folder we want to inspect and then we are calling the GetItemChangeCollection method of the ExchangeService. You will notice that this method has a syncState parameter. Each call to the GetItemChangeCollection method is returning a sync state. When we pass the sync state next time we call the method we will get only the changes since the last method call. This is super useful when we want to download only the new data from the exchange server. You can read more about SyncState here.

Continue to part3 of the series - Displaying the data using Metro UI.

Follow me on Twitter @ValioStoychev