SilverlightShow: Silverlight Community

Windows 8 Apps: The 8 Must-Know Tricks! Day 8

editorial@silverlightshow.net (Samidip Basu ) — Thu, 01 Nov 2012 08:02:00 GMT

This is Day # 8 in the Windows 8 development article series on common tips & tricks towards real-world Windows 8 Store apps. With our App nearing function-complete, time to provide the personal touch in user experience through the use of Live Services. Over the last several weeks, you saw 8 articles talk about some must-do things for Windows 8 app developers. Simple & to the point, with some code examples on XAML/C# stack. Here’s the indexed list for the series:

Don't miss...

All SilverlightShow Ebooks

Day 1: Know the ecosystem; Start
Day 2: Layout, Navigation & Visual States
Day 3: Semantic Zoom
Day 4: Controls & Styling
Day 5: Search, Share & Settings Contracts
Day 6: Data Persistence & Application Life-Cycle Management
Day 7: Use of OData or Web Services
Day 8: Live Services integration

Day 8: Live Services Integration

Live Services is a suite of services comprising of Microsoft’s SkyDrive, Hotmail/Live/Outlook email & Windows Live Messenger, often clubbed together as Software-As-Service. The user base count of Live Services is well over 500 million & integration with such services in our Windows 8 Apps provides new ways to engage the user with what he already considers personal, thus leading to a more intimate UX and increased usage. Live Connect is a collection of APIs with RESTful endpoints on top of Live Services, which helps us integrate the user’s “personal cloud” in our applications; while .NET wrappers make the developers life simple while performing asynchronous network calls. Let’s look at our options on C#/XAML stack.

Single Sign-On

People hate signing in, period. With myriads of websites/applications requiring form-based User ID/Password authentication, no wonder users are at a loss remembering credentials. Also, authenticating users is serious business and needs appropriate safety in system architecture, before applications can be developed. So, it makes sense for developers to get away from user authentication when possible, and trusting established identity providers for user tokens. With Windows 8 allowing Microsoft Accounts to sign users in, Live Services offer a unique way to facilitate single sign-on across Apps & websites. Not only can our Apps let MSFT sign users in; but in the same breath, we also can request access to the signed-on user’s information to provide a personalized UX.

Here are the steps needed to allow Live Service single sign-on:

Get the Live Connect SDK from http://msdn.microsoft.com/en-US/live/ff621310.
Start the Windows 8 Store App project & Add a Service Reference to the Live Connect DLL.
Figure out what Scopes your App might need. Details @ http://msdn.microsoft.com/en-us/library/live/hh243646.aspx.
It is not a good idea to ask for everything all at once, since it may make the user suspicious of your goals. We can always go back & ask for more permissions as needed.
Use the built-in Sign-In XAML control to allow the user to sign-in with their MSFT Account credentials, passing along the Scopes needed. This takes care of all the heavy-lifting of making the appropriate HTTP calls on our behalf.
Add appropriate branding to Sign-in button as suited for App.

Here’s some code, to add the Sign-In button and handle changes with respect to the user providing credentials through MSFT Account & us having access to the user’s Session object:

// XAML Button on screen.

"btnLogin" Scopes="wl.signin wl.basic" TextType="Custom" SignInText="Come join the wonderland ..." SignOutText="Adios .." 

                   Branding="Messenger" Theme="Dark" SessionChanged="btnLogin_SessionChanged" />

  

// Code-behind.

using Microsoft.Live.Controls;

  

private LiveConnectClient client;

private async void btnLogin_SessionChanged(object sender, LiveConnectSessionChangedEventArgs e)

{

   if (e.Status == LiveConnectSessionStatus.Connected)

   {

       client = new LiveConnectClient(e.Session);

       LiveOperationResult operationResult = await client.GetAsync("me");

        

       try

       {

           dynamic meResult = operationResult.Result;

           if (meResult.first_name != null && meResult.last_name != null)

           {

               infoTextBlock.Text = "Hello " + meResult.first_name + " " + meResult.last_name + "!";

           }

           else

           {

               infoTextBlock.Text = "Hello, signed-in user!";

           }

        

           contactHeader.Visibility = Windows.UI.Xaml.Visibility.Visible;

           FetchContacts();

       }

       catch (LiveConnectException exception)

       {

           this.infoTextBlock.Text = "Error calling API: " + exception.Message;

       }

   }

   else

   {

       infoTextBlock.Text = "Not signed in.";

   }

        

   infoTextBlock.Visibility = Windows.UI.Xaml.Visibility.Visible;

 }

Even though a user is signed on to their Windows 8 PC using a MSFT Account, user information is not automatically available for Apps to tap into, since that would be an invasion to privacy. So, the user has to explicitly provide consent to your App towards using his/her information, based on the Scopes/Permissions that your App asked for. First time users will be greeted with an approval UI, like below, automatically displayed by the Live Connect Sign-In button plumbing:

Upon user consent, we can sign in the user & use his/her profile information to greet, as seen in the event handler in the code above. Once the user starts using your App upon signing-in & allowing permissions, he/she can see your App in their MSFT Account profile, as shown below, including the ability to revoke rights with granularity:

User Data

Once declared Scopes are permitted through user permission, the Live Connect APIs can be used to create/read a user's Contacts, and can create/read/update/delete the user's Calendars. But with power comes responsibility and restraint & justification should be in place for such use in our Windows 8 Store Apps.

Armed with the wl.basic Scope, here’s a way to retrieve the user’s Contacts list and display them in a GridView:

private async void FetchContacts()

{

    try

    {

        LiveConnectClient liveClient = new LiveConnectClient(client.Session);

        LiveOperationResult operationResult = await liveClient.GetAsync("me/contacts");

  

        dynamic contactsResult = operationResult.Result;

        List contactsList = contactsResult.data;

        

        this.itemGridView.ItemsSource = contactsList;                

    }

    catch (LiveConnectException exception)

    {

        this.contactsError.Text = "Error getting contact info: " + exception.Message;

        this.contactsError.Visibility = Windows.UI.Xaml.Visibility.Visible;

    }

}

Did you notice the use of the shortcut “me”? It’s a quick HTTP endpoint to refer to the signed-in user. And here’s how we could bind it to our GridView UI; you have complete flexibility to parse & bind data to UI as needed:



    x:Name="itemGridView"

    AutomationProperties.AutomationId="ItemGridView"

    AutomationProperties.Name="Grouped Items"

    Margin="0,30,40,46"

    ItemTemplate="{StaticResource Contacts250x100Template}">

  

    

                                    

            "Horizontal" Margin="0,0,100,0" FlowDirection="LeftToRight" Height="700" Width="1400" />

        

                        



  



"Contacts250x100Template">

    "Left" Width="250" Height="100">

        "#99FFDD" Opacity="1">

            "Vertical">

                "{Binding id}" Foreground="#6655FF" Margin="5,5,15,2" VerticalAlignment="Top" TextWrapping="Wrap" FontSize="10"/>                    

            

        

        "Bottom" Background="{StaticResource ListViewItemOverlayBackgroundThemeBrush}" Height="30" Orientation="Horizontal">

            "{Binding name}" Foreground="{StaticResource ListViewItemOverlayForegroundThemeBrush}" Style="{StaticResource TitleTextStyle}" Margin="5,0,15,0"/>                

        

    





SkyDrive

SkyDrive is the MSFT Account holder’s personal space in the cloud & heavily used as a feature, specially in the Windows 8/Windows Phone ecosystem. So, while a convenient storage option, we developers need to be careful to not undermine the faith users have in SkyDrive. Need to store data outside of the user’s device and thinking of hosting a cloud data storage yourself - Why not just leverage the user’s SkyDrive? Not only is the user accustomed to SkyDrive, but his/her settings/data also roam across devices, leading to convenience.

The wl.skydrive Scope gives us the permission to traverse up & down the user’s SkyDrive directory and inspect files/folders. Armed with the wl.skydrive_update Scope, we have complete access to read/write files & folders, move/delete/copy files from any location. Here’s the quick & easy way to upload a photo from a Windows 8 App onto the the base directory of user’s SkyDrive. Note the use of FileOpenPicker to select a photo from user’s photo library, before we upload the file asynchronously to SkyDrive root directory:

private async void UploadPicture()

{

    try

    {

        var picker = new Windows.Storage.Pickers.FileOpenPicker();

        picker.ViewMode = Windows.Storage.Pickers.PickerViewMode.Thumbnail;

        picker.SuggestedStartLocation = Windows.Storage.Pickers.PickerLocationId.PicturesLibrary;

        picker.FileTypeFilter.Add("*");

        Windows.Storage.StorageFile file = await picker.PickSingleFileAsync();

  

        if (file != null)

        {                   

            LiveConnectClient liveClient = new LiveConnectClient(client.Session);

            await liveClient.BackgroundUploadAsync("me/skydrive", "MyUploadedPicture.jpg", file, OverwriteOption.Overwrite);                   

        }

    }            

    catch (LiveConnectException exception)

    {

        this.infoTextBlock.Text = "Error uploading file: " + exception.Message;

    }

}

Conclusion

That’s it for today. The crux of this article was to talk about Live Service integration from Windows 8 Store Apps to provide the personal user experience users deserve. For more information on the various options of using Live Connect APIs to tap into the user’s already existing cloud presence through MSFT Account, start @ http://msdn.microsoft.com/en-us/library/live/hh243641.

This concludes our little 8-part Windows 8 App development article series. Hopefully, the tips & tricks I have learnt along the way saves you some time. Please offer feedback & thanks for reading. Happy coding!

About Author

Samidip Basu (@samidip) is a technologist, gadget-lover and MSFT Mobility Solutions Lead for Sogeti USA working out of Columbus OH. With a strong developer background in Microsoft technology stack, he now spends much of his time evangelizing Windows Phone/Windows 8 platforms & cloud-supported mobile solutions in general. He passionately helps run The Windows Developer User Group (http://thewindowsdeveloperusergroup.com/), labors in M3 Conf (http://m3conf.com/) organization and can be found with at-least a couple of hobbyist projects at any time. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com.

Windows 8 Apps: The 8 Must-Know Tricks! Day 7

editorial@silverlightshow.net (Samidip Basu ) — Mon, 22 Oct 2012 11:30:00 GMT

This is Day # 7 in the Windows 8 development article series on common tips & tricks towards real-world Windows 8 Store apps. Now that we’ve got our Windows 8 App working, time to provide the always-on & always-connected user experience – leveraging services the right way. Over the last several weeks, you saw 8 articles talk about some must-do things for Windows 8 app developers. Simple & to the point, with some code examples on XAML/C# stack. Here’s the indexed list for the series:

Don't miss...

All SilverlightShow Ebooks

Day 1: Know the ecosystem; Start
Day 2: Layout, Navigation & Visual States
Day 3: Semantic Zoom
Day 4: Controls & Styling
Day 5: Search, Share & Settings Contracts
Day 6: Data Persistence & Application Life-Cycle Management
Day 7: Use of OData or Web Services
Day 8: Live Services integration

Day 7: Use of OData or Web Services

Connected & Alive – one of key guiding principles of Modern UI Design Language that contributes towards the user experience provided by Windows 8 style Apps. How can the Start screen be lit up with customized content and innovative Tiles? How can Apps not be running, but yet appearing to have fresh data/content? How can one have Apps feel connected, even without network connectivity? Well, through the use of services that reside outside the Windows 8 App we are making. It is this outside partner to our App that often does some heavy lifting in processing logic to make the App feel alive & connected. It is important to understand how to leverage services to manage data and push back content to our mobile Apps. Let’s explore our options on XAML/C# stack ..

Connectivity to Services

Few Windows 8 Apps would come alive without access to some network data. Many a times, we may be pulling down resources from web URLs or RESTful services. What’s the easiest way? Why off course, the HTTPClient class in the System.Net.Http namespace. It can be used to send basic HTTP requests in the form of GET, PUT, POST & DELETE and receive HTTP responses back, all asynchronous in Windows 8.

For example, here’s some sample code to pull down a SilverlightShow article:

HttpClient httpClient = new HttpClient();

HttpResponseMessage response = await httpClient.GetAsync("http://www.silverlightshow.net/items/Windows-8-Apps-The-8-Must-Know-Tricks-Day-6.aspx");

string articleAsHTMLString = await response.Content.ReadAsStringAsync();

As you can see, this is pretty simple. What you do with the response and how you bind it to your UI is up to what your application needs. However, one thing to remember is that before you make any network calls from Windows 8 Store Apps, it must be declared explicitly as a Capability that the application needs in the corresponding .AppManifest file, as shown below.

Now, the above is only the simplest example of accessing a network resource from Windows 8 Apps; there are off course, other forms of connectivity, like pulling down RSS Feeds using SyndicationFeed classes, secure connections over HTTPS, two way client-server communication over WebSockets protocol or low level connections over TCP/UDP. For more information, a great starting point would be http://msdn.microsoft.com/en-us/library/windows/apps/xaml/br229573.aspx.

Windows 8 Apps can also talk more intimately with hosted Web Services, if we add references to the Service in our project. With a service reference, our code could have access to service data types & have tight coupling with object structures on the service side, to invoke methods for connectivity, obviously in an asynchronous way. While this is true for most WCF or RESTful services, we shall see examples of this for an OData service, as below.

OData

The Open Data Protocol (OData), as we know, is an HTTP based protocol for querying and updating data through a service layer that is easily configurable; more details @ http://www.odata.org/. Handing out data in ATOM/JSon formats, OData extends itself to use from multitude of platforms, and yes natively from Windows 8 Store Apps. While we can absolutely hand-code the HTTP requests, .NET wrappers for the XAML/C# world make it really easy to query/update data back on a service. In fact, OData may be considered to be one of the easiest ways to support Database CRUD (Create, Read, Update. Delete) from a Windows 8 style App.

One of the advantages of having easy access to a Service that handles data CRUD is the seamless connectivity it offers for Windows 8 Style Apps. We can lazy load data opportunistically and the user can have latest data locally, make edits & push it back to the OData service for syncing with the server. This particularly facilitates the scenario of Technicians or other types of users going out to areas of no connectivity with Windows 8 tablets and yet being able to sync data easily (automatically or by trigger) when network is available. Local data, with changes, can be persisted in serialized objects Isolated Storage or through the use of SQLLite for truly relational data. And classes like DataServiceCollection and LINQ techniques make handling the data a breeze – pull down filtered data, bind locally to UI and when done with changes, easily update back up to the OData service.

Here are few of the steps you need to integrate OData service usage from a Windows 8 Store App:

First host the OData service or use one that is already available for your cause. Just about any relational data can be exposed as an OData feed with little orchestration, but allowing complete CRUD operations on data, over proper authentication. For more info on how to create an OData service, start with Michael Crump’s brilliantly simple article series @ http://www.silverlightshow.net/items/Producing-and-Consuming-OData-in-a-Silverlight-and-Windows-Phone-7-application.aspx.
Check the OData service endpoint in a browser to make sure that all the HTTP collection URLs are returning data as expected.
Next, download the WCF Data Services Tools for Windows Store Apps from http://www.microsoft.com/en-us/download/details.aspx?id=30714. This enables all the plumbing needed to easily add a Service Reference to the OData service endpoint.
Fire up your Windows 8 Store App project in Visual Studio and simply add a Service Reference to the OData service.

Using the quintessential Netflix OData service feed found at http://odata.netflix.com/catalog/ as an example, our Service Reference addition is trivial, and it immediately gives our project access to the data types exposed in the OData service:

Fetching data down from an OData service is trivial, with our tooling making asynchronous HTTP GET calls behind the scenes:

using System.Data.Services.Client;

  

// Reference to Context & Object Collection from OData Service.

DataServiceContext oDataContext;

DataServiceCollection objectListFromService;

  

// Instantiate the context.

oDataContext = new DataServiceContext(new Uri("OData EndPoint"));

objectListFromService = new DataServiceCollection(oDataContext);

  

// Reach the entities.

Uri uriQuery = new Uri("/SomeCustomHTTPEndpoint", UriKind.Relative);

  

// Asynchronously load the fresh data from Service.

objectListFromService.LoadAsync(uriQuery);

  

objectListFromService.LoadCompleted += (sender, args) =>

{

    if (args.Error != null)

    {

        // Do some error handling.

    }

    else

    {

        // Success.         

        // Bind to UI.

    }

};

Once fetched, the data objects could be serialized and saved locally. If there are updates to made, we could simply locate the object which needs to change, update it’s properties, mark it dirty & send HTTP POST requests back to the OData service to update records in the backend. The beauty is, this can all be done without writing any low-level HTTP stuff, but rather simple .NET code, as show below:

// Find the object to update from local list.

SomeCustomObjectType serviceObj = objectListFromService.First(T => [some predicate expression]);

  

serviceObj.Prop1 = ...

serviceObj.Prop2 = ...

  

// Mark the object dirty & ready for update to DB.

oDataContext.UpdateObject(serviceObj);      

  

// Commit all at once.

oDataContext.BeginSaveChanges(new AsyncCallback(SaveDoneCB), null);   

  

    private void SaveDoneCB(IAsyncResult asynchronousResult)

    {

        // On a different thread here!

        if (asynchronousResult.IsCompleted)

        {

            // Indicate completion.

            // Bubble event up to any listeners or update UI.                

        }

    }

Push Notifications

Now, the other huge usage of Services for Windows 8 Store Apps is in supporting Push Notifications. This truly contributes to the connected and alive user experience in Windows 8 Apps, by feeding Live Tiles on the Start screen or Toast notifications. The basics of Push Notification on Windows 8 is captured by the following:

Few steps to get this working are:

Windows 8 App client requests an unique Channel URI through the PushNotificationChannelManager from WNS.
Once received, the App sends up the Channel URI to some hosted Web Service, preferably over a secure connection. This is where the service integration comes into play. This other companion service to the App could be hosted anywhere and may be a WCF/RESTful/regular web service. The client app may have a reference to this service & needs to invoke methods on the service to send up the channel URI. Or in case of a RESTful service, a simple HTTP POST would be enough to send up the channel URI.
Next, our service will authenticate itself with Windows Push Notification Service (WNS) through some handshaking of tokens and send down push notification packets at the given channel URIs through a secured HTTP POST.
WNS turns around and delivers the push packets down to each Windows 8 devices.
Before our cloud web service can utilize WNS to send Push Notifications, the App needs to be registered through the Windows Dashboard to provide authenticating credentials. These take the form of a Package Identifier & a security key, which is sent up to the cloud service. The cloud service uses the credentials to handshake with WNS through OAuth and receives an access token, which is utilized across every WNS POST request.
For more detailed information, please see http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh913756.aspx.

Tiles & Toasts

Although we primarily talked service integrations here, it is worth mentioning what the Push Notification services fuel. Live Tiles on the Start screen are live representations of each App; they are the gateway to the App & need to impress and then continue to invite the user back into the application. Tiles are available in two sizes – square and wide; and can be any combination of text, images and notifications called badges. Tiles are based on a non-extensible set of predefined XML templates, so that the OS may know how to process them and can truly be used to push through App branding. Also, tiles can cycle through the last 5 received push notifications for an enticing peak animation, thus inviting the user back. And just like in Windows Phone, there is support for Secondary Tiles, which can pin specific sections of the App to the Start screen & take the user back to a particular sub-experience when tapped. More information on Tiles available @ http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh779724.aspx.

A Toast, on the other hand, is a transient notification that pops up on the top right edge of the Windows 8 screen, irrespective of where the user is at. Toasts are meant to provide relevant, time-sensitive information to users & allow the user to quickly jump into related content in the App which triggered the Toast notification. Since this can be intrusive and only used for high-interest content, a capability declaration is needed in the App Manifest file and the user has the option of turning off notifications. A Toast notification is made up of texts/images and just like Tiles, supported through pre-defined templates. More detailed information about Toasts is over @ http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh779727.aspx.

An assortment of Tile & Toast templates is shown below:

Image courtesy – Microsoft.

Conclusion

That’s it for today. The crux of this article was to talk about Service integration from Windows 8 Store Apps. In particular,we saw how OData service could fuel CRUD operations from our Apps and then how to have Push Notifications supported through our cloud service, thus feeding various Tiles & Toasts.
See you next time as we dive into Live Services integration in Windows 8 Apps. Thanks for reading!

About Author

Windows 8 Apps: The 8 Must-Know Tricks! Day 6

editorial@silverlightshow.net (Samidip Basu ) — Mon, 15 Oct 2012 09:50:00 GMT

This is Day # 6 in the Windows 8 development article series on common tips & tricks towards real-world Windows 8 Store apps. Now that our Windows 8 App is starting to behave like a good citizen, time to take care of data – the crux of most applications & also make sure that our app lives its lifecycle cleanly. Over the next several weeks, you’ll see 8 articles talk about some must-do things for Windows 8 app developers. Simple & to the point, with some code examples on XAML/C# stack. Here’s the indexed list for the series:

Don't miss...

All SilverlightShow Ebooks

Day 1: Know the ecosystem; Start
Day 2: Layout, Navigation & Visual States
Day 3: Semantic Zoom
Day 4: Controls & Styling
Day 5: Search, Share & Settings Contracts
Day 6: Data Persistence & Application Life-Cycle Management
Day 7: Use of OData or Web Services
Day 8: Live Services integration

Day 6: Data Persistence & Application Life-Cycle Management

It is not by chance that the topics of persisting data in Windows 8 Store Apps and the Application Lifecycle Management have been chosen together; they are very much inter-related and the timing of actions matter. Data – whether application or user specific, is gold & needs to persisted correctly, across uses of the same application. Application lifecycle, on the other hand, deals with all the states that a Windows 8 App goes through in between launch & termination. It is this lifecycle that exposes checkpoints where we App developers get chances to persist our data correctly. Let’s explore our options in the C#/XAML stack ..

Data Persistence

Before we start talking about saving data, let’s first see what type of data we may be dealing with. For most Windows 8 Store apps, data can largely be classified under two categories:

App Data – settings, files, cache, session state, custom lists etc.
User Data – documents, credentials, photos, music etc.

Windows 8 apps, especially when used on tablets, should provide for an intimate UX. This is why managing the data persistence becomes important, to increase user confidence & usage of apps. Windows 8 Store apps run in their own sandbox, for the obvious reasons of application security. Data leaks, possible malware or other catastrophes are much less of a headache to the end user with this setup. So, applications get their own sort of Isolated Storage to read/write data to disk, much like what we have been used to from Windows Phone development. However, that is not the only option – remember, Windows 8 is a cloud-connected OS. With the benefits of the one consolidated MSFT Account, wouldn’t it be cool if 3^rd part Apps could also sync data between the same App running on multiple PCs? Yep, possible!

So, here are the options for data persistence for Windows 8 Store Apps:

Data can be persisted, as Application Settings in key-value pairs, with the value being set as per application needs. Simple settings, strings, and all the way up to serialized objects can be persisted. This type of data is usually stored in the registry, but actual mechanism of storage is transparent to developers. Within the App data store, each app gets its root container to store information, with the flexibility of supporting custom nested containers.

Data can also be saved as Application Files, which is usually stored in the sandboxed file system access that Apps have. While a pre-defined root directory is present, any nested folder structures are supported for better organization of data.

The application data API exposes three possible storage targets:

Local – for data persistence on the particular device only.
Roaming – for making the data available for sync across multiple devices running the same App under MSFT account. Windows roams app data opportunistically and doesn't guarantee an instant sync.
Temporary – for transient storage that can act as a cache; but may be removed up by user/system cleanup.

The lifetime of application data storage is tied to lifetime of the App on the given device; upon un-installation, all of the App’s sandboxed data is cleaned up, locally & in the cloud.

Let’s look at some examples through code:

// Reference to Local Application Settings.

Windows.Storage.ApplicationDataContainer localSettings = Windows.Storage.ApplicationData.Current.LocalSettings;

  

// Reference to Roaming Application Settings.

Windows.Storage.ApplicationDataContainer roamingSettings = Windows.Storage.ApplicationData.Current.RoamingSettings;

  

// Persisting simple Application Settings.

localSettings.Values["NumberOfArticlesToDownload"] = 20;

roamingSettings.Values["LastReadArticleID"] = 5;

  

// Reading settings back.

int numberOfArticlesToDownload = Convert.ToInt16(localSettings.Values["NumberOfArticlesToDownload"]);

int lastReadArticleID = Convert.ToInt16(roamingSettings.Values["LastReadArticleID"]);

  

  



We’ll see examples of persisting Application Files in the next section.

Application Lifecycle Management

Every Windows 8 Store app goes through several lifecycle stages between installation & removal, and also on every application run. Having an App that is a well-behaved Windows 8 citizen in this lifecycle management is important, since it truly ensures a consistent UX for the end user.

The Windows 8 App Execution States are captured by the following illustration:

Let’s break down the different execution states:

On fresh App launch, Windows 8 applications will display a Splash screen and try to start showing the first page of the App.

During the time the Splash screen shows, the custom UI, data bindings & registering of event handlers is happening at a frantic pace. Since we will only get a few seconds to show the first page, heavy operations should be avoided to quicken application load time. The App.xaml.cs file exposes an OnLaunched Activation event handler for being notified when the app starts up. Once done, the splash screen is torn down & the App enters the Running state.

In addition to the normal launch by tapping on App Tile, Windows 8 Apps may be launched through several Contract implementations (like Search, Share Target, File opener etc.). Each one would add an Activation checkpoint in App.xaml.cs to take appropriate action in the event handler & restore state if needed.
Once an App is running, the user may step away from it, thus putting it in the background. When the user moves an app to the background, Windows waits a few seconds to see whether the user might immediately switch back to the app. If the user does not switch back, Windows suspends the app. This triggers the App to go into a Suspended state immediately. Developers get a OnSuspending notification in App.xaml.cs. As we shall see next, this really is the only opportunity to save relevant application state & user data for persistence. If an app does not save state & return from the suspending event within 5 seconds, Windows assumes that the app has stopped responding and terminates it.
While in Suspended state, the App, with all its contents, is just being held in memory by Windows, although it does not get CPU cycles (except for background tasks). This is to support fast application switching, so that, when the user comes back to your app through the application backstack, it is immediately re-hydrated & running again. This is called App Resume, and most application developers should not have to do anything with Windows bringing it back from memory. However, if network content or something else needs to be refreshed after substantially long suspension, a Resuming event handler provides notification.
Now lot of apps in suspension might eventually stretch system resources, at which point Windows decides to Terminate suspended Apps. This is when apps are truly killed with all resources being freed up. Developers will not get a notification when their apps are terminated; so the Suspending event handler remains the only indicator to persist appropriate content. The apps enter a Not Running state upon termination.
Although users generally do not need to close Windows 8 apps, they can choose to do so through a gesture swipe or hitting Alt+F4. Or a running application may have crashed due to unforeseen circumstances, bringing the user back to the Start screen. In both these cases, the app is terminated and enters the Not Running state. If one needs to differentiate between termination mechanisms, the ApplicationExecutionState enumeration may be used to inspect last execution state.
The user may navigate the backstack & eventually come back to an App that has been terminated by Windows. When the app determines that it is activated after being terminated, developers should take care to load the application data that it saved during suspend so that the app appears to the user just as it did when it was suspended.

Let’s look at some code to understand the persistence of data at different execution states of the Windows 8 App. We go back to our demo SilverlightShow Windows 8 application that primarily shows us a list of categorized articles:

Now, at the heart of this applications data is a list of SilverlightShow articles. We have defined our own class and essentially have a globally accessible “ObservableCollection” that is used for data-binding. In real world, we would pull down latest articles and maintain/cache this collection of articles for use throughout the application. So, it makes sense that on suspension, we try to persist this entire collection and on resume from termination, we’ll try to rehydrate our collection back. We’re going to use simple DataContractSerializer serialization/deserialization to persist our collection in a local file. Let’s look at some code:

private async void OnSuspending(object sender, SuspendingEventArgs e)

{            

    var deferral = e.SuspendingOperation.GetDeferral();

  

    // Save application data.

    await SuspensionManager.SaveAsync();

    deferral.Complete();

}

  

private const string articleListFileName = "serializedArticlelist.xml";

public static async Task SaveAsync()

{

    // Save the navigation state for all registered frames

    foreach (var weakFrameReference in _registeredFrames)

    {

        Frame frame;

        if (weakFrameReference.TryGetTarget(out frame))

        {

            SaveFrameNavigationState(frame);

        }

    }            

  

    // Push current Article list to persistent Storage as File.

    MemoryStream articleListData = new MemoryStream();

    DataContractSerializer articleListSerializer = new DataContractSerializer(typeof(ObservableCollection));

    articleListSerializer.WriteObject(articleListData, ((App)Application.Current).ArticleCollection);

  

    StorageFile articleListfile = await ApplicationData.Current.LocalFolder.CreateFileAsync(articleListFileName, CreationCollisionOption.ReplaceExisting);

    using (Stream fileStream = await articleListfile.OpenStreamForWriteAsync())

    {

        articleListData.Seek(0, SeekOrigin.Begin);

        await articleListData.CopyToAsync(fileStream);

        await fileStream.FlushAsync();

    }

}

As you see above, we are using the event handler to get notified that our App is suspending and trying to save our collection of articles in a named XML file in local isolated storage. The Application Data API gives us access to the LocalFolder, where we get to write out our file using a serialized file stream. Now, we did all this just for demonstration; in reality, there is a SuspensionManager class that is added by most templates in the Common folder, that does pretty much exactly what we did. So, simply add your data collection type (may need Data Contract decorations for serialization) to the SuspensionManager’s KnownTypes, and the rest should be transparent. Now, how about re-hydrating this data back on resume? Here’s the code:

protected override async void OnLaunched(LaunchActivatedEventArgs args)

{

    // Do not repeat app initialization when already running, just ensure that the window is active.

    if (args.PreviousExecutionState == ApplicationExecutionState.Running)

    {

        Window.Current.Activate();

        return;

    }            

  

    // Create a Frame to act as the navigation context and associate it with a SuspensionManager key.

    var rootFrame = new Frame();

    SuspensionManager.RegisterFrame(rootFrame, "AppFrame");

  

    if (args.PreviousExecutionState == ApplicationExecutionState.Terminated || args.PreviousExecutionState == ApplicationExecutionState.ClosedByUser)

    {

        // Restore the saved session state only when appropriate.

        await SuspensionManager.RestoreAsync();                

    }

    else

    {

        // Initialize sample data.

        this.ArticleCollection = LoadSampleData();

    }

    

  

    if (rootFrame.Content == null)

    {

        if (!rootFrame.Navigate(typeof(ArticleList)))

        {

            throw new Exception("Failed to create initial page");

        }

    }

  

    // Place the frame in the current Window and ensure that it is active.

    Window.Current.Content = rootFrame;

    Window.Current.Activate();

}

  

public static async Task RestoreAsync()

{            

    // Restore any registered frames to their saved state

    foreach (var weakFrameReference in _registeredFrames)

    {

        Frame frame;

        if (weakFrameReference.TryGetTarget(out frame))

        {

            frame.ClearValue(FrameSessionStateProperty);

            RestoreFrameNavigationState(frame);

        }

    }

  

    // Restore Global Article List from Isolated Storage.

    StorageFile articleListfile = await ApplicationData.Current.LocalFolder.GetFileAsync(articleListFileName);

    using (IInputStream inStream = await articleListfile.OpenSequentialReadAsync())

    {

        // Deserialize & re-hydrate TaskList.

        DataContractSerializer serializer = new DataContractSerializer(typeof(ObservableCollection));

        ((App)Application.Current).ArticleCollection = (ObservableCollection)serializer.ReadObject(inStream.AsStreamForRead());

    }

}

Not too difficult, is it? We check to see how the App was terminated, and if needed, fetch the file from storage and rehydrate our object model back, for the rest of the app to utilize. And that’s it, we have accomplished the basics of data persistence across our application’s lifecycle.

Conclusion

That’s it for today. The crux of this article was to talk about the various data persistence mechanisms available to Windows 8 Store apps and how to leverage different checkpoints in the Application’s Lifecycle to save our content.
See you next time as we dive into Service Integration from Windows 8 Store Apps. Thanks for reading!

About Author

Connecting Windows 8 applications with services: Part 1: Using services to get data in our Windows 8 applications

editorial@silverlightshow.net (Gill Cleeren ) — Mon, 13 Aug 2012 13:18:00 GMT

Download the source code for this article

Windows 8’s biggest novelty is without a doubt “Apps”. Microsoft is entering the world of apps and is for the first time introducing a “real marketplace”, named the Windows 8 Store where developers can publish, market and sell their applications. This new (for Microsoft developers at least) way of working requires in many views a change of mindset. We as developers are facing many new things, including a new application lifetime management, a new API (WinRT), a different type of communication between apps (Contracts), a new Start experience (Tiles) and many more.

Since apps are going to be distributed through the means of a store, topics such as accessing data also requires some thought. In many views, accessing data through services is similar to accessing data in Silverlight applications. Although the principles are similar, the implementation tends to differ in many places.

The apps we build need to give the user the feeling of being connected. When we’re building a stock ticker application, the app needs access to up-to-date data. An RSS reader would be pretty useless without access to RSS feeds. A LOB app may need access to a CRM data. Without being connected to (up-to-date) data, many apps can’t even execute their normal routine.

Don't miss...

All SilverlightShow Ebooks

In this new series of articles on SilverlightShow, we are going to explore how we can build connected Windows 8 applications. In other words, we are going to explore the options we have to connect our Windows 8 apps to services. The good news for us as developers is that Windows 8 apps can connect with many types of services.

In this first article, we are going to explore the principles of accessing data over services in Windows 8 apps. We are going to apply this knowledge by accessing ASMX and WCF Services from a Windows 8 application. The code for this article can be found here.

Accessing data over services in Windows 8

As outlined in the introduction, many scenarios for Windows 8 apps require access to services. Stock tickers, chat apps, LOB apps, RSS readers… all require access to data. In many scenarios, this data is required to be recent.

Most data resides in databases. In a Windows 8 app, we can specify for example a connection string to read out data stored in a server-side database. Not only would this be a huge security risk (imagine your connection string being on the thousands of devices where your app is downloaded!), it would also be pretty useless to have it there. WinRT has no knowledge of talking with a (remote) database. This means no ADO.NET or LINQ-To-SQL classes are in the API.

Moreover, there’s even no out-of-the-box database built into WinRT. Many Windows Phone developers will expect an implementation of SQL Server CE to be present (which was added in Windows Phone 7.5). Well, I have to disappoint you, since it’s not currently in WinRT. The only option we have is using sqlite for local database needs. Some information about this can be found here.

A local database would not be a solution to gaining access to data. It would mostly be useful for offline/occasionally connected systems. The requirements for these however can be satisfied using the Application Data API or using the above mentioned sqlite.

Where does that leave us? Well, the story is pretty much the same as we had in Silverlight. Relational data is to be stored server-side and should be behind a service layer. Luckily for us, many service types are available to be used from Windows 8 apps. The list below shows the services types we’ll be using throughout these articles:

ASMX services
WCF services
REST services
oData services (created using WCF Data Services)
Sockets

One that is notably missing from this list is indeed WCF RIA Services, a framework created for Silverlight LOB development. At the moment of writing, there’s no word on any integration between Windows 8 apps and WCF RIA Services.

In Windows 8, Microsoft heavily invested in speed and performance. The platform is very responsive and feels especially fluent using touch input. Apps should also be made as responsive as possible. Service access in Windows 8 apps therefore is all done asynchronously. This was also the case in Silverlight using callbacks. One thing that bothered me in this model is the fact that when we have a lot of sequential calls, the code tends to get messy. For example, we download orders; in the callback of this, we download order items for each order; in the callback of that... and so on.

The development languages teams have been focusing on making async development easier. In C# 5, the await/async pattern has been introduced. This allows writing asynchronous code in a more synchronous manner. Take a look at the code below. The code does an async operation, however, apart from the await keyword, it looks just like some plain sequential code!

try

    HttpResponseMessage response = await httpClient.GetAsync(String.Format(searchUrl, api_key, SearchTextBox.Text));

    ParseFlickrResponse(response);

catch (HttpRequestException hre)

    ResultTextBlock.Text = hre.Message;

Internally, the compiler builds a state machine. A blog post on MSDN explains in-depth what is happening behind the scenes when you use async/await.

Once we got in the response, we get access to the data. Depending on the data source, we need to act differently on the result. If the result is XML, we can parse the data using perhaps LINQ-To-XML. With the objects materialized, we can use the data in our UI, probably in a data-binding scenario.

With the principles explained, let’s look at using an ASMX and a WCF service from Windows 8.

Accessing ASMX services from Windows 8 apps

The services many of us wrote as their very first services were web services (ASMX services). Plain web services are still being written today and many are still being used. How can we use them from Windows 8 apps?

The good news is that we can access these services without any change whatsoever. When connecting to an ASMX service from Windows 8, we perform the following steps, similar to what we did in Silverlight:

Create a service reference to the *.wsdl file exposed by the service
Based on this file, Visual Studio will generate a service reference (the proxy class). Although this is similar, the code generated in the proxy class is different. Take a look at the Reference.cs file (part of it is shown below). All the generated methods are now Task based. Task is the very base of the await/async pattern (only methods that return void or Task can be awaited).

public System.Threading.Tasks.Task GetWeatherInformationAsync() {

    ASMXServiceSample.WeatherService.GetWeatherInformationRequest inValue = new ASMXServiceSample.WeatherService.GetWeatherInformationRequest();

    return ((ASMXServiceSample.WeatherService.WeatherSoap)(this)).GetWeatherInformationAsync(inValue);

public System.Threading.Tasks.Task GetCityForecastByZIPAsync(string ZIP) {

    return base.Channel.GetCityForecastByZIPAsync(ZIP);

public System.Threading.Tasks.Task GetCityWeatherByZIPAsync(string ZIP) {

    return base.Channel.GetCityWeatherByZIPAsync(ZIP);

Use the proxy methods in an asynchronous manner (based on the generated Task methods in the proxy).

Let’s take a look at doing this in a sample. In Visual Studio 2012, create a new Windows 8 application named ASMXServiceSample.

For the service, we are going to use a public ASMX endpoint: http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl. Copy this URL in the Add Service Reference dialog and click Go. Visual Studio will try reading out the WSDL file. Enter the name WeatherService for the namespace. If all goes well, the proxy will be generated for you. Open the Reference.cs file and notice the Task-based methods. This code can now be used in combination with the await/async pattern.

Notice that no configuration code is generated in the Windows 8 application. The idea here is that apps are going to be distributed from the store anyway, so the use of configuration, which is compiling and then changing settings, is not applicable with Windows 8 apps. Instead, a method is generated in the proxy class named ConfigureEndpoint:

static partial void ConfigureEndpoint(System.ServiceModel.Description.ServiceEndpoint serviceEndpoint,

    System.ServiceModel.Description.ClientCredentials clientCredentials);

This method is partial, so we can use it from our own code to pass configuration code if needed. The configuration changes we would do normally (for example in a Silverlight application) will now be done in code using this method.

Let’s now take a look at using this service. In the MainPage.xaml of the application, add the following code:

<Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">

    <StackPanel Margin="30" Orientation="Vertical">

        <Button x:Name="backButton" Click="GoBack" Style="{StaticResource BackButtonStyle}"/>

        <TextBlock Text="Enter zip" FontSize="25">TextBlock>

        <TextBox Name="ZipCodeTextBox" Width="300" >TextBox>

        <Button Content="Load weather" Name="LoadWeatherButton" Click="LoadWeatherButton_Click_1">Button>

        <TextBox IsEnabled="False" AcceptsReturn="True" TextWrapping="Wrap" Name="WeatherTextBox"

            Width="300" Height="200" HorizontalAlignment="Left" Margin="20">TextBox>

    StackPanel>

Grid>

The UI is very simple and allows for entering a US ZIP code. The response will be shown in the WeatherTextBox. Some code needs to be added to the click event of the Button. Let’s take a look.

private async void LoadWeatherButton_Click_1(object sender, RoutedEventArgs e)

    StringBuilder builder = new StringBuilder();

    WeatherService.WeatherSoapClient client = new WeatherService.WeatherSoapClient();

    WeatherReturn result = await client.GetCityWeatherByZIPAsync(ZipCodeTextBox.Text);

    if (result.Success)

        builder.Append(String.Format("{0}, {1}\n", result.City, result.State));

        builder.Append(String.Format

            ("\n\nConditions - {0} \nTemperature - {1}F \nRelative Humidity - {2} \nWind - {3} \nPressure - {4}",

                result.Description, result.Temperature, result.RelativeHumidity, result.Wind, result.Pressure));

        WeatherTextBox.Text = builder.ToString();

    else

        WeatherTextBox.Text = "City not found";

We start by instantiating the proxy class (new WeatherService.WeatherSoapClient()). Then we use the magic of await. In Silverlight, we would write the callback and then call the service using the *Async method. However here, we use the await keyword. This makes sure that all code that comes after it, isn’t executed until the call is returned. Notice that the method itself is marked with async since we are using await inside of it.

The result of the service call is an instance of type WeatherReturn, as defined by the service. We use this object to read out the weather and display it on the UI. If you run the sample now and enter a US ZIP code, you should get a response.

If you can’t access the service, take a look at the capabilities of the Windows 8 app by opening the Package.appxmanifest file. Under the capabilities tab, the Internet (Client) capability should be enabled.

There we go, we have our first service-enabled Windows 8 application running. Great! Let’s know look at what happens if we want to use WCF. In most cases, you’ll be using WCF instead of ASMX, that’s for sure!

Accessing WCF services from Windows 8 apps

Working with WCF in Windows 8 apps is pretty similar to working with ASMX. However, not every type of WCF service is supported: only the following bindings are supported from a Windows 8 application:

BasicHttpBinding
NetTcpBinding
NetHttpBinding
CustomBinding

This means indeed that we have pretty much the same options as we had in Silverlight. Services using the BasicHttpBinding are supported (which is basically what ASMX uses). The wsHttpBinding isn’t supported, so for security, we have to look at other solutions (we’ll look later in this article series at how we can secure communication between a Windows 8 app and a service). The CustomBinding can be used for example if you want to use BinaryEncoding. For a complete rundown on the specifics that are supported in Windows 8 apps, take a look at the following link.

Let’s look at a sample. Create a new Windows 8 app and name it WCFServiceSample. Add an empty ASP.NET web application to the solution (WeatherSite) and add a WCF Service to the project (WeatherService). In the service contract (IWeatherService), add the following code (which is some very basic WCF code using a ServiceContract and a DataContract):

[ServiceContract]

public interface IWeatherService

    [OperationContract]

    Weather GetCityWeatherByZip(string zipCode);

[DataContract]

public class Weather

    [DataMember]

    public bool Success { get; set; }

    [DataMember]

    public int Temperature { get; set; }

    [DataMember]

    public string WeatherDescription { get; set; }

In the implementation of the contract, add the following code:

public Weather GetCityWeatherByZip(string zipCode)

    switch (zipCode)

        case "12345": return new Weather() { Success = true, Temperature = 15,

            WeatherDescription = "Rainy, typical Belgian weather" };

        case "90210": return new Weather() { Success = true, Temperature = 25,

            WeatherDescription = "Sunny all day long" };

        default: return new Weather() { Success = false, Temperature = 0,

            WeatherDescription = "In your location, there's not weather... We don't know what happened" };

In the Windows 8 app, add a service reference in the same way as you did with the ASMX service. We can now use the proxy from code as follows:

StringBuilder builder = new StringBuilder();

WeatherService.WeatherServiceClient client = new WeatherService.WeatherServiceClient();

Weather result = await client.GetCityWeatherByZipAsync(ZipCodeTextBox.Text);

if (result.Success)

    builder.Append(String.Format("Temperature: {0} °C, \nWeather description: {1}\n", result.Temperature, result.WeatherDescription));

    WeatherTextBox.Text = builder.ToString();

else

    WeatherTextBox.Text = "City not found";

As you can see the code is very similar. Behind the scenes, this service uses the BasicHttpBinding (which is the default when adding a new service). That’s the reason why we can use it from Windows 8!

Summary

We have covered the basics of communicating with services in Windows 8 apps. In the next article, we’ll look at other types of services to communicate with, including REST services. Stay tuned!

About the author

Gill Cleeren is Microsoft Regional Director (www.theregion.com), Silverlight MVP (former ASP.NET MVP) and Telerik MVP. He lives in Belgium where he works as .NET architect at Ordina (http://www.ordina.be/). Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd Berlin 2010, TechDays Belgium – Switzerland - Sweden, DevDays NL, NDC Oslo Norway, SQL Server Saturday Switzerland, Spring Conference UK, Silverlight Roadshow in Sweden, Telerik RoadShow UK… He’s also the author of many articles in various developer magazines and for SilverlightShow.net and he organizes the yearly Community Day event in Belgium. He also leads Visug (www.visug.be), the largest .NET user group in Belgium. Gill is the author of “Silverlight 4 Data and Services Cookbook”. In 2012, the second edition, “Silverlight 5 Data and Services Cookbook” was released.

You can find his blog at www.snowball.be.

Twitter: @gillcleeren

Windows Phone + SignalR = Awesome Possibilities!

editorial@silverlightshow.net (Samidip Basu ) — Mon, 27 Feb 2012 04:29:00 GMT

Real-time communication. Many software applications on variety of platforms & form factors have a genuine need for it. But persistent networks, real-time connectivity & asynchrony continue to challenge us developers in building such applications. Is there a silver lining? Could we have near-real-time communication in our mobile apps? Imagine the possibilities.

Download Source Code

Live Demo

Now, let’s do something a little fun before we get to the crux of what this article is about.

Don't miss...

All SilverlightShow Ebooks

How about a live demo of the sample application in action? Works from anywhere on earth with a data connection; in fact, more & diverse the user demographics, the merrier. Let’s do this:

This demo will work with your Windows Phone emulator; but better with your unlocked Windows Phone that can side-load apps, given XAP or source code.
Download the Source Code & extract the Windows Phone solution.
Load in Visual Studio, build & Deploy to emulator/phone.
The sample Windows Phone app essentially shares your location & connects you to a backend SignalR server for continuous real-time chat.
Go to http://signalrserver.cloudapp.net/ and keep it open.
Fire up the app and give yourself a name for the Chatroom.
Share your location & join the fun.
If on a Windows Phone, you should see a pushpin on the Bing map for your actual location (if allowed by your settings). On the emulator, you’ll start out at the mothership, that is, Seattle. Feel free to use the location simulator to fake your position.
See yourself pop up in the chat dialog box?
Now fire away what you want to say .. no profanity please.
See what you say show up in your phone’s chat dialog & on the Server almost immediately? Fun, eh?
Exit the chatroom and you’ll see yourself leave, along with a disappearing pushpin on map.

The result should be something like this:

I’m hoping if we keep the site running, we can see Pushpins show up on different parts of the world map; the Bing map used should zoom in & out to accommodate all pins. Having said that, the server side code isn’t hosted on massive hardware. I’ll try to keep it up; but if load or other issues force it down, please feel free unpack the server code & run it locally. It is a simple MVC3 app that should run just fine on your machine. Only change you would have to do is to point your Windows Phone app to Localhost, instead of the above server. So, let’s hope the site stays up & we can see folks from different places show up on live map & chatroom.

Introduction

SignalR is an async persistent connection library for client-server communication that aids in building real-time, multi-user connected applications across multiple platforms. The connection between clients & server is persisted over best possible transport mechanism, which could be a combination of long polling, periodic polling & sockets. The point is the transport layer is abstracted away to provide a seamless persistent connection for ease of development in making connected applications across the web, mobile & other form factors.

SignalR was started by Damian Edwards & David Fowler from the ASP.NET team and is now an OSS on GitHub (https://github.com/SignalR/SignalR). Want to chat with these & other cool folks working with SignalR? Join the conversations @ http://jabbr.net/#/rooms/signalr. The easiest way to start using SignalR is to utilize the Nugets as need in your application. They are:

SignalR - Package for SignalR.Server and SignalR.Js
SignalR.Server - Server components needed for SignalR endpoints
SignalR.Js - Javascript client for SignalR
SignalR.Client - .NET client for SignalR
SignalR.Ninject - Ninject dependeny resolver for SignalR

These can be incorporated in your project by using the visual Nuget Library Manager or the command-based Management console. This one statement gets you all dependencies:

While there are other technologies that have tried to solve the real-time communication problem, like Socket.IO or HTML5 WebSockets, few do it as simply as SignalR and support cross-platform between the web and mobile platforms like Windows Phone, iOS & Android (through Mono). While the low-level PersistenceConnection class might give you more control, most times the abstraction over it called the Hub class & your implementation of it, will provide easy persistence between client & Server. Want to learn more about SignalR? Try these wonderful posts:

The Sample

So, having learnt a little about SignalR, do you think it would work with and have applications in Windows Phone development? Absolutely! Real-time communication with a backend server on a personal device like the Windows Phone has potentially tons of ways to leverage the technology in Apps. Allow me to show you two here – mapping Windows Phone App users across the globe and real-time chat dialog between multiple Windows Phones & the web. The rest is up to your imagination ..

The Server

You obviously have choices here. I started with a default MVC3 web application; but wanted to change the look to showing mapping & chat dialog. First up, let’s get it ready to be a SignalR server. Here’s how to add the Nuget package:

With that, we know what a Hub is. Let us extend it to make something our own. We essentially want to uniquely keep track of Windows Phone users using our app; so let’s define a class for the phone clients:

// Individual Phone clients.

public class PhoneClient

{

    public string PhoneClientId { get; set; }

    public float Latitude { get; set; }

    public float Longitude { get; set; }

}

Next, let’s add functionality to add phone clients to Hub, disconnect & broadcast messages to all:

// The Hub of communication.

public class MessagingHub : Hub

{

    private static List PhoneClientList = new List();        

  

    public void JoinFromPhone(string phoneID, float latitude, float longitude)

    {

        PhoneClient phoneClientToAdd = new PhoneClient();

        phoneClientToAdd.PhoneClientId = phoneID;            

        phoneClientToAdd.Latitude = latitude;

        phoneClientToAdd.Longitude = longitude;

  

        PhoneClientList.Add(phoneClientToAdd);

        Clients.addClient(phoneClientToAdd);

        this.Caller.addClients(PhoneClientList.ToArray());

    }

  

    public void Disconnect(string phoneID)

    {

        PhoneClient client = null;

  

        foreach (PhoneClient existingClient in PhoneClientList)

        {

            if (phoneID == existingClient.PhoneClientId)

            {

                client = existingClient;

                break;

            }

        }

  

        PhoneClientList.Remove(client);

        Clients.removeClient(client);

    }

  

    public void PushMessageToClients(string message)

    {

        Clients.addChatMessage(message);

    }        

}

Wondering what some of the function calls are within our Hub? Well .. that’s the magic! These are actually JavaScript methods defined in our web UI view. So, let’s shoot for a UI like this (in the Index view off our Home controller).. Chat dialog on left & Bing Maps to show the pushpins on the right:

Here’s what’s on the view, along with subtle styling included in the downloadable code:

1:

2:

3:

4:

5:

   6: 'container'>

   7:     'chat'>

   8:         Chatroom:

9:

  10:         "text" id="message" maxlength="20" />

  11:         "button" id="broadcast" value="Broadcast" />

  12:         "button" id="clear" value="Clear" />

13:

  14:         "chatdialog">

15:

  16:     'map'>

17:

18:

  19: "legend">

  20:     for="userCount">Mapped Users:

  21:     "userCount">0

22:

The Bing Maps on the page would be using the Bing Maps Ajax/JavaScript SDK. If you need to use this on your own, please make sure to get yourself a developer ID that you could pass along to Bing; get it HERE.

Now, most of the connectivity magic offered by the SignalR server will be in the code bits below. You’ll see how we open a connection to our SignalR Hub from the web client and define JavaScript methods to manipulate the UI that will be used by the Hub. You’ll notice how we add/remove PushPins on the map using JavaScript & location of phone clients joining the Hub. Also, you’ll see the code sending off Chat messages typed in from the web and appending those received from the server. So, here goes:

1:

The Windows Phone Client

Now that we have the SignalR server all set up and waiting for interaction from phone clients, let us develop our Windows Phone client app. We’ll build a regular one page Windows Phone application just to demo functionality & connectivity to the SignalR Hub. Let’s begin by adding the appropriate SignalR nuget as below:

As we launch the app, we ask for a one-time user name so the phone client can be identified in the chatroom. For brevity, let us skip showing the simple XAML markup; you may find it in the downloadable code. Both UIs as below:

As the user indicates with button click that he/she wants to join, we use location awareness in Windows Phone to figure out current geo-coordinates of the user with a physical device or read mock emulator inputs. Here’s some code:

private GeoCoordinateWatcher gcw;

private double phoneLatitude;

private double phoneLongitude;

  

private void connectButton_Click(object sender, RoutedEventArgs e)

 {

     if (gcw == null)

     {

         // Look for present geo-location with GPS.

         gcw = new GeoCoordinateWatcher(GeoPositionAccuracy.High);

         gcw.MovementThreshold = 10;

         gcw.StatusChanged += new EventHandler(gcw_StatusChanged);

     }

  

     gcw.Start();            

 }

Once we have location, it’s time to fire up the reference to the SignalR server and try to connect. Here’s the sample code:

IHubProxy SignalRServerHub;

HubConnection connection = new HubConnection("http://localhost:49968/");

  

private void gcw_StatusChanged(object sender, GeoPositionStatusChangedEventArgs e)

 {

     if (e.Status == GeoPositionStatus.Ready)

     {

         // Get position from watcher & stop it to conserve battery.

         phoneLatitude = gcw.Position.Location.Latitude;

         phoneLongitude = gcw.Position.Location.Longitude;

         gcw.Stop();

  

         // Reference to SignalR Server Hub & Proxy.                      

         var messagingHub = connection.CreateProxy("SignalRServer.MessagingHub");

         SignalRServerHub = messagingHub;               

  

         // Fire up SignalR Connection & share location.  

         connection.Start().ContinueWith(task =>

         {

             if (task.IsFaulted)

             {

                 // Oopsie, do some error handling.

             }

  

             // Join the Server's list of mapped clients.

             messagingHub.Invoke("JoinFromPhone", deviceID, phoneLatitude, phoneLongitude).Wait();

  

             // Tell the chatroom that you joined.

             SignalRServerHub.Invoke("PushMessageToClients", App.Current.userName + " just joined!").Wait();                  

         });

      }

   }

Notice how we build a proxy on the fly (not tight-binding though) and invoke the “JoinFromPhone()” method of the server from the phone app, passing in some identifying information & location coordinates. The point is, you can pass in whatever your server needs. The unique qualifier that we pass in for every phone client to the server is the unique Device ID of the phone. Once pinged, the SignalR Hub wakes up, adds the incoming phone client to an internal collection (which you can persist) and reaches back to each web client (MVC3 view) to invoke some JavaScript functions that actually add a Pushpin on the map. Next up, we also announce on the Chatroom that a new user has joined the Hub by invoking the “PushMessageToClients()” server method. Simple enough, right?

When the user types in some content and hits the Chat button, we got to let the SignalR server know, so that the chat message gets posted on the web front-end & all connected Windows Phone clients. Here’s how we achieve that .. notice that we are making some of these server calls on background threads so as to not hose up our UI:

private void chatButton_Click(object sender, RoutedEventArgs e)

 {

     if (chatTextbox.Text != string.Empty && chatTextbox.Text != null)

     {

         // Fire off background thread to post message to server Chatroom.

         chatMessage = chatTextbox.Text.Trim();

         chatTextbox.Text = string.Empty;

         ChatBackgroundDataWorker.RunWorkerAsync();

     }

 }

  

private void ChatBackgroundDataWorker_DoWork(object sender, DoWorkEventArgs e)

 {

     // Post message to server chatroom.

     SignalRServerHub.Invoke("PushMessageToClients", chatMessage).Wait();

     chatMessage = string.Empty;

 }

Now, this takes care of the chat message posting part where the server informs all other clients. However, if someone posts a chat message from the web front-end or other phone clients, how does our app know to update the chat dialog with content? There has to be a trigger, right? Unlike JavaScript clients which the SignalR server can directly reach out to in case something of interest happens, there isn’t an easy proposition for .NET clients since we do not have a reference. But, we do have a persistent connection and there is an “On” method on the connection that can be rigged up to fire anytime a certain event happens on the server. Let us do that any time the server posts a message to all clients. Here’s the code .. you’ll be surprised how instantaneously this mechanism posts the chat message to all connected Windows Phone clients:

// Listen in on when Server posts anything to Chatroom.

 SignalRServerHub.On<string>("addChatMessage", message =>

 {

     // Add to local ChatRoom.

     chatDialog.Text += "\r\n";

     chatDialog.Text += message.Trim();

 });

Now, when you are done chit-chatting with your fellow geeks, you would like to disconnect officially and take your Pushpin out, right? Let’s add this code to disconnect, so that the corresponding Disconnect method is fired on the server. Again, notice how we do this on the background thread and officially sign out of the chatroom:

private void disconnectButton_Click(object sender, RoutedEventArgs e)

{            

    DisconnectBackgroundDataWorker.RunWorkerAsync();

  

    chatTextbox.IsEnabled = false;

    chatButton.IsEnabled = false;

    disconnectButton.IsEnabled = false;

    connectButton.IsEnabled = true;

}

  

private void DisconnectBackgroundDataWorker_DoWork(object sender, DoWorkEventArgs e)

{

    // Send Farewell to Chatroom.

    SignalRServerHub.Invoke("PushMessageToClients", App.Current.userName + " just left!").Wait();

  

    // Disconnect from Hub.

    SignalRServerHub.Invoke("Disconnect", deviceID).Wait();

}

Conclusion

That’s it. A functional Windows Phone client that connects to a SignalR server backend and allows us to see the interactions on a web front-end. The SignalR magic simply provides the persistent connectivity through whatever transport means feasible. Now, could there be potential benefit in leveraging such technology in our Windows Phone apps? Think, think ...

About the Author

Samidip Basu (@samidip) is a technologist & gadget-lover working as a Manager & Solutions Lead for Sogeti USA out of the Columbus Unit. With a strong developer background in Microsoft technology stack, he now spends much of his time in spreading the word to discover the full potential of the Windows Phone platform & cloud-backed mobile solutions in general. He passionately runs the Central Ohio Windows Phone User Group (http://cowpug.org), labors in M3 Conf (http://m3conf.com/) organization and can be found with at-least a couple of hobbyist projects at any time. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com.

SkyDrive usage through Live SDK on Windows Phone

editorial@silverlightshow.net (Samidip Basu ) — Mon, 19 Dec 2011 07:34:25 GMT

This article is also available in print (Word, PDF) and e-reader formats (MOBI, EPUB).

Download all formats, including source code.

Guess how many people use Live Services? 500 million plus! And when our applications connect to the same services, they start feeling right at home with what our users are already used to. Microsoft recently opened the Live Connect APIs, along with some SDKs for 3rd party applications on desktop/web/mobile platforms to leverage the cloud offerings from Live Services.

Don't miss...

All SilverlightShow Ebooks

In this short article, we take a look at how we could get started using the Live Connect API from our Windows Phone applications and interact with SkyDrive storage through the new Live SDK.

Download Source Code

[Please note that unlike other Demo solutions, you simply cannot hit F5 to run it. For obvious reasons, I have had to strip out references to my personal SkyDrive; so you would have to get yourself a client ID & make a one-word change before running the solution. Steps explained below.]

Introduction

The new Live APIs expose information around the following .. more information @ Live Connect Developer Guide:

SkyDrive -- This is for working with files & media; we can read/write against the user's SkyDrive files/folders/albums. SkyDrive offers the perfect cloud storage for Windows Phone applications to push persistence to the user's SkyDrive or to act as back-up storage.
Hotmail -- These sets of APIs expose the users contacts & calendars for read/writes.
Messenger -- These APIs are for use in instant messaging. We can read user's current status & communicate with user's buddies.
Windows Live ID -- This acts as a sort of Access Control Service that we could use to authenticate users & access their Live profile information.

The Live Connect APIs use standard protocols such as HTTP, OAuth 2.0, JSON and XMPP to make it easy working with them across multiple platforms. To leverage the APIs, we primarily use Representational State Transfer (REST) requests which return information in JSON.

While any of the above classes of APIs may be useful from a Windows Phone application, in this article we shall focus on the SkyDrive APIs, which arguably would be the most commonly used. No longer would developers need to spin up storage in cloud to augment their solutions; we can simply leverage the user's SkyDrive which has the additional benefit of user's accessibility & familiarity.

Getting Started

So, let's start integrating the Live Connect SDK into our Windows Phone application:

While the standard technologies of HTTP/REST/JSon make it easy to work with in any platform, there is some additional help in the form of wrapper SDKs for Windows Phone & Windows 8. Let's grab the Windows Phone Live SDK first.
Next, to have Live Connect recognize requests from our Windows Phone App, we need an unique identifier, called the Client ID. So, let's head over to the Live Connect App Management site & create a new application to interact with Live Services.
The new application will be registered with a Client ID, along with a Client Secret & Redirect Domain (that you type in). The two latter ones are not strictly needed for Windows Phone integration. The end result should be something like this:

Live Connect is a combination of several services allowing access to different categories of information. These are organized into what's called Scopes, and explicit declaration & user permission is required for our App to access the categorized information; as a good practice, we should never ask for more than what our App actually needs. For more information, please see Scopes & Permissions.
Users need to signed in with their Live Credentials & provide consent to utilize their SkyDrive, before we can leverage Live Connect APIs to manipulate files/folders in SkyDrive. While there are several ways to achieve this, in the XAML/C# world of Windows Phone, the easiest is to utilize the built-in Sign-in control in the SDK. Before you use it, make sure to Add Reference to these two libraries:

Next,, if you're in the XAML Designer view & you don't see the Sign-in control in your Toolbox, here's how to add it. The obvious benefit of using the Sign-In control is that we do not need to write the low-level HTTP RESTful GET calls to authenticate & authorize our user; the log-on UI comes up automatically & the client classes hang on to the access tokens passed back from the sign-in control for utilization in future requests.

The Demo App

So, let's write a simple Windows Phone application that allows the user to sign in & see/insert files in one's SkyDrive storage. Here's some XAML on our MainPage.xaml to show the sign-in control. Watch the use of scopes to declare what we want access to:

"ContentPanel" Grid.Row="1" Margin="12,0,12,0">

     "Vertical" >

         "Please sign-in and allow access to your SkyDrive!" Margin="20" TextWrapping="Wrap" Width="450" FontSize="30"/>

         "btnSignin" ClientId="Your_Client_ID" Scopes="wl.signin wl.basic wl.skydrive wl.skydrive_update" 

                        RedirectUri="Your_Redirect_URI" Branding="Windows" TextType="SignIn" SessionChanged="btnSignin_SessionChanged" 

                        HorizontalAlignment="Center" VerticalAlignment="Top" />

         "txtLoginResult" HorizontalAlignment="Center" Margin="0,20,0,0" FontSize="30" Style="{StaticResource PhoneTextAccentStyle}"/>

         "txtWelcome" HorizontalAlignment="Center" Margin="0,20,0,0" FontSize="30" Style="{StaticResource PhoneTextAccentStyle}"/>

         

                 Click="btnShowContent_Click"/>

         

                 Click="btnAddFile_Click"/>

     



The resultant UI before the user signs in as as follows. Also, on first usage of the sign-in button, the user will be prompted to sign-on to Windows Live and provide one-time OAuth access to our application, as demonstrated below:

And here's some C# code to handle sign-on attempts. We use the wl.signin to log the user in & wl.basic to greet the user after reading some basic identifying information:

private void btnSignin_SessionChanged(object sender, LiveConnectSessionChangedEventArgs e)

{           

    if (e.Status == LiveConnectSessionStatus.Connected)

    {

        client = new LiveConnectClient(e.Session);

        App.Current.LiveSession = e.Session;

        this.txtLoginResult.Text = "Signed in.";

        this.txtWelcome.Visibility = System.Windows.Visibility.Visible;

        this.btnShowContent.Visibility = System.Windows.Visibility.Visible;

        this.btnAddFile.Visibility = System.Windows.Visibility.Visible;

  

        client.GetCompleted += new EventHandler(OnGetCompleted);

        client.GetAsync("me", null);

    }

    else

    {

        this.txtLoginResult.Text = "Not signed in.";

        this.txtWelcome.Visibility = System.Windows.Visibility.Collapsed;

        client = null;

    }           

}

  

void OnGetCompleted(object sender, LiveOperationCompletedEventArgs e)

{

    if (e.Error == null)

    {

        if (e.Result.ContainsKey("first_name") &&

            e.Result.ContainsKey("last_name"))

        {

            if (e.Result["first_name"] != null &&

                e.Result["last_name"] != null)

            {

                this.txtWelcome.Text =

                    "Hello, " +

                    e.Result["first_name"].ToString() + " " +

                    e.Result["last_name"].ToString() + "!";

            }

        }

        else

        {

            txtWelcome.Text = "Hello, signed-in user!";

        }

    }

    else

    {

        txtWelcome.Text = "Error calling API: " +

            e.Error.ToString();

    }

}

Did you notice a couple of fun things? Once connected, we store the instance of the LiveConnectClient as a property on our App object; this allows for reuse throughout the application. Also, the RESTful Live APIs support several shortcuts that include “me” to indicate the current user. And here's the UI we are shooting for, after sign-on:

SkyDrive Files

Now that we have permission to user’s Live Services, let’s dig into SkyDrive. Most of us are used to storing documents & media on SkyDrive, and have the content show up in our Windows Phone, or folders kept in sync between multiple PCs/Macs through Live Mesh. With programmatic access to SkyDrive, we have access to a lot of operations, such as:

Create/Read/Update/Delete Folders
Do the same with Albums, a special folder to handle media efficiently
Traversing Directories
Upload/Download Files
Read/Update file/folder properties
Move/copy files/folders etc.

For much more information & details, please see SkyDrive Developer Center. For our Demo application, let us do the simple operations of reading files/folders from user’s SkyDrive root & adding files to it. Here’s how we fetch & list all content from the root directory on user’s SkyDrive:

public class SkyDriveContent

{

 public string Name { get; set; }

 public string Description { get; set; }

}

  

// Code in Phone Page.

List ContentList = new List();

  

private void PhoneApplicationPage_Loaded(object sender, RoutedEventArgs e)

{

    LiveConnectClient client = new LiveConnectClient(App.Current.LiveSession);

    client.GetCompleted += new EventHandler(clientDataFetch_GetCompleted);

    client.GetAsync("/me/skydrive/files");

}

  

void clientDataFetch_GetCompleted(object sender, LiveOperationCompletedEventArgs e)

{

    if (e.Error == null)

    {

        List<object> data = (List<object>)e.Result["data"];

        foreach (IDictionary<string, object> content in data)

        {                   

            SkyDriveContent skyContent = new SkyDriveContent();

            skyContent.Name = (string)content["name"];

            ContentList.Add(skyContent);                   

        }

  

        this.contentList.ItemsSource = ContentList;

    }

}

And, here’s the resulting UI that we bind the results to, simply showing the content names from SkyDrive root:

Did you notice how we used “me/skydrive/files” to fetch all content from user’s SkyDrive root? Every folder/album in SkyDrive has a unique ID, visible when we inspect the folder properties. From this point on, we can easily dive into any folder & traverse the user’s SkyDrive by making requests with Folder_ID/files or Album_ID/files. Having fun?

Now, how about putting files in user’s SkyDrive? Sure, we can .. here’s some simple UI & code to add a file to the root of the user’s SkyDrive directory:

private void btnSave_Click(object sender, EventArgs e)

{

    string fileName = this.fileName.Text.Trim();

    byte[] byteArray = Encoding.Unicode.GetBytes(this.fileContent.Text.Trim());

    MemoryStream fileStream = new MemoryStream(byteArray);

    

    LiveConnectClient uploadClient = new LiveConnectClient(App.Current.LiveSession);

    uploadClient.UploadCompleted += new EventHandler(uploadClient_UploadCompleted);

    uploadClient.UploadAsync("me/skydrive", fileName, fileStream );

}

  

void uploadClient_UploadCompleted(object sender, LiveOperationCompletedEventArgs e)

{

    if (e.Error == null)

    {

        Dispatcher.BeginInvoke(() =>

        {

            MessageBox.Show("Voila, Saved to the SkyDrive :)", "All Done!", MessageBoxButton.OK);                    

        });

    }

  

    this.NavigationService.GoBack();

}

So, what did we see? A simple upload location indicator of “me/skydrive” puts the file at the root directory. You can certainly put it in any folder of your choice, as long as you know the ID of the folder. For confirmation, surely authenticate yourself & check if the file addition did work on your SkyDrive. Did for our case :

Conclusion & Caveats

With great power, comes great responsibility! Let us not undermine the end-user’s faith in SkyDrive.
More specific details about SkyDrive File/Folder APIs can be found HERE.
Watch the BUILD session recording on Live Connect HERE.
SkyDrive is a fantastic reliable alternative to augment storage for our Windows Phone applications, and user’s immediately see the file/folders we add in their SkyDrive. More importantly, Office sync on Windows Phone, and the dedicated SkyDrive apps on Windows Phone, iPhone & iPad immediately make the files available to the user. The story gets even better with built-in support in Windows 8, but I digress
Needless to say, SkyDrive access requires network connectivity. So, this should not possibly be our primary means of storage on Windows Phones.

Summary

In this article, we talked about how to leverage the new Live Connect APIs, in particular, the Live SDK in our Windows Phone applications. We saw the usage of the Sign-in control to ask for user’s authentication & seeking permission to use specific resources through the Live API. SkyDrive access is now handy, with full support to traverse, read & manipulate content in user’s SkyDrive directories. So, what are you waiting for? Look up some documentation & enable SkyDrive access from your Windows Phone application, resulting in happy users & happier you!

I would appreciate any comments or concerns or how things could be done better. Thanks for reading & happy coding.

Cheers SilverlightShow!

About the Author

10 Laps around Silverlight 5 (Part 10 of 10)

editorial@silverlightshow.net (Michael Crump ) — Mon, 12 Dec 2011 21:50:15 GMT

This article is sponsored by Telerik RadControls for Silverlight. For similarly awesome content check out Telerik XAMLflix, your step-by-step guide to Telerik Silverlight and WPF controls. Get access to video tutorials, written tutorials, and tons of code!

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

More resources...

All SilverlightShow Ebooks

This article is Part 10 of the series “10 Laps around Silverlight 5.” If you have missed any other section then please see the Roadmap below.

To refresh your memory on what Silverlight is:

Microsoft Silverlight is an application framework for writing Rich Internet Applications.

The run-time environment is available as a plug-in for most web browsers and works on a variety of operating systems including Windows, Mac and Linux.

To recap what we learned in the previous section:

We took a look at several new controls in Silverlight 5 including: Double and Triple click support and ComboBox Type-Ahead.
We then took a deeper dive into the PivotViewer control as it is more complex than the others and provided additional links.

In this article, I am going to discuss several new features that did not fit in any of the above categories. We will discuss In-Browser HTML, PostScript and Tasks for TPL. Please review the Roadmap for the series before going any further.

The Roadmap for this Series

I’ve included the Roadmap for the series below as you may want to visit other sections as you learn Silverlight 5. I picked the following features as I thought that you may find them useful in your day-to-day work. If you want a specific topic covered then please leave it in the comments below.

1) Introduction to SL5 – This post which provides a brief history of Silverlight and relevant links.

2) Binding- Ancestor Relative Source Binding and Implicit Data Templates.

3) Graphics –XNA 3D API and Improved Graphics Stack.

4) Media - Low-Latency Sound using XNA and Remote Control and Media Command (Keys) Support.

5) Text - Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions.

6) Operating System Integration - Part 1 - P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust.

7) Operating System Integration - Part 2 - Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness.

8) Productivity and Performance - XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time.

9) Controls - Double and Triple click support, PivotViewer and ComboBox Type-Ahead.

10) Other items [This post] - In-Browser HTML, PostScript and Tasks for TPL.

In-Browser HTML

In Silverlight 4, we could use the WebBrowser control only in an “Out-of-Browser” application. This has changed in Silverlight 5 as we can now use the WebBrowser control in the browser (IE). It will however require that you make a few changes to your system. Let’s get started:

1) Update the registry – Locate the following keys:

If you running on a 32 bit machine,

HKEY_LOCAL_MACHINE\Software\Microsoft\Silverlight\

and if you are running on a 64-bit machine,

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Silverlight\

change the UpdateConsentMode from a 0 to 1.

2) Sign the XAP File - Right click on the Silverlight application and go to properties. Choose Signing and check the checkbox Sign the .XAP file. Now click on the button Create Test Certificate. Enter any password that you want and hit the OK button. Now click on the More Details button.

Click on the Install Certificate button. Clicking on the button brings up the Certificate Import wizard. Click on the Next button and choose Place all certificates in the following store. Click on the Browse button. This will show you a Certificate Store. Choose Trusted Publisher and finish the wizard. Now repeat the same step to install this certificate in Trusted Root Certification Authorities.

3) Enable Out-of-Browser and Require elevated trust when running in-browser. Right click on the Silverlight application and go to properties. Place a checkmark in Enable Out-of-Browser and Require elevated trust when running in-browser.

Now let’s switch over to the MainPage.xaml and replace the Grid with the following code:

<Grid x:Name="LayoutRoot" Background="White">

       <WebBrowser x:Name="webBrowser" Source="http://michaelcrump.net/"/>

Grid>

If we run our application now (using Internet Explorer), then we will see the WebBrowser control working inside of the browser.

Note: This will not work in Chrome, Safari, others (Only Internet Explorer).

You can also add html pages to your project and point the source to that file as well.

PostScript Vector Printing

In Silverlight 4, we had bitmap-based printing. This meant that every time a page was going to print that Silverlight 4 sent the bitmap representing the entire page to the printer. We quickly found out that this resulted in horrible performance for larger print jobs. Now in Silverlight 5 we have PostScript Vector printing. This provides us with a much faster solution. Let’s get started building a sample application that uses this features.

Let’s switch over to the MainPage.xaml and replace the Grid with the following code:

<StackPanel x:Name="LayoutRoot" Background="White" HorizontalAlignment="Center" VerticalAlignment="Center">

    <Button x:Name="basicVector" Click="basicVector_Click" />

    <Button x:Name="forceVector" Click="forceVector_Click" />

StackPanel>

We can navigate over to our MainPage.xaml.cs file and add in the following code snippet for our button event handlers:

private void basicVector_Click(object sender, RoutedEventArgs e)

{

    PrintDocument document = new PrintDocument();

  

    document.PrintPage += (s, ea) =>

    {

        StackPanel stPanel = new StackPanel();                

  

        for (int i = 0; i < 10; i++)

        {

            TextBlock tb = new TextBlock();

            tb.Text = "Basic Vector mode.";

  

            stPanel.Children.Add(tb);

        }

  

        ea.PageVisual = stPanel;

        ea.HasMorePages = true;

    };

  

    document.Print("Basic Vector Demo");

    

}

  

private void forceVector_Click(object sender, RoutedEventArgs e)

{

    PrintDocument document = new PrintDocument();

  

    document.PrintPage += (s, ea) =>

    {

        StackPanel stPanel = new StackPanel();

  

        for (int i = 0; i < 10; i++)

        {

            TextBlock tb = new TextBlock();

            tb.Text = "Forced Vector mode.";

  

            stPanel.Children.Add(tb);

        }

  

        ea.PageVisual = stPanel;

        ea.HasMorePages = true;

    };

  

    PrinterFallbackSettings settings = new PrinterFallbackSettings();

    settings.ForceVector = true;

    settings.OpacityThreshold = 0.7;

  

    document.Print("Forced Vector Print", settings);

}

In our first button, we have a basic PostScript Vector Printing job. We create a PrintDocument (which was also in SL4), then add a PrintPage with some basic text to it. We finally print the document using Vector printing with document.Print.

In our second button, we do the same thing but we call PrinterFallbackSettings and force the print job to print in Vector mode. We can also set the Opacity value by calling OpacityThreshold.

Tasks Parallel Library (TPL)

In short, TPL is to simply asynchronous methods. Silverlight 5 does not include the full TPL but it does provide Tasks and it’s related factories. Which is exactly what you want! Let’s get started.

We are going to use a sample XML file provided by Microsoft found here. Go ahead and download it and add it to your Web Project with the name of books.xml.

Next, Let’s go ahead and navigate over to our MainPage.xaml.cs file and add in the proper namespaces to use TPL. Next, we will add in the second code snippet:

using System;

using System.Linq;

using System.Net;

using System.Threading.Tasks;

using System.Windows;

using System.Windows.Controls;

using System.Diagnostics;

public MainPage()

{

    InitializeComponent();

    Loaded += new RoutedEventHandler(MainPage_Loaded);

}

  

void MainPage_Loaded(object sender, RoutedEventArgs e)

{

    string uri = "http://localhost:15863/books.xml";

  

    var request = HttpWebRequest.Create(uri);

  

    Task.Factory.FromAsync(

      request.BeginGetResponse, request.EndGetResponse, null)

      .ContinueWith(

        task =>

        {

            var response = (HttpWebResponse)task.Result;

            Debug.WriteLine("Content Type: " + response.ContentType);

            Debug.WriteLine("Content Length: " + response.ContentLength);

            Debug.WriteLine("Method: " + response.Method);

            Debug.WriteLine("Status Code: " + response.StatusCode);

            Debug.WriteLine("Status Description: " + response.StatusDescription);  

        });

}

Note: You will need to change the localhost port in the above code sample before proceeding.

Go ahead and run the application and then look at your Output window in VS2010. You should see the following information.

The thing to note here is Task.Factory.FromAsync. This creates a Tasks that represents a pair of begin and end methods that conform to the Asynchronous Programming Model Pattern.

Conclusion

At this point, we have taken a dive into all of the new features of Silverlight 5. Now that you are equipped with a solid understanding of what Silverlight 5 has to offer, you can begin to use this in your own applications. I want to thank you for reading this series and if you ever have any questions feel free to contact me on the various sources listed below. I also wanted to thank SilverlightShow.Net and Telerik for giving me the opportunity to share this information with everyone. I hope that you enjoyed this series and if you To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

Windows 8 XAML Metro Apps with OData - Part 1

editorial@silverlightshow.net (Samidip Basu ) — Wed, 07 Dec 2011 09:59:00 GMT

So, you have heard the buzz about the brave new world of Windows 8 from MSFT’s BUILD Conference! May be you even attended the wonderful SilverlightShow webinar about “Getting Started with XAML Development in Windows 8” by Gill Cleeren.

Don't miss...

All SilverlightShow Ebooks

Ready to get your hands muddy? In this short 2-part article series, we talk about how to get started towards writing data-driven (specifically OData) Windows 8 Metro apps with XAML & C#. Here’s what we’ll cover:

Part 1 – Handling of OData from our XAML Metro App [Consumption & Updates to OData source]
Part 2 – How to make your XAML App a well-behaved Windows 8 citizen [Artwork, Snapped Views, Contracts, Application Bar etc]

As always, the demo solution, along with all code samples is available for download through the link below:

Download Source Code

Introduction

At the BUILD Conference in August 2011, Microsoft launched Windows 8 .. the next iteration of Windows. It isn’t a forked world between desktop & mobile/tablet Operating Systems; rather “One OS to rule them all..” which runs on variety of form factors with touch-based interaction being a first-class citizen.

We could obviously talk a lot about Windows 8; but for the sake of the length of this blog post, let me refer you to 2 valuable resources:

BUILD Website @ http://www.buildwindows.com/. Great place to start would be the 5 Keynotes, followed by tons of recorded Session content.
Windows 8 Developer Home @ http://msdn.microsoft.com/en-us/windows/home. On this site is a link to download the Windows 8 Developer Preview – the latest Windows 8 bits along with Development tools. Also, as you get into serious Windows 8 Metro development, the samples from Microsoft & contributions from our fabulous community should be very valuable.

Also, check out the overall technology stack in Windows 8 below: [Source: Doug Seven’s Post]

A lot has been written in the past few months about Win RT & the development stack in Windows 8 .. simple web searches should get us lots of resources. For this article & the demo app, we will stick to the managed world of XAML UI & C# code running on .NET 4.5 on top of Win RT. There might be some rough edges .. but we are all trying to learn, right?

Prerequisites

To follow along or to try the Demo or build something similar yourself, you need the following:

Windows 8 Developer Preview running “on the metal” on some laptop/tablet.
Alternatively, you could also run Windows 8 in a VM (VirtualBox being the best fit at this time) or off a VHD.
Visual Studio 11 included as a part of Windows 8 Developer Preview. At this point, the templates to build Metro Apps aren’t available outside the Windows 8 bits.
Curiosity

The Data

Let’s try building a data-driven Metro App, shall we? For Demo purposes, I’m going to use a simple relational DB called “Demo” hosted in SQL Azure with just one table called “Team”, as shown below with schema/data:

So essentially, we want to keep track of Team Members with Names & TwitterHandles. How can we get this data easily into a Windows 8 Metro App? Why off course, OData !!

You may learn more about OData from http://www.odata.org/. I already have an OData Service built on top of our DB to expose the Team table data as an OData feed for consumption. Need to expose your data as OData? – Check out Michael Crump’s great series on Producing & Consuming OData in Silverlight & Windows Phone Applications.

Also, remember my article on Connecting Azure & Windows Phone through OData ? In that article, we talked about consuming OData from the same SQL Azure DB Table & also easily performing CRUD operations against data source through OData from a Windows Phone application. So essentially, we want to take the Windows Phone Demo application handling OData & port it over to being a Windows 8 Metro App in XAML & C#. You’ll soon realize that while we have to accommodate the UI having a lot more real estate in Windows 8, a lot of the coding artifacts are very similar or can be reused in the Windows 8 world with minor changes. If you have done Windows Phone Development, you should feel right at home in doing XAML Metro Apps!

So, here’s the OData service endpoint which provides access to our Table data in AtomPub (default) or JSon format:

The Metro App

So, now that we have a data source & an OData service on top of it exposing the data, let’s see how we may consume it in a Windows 8 Metro App. Let’s fire up Visual Studio 11 & make our appropriate selections as below:

The above selection gets us into a mode for building Metro Apps with XAML UI & C# code in a managed runtime. Just like in Windows Phone, the templates provided are your friends, as they get us a long way towards achieving Metro UI look & feel in our applications. For our demo, we shall choose to start with an empty application canvas & focus on fetching data into our app.

Now, since we have an OData service, it’ll be nice to Add a Service Reference to the service in our project so that we know the backend entities & can refer to them in code. Ouch – too soon The automatic proxy building against an OData service by adding a Service Reference isn’t quite ready in the Windows 8 tooling yet! So, we revert to the old-school way of adding our service reference into the project:

DataSvcUtil.exe /uri:Your_OData_Endpoint/out:TeamModel.cs /Version:2.0 /DataServiceCollection

As you could see, we used the DataSvcUtil tool (tucked away in your .NET Framework folder) to generate a proxy class which has all the entity bindings .. now we could simply drop the generated file into our project. Our project structure looks something like this .. the “Package.appxmanifest” file quite simply houses all your App configuration:

The UI

Don’t you wish you were working with a Team where every member is a Ninja? Well, let’s say that’s the case & we shall shoot for our Metro App UI to be something simple, like this:

The above screenshot is our Demo app running in the normal full-screen immersive UI mode. Notice how it is completely Chrome-free & puts content first. Just because we can clutter the UI with all kinds of controls, doesn’t mean that we should, right?

So, in our app, there is one & only XAML page that does the above rendering, that being MainPage.xaml. Here’s the XAML that drives the UI:

"TeamMetro.MainPage"
    
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    
 xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    
 xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    
 mc:Ignorable="d"
    
 d:DesignHeight="768" d:DesignWidth="1366">
    
  
    
 
    
 "LayoutRoot" Background="Chocolate">
    
     
    
     "Transparent" VerticalAlignment="Center" x:Name="fullMode">
    
     "fullTeamList" Margin="40" ItemsSource="{Binding WCFTeam}" Foreground="Blue" Background="Transparent">
    
         
    
             
    
                 "400,0,0,40" VerticalAlignment="Center" Orientation="Horizontal">
    
                     "ninja.png" Height="75" Width="75"/>
    
                     "{Binding Name}" Margin="10,0,0,0" FontSize="26" VerticalAlignment="Center"/>
    
                     " -- aka " FontSize="22" VerticalAlignment="Center"/>
    
                     "{Binding TwitterHandle}" Margin="10,0,0,0" FontSize="22" VerticalAlignment="Center"/>
    
                 
    
             
    
         
    
     
    
     
    
  
    
    
    
  
    


So, we essentially defined a ListBox & we are expecting it to be bound to some collection of Team members with appropriate property values. Did you notice that except for a few namespaces, the XAML markup is very similar to what we are used to seeing in Windows Phone & Silverlight applications? This is what should make you feel right at home .. there are off course, some Windows 8 specific UI controls, which can cover in a subsequent blog post.

Another point to note is that the XAML markup for Windows 8 Metro apps can be borrowed to a large extent if you have existing Windows Phone or Silverlight applications. In fact, if you have a a Windows Phone app in the Marketplace and simply want to port to over to the Windows 8 App Store, there are a fixed set of guidelines to do so, as explained here. However, we might need to be wary of a plain port-over & the UX of our Metro apps, since the Windows 8 tablet form factor will have substantially more real estate, which should absolutely be utilized. In our demo app, you see a simple list of data items consuming OData; while ok for a demo (see I excuse myself ), you ideally want to provide your users with a richer experience.

Fetching the Data

Now, this will be very interesting. One of the buzz terms with Windows Phone/Silverlight and now heavily so with Windows 8 is “fast & fluid” – which essentially means that your App may be doing some expensive operation; but to the end user interacting through Touch, it should always seem responsive. Asynchronous Programming is certainly not new & Windows Phone development very much enforces that; however, it may be a little painful at times, specially if you are marshaling data between threads or writing callback after callback.

Win RT enforces that any operation that might take more than 50 ms be done asynchronously, and this off course, extends to every web request our app might make. So, we are looking to fetch the OData feed asynchronously without blocking the UI thread.

Now, C# 5.0 running on .NET 4.5 framework tries to make it easy for us developers to do asynchronous programming through Async-Await patterns, so that we can get around not writing callback after callback or have to deal with thread marshaling. This however is a wider topic than this post – so please allow me to point you to some resources that should help understand this better:

I was intrigued about Asynchrony and wrote a lengthy post; if interested, you’ll find it HERE. So, let’s look at a few ways we can fetch data:

The Pure HTTP Way

In this approach, we make a basic HTTP Get call to our OData service endpoint & fetch data as Atom. This is simple, but we would have to manually parse the response to pluck out the data contents for binding to UI. Here’s some sample code .. watch the use of async-await to achieve asynchrony:

private async void LoadTeamThruXML()
    
{
    
    // Get Atom over HTTP.
    
    var client = new HttpClient();
    
    Uri teamDataURI = new Uri("Your_OData_Endpoint");
    
  
    
    try
    
    {
    
        HttpResponseMessage response = await client.GetAsync(teamDataURI);
    
  
    
        string xmlResponse = response.Content.ReadAsString();
    
        XDocument xDoc = XDocument.Parse(xmlResponse);
    
  
    
        // Do appropriate parsing.
    
        // LINQ to XML.
    
        IEnumerable teamCollection = from teamMember in xDoc.Descendants("Entry")
    
                                           select new Team
    
                                           {
    
                                               Name = teamMember.Element("Name").ToString(),
    
                                               TwitterHandle = teamMember.Element("TwitterHandle").ToString()
    
                                           };
    
  
    
        // Bind to UI.
    
    }
    
    catch (Exception ex)
    
    {
    
        // Oopsie
    
    }
    
}

The Threaded Way

One important aspect about Asynchrony is that it does not always mean multi-threading, as in parallelism. All the goodness of the Task Parallel Library is now built in and as we await on a Task, the underlying implementation may or may not spin up a new thread based on computing cycles needed. The point is, you should not have to care as a developer. However, if using Task.Factory, you are essentially carrying out synchronous operations on a worker thread without blocking the UI. So, here’s another way to fetch data .. notice how we can return a strongly-typed collection of Team members:

private async void LoadTeamThruOData()
    
{
    
    var client = new Demo(new Uri("Your_OData_Endpoint"));
    
    
    
    var results = await Task>.Factory.StartNew(() => FetchOData());
    
  
    
    // This fires only after we have a response back. 
    
    this.ParseAndBindData(results);
    
}
    
  
    
private IEnumerable FetchOData()
    
{
    
    Demo client = new Demo(new Uri("Your_OData_Endpoint"));
    
    return client.Teams.Execute();
    
}

Wrapped APM Way

Asynchronous Programming Model (APM) is the traditional way of doing asynchrony through BeginXX/EndXX patterns; but this lead us to write a lot of callbacks. In the new world, APM calls can be wrapped inside an Async-Await pattern to make asynchronous requests. Let’s look at some code:

private async void LoadTeamThruOData()
    
{
    
    var client = new Demo(new Uri("Your_OData_Endpoint"));
    
   
    
    var results = await Task>.Factory.FromAsync(client.Teams.BeginExecute(AnotherEndContinuation, client), ContinuationDelegate);
    
  
    
    // This fires only after we have a response back. 
    
    this.ParseAndBindData(results);
    
}
    
  
    
Func> ContinuationDelegate = EndContinuation;
    
private static IEnumerable EndContinuation(IAsyncResult result)
    
{
    
    Demo client = (Demo)result.AsyncState;            
    
    return client.Teams.EndExecute(result);
    
}
    
  
    
private static void AnotherEndContinuation(IAsyncResult result)
    
{
    
   // Do nothing here.
    
}

Now, the above code might look a little clunky, but the wrapping of the APM methods can be done through an Extension method to make reuse easier. Eventually with future updates, if we have a method Foo in our custom WCF Service, proxy integration should generate three method endpoints – BeginFoo, EndFoo & FooAsync. It is the last that we shall use comfortably with Async-Await patterns.

Data Updates?

So, by now we know how to fetch OData into a Windows 8 Metro app using XAML/C# and bind the results to a simple list. But what if we wanted to perform updates against the data source? That is absolutely possible since we are dealing with an OData service here. Unless blocked at the service side, OData will support full CRUD operations through the DataServiceContext & DataServiceCollection classes.

Now, let’s think about the UI for second. Just because we can put buttons & controls for data updates all over, doesn’t mean that we should. Common tasks should be presented in a minimalist fashion & accessible when needed. Accordingly, we revert to using the Windows 8 Metro Application Bar to add some metro buttons for allowing data manipulation. Let’s shoot for a UI like below .. we shall talk more about the Application Bar in the next article:

So, what happens when the user hits the Application Bar buttons? Simple – just like in Windows Phone, you can have event handlers assigned to each. Let’s see how we may delete a record & have it reflected in the OData data source, that is our Table data in SQL Azure. Here’s some code:

private void DeleteButton_Click(object sender, RoutedEventArgs e)
    
{
    
    if (this.fullTeamList.SelectedItem != null)
    
    {
    
        Team selectedTeamMember = (Team)this.fullTeamList.SelectedItem;
    
                        
    
        // LINQ to Context.
    
        var client = new Demo(new Uri("Your_OData_Endpoint"));
    
        var teamMemberToDelete = (from TeamMember in client.Teams
    
                                  where TeamMember.Name == selectedTeamMember.Name
    
                                  select TeamMember).First();
    
  
    
        // Delete backend entity.
    
        client.DeleteObject(teamMemberToDelete);
    
        client.BeginSaveChanges(new AsyncCallback(SaveDoneCB), client);               
    
    }
    
}
    
  
    
private void SaveDoneCB(IAsyncResult asyncResult)
    
{
    
    // Any error handling.
    
}

What about adding/editing records? Exactly the same way. Off of our “client” object above (which is in essence the DataServiceContext), you’ll see methods like AddObject & UpdateObject to insert/manipulate table records and then you simply need to call SaveChanges asynchronously to update the backend DB. You’ll see some sample code in the downloadable solution; but why not give it a shot yourself? You can get a lot of hints about how to perform CRUD operations against OData from a Windows Phone application from mine & Michael Crump’s articles HERE & HERE. So, go ahead & throw in a fresh XAML page to capture inserts/edits & fire away .

Summary

In this article, we talked about how to get started with Windows 8 Metro Apps with XAML/C# and we went on to consumption/updates of OData from a Windows 8 Metro application. We looked at a few techniques on how to do asynchronous programming in Windows 8 using the new C# 5.0 constructs of Async-Await. In the next part of article, we shall talk about taking the first steps towards making your Metro Apps feel at home in the Windows 8 Operating System.

I would appreciate any comments or concerns or how things could be done better. Thanks for reading & happy coding.

Cheers SilverlightShow!

About the Author

Samidip Basu (@samidip) is a technologist & gadget-lover working as a Manager & Solutions Lead for Sogeti out of the Columbus Unit. Having worked on WP7 since CTP days, he now spends much of his time in spreading the word to discover the full potential of the Windows Phone platform & cloud-based mobile solutions in general. He passionately runs the Central Ohio Windows Phone User Group (http://cowpug.org/), labors in M3 Conf (http://m3conf.com//) organization and can be found with at-least a couple of hobbyist projects at any time. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com/.

OData caching in Windows Phone

editorial@silverlightshow.net (Samidip Basu ) — Wed, 23 Nov 2011 03:53:00 GMT

OData seems to have a lot of promise in simplifying data access across multiple platforms by using fundamental technologies of HTTP and Atom/JSon. Using an OData source for data consumption/updates in your Windows Phone application?

Don't miss...

All SilverlightShow Ebooks

In this short article, we take a quick look at a data caching strategy in our Windows Phone applications while using an OData data source. While we talk about a Windows Phone solution in particular, these concepts are perfectly applicable when using OData on other mobile platforms.

As always, the demo solution, along with all code samples is available for download through the link below:

Download Source Code

Introduction

The Open Data Protocol (OData) is an HTTP-based protocol for querying and updating a data source. Based on the platform or type of application we are building, we have the option of using either Atom or JSon as our feed protocol of choice and then utilize support for filtering, sorting & paging in our application. Want to learn more? http://www.odata.org/is a great place to start. OData has now built up a nice ecosystem around it’s support, with proxy-building libraries in a variety of platforms; and it obviously lends itself very nicely to usage from mobile applications.

Also, just about any data source that .NET runtime can connect to, can be exposed as an OData feed. It is essentially a two-step process: First – put Entity Framework type Object Relational Mapping (ORM) on top of our data source, in particular the ADO.NET Entity Data Model; and Second – put a WCF Data Service on top of the data entities to expose a read-only/updateable feed for the data. Want to try it yourself? Michael Crump’s “Producing & Consuming OData..” series here is a great start. Want to leverage OData as you augment your mobile application with cloud support? My last two articles here & here should be decent starting points.

The Demo

One of the best ways to learn more about OData is to start playing with a live OData service. And what better example than that of Netfllix .. we all love movies, right? Now, Netflix worked with MSFT to expose their entire Movie/Shows catalog as a live OData feed, one that you can hit through the URL below:

http://odata.netflix.com/v2/Catalog/

Once we look up the catalog, we can see all the supported HTTP endpoints to get various information. Head over to the official Netlfix documentation here to learn more about the supported Metadata, filters & formats. For our demo purpose, we shall choose to do a very simple lookup against the Netflix OData catalog .. just to get a list of Genres. Take a guess how many Genres Netflix knows? – Close to 400 !!

So, we make a simple HTTP Get request through our browser to the following URI to get a list of Genres, in default Atom format. Since this is not huge amount of data, there is no continuation token & we get the whole catalog of Genres back in one request:

http://odata.netflix.com/v2/Catalog/Genres

So, let’s build a simple Windows Phone application which consumes the Netflix OData feed & pulls up the list of Genres programmatically. We begin with the default template of a Windows Phone application with a portrait page. One of the first things we do is to add a reference to the root of the Netflix OData service, so that the proxies are built & we can refer to the Netflix entities in our code. Here’s how & the resulting project structure:

Next, let’s add some code to our MainPage.xaml’s code-behind file so we can load the list of Netflix Genres:

using NetflixODataService; 

  

DataServiceCollection Genres { get; set; }

DataServiceContext context = new DataServiceContext(new Uri("http://odata.netflix.com/v2/Catalog/"));

  

public MainPage()

{

  InitializeComponent();

  this.LoadAndStoreGenres();

}

  

  

public void LoadAndStoreGenres()

{

    // Instantiates our collection.

    this.Genres = new DataServiceCollection(context);

  

    // Base HTTP endpoint or custom query goes here.

    Uri uriQuery = new Uri("/Genres()", UriKind.Relative);

  

    // Asynchronously load the result of the query.

    this.Genres.LoadAsync(uriQuery);

  

    this.Genres.LoadCompleted += (sender, args) =>

    {

        if (args.Error == null)

        {

            // Databind.

            this.genreList.ItemsSource = this.Genres;

    };

}

Now, let’s dig in, since a few interesting things happened. First, we added the reference to the Netflix Service namespace and utilized a special collection class called DataServiceCollection. A DataServiceCollection “represents a dynamic entity collection that provides notifications when items get added, removed, or when the list is refreshed.” So essentially, this has the features of an ObservableCollection built-in & the INotifyPropertyChanged interface makes sure that any UI bound to such a collection is informed of changes on bound property values in the collection. In addition, the DataServiceCollection has been optimized to be the representation of an OData HTTP endpoint collection and supports features like query collections, continuation tokens & tracking changes in the collection. Find out more about the DataServiceCollection here.

Also, we used a DataServiceContext which pointed to the root of the Netflix OData feed as the base context, beyond which we can do our queries/filtering/sorting. Also, once we knew exactly the query to request (in our simple demo – “/Genres()”), we used a LoadAsync() method off of our DataServiceCollection. This, behind the scenes, wraps up our query into an HTTP request to the OData service and does so without blocking the all-important UI thread. When the remote server responds, a LoadCompleted event triggers to allow us to handle the response & bind to our UI, thus automatically marshaling data back to the UI thread.

Now, how do we display the list of Genres we are fetching? Through a very simple XAML UI as below:

"15,0,15,10" x:Name="genreList">

    

        

            "0,0,0,17" Width="432">

                "{Binding Name}" TextWrapping="Wrap" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

            

        

    



So, we simply want to display a list of Genres as “Name” as we get back from Netflix. With just the little code above added to our MainPage.xaml page, we can have our application fetch & display Genres as follows. Please note that is for demo only .. so no fancy progress bars, which you might want to add to indicate to the user that some web request is being served.

The Problem

Now, consider this .. let’s say the source of the OData feed does not change very often or you want this demo Netflix application to work in offline mode, after the data has been fetched at least once. Both of these indicate that we should figure out a way to not make the HTTP Get request to the OData source every time! So, the first time we fetch the data, we have to cache it in the application’s Isolated Storage, to be read on subsequence application runs until something triggers a refresh of the data feed.

So, common sense suggests that we try to put the whole Genres DataServiceCollection in Isolated Storage & rehydrate our entity objects on successive needs for the data. Here’s the problem though – you will get strange error if you simply try to put the DataServiceCollection in Isolated Storage. Something along the lines of :

"An item could not be added to the collection. When items in a DataServiceCollection are tracked by the DataServiceContext, new items cannot be added before items have been loaded into the collection."

So, what’s happening? The problem is that DataServiceCollection was not designed for serialization/deserialization. When we use the DataServiceCollection, the collection is responsible for tracking all the objects that it contains. Because the collection also has a reference to the DataServiceContext, it notifies the DataServiceContext of all changes to the collection and the entities in the collection. This means that we can just add,remove and update objects in the collection and when we want to persist the changes, we call SaveChanges() on the DataServiceContext. This is the crux of the problem, since Isolated Storage requires the entities to be serialized, which triggers the object being updated events. If we create a new DataServiceCollection() (constructor without parameters), it creates the collection in so called auto-tracking mode. That is the collection has tracking turned on, and in order for tracking to work correctly, we must call Load on it (this will add items and connect the collection to the right DataServiceContext which will track the items). This behavior is by design.

Oops! So, is there no way to store away a DataServiceCollection for re-use? Thankfully – Yes!

The Solution

A new class called DataServiceState has been added to keep track of the state of a DataServiceCollection & it’s backend DataServiceContext. The DataServiceState simply knows how to serialize/deserialize a typed DataServiceContext with one or more DataServiceCollection objects. Essentially, during serialization through an explicit static Serialize() method, the whole DataServiceCollection is flattened into a string that is the XML serialized representation of the stored objects, along with support for nested collections.

Shall we see this in action? In our case, we have a DataServiceCollection that we would serialize & store in Isolated Storage for future use. Also, we would add a boolean flag to indicate whether we have cached data vs when we would have to refetch. So, in our case, the moment we receive a response to our query to fetch Genres, we would serialize the collection into Isolated Storage. You may switch around where you do this for cleaner code .. but here’s the demo code that shows serialization:

public partial class MainPage : PhoneApplicationPage

{

    #region "Data Members"

  

    DataServiceCollection Genres { get; set; }

    DataServiceContext context = new DataServiceContext(new Uri("http://odata.netflix.com/v2/Catalog/"));

  

    public bool AppHasFeed { get; set; }

  

    #endregion

  

    #region "Constructor"

  

    public MainPage()

    {

        InitializeComponent();

  

        if (IsolatedStorageSettings.ApplicationSettings.Contains("AppHasFeed"))

        {

            AppHasFeed = (bool)IsolatedStorageSettings.ApplicationSettings["AppHasFeed"];

        }

  

        if (!AppHasFeed)

        {

            this.LoadAndStoreGenres();

        }

        else

        {

            this.HydrateFromIso();

        }

    }

  

    #endregion

  

    #region "Methods"

  

    public void LoadAndStoreGenres()

    {

        // Instantiates our collection.

        this.Genres = new DataServiceCollection(context);

  

        // Base HTTP endpoint or custom query goes here.

        Uri uriQuery = new Uri("/Genres()", UriKind.Relative);

  

        // Asynchronously load the result of the query.

        this.Genres.LoadAsync(uriQuery);

  

        this.Genres.LoadCompleted += (sender, args) =>

        {

            if (args.Error == null)

            {

                // Databind.

                this.genreList.ItemsSource = this.Genres;

  

                // Set & store the flag indicating we have fetched data once.

                AppHasFeed = true;

  

                if (IsolatedStorageSettings.ApplicationSettings.Contains("AppHasFeed"))

                    IsolatedStorageSettings.ApplicationSettings.Remove("AppHasFeed");                        

                

                IsolatedStorageSettings.ApplicationSettings.Add("AppHasFeed", AppHasFeed);

                

  

                // Serialize our collection.

                var GenresCollection = new Dictionary<string, object>();

                GenresCollection["Genres"] = this.Genres;

                string GenresDataFeed = DataServiceState.Serialize(context, GenresCollection);

  

                // Store flattened data in Isolated Storage.

                if (IsolatedStorageSettings.ApplicationSettings.Contains("Genres"))

                    IsolatedStorageSettings.ApplicationSettings.Remove("Genres");

  

                IsolatedStorageSettings.ApplicationSettings.Add("Genres", GenresDataFeed);                    

            }

        };

    }

    #endregion

}

So, our boolean flag “AppHasFeed” indicates whether we have fetched the Genre collection at least once .. in your actual use, you may choose to implement an explicit way to refresh the data feed. Back in our case, if we don’t have any data, we make the one-time asynchronous request to fetch OData as Atom. Next, we utilize the DataServiceState class to serialize the entire DataServiceCollection of Genres with respect to its DataServiceContext and store the resulting string XML into Isolated Storage as a key-value pair. Voila, now we are storing state and caching OData inside our application!

One thing to note is that in our demo case, we simply put the whole DataServiceCollection in Isolated Storage for future use. If you do not want that level of persistence & are dealing with temporary data, there is a way out as well. The same techniques of serialization of a DataServiceCollection apply perfectly well when storing the resulting string in PhoneApplicationService.Current.State, in case you simply want the data to be available in case your application is tombstoned & you want you data entities to be rehydrated without making a fresh HTTP request.

So, in the code above, we saw how to serialize & store a DataServiceCollection in Isolated Storage. But we also need the same data to be deserialized & re-hydrating our data entities if we are not making another fresh request. So, in our case, if the AppHasFeed flag indicates that we have fetched data already, we simply use the following deserialization technique:

public void HydrateFromIso()

{

    if (IsolatedStorageSettings.ApplicationSettings.Contains("Genres"))

    {

        // Fetch flattened data & rehydrate object model.

        string GenresDataFeed = IsolatedStorageSettings.ApplicationSettings["Genres"].ToString();

        DataServiceState state = DataServiceState.Deserialize(GenresDataFeed);

        Dictionary<string, object> collections = state.RootCollections;

  

        // Hydrate our DataServiceCollection.

        this.Genres = collections["Genres"] as DataServiceCollection;

  

        // Databind.

        this.genreList.ItemsSource = this.Genres;

    }

}

So essentially, we deserialize the string XML from Isolated Storage through the static Deserialize() method to re-instantiate a DataServiceState. Once done, the RootCollections property holds the individual DataServiceCollection entities, which we can use to re-hydrate our data model. Easy? Again, where I do this in code is questionable, but this is for the sake of keeping the demo simple. You should be able to take the concept & add code to your application as & when needed to cache/uncache OData collections.

So, after you add the above code, go ahead & run the Netflix Demo again, but this time after turning off all network connectivity for emulator or Windows Phone device. You’ll see that we have been able to serialize/deserialize the fetched OData collection and now our applications works perfectly fine in offline mode, on successive attempts!

Summary

In this article, we talked about consumption of OData from a Windows Phone application and the subsequent serialization/deserialization of data collections. These techniques should help in building lean applications which are careful about misuse of the user’s bandwidth in fetching the same data over & over again. So, what are you waiting for? Expose just about any data store as an OData feed, put appropriate security on the data & consume it responsibly from multiple mobile platforms!

I would appreciate any comments or concerns or how things can be done better. Thanks for reading & happy coding.

Cheers SilverlightShow!

About the Author

Facebook Graph API and Silverlight Part 2 – Publishing data

editorial@silverlightshow.net (Lazar Nikolov ) — Thu, 17 Nov 2011 14:01:00 GMT

This article is compatible with the latest version of Silverlight.

This is the follow up of my article Facebook Graph API and Silverlight. Don’t miss to check it out to learn more about the Facebook Graph API and how to access Facebook data in the easy way.

More resources...

($9.99)

All SilverlightShow Ebooks

No API can be complete if you can’t publish data through it. Facebook Graph API sets you no boundaries. This time I focus on posting data in your or your friends’ Facebook profiles – like or comment on a photo, post to someone’s wall, responding to event request as attending, and so on.

The big picture

Again, when publishing to Facebook, you use an access token. Depending on what you need to do, the access token must grant you user data permissions, friends’ data permissions or extended permissions. In most cases you will need combined permissions. To publish stream on public profile (that includes like or comment on a public photo) you need only publish_stream permission from the extended permissions. But, if you want to use your or your friend profile, you must get access token with all sufficient permissions. That means that:

When posting a like or comment on a photo in your own profile, you need additional user_photos permission.
When posting a like or comment on a friend’s photo, you need to grand friends_photos permission.
When responding to an event request, you need the rsvp_event permission from the extended permissions set.

And counting... It’s impossible to cover all scenarios, but you got the logic. Or just experiment with the permission sets. Facebook provides you with the Graph API Explorer to easy generate your access token - Facebook Graph API Explorer.

I think that’s enough for the sufficient permissions. This is only the first step. What you must do after that is issuing a HTTP POST request to the appropriate url. Here are several examples again:

If you need to like a photo, you issue a POST request to https://graph.facebook.com/OBJECT_ID/likes, where OBJECT_ID is the id of the photo. You are not limited only to photos. You like any object that has a /likes connection. When liking, you don’t need to send any additional information.
If you need to comment a photo, you issue a POST request to https://graph.facebook.com/OBJECT_ID/comments, where OBJECT_ID is the id of the photo. Again, you can comment on any object that has /comments connection in the graph. The difference from liking a photo, here, is that you must send the comment message with the POST request.

These are only examples that you apply in any other scenario. Responding to event request is posting to /EVENT_ID/response, where response is attending, maybe or declined depending on whether you intend to attend the event or not. Posting to wall is sending the request to /PROFILE_ID/feed, where PROFILE_ID is the id of the profile of your friend.

All HTTP requests can be issued in the graph API explorer.

Posting in Silverlight

In my first article in this series, I used WebClient to get Facebook data through the Graph API. This was like a GET request. This time we need a POST request.

After you identify the action for your request (like, comment, etc.), generate the sufficient permission set and make it clear what is the appropriate url you are to post to, it’s Silverlight show time!

Let me first go through liking a photo.

private void FacebookPOSTRequest()

{

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(new Uri("https://graph.facebook.com/" + picId + "/likes?access_token=" + AccessToken));

request.Method = "POST";

request.ContentLength = 0;

request.BeginGetRequestStream(new AsyncCallback(RequestReady), request);

}

This code issues a POST request that likes the photo with id picId. The sufficient permission set is in AccessToken. Remember, you can like any object that has /likes connection.

If you need to comment on a photo, you replace /likes in the url with /comments. And, later you must also set the arguments with the comment message. When comment, you don’t need to set ContentLength:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(new Uri("https://graph.facebook.com/" + picId + "/comments?access_token=" + AccessToken));

request.Method = "POST";

request.BeginGetRequestStream(new AsyncCallback(RequestReady), request);

You write the comment message in the RequestReady method:

private void RequestReady(IAsyncResult asyncResult)

{

HttpWebRequest request = asyncResult.AsyncState as HttpWebRequest;

Stream stream = request.EndGetRequestStream(asyncResult);

this.Dispatcher.BeginInvoke(delegate()

{

// Write the POST arguments

StreamWriter writer = new StreamWriter(stream);

writer.Write("message=my comment");

writer.Flush();

writer.Close();

request.BeginGetResponse(new AsyncCallback(ResponseReady), request);

});

}

You find the required arguments with their names on http://developers.facebook.com/docs/reference/api/.

When liking a photo you just flush and close the StreamWriter after creating it:

StreamWriter writer = new StreamWriter(stream);

writer.Flush();

writer.Close();

request.BeginGetResponse(new AsyncCallback(ResponseReady), request);

The same is valid for the event response. Here is the url for the event response with attending:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(new Uri("https://graph.facebook.com/" + eventId + "/attending?access_token=" + AccessToken));

To parse the result from the request, you use the ResponseReady method:

private void ResponseReady(IAsyncResult asyncResult)

{

HttpWebRequest request = asyncResult.AsyncState as HttpWebRequest;

HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(asyncResult);

this.Dispatcher.BeginInvoke(delegate()

{

Stream responseStream = response.GetResponseStream();

StreamReader reader = new StreamReader(responseStream);

string result = reader.ReadToEnd();

});

}

Conclusion

In this article the focus was on issuing a POST request in Silverlight to harness the Facebook Graph API publishing capabilities. You learned what you need to do to gain the sufficient permission set depending on the action you do. For accessing Facebook data, read the first article from the series - Facebook Graph API and Silverlight. In part 3 of the series I will show you how to create albums and upload images.

Feel free to leave you comment on everything that isn’t clear! I will be glad to share my answer, if I can.

10 Laps around Silverlight 5 (Part 6 of 10)

editorial@silverlightshow.net (Michael Crump ) — Tue, 15 Nov 2011 08:15:00 GMT

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

This article is Part 6 of the series “10 Laps around Silverlight 5.” If you have missed any other section then please see the Roadmap below.

To refresh your memory on what Silverlight is:

Microsoft Silverlight is an application framework for writing Rich Internet Applications.

More resources...

All SilverlightShow Ebooks

The run-time environment is available as a plug-in for most web browsers and works on a variety of operating systems including Windows, Mac and Linux.

To recap what we learned in the previous section:

We spend the entire “lap” discussing improvements in text in Silverlight 5.
We discussed Linked and Multi-Column Text and where it might be useful in your next Silverlight application.
We also looked at character spacing, open-type font. pixel snapped text and TextOptions.

In this article, I am going to discuss several new operating system integration features in Silverlight 5 including: P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust. Please review the Roadmap for the series before going any further.

The Roadmap for this Series

1) Introduction to SL5 – This post which provides a brief history of Silverlight and relevant links.

2) Binding- Ancestor Relative Source Binding and Implicit Data Templates.

3) Graphics –XNA 3D API and Improved Graphics Stack.

4) Media - Low-Latency Sound using XNA and Remote Control and Media Command (Keys) Support.

5) Text - Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions.

6) Operating System Integration [This post] - Part 1 - P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust.

7) Operating System Integration Part 2 - Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness.

8) Productivity and Performance - XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time.

9) Controls - Double and Triple click support, PivotViewer and ComboBox Type-Ahead.

10) Other items - In-Browser HTML, PostScript and Tasks for TPL.

P/Invoke or Platform Invocation

Before we dive into an example. Let’s first answer the question, What is it? Platform Invocation Services, commonly referred to as P/Invoke, is a feature of Common Language Infrastructure implementations, like Microsoft's Common Language Runtime, that enables managed code to call native code.

*Reference to Wiki

This feature is new to Silverlight 5 and we will take a look at how to use it in your own applications.

In order to create a new P/Invoke application in Silverlight 5, we will need to enable “Require elevated trust” in Silverlight 5. We can also use the functionality in-browser or out-of-browser. Let’s begin.

Fire up a new Silverlight 5 project and right click on our project and select Properties. Put a check in “Enable running application out of the browser” as shown below.

After you put a check in “Enable running application out of the browser”, go ahead and click the button. Now put a check in “Require elevated trust when running outside the browser”.

Switch back over to the MainPage.xaml and add in the following code:

<Grid x:Name="LayoutRoot" Background="White">

    <Button Height="23" HorizontalAlignment="Left" Margin="169,132,0,0" VerticalAlignment="Top" Width="75" x:Name="btnclick" Content="click" Click="click_Click" />

Grid>

This simply puts a button on our page that when the user clicks it the pc will make a beep sound.

Go ahead and add a new class to the project named PlatformInvokeTest.cs and add the following code.

using System;

using System.Runtime.InteropServices;

  

namespace PInvoke

{

    public class PlatformInvokeTest

    {   

        [DllImport("kernel32.dll")]

        public static extern bool Beep(int frequency, int duration);

 

     

        public static void PlaySound()

        {

            Random random = new Random();

            for (int i = 0; i < 50; i++)

            {

                Beep(random.Next(10000), 100);

            }

        }

  

    }

}

Let’s switch back over to the MainPage.xaml.cs and add the following code to our button event handler:

private void click_Click(object sender, RoutedEventArgs e)

{

    PlatformInvokeTest.PlaySound();

}

If we run the application now, we will hear our PC beep many times. There are many other thing you can do with P/Invoke such as Detecting if the user inserted a USK Key into their computer, opening the run dialog box and much much more! Very cool stuff!

Multiple Window Support

With Silverlight 5, we now have the ability to spawn multiple windows from an Out-of-Browser application with elevated trust with just a couple of lines of code.

A few things to note about Multiple Window Support though:

If the main window closes, then all spawned windows close.
You need to be running your application “Out-of-Browser” as well as in Elevated Trust mode.

If you followed the P/Invoke guide before then you will need to do the same thing for Multiple Window Support. That is, make this an out-of-browser application and add Elevated Trust.

After that is complete then go ahead and double click on your MainPage.xaml.cs file and add the following code:

public MainPage()

{

    InitializeComponent();

    Loaded += new RoutedEventHandler(MainPage_Loaded);

}

  

void MainPage_Loaded(object sender, RoutedEventArgs e)

{

    for (int i = 0; i < 5; i++)

    {

        new Window()

           {

               Height = 400,

               Width = 600,

               Top = 24,

               Left = 30,

               Title = "Silverlight Show New Window",

               Content = new Button() { Content = "Can be any Framework Element" },

               Visibility = Visibility.Visible

           };

    }

   

}

This application will spawn 5 windows when you run it. Below is a sample screenshot from the application with 2 additional windows showing. The other windows are closed for demonstration purposes.

Unrestricted File System Access in Full Trust

Have you ever wanted to write a file anywhere on a users computer in earlier versions of Silverlight but found out that you couldn’t? Well in Silverlight 5 you can.

Just like the earlier samples make this an out-of-browser application and add Elevated Trust. (See the P/Invoke demo at the beginning of this article for a quick-how to.)

Switch over to the MainPage.xaml and add in the following code:

<Grid x:Name="LayoutRoot" Background="White">

    <Button Height="23" HorizontalAlignment="Left" Margin="169,132,0,0" VerticalAlignment="Top" Width="75" x:Name="btnclick" Content="click" Click="click_Click" />

Grid>

Let’s switch back over to the MainPage.xaml.cs and add the following code to our button event handler:

private void click_Click(object sender, RoutedEventArgs e)

{

    // Create a Directory on the Root of C

    var tempDirectory = @"c:\michaelcrump";

    if (!Directory.Exists(tempDirectory))

    {

        Directory.CreateDirectory(tempDirectory);

    }

  

    // Give it a FileName

    var filename = string.Format("slshowrocks.txt");

    var fullPath = System.IO.Path.Combine(tempDirectory, filename);

  

    // Write Something in the File!

    using (FileStream fs = File.Create(fullPath))

    using (StreamWriter sr = new StreamWriter(fs, Encoding.UTF8))

    {

        sr.WriteLine("Hello World");

    }

}

This will create a directory on our C:\ called michaelcrump. Then it will create a file named “slshowrocks.txt” and give it some content. If you run the application and click on the button then you should have the new folder/file created on your root hard disk.

If Visual Studio 2010 is complaining of any missing namespaces then just make sure you add the following:

using System.IO;

using System.Text;

Very easy to accomplish and it is not limited to writing files. You can also read files from anywhere on the hard disk! In the next part of this series, we will look at letting the user specify the location of the saved file.

Conclusion

At this point, we have seen how you would use P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust in your Silverlight 5 Applications. We have also discussed a few other features in Silverlight 5. In the next part of the series, I am going to take a look at more new operating system features including : Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness. Again, thanks for reading and please come back for the next part.

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

10 Laps around Silverlight 5 (Part 5 of 10)

editorial@silverlightshow.net (Michael Crump ) — Tue, 08 Nov 2011 20:18:00 GMT

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

More resources...

All SilverlightShow Ebooks

This article is Part 5 of the series “10 Laps around Silverlight 5.” If you have missed any other section then please see the Roadmap below.

To refresh your memory on what Silverlight is:

Microsoft Silverlight is an application framework for writing Rich Internet Applications. The run-time environment is available as a plug-in for most web browsers and works on a variety of operating systems including Windows, Mac and Linux.

To recap what we learned in the previous section:

We discussed the new media features included with Silverlight 5.
We looked at using Low-Latency Sound with XNA SoundEffect and SoundEffectInstance classes.
We also learned how to use remote control and media command (keys) support.

In this article, I am going to discuss the new text improvements in Silverlight 5 including: Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions. Please review the Roadmap for the series before going any further.

The Roadmap for this Series

1) Introduction to SL5 – This post which provides a brief history of Silverlight and relevant links.

2) Binding- Ancestor Relative Source Binding and Implicit Data Templates.

3) Graphics –XNA 3D API and Improved Graphics Stack.

4) Media - Low-Latency Sound using XNA and Remote Control and Media Command (Keys) Support.

5) Text [This post] - Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions.

6) Operating System Integration Part 1 - P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust.

7) Operating System Integration Part 2 - Default Filename for SaveFileDialog, 64-bit browser support and Power Awareness.

8) Productivity and Performance - XAML Binding Debugging, Parser Performance Improvements and Multi-core JIT for improved start-up time.

9) Controls - Double and Triple click support, PivotViewer and ComboBox Type-Ahead.

10) Other items - In-Browser HTML, PostScript and Tasks for TPL.

Linked and Multi-Column Text

We will use an example that I’ve demonstrated in the past that many have found helpful. The Linked and Multi-Column Text feature enables the text of a RichTextBlock control to overflow from one into the next. Multiple RichTextBlockOverflows can be chained together to spread text across a layout. Let’s go ahead and take a look at a screenshot of a RichTextBlock with a RichTextBlockOverflow working together.

As you can see from this screenshot, we had a RichTextBlock in the upper left and its content overflowed onto the RichTextBlockOverFlow #1, #2 and #3. You can think of this as something that is similar to a newspaper article. As the browser expands or contracts the content fills the available area.

Let’s check out the code that made it happen:

<Grid x:Name="LayoutRoot"

        Background="White">

      <Grid.ColumnDefinitions>

          <ColumnDefinition Width="0.415*" />

          <ColumnDefinition Width="0.168*" />

          <ColumnDefinition Width="0.418*" />

      Grid.ColumnDefinitions>

      <Grid.RowDefinitions>

          <RowDefinition Height="0.373*" />

          <RowDefinition Height="0.143*" />

          <RowDefinition Height="0.483*" />

      Grid.RowDefinitions>

      <Rectangle Fill="Blue"

                 Margin="0,1"

                 Stroke="Black"

                 Grid.Row="1"

                 Grid.ColumnSpan="3" />

      <Rectangle Fill="Blue"

                 Margin="-1,0,1,0"

                 Stroke="Black"

                 Grid.RowSpan="3"

                 Grid.Column="1" />

      <RichTextBlock x:Name="rtb1"

                   Margin="0,0,5,3"                     

                   OverflowContentTarget="{Binding ElementName=rtb2}"

                     

                 >

          <Paragraph>

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

              Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum tincidunt vestibulum. Quisque accumsan nibh nisl. Aenean eget leo enim. Aenean tincidunt nulla nec elit vestibulum sit amet posuere arcu laoreet. Curabitur diam nisi, ullamcorper vel consectetur sed, volutpat nec orci. Aenean eu purus sit amet diam sollicitudin vulputate sed in sapien. Sed pulvinar viverra sapien, a elementum arcu fringilla sed. Proin tincidunt iaculis fringilla. Proin semper venenatis nisi vel hendrerit. Etiam elementum bibendum dignissim. Integer tincidunt pharetra est, ut porttitor urna dictum at. Nulla nisi velit, consequat accumsan tincidunt id, congue vitae lacus. Donec convallis est ligula. Suspendisse fermentum pharetra cursus. Maecenas a gravida nunc. In ante lacus, sollicitudin blandit adipiscing vel, mollis sed ipsum. Nullam a est nec tortor porttitor consectetur. Aliquam consequat pharetra rutrum. Pellentesque viverra dapibus scelerisque. Praesent ullamcorper, sapien vitae facilisis varius, nibh justo luctus odio, faucibus viverra risus metus non lacus. Sed porta, magna in tincidunt fringilla, elit elit sollicitudin sem, et ornare mi nulla hendrerit augue. Vestibulum vitae mollis dolor.

  

          Paragraph>

      RichTextBlock>

      <RichTextBlockOverflow x:Name="rtb2"

                           Grid.Row="2"

                           OverflowContentTarget="{Binding ElementName=rtb3}"

                           

                           />

      <RichTextBlockOverflow x:Name="rtb3"

                           Grid.Column="2"

                           OverflowContentTarget="{Binding ElementName=rtb4}"

                           />

  

      <RichTextBlockOverflow x:Name="rtb4"

                           Grid.Column="2"

                           Grid.Row="2"

                           />

  

  

  Grid>

The key thing to remember here is that a RichTextBlock contains OverflowContentTarget which will allow you to bind to a special control called RichTextBlockOverflow.

NOTE: Post-beta, Microsoft changed this to use the non-editable RichTextBlock instead of RichTextBox. So a word of warning, many post-beta demos of this functionality on the web will no longer work. Good thing you are reading this guide, right? =)

Character Spacing

The TextBox and TextBlock controls provides a way to control the spacing of letters inside the text very easily. Let’s go ahead and take a look at a screenshot of the various character spacing inside of a TextBlock.

Let’s look at the code:

<Grid x:Name="LayoutRoot" >

      <StackPanel>

          <TextBlock CharacterSpacing="1000" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

          <TextBlock CharacterSpacing="500" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

          <TextBlock CharacterSpacing="250" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

          <TextBlock CharacterSpacing="100" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

          <TextBlock CharacterSpacing="-100" FontSize="14"

                     Text="The quick brown fox jumps over the lazy dog" />

      StackPanel>

  Grid>

As you can see, we just set the CharacterSpacing property of the TextBlock control. Please note that you may use a negative number to “squish” text together.

Open-Type Font

Silverlight 5 provides many new options for the Typography class inside of a TextBlock. They have so many improvements that the best way to see everything is to explore the class. Let’s look at two new features:

ContextualAlternates - Gets or sets a value that determines whether custom glyph forms can be used based upon the context of the text being rendered.
StylisticSets - Gets or sets a value that indicates whether a stylistic set of a font form is enabled. (20 StylisticSets are available)

Let’s look at a sample that uses ContextualAlternates and StylisticSets.

The code looks like the following:

<TextBlock FontSize="80"

           FontFamily="Gabriola" 

           Text="Michael Crump"                   

           Typography.ContextualAlternates="True"

           Typography.StylisticSet5="True" />

Pixel Snapped Text and TextOptions

Silverlight 5 provides many new options for the TextOptions property inside of a TextBlock.

TextFormattingMode – Gets the TextFormattingMode for the element
TextHintingMode – Gets or sets a value that indicates whether text rendering is optimized for readability or animation.
TextRenderingMode - Sets the TextRenderingMode for the element. 4 options are available: Aliased, Auto, ClearType and Grayscale.

Let’s look at a sample that uses all of them together (Display, Fixed and Aliased). It may be hard to see in this demo, so try this one in your own application.

The code looks like the following:

<TextBlock FontSize="30" Text="The quick brown fox jumps over the lazy dog"

               TextOptions.TextFormattingMode="Display"

               TextOptions.TextHintingMode="Fixed"

               TextOptions.TextRenderingMode="Aliased" />

Conclusion

At this point, we have seen how you would use Text Tracking and Leading, Linked and Multi-column Text, OpenType Support, Pixel Snapped Text and TextOptions in your Silverlight 5 Applications. We have also discussed a few other features in Silverlight 5. In the next part of the series, I am going to take a look at the new operating system integrations including : P/Invoke, Multiple Windows and Unrestricted File System Access in Full Trust. Again, thanks for reading and please come back for the next part.

To contact me directly please visit my blog at http://michaelcrump.net/ or through twitter at http://twitter.com/mbcrump.

Telerik XAML Q3'11 Beta - Walkthrough (Part 2 of 3)

editorial@silverlightshow.net (Michael Crump ) — Wed, 02 Nov 2011 17:24:00 GMT

This is part 2 from an article on Telerik XAML Q3'11 Beta, authored by Michael Crump and Evan Hutnick. Part 1 | Part 3

SilverlightShow will occasionally publish content related to 3rd party Silverlight and Windows Phone products, following interest and article topic requests received through our surveys and feedback email (editorial at silverlightshow dot net).

Telerik XAML Q3’11 Beta

Part 2: RadVirtualizingWrapPanel

Here begins the second of three parts, which comprise Telerik XAML Q3’11 Beta—A Walkthrough. In case you missed it, with Telerik’s upcoming release in November you’ll have access to the official versions of RadBarCode, RadVirtualizingWrapPanel, and RadChartView—and a few sure-to-please extras.

More resources...

All SilverlightShow Ebooks

To make the most of these articles, download the beta before getting started.

For an introductory overview you can check out the official beta announcement on our Silverlight Team blog.

Introducing RadVirtualizingWrapPanel

RadVirtualizingWrapPanel boosts the performance of your ListBox/ListView when binding to a large amount of data. The control generates only the visible items and positions them in sequential order from left to right and top to bottom, breaking the content to the next line at the edge of its containing box.

You can check out the VisualizingWrapPanel demos here.

Let’s Get Buildin’

We are going to build a sample project that uses Telerik’s RadVirtualizingWrapPanel in Silverlight 4.

Open Visual Studio 2010, select a new Silverlight Project, and give it any name that you want. In this example, I have given it the name of RadVirtualizingWrapPanelSample.

We are going to need to add one reference to our project in order to use Telerik’s VirtualizingWrapPanel.

Telerik.Windows.Controls

Make sure that you select 2011.3.1020.1040 as the version number to ensure that you are using the Q3 Beta release.

With the reference added, we now need to add the Telerik XAML Namespace to our MainPage.xaml file. Simply double-click the MainPage.xaml file and add the following code snippet:

 1: xmlns:telerik="http://schemas.telerik.com/2008/xaml/presentation"

Now, we must add a Listbox to our grid and define an ItemTemplate as shown below:

<Grid x:Name="LayoutRoot" Background="White">

     <ListBox Name="listBox1">

          <ListBox.ItemTemplate>

               <DataTemplate>

                  <StackPanel Orientation="Vertical">

                     <TextBlock Text="{Binding Author}" />

                     <TextBlock Text="{Binding Description}" />

                     <TextBlock Text="{Binding ReleaseDate}" />

                     <HyperlinkButton Content="Listen to this Episode" NavigateUri="{Binding Link}" TargetName="_blank" />

                  StackPanel>

               DataTemplate>

          ListBox.ItemTemplate>

     ListBox>

Grid>

Let’s go ahead and add the following code to our MainPage.xaml.cs: (This will add 40,000 items to our ListBox)

public class Podcast

{

    public string Description { get; set; }

    public DateTime ReleaseDate { get; set; }

    public Uri Link { get; set; }

    public string Author { get; set; }

}

  

public partial class MainPage : UserControl

{

  

    public List _samplePodcastList;

  

    public MainPage()

    {

        InitializeComponent();

        Loaded += new RoutedEventHandler(MainPage_Loaded);

    }

  

    void MainPage_Loaded(object sender, RoutedEventArgs e)

    {

        _samplePodcastList = new List();

  

        for (int i = 0; i < 40000; i++)

        {

            Podcast PD = new Podcast();

  

            PD.Description = string.Format("Description{0} ", i.ToString());

            PD.ReleaseDate = DateTime.Now.AddDays(-10000).AddHours(i);

            PD.Link = new Uri(string.Format("http://www.podcast.com/{0}", i.ToString()));

            PD.Author = string.Format("FirstName {0}. LastName {1}", i.ToString(), i.ToString());

            

  

            _samplePodcastList.Add(PD);

        }

  

        listBox1.ItemsSource = _samplePodcastList;

    }

}

At this point, if we run our application, we should get the following:

This result, however, is not exactly what we want. It is not a WrapPanel and it is very slow navigating the 40,000 items bound to it.

With those 40,000 items in mind, let’s head back into our MainPage.xaml and add the Telerik VirtualizingWrapPanel inside our ListBox’s ItemsPanel, using the following code snippet:

<ListBox.ItemsPanel>

       <ItemsPanelTemplate>

             <telerik:VirtualizingWrapPanel ItemWidth="250" />

       ItemsPanelTemplate>

ListBox.ItemsPanel>

Now, if we run the application, we will see something much better:

We now have our items in the ListBox using a WrapPanel and it is very easy to scroll hundreds of thousands of records.

Meanwhile, our completed MainPage.xaml file should look like the following:

<UserControl x:Class="RadVirtualizingWrapPanelSample.MainPage"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

    xmlns:telerik="http://schemas.telerik.com/2008/xaml/presentation"

    mc:Ignorable="d"

    d:DesignHeight="300" d:DesignWidth="400">

  

    <Grid x:Name="LayoutRoot" Background="White">

        <ListBox Name="listBox1">

            <ListBox.ItemTemplate>

                <DataTemplate>

                    <StackPanel Orientation="Vertical">

                        <TextBlock Text="{Binding Author}" />

                        <TextBlock Text="{Binding Description}" />

                        <TextBlock Name="txtReleaseDate" Text="{Binding ReleaseDate}" />

                        <HyperlinkButton Content="Listen to this Episode" NavigateUri="{Binding Link}" TargetName="_blank" />

                    StackPanel>

                DataTemplate>

            ListBox.ItemTemplate>

  

            <ListBox.ItemsPanel>

                <ItemsPanelTemplate>

                    <telerik:VirtualizingWrapPanel ItemWidth="250" />

                ItemsPanelTemplate>

            ListBox.ItemsPanel>

        ListBox>

    Grid>

UserControl>

Thanks for Reading

We hope this article has you convinced at how easy it is to get started with Telerik’s RadVirtualizingWrapPanel. Don’t forget to check out parts one and three of Telerik XAML Q3’11 Beta—A Walkthrough: each discussing RadBarCode and ChartView, respectively.

If you enjoyed this article, you can find similar postings by XAML Evangelist, Michael Crump, on his Telerik blog.

Facebook Graph API and Silverlight

editorial@silverlightshow.net (Lazar Nikolov ) — Wed, 19 Oct 2011 00:42:00 GMT

This article is compatible with the latest version of Silverlight.

Introduction

Facebook, Facebook, Facebook. It’s a constant part of our daily life. Contacting your friends thousand miles away (where your day is their night), spending your free time on the net, bragging for your new acquisition or where you’ve been, Facebook is all around.

More resources...

($9.99)

All SilverlightShow Ebooks

And not only in you, it’s also in the applications you use. An amazing amount of web sites integrate with Facebook and, I believe, more and more applications are to use the social network to access data.

Recently, it was my turn to import Facebook data into my application. To share my experience with you and save you several hours of research, in this article I intend to face you with the whole world of something very cool – Facebook Graph API. Moreover, I will show you the alternatives and lead you through the flow when you access Facebook data.

Why the Graph API?

http://developers.facebook.com/docs/reference/api/.

You can also use some Facebook API wrappers that you can find on codeplex. But I prefer the Graph API. At least I have experience with it and not with the alternatives. You are always free to play depending on what you need.

Okay, nice. But how can I consume the data and how Facebook presents it to me? It’s simply JSON...Every connection of an object in the social network in JSON. And codeplex provides you JSON.NET - http://json.codeplex.com/. Anything else you need?

Unfortunately, yes. You do.

Setting an application

Almost every call to the Graph API requires you to have previously set a developer application in the portal. To do this you follow the steps on https://developers.facebook.com/apps.

After you finish, you get an application id and application secret. These both are used to generate an access token. This token is crucial. You can NOT do almost anything without the token. Moreover, the token is even more complicated than this.

So, when you have the id and the secret, you get the token by calling:

https://graph.facebook.com/oauth/access_token?grant_type=client_credentials&client_id=APP_ID&client_secret=APP_SECRET’

Just replace APP_ID with your application id and APP_SECRET with your application secret. If both are correct you will see the token.

But, you can use this token only for public data like the events of a company (page), etc.

To get a token that allows you to access more complicated data, you must use permissions. The easiest way to generate a token that allows you, for example, to access your events, friends and friend’s photos and so on, is to use the Graph API Explorer. Or, just go here - https://developers.facebook.com/tools/explorer.

See, you get a token for your specific needs in a second!

Accessing data

Here is an example. I’ve generated a token that allows me to access my events. Precisely, the events I’ve responded with “attending”.

To get my events, I need to know the id of my profile in the Graph API. Remember? My profile is an object! To make all easier, Facebook can handle you profile address (that is the username) instead of the id. My username is “lazar.nikolov” (public link for my profile – “facebook.com/lazar.nikolov”) – you have yours! Just check for it in you profile information.

So, the base part is “https://graph.facebook.com/lazar.nikolov”. To get the events I add “/events?”. Finally, I add the access token, preceded with “access_token=”.

And I get this:

{

"data": [

{

"name": "SANDER VAN DOORN - ELEVE11 Album World Tour 2011",

"start_time": "2011-11-05T05:00:00+0000",

"end_time": "2011-11-05T13:00:00+0000",

"location": "Arenele Romane (Carol Park)",

"id": "247241851961568",

"rsvp_status": "attending"

},

{

"name": "The Mission presents: Armin Van Buuren, Sunnery James & Ryan Marciano",

"start_time": "2011-10-16T05:00:00+0000",

"end_time": "2011-10-16T13:00:00+0000",

"location": "Sala polivalenta",

"id": "156220381126225",

"rsvp_status": "attending"

}

],

"paging": {

"previous": "https://graph.facebook.com/me/events?access_token=AAAAAAITEghMBAER8ATHST4DZAClBPp5tEBoYqbeZC6MZCCZCyS7NNiTufMamzZAlI5ZAumjZA5Iei5FVA9I63hTwC8yPqSron9uLtZBOuo8kOwec68CYKuLs&limit=25&since=1320469200",

"next": "https://graph.facebook.com/me/events?access_token=AAAAAAITEghMBAER8ATHST4DZAClBPp5tEBoYqbeZC6MZCCZCyS7NNiTufMamzZAlI5ZAumjZA5Iei5FVA9I63hTwC8yPqSron9uLtZBOuo8kOwec68CYKuLs&limit=25&until=1318741200"

}

Yeah, I am a hopeless trance music fan...

Now it's easy!

To do this in Silverlight, you don’t need any special equipment. Something that one must know is that Silverlight uses asynchronous data retrieval model. Look at this:

WebClient facebookClient = new WebClient();

this.facebookClient.DownloadStringCompleted += new DownloadStringCompletedEventHandler( facebookClientDownloadStringCompleted );

this.facebookClient.DownloadStringAsync(new Uri("https://graph.facebook.com/" + Profile + "/events?access_token=" + AccessToken));

The WebClient is the easiest way to do all the stuff. You must have your profile id/name and the access token and can retrieve all kind of information using the Graph API.

If you need your friends, generate the appropriate token and use:

this.facebookClient.DownloadStringAsync(new Uri("https://graph.facebook.com/" + Profile + "/friends?access_token=" + AccessToken));

Using the Newtonsoft.Json library from codeplex you can deserialize the JSON and iterate through your friends. Don’t forget, every friend is a profile, and thus an object in the social network. Being an object, it has id that you can retrieve and use to access additional information.

Conclusion

In this article I give you the basics when using the Facebook Graph API in your Silverlight application to make it social. But not all ends here. It is not only accessing information but also posting! The Graph API allows you to do practically everything you would need. Comment a status update, get profile pictures, publish on a wall, upload a photo...explore the entire social graph! And most important of all – enjoy!

Azure Services connecting Windows Phone to Data

editorial@silverlightshow.net (Samidip Basu ) — Wed, 21 Sep 2011 11:28:00 GMT

This article would be a natural continuation of my previous post on “Connecting Azure and Windows Phone through OData” and show a different way of leveraging Azure cloud services for your Mobile applications.

Don't miss...

All SilverlightShow Ebooks

Also, Peter Kuhn (aka MisterGoodcat) did a brilliant article series on “Getting Ready for the Windows Phone 7 Exam 70-599” and I wanted to expand on the Data Access Strategy section by talking more about connectivity to Windows Azure.

Prelude

In the last article (here), we talked about how OData can really be very handy when providing cloud data backend support for a variety of mobile & web platforms. We simply had a SQL Azure database & used the SQL Azure services to expose the data through an OData feed straight out of Azure, which had full support for CRUD operations given the right roles. However, this approach might seem brute-force for some project needs. For one, we did not have any granularity over how much of a Table’s data we wanted to expose; it was all or nothing. Also, what if you did not want to expose all of the data, but just a few operations on it? And what if you really wanted to have your database on-premise; yet use the ubiquitous Azure services to empower Mobile applications to perform operations on the data? That’s what we talk about in this installment :)

Download Source Code here.

The Database

Now, let’s say we are trying to write a Windows Phone application that interacts with data housed in a remote Database. This is obviously quite a common scenario, because it allows for the data to be utilized/consumed on other platforms. Now, for this demo, I chose to use a simple Database hosted in SQL Azure, since I find it very easy to do so. It is important to note that this Database can be just about anything, on-premise or in the cloud; as long as .NET can connect to it, we should be fine. That said, here’s my Azure Portal set-up:

You’ll notice that I have used one of my Azure subscriptions to create a “PatientData” Database in my SQL Azure server .. this will house our super-secret patient information :) Now, before moving on, you may want to copy the appropriate Connection String to this Database so that we may connect to it remotely. Now, let’s get inside our “PatientData” Database and create a simple table, also called “PatientData”, & fill in some dummy data like here:

The data schema is over-simplified: the ID field is an auto-incrementing integer & we just keep track of Patient “Name” & “Condition” – told you we were dealing with sensitive data :)

Again, this Database could be anywhere. What we want to do however, is to have a Service that is globally accessible from mobile applications and one that interacts with the backend Database only supporting agreed-upon operations.

The Service

We want a simple a service that interacts with our backend Database & one that can be consumed from a Windows Phone application. Again, Windows Azure seems like one of the easiest places to host such a service and make it globally accessible. So, here’s our goal:

Create a Windows Azure cloud project
Use ADO.NET Entity Data Model as an ORM Mapper to our backend Database
Create a simple WCF Service inside of a Azure WebRole
Utilize the ORM context to expose specific operations through the WCF service
When all is done & working, host the WCF service in Azure

This is how we start:

Next step, we need a way to map the relational Database table into .NET world objects .. this is where an Object Relational Mapper [ORM] steps in. For our purpose, let’s add the ADO.NET Entity Data Model to our project, like below:

As a part of adding the ADO.NET Entity Data Model, you step through a wizard that is essentially going to point to a Database table to reflect upon & provides column-mapping as Properties to a .NET object. This is where we get to utilize the “Connection String” that we had copied from the Azure Portal, so that we can point ADO.NET Entity Data Model to our SQL Azure table, as shown in the steps below:

The last image shows generated “.edmx” file that ADO.NET Data Entity Model created, on being pointed to our Database Table. That’s it! Now we have “PatientData” as an entity in our C# code. The final project structure should look like this:

Now, let’s define the “PatientService” Interface with exactly the operations we want to support & implement them. For this demo, I chose to do two – one that gets us a list of “Patients” & one that allows for adding “Patients”. Here’s the simple Interface:

namespace PatientService

{  

    [ServiceContract]

    public interface IPatientServiceInterface

    {

        [OperationContract]

        List GetPatientList();

  

        [OperationContract]

        string AddPatient(PatientData newPatient);

    }

      

}

And the implementation:

namespace PatientService

{    

    public class PatientDataService : IPatientServiceInterface

    {

        #region "Interface Implementation"

  

        public List GetPatientList()

        {

            var context = new PatientDataEntities();

            return context.PatientData.ToList();

        }

  

        public string AddPatient(PatientData newPatient)

        {

            try

            {

                var context = new PatientDataEntities();

                context.AddObject("PatientData", newPatient);

  

                context.SaveChanges();

                return "Success!";

            }

            catch (Exception e)

            {

                return e.Message;

            }

        }

  

        #endregion

    }

}

Notice how we are easily able to utilize the “PatientDataEntities” mapping provided by ADO.NET Entity Data Model as a “Context” within our service implementation. Now, with our service looking like it has all the needed pieces, we do some testing locally to make sure that the methods invoked do actually reach out to our SQL Azure Database & do what they are supposed to do. If satisfied, comes the next step of hosting our service in Azure for ubiquitous availability. This is where the “Windows Azure Project” template helps, as it has already provided an Azure wrapper for our WCF Service. Here the steps to host our simple service in Azure:

Right Click on the “AzurePatientService” cloud project & select “Publish”
Then, “Create Service Packages only”
This should build our Project & produce two deliverables
One is the Cloud Service Configuration File (.cscfg)
Other, the actual Project package (.cspkg)

The steps are demonstrated below:

Once the deployment packages are created locally, you may want to copy the directory file path, as we shall need it in the next step. Now, to actually hosting the Service in Azure – Create a new “Hosted Service” in the Azure Portal, with appropriate settings. Notice how we use our local directory file path to point Azure where to pick up the Service Configuration & Project Package from. Also, for demo purposes, we are directly making our Service live in “Production”; actual Services may benefit from being tested in “Staging” before going to “Production”.

Now, little wait till Azure spins up the resources needed to host our Service & voila, we are live in Azure! Let’s hit the WCF endpoint to make sure our Service is properly hosted & its metadata is accessible. If you’re with me so far, you now know how to deploy & host simple WCF Services in Azure! The rest will be easy :)

The Windows Phone Client

Now that we have our WCF Service hosted & accessible in Azure, consuming it from our Windows Phone Mango application will be standard procedure. Let us aim to build a simple Windows Phone client that leverages the two operations supported by our Service – show list of “Patients” & ability to add new “Patients”. My demo UI looks like the following:

As we start building our Windows Phone client, one of our first steps would be to “Add Service Reference” to our Service, so that our project knows the metadata & exposes methods from the Service. This is as simple as copying the URL to our Azure-hosted Service & adding it as a Reference as below:

That’s it! .NET builds the proxies & we are ready to consume our Service methods. Here’s how we request the “List of Patients” from our Service:

PatientServiceInterfaceClient PatientServiceClient = new PatientServiceInterfaceClient();

PatientServiceClient.GetPatientListCompleted += new EventHandler(PatientServiceClient_GetPatientListCompleted);

PatientServiceClient.GetPatientListAsync();

  

void PatientServiceClient_GetPatientListCompleted(object sender, GetPatientListCompletedEventArgs e)

{

    ObservableCollection patientList = e.Result;

    this.lstPatients.ItemsSource = patientList;

}

And the little XAML code to bind the results to UI:

"lstPatients" Margin="20,0,0,60">

    

        

            "Vertical">

                "Horizontal">

                    "/Images/Medicine.png" Height="50" Width="50"/>

                    "{Binding Name}" FontSize="40" Margin="10,0,0,0" Style="{StaticResource PhoneTextAccentStyle}"/>

                

                "{Binding Condition}" FontSize="32" Margin="60,0,0,20"/>

            

        

    



Here’s how we use the Service to “Add Patients”:

// Instantiate the client.

PatientServiceInterfaceClient PatientServiceClient = new PatientServiceInterfaceClient();

  

PatientData newPatient = new PatientData();

newPatient.Name = this.txtName.Text.Trim();

newPatient.Condition = this.txtCondition.Text.Trim();

     

// Invoke method asynchronously.

PatientServiceClient.AddPatientCompleted += new EventHandler(PatientServiceClient_AddPatientCompleted);

PatientServiceClient.AddPatientAsync(newPatient);

  

void PatientServiceClient_AddPatientCompleted(object sender, AddPatientCompletedEventArgs e)

{

    if (e.Result == "Success!")

    {

        MessageBox.Show("Voila, Saved to the Cloud :)", "All Done!", MessageBoxButton.OK);

        this.NavigationService.Navigate(new Uri("/PatientList.xaml", UriKind.Relative));

    }

    else

    {

        MessageBox.Show(e.Result, "Save Error!", MessageBoxButton.OK);

        this.NavigationService.Navigate(new Uri("/PatientList.xaml", UriKind.Relative));

    }

}

Conclusion

So, what we talked about so far was ways in which Azure can be of much benefit in hosting WCF Services, which in turn communicate with remote Databases & could easily provide CRUD operation functionality to your backend server. You could take this concept & literally make your services do anything you want .. Azure just makes hosting a snap, with high availability & failover. And, each of these Services can be easily consumed from Mobile applications, like the Windows Phone one in our case. Hope this article demonstrated some techniques & got you thinking on how to Service-enable your Mobile applications. Thanks a lot for reading & cheers to SilverlightShow.

About Author

Samidip Basu (@samidip ) is a technologist & gadget-lover working as a Manager & Solutions Lead for Sogeti out of the Columbus OH Unit. Having worked on WP7 since CTP days, he now spends much of his time in spreading the word to discover the full potential of the Windows Phone platform & cloud-based mobile solutions in general. He passionately runs the Central Ohio Windows Phone User Group (http://cowpug.org/) and can be found with atleast a couple of hobbyist projects at any time. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com/ .

Connecting Azure and Windows Phone through OData

editorial@silverlightshow.net (Samidip Basu ) — Tue, 06 Sep 2011 02:23:00 GMT

Windows Azure & Windows Phone seem to be two very popular technologies out of Redmond right now.

Don't miss...

All SilverlightShow Ebooks

There is obviously a lot of buzz around cloud infrastructure involving Azure solutions and the wonderful developer story that we have for Windows Phone development. But, should these two platforms work together & if so, can they? How can you as a Mobile/Windows Phone developer utilize the cloud?

In this article, we talk about how to leverage Windows Azure to supplement our Windows Phone application. In particular, we will see how SQL Azure can be rather beneficial in providing globally accessible & scalable backend for mobile solutions on Windows Phone & other disparate platforms. The key link we shall leverage is OData Services for providing cross-platform read/write access to a central data repository.

Practicality

First, some caveats. As you consider a solution for your Windows Phone application leveraging Azure as the backend, it is always good to do some feasibility checks to make sure that the approach makes sense. As Windows Phone & other mobile platforms have shown us, smartphones do a lot with their small batteries & any work we can offload from their processing power, helps in increasing battery life & hence user experience. So, cloud/external augmentation of mobile solutions makes a lot of sense and Azure can provide a stable & elastic cloud support. However, it may not be suited for all, given the expenses. If you have MSDN licensing, you get a fair amount of Azure benefits free .. find out details here . These Azure benefits should be more than enough for you to play around for feasibility or even keep a couple of simple hosted solutions running 24/7. However, you may be in shady territory if you are making money off of a Windows Phone app with cloud support for which you are using MSDN benefits that have been paid for by your employer. And if you are paying for Azure time out of your pocket, you need to make sure you can economically justify the cost of the cloud support you are utilizing. In essence, what I am saying is Azure can be a wonderful companion to your Windows Phone solution, if you are sure that the economics of it make sense.

What you need to follow along

Here are the software/subscriptions you need to get started:

An Active Windows Azure subscription. Utilize your MSDN benefits by starting here or head over here to get a free trial.
Visual Studio 2010 with Service Pack 1
Windows Phone SDK 7.1 SDK RC found here
Optionally, Entity Framework 4.1 available here or as a Nuget

Download Source Code here.

Please note that in the Windows Phone project source code, the actual Reference to the Azure OData Service has been dummied up for confidentiality reasons. Everything should compile; but you will have to point the Service Reference to your own similar OData service for it to work.

The Prelude

Say, you are trying to write a To-Do/Shopping List application for Windows Phone .. Great! However, as much as we love it, our Windows Phone, or for that matter, any smartphone is not a great form factor for a lot of data entry. So ideally, you may consider giving your users an alternate view of the data that is handled by your application. Wouldn't it be nice if I could log on to a website, and set up my To-Do lists or Shopping lists, only for the same lists to show up on my Windows Phone app? Further, changes made from the Windows Phone app should be reflected back in the data source so you can see the updates from a webpage & vice versa.

To support such an approach, we are going to need a central repository/database which is easily accessible & updateable from multiple platforms like web and Windows Phone or other mobile platforms. This is where Windows Azure may come in very handy!

SQL Azure Database & the Backend Service

Let us begin with a SQL Azure data store. You my think of SQL Azure to be almost the same as a regular SQL Server, except it is running as a service in the Azure infrastructure and has a whole lot of plumbing underneath to support failovers, replication, billing & OData services etc. But, for you as a developer, your interaction with a SQL Azure Database should be no different than communicating with a local/remote SQL Server. So essentially, if we can maintain a global Database in SQL Azure, and provide secure access to data to various client platforms, we may be able to achieve what we set out trying .. right?

As you will see in the screenshot below, I have gone to the Azure Developer portal (here), chosen a subscription & created a SQL Azure server:

As you can see above, the highlighted URL showing the “Fully Qualified DNS Name” is important. This is what you will use in the Connection String if you had to connect to this SQL Server instance remotely, along with your Azure credentials. Also, you will notice that I have created a Database called “Demo”, which we shall use as our primary backend database. Now, I can hit the “Manage” link to go inside my database and handle Tables/Stored Procedures etc., as shown in the screenshot below:

You’ll notice that once inside my Database, I have created a simple table called “Team”, with its schema showing on the right. Essentially, I want to maintain a list of Team Members, and hang on to “Name” & “TwitterHandle” for each; the “ID” column is the unique Primary Key & is self-incrementing. The graphical tools provided should make it fairly easy to setup your database tables just the way you want; alternatively you can do all of this from SQL Server Management Studio if you connect remotely. Now, let’s go ahead and add some dummy data to our table, shall we?

So, now we have some data in SQL Azure, which is to be our Global repository .. how do we access it from a Windows Phone app? Super simple – OData! If you had a local data store, you could make an OData service out of it by adding ADO.NET Data Model & a WCF Data Service on top of it. With your data in SQL Azure, this comes free!!

Before we proceed, may be let’s take a step back & define what we are dealing with here. “In very simple terms, OData is a resource-based Web protocol for querying and updating data. OData defines operations on resources using HTTP verbs (PUT, POST, UPDATE and DELETE), and it identifies those resources using a standard URI syntax. Data is transferred over HTTP using the AtomPub or JSON standards.” (Source: MSDN Magazine, June 2010 Issue). One of the best places to start learning about OData is this; you can learn about all the public Producers, Consumers and OData Client SDK for various platforms.

Now, let's head over to the SQL Azure Labs (still CTP) site here, which requires signing in with your Live credentials .. the same one that is tied to the Azure subscription/trial that your are using. Then, if you select the "SQL Azure OData Service", you should see all your Databases from the SQL Azure server you created. Let’s select the “Demo” database, and then one checkbox is all it takes to open up OData service on top of it!! Make sure you select "dbo" to have the service openly accessible for this demo and copy the resulting OData Service URL:

That's it! Let's grab the Service URL and try it in our browser. Notice below that I appended the collection name “Teams” at the end of the service URL. Our data from the "Team" table is now perfectly accessible through the OData service from SQL Azure! Yay -- now we are ready to interact with this data in our Windows Phone application.

The Windows Phone Client

For the Windows Phone app to consume the OData service out of SQL Azure, we start with a simple UI to accommodate only what is needed. So, we have one page that shows a list of all "Team" members from the OData service, in turn, coming directly out of the Team table in the SQL Azure database. From this initial page listing Team members, one may add new Team members or edit/delete existing Team members. The goal is to demonstrate CRUD [Create, Read, Update & Delete] operations against the OData service and have it reflected in the underlying data store in our SQL Azure Table. Here are few screenshots of how the Windows Phone client looks like:

As you can see, two simple XAML pages is what makes up the UI. For the sake of the length of this post, I'm going to skip showing most of the XAML code driving the UI; you have access to it from the downloadable source code. Let's talk about how this thing works, shall we?

Now, since this is a demo application, I don't have any fancy UI or Progress Bars; I simply try to load up my list of Team Members from the OData service as the "TeamList.xaml" page loads up in its frame. Before writing any code though, we need to let the Windows Phone project know where it can find a Reference to the Team collection; essentially register the OData service in the project so we can have a proxy built & can perform operations against the service. Here's how we add reference:

You'll notice that I used the same URL that SQL Azure Labs had created for exposing OData service on top of the "Demo" database for us to have access to "Team" table data. Once we have the Service Reference in place, half the work is done! One thing to note is adding an OData Service directly as a reference is supported in Windows Phone SDK 7.1 onwards. If using previous versions, you could still interact with an OData Service; but would just have to build out your proxy classes manually using the OData Client for Windows Phone, found here and the “DataSvcUtil.exe” utility.

Next, we utilize a special class called the "DataServiceCollection" to reference a collection of "Team" members from the OData service. This is a dynamic entity collection that is also an "ObservableCollection" .. this means a “DataServiceCollection” is totally bindable to XAML UI and changes in the underlying list get reflected in the UI automatically through the implementation of "INotifyPropertyChanged" interface. In addition to being an "ObservableCollection", the "DataServiceCollection" also exposes CRUD operations against the backend data store through the “DataContext” class, as we shall see soon. Here's how we hydrate our "Team" collection from the OData service .. remember this is Silverlight; so we cannot lock up the UI thread & have to use Async calls:

using TeamService;

using System.Data.Services.Client;

  

DataServiceContext context;

DataServiceCollection team;

  

// Instantiate the context & fetch data.

context = new DataServiceContext(new Uri("https://odata.sqlazurelabs.com/OData.svc/v0.1//Demo"));

team = new DataServiceCollection(context);

Uri uriQuery = new Uri("/Teams()", UriKind.Relative);

  

// Asynchronously load the result of the query.

team.LoadAsync(uriQuery);

  

team.LoadCompleted += (sender, args) =>

{

   if (args.Error != null)

   {

      // Do error handling.

   }

   else

   {

      // Success.

      // Do data-binding if needed.

   }

};

  



Once we have the "Team" collection hydrated, data binding to our XAML UI is rather simple, as shown below:

"teamList" Margin="0,0,-12,0" ItemsSource="{Binding Teams}" Foreground="White">

    

        

            "10,0,0,25" Width="432">

                "{Binding Name}" Style="{StaticResource PhoneTextAccentStyle}" Margin="10,0,0,0" FontSize="42"/>

                "{Binding TwitterHandle}" Margin="20,0,0,0" FontSize="38"/>

            

        

    



Now, adding a record through the OData Service is also very easy .. note this is done entirely in C# code through the beauty of the “DataServiceCollection” & “DataServiceContext” classes:

private void InsertDataThruODataService()

{

    var TeamMember = new Team();

    // Grab user entered info from UI.

    TeamMember.Name = this.txtName.Text.Trim();

    TeamMember.TwitterHandle = this.txtTwitterHandle.Text.Trim();

  

    var collection = new DataServiceCollection(context);           

    collection.Add(TeamMember);

    context.BeginSaveChanges(new AsyncCallback(SaveDoneCB), null);

}    

  

private void SaveDoneCB(IAsyncResult asynchronousResult)

{

   // Warning: You are on a different thread! 

   Dispatcher.BeginInvoke(() =>

   {

       MessageBox.Show("Voila, Saved to the Cloud :)", "All Done!", MessageBoxButton.OK);

       this.NavigationService.Navigate(new Uri("/TeamList.xaml", UriKind.Relative));

   });

}   



The only little thing to note in the code above is that the actual Insert is a Save operation against the context of the OData Service & this has to be done asynchronously. Correspondingly, we wire up an Async event-handler that fires when the Save operation is done. Please note here that if you are trying to update anything on the UI from this CallBack method, you might want to be aware that the Async method is possibly on a different thread for optimization. Hence, we need to do the little marshaling of threads to merge before we update UI pieces.

If the user selected an existing “Team” member, our second page now goes into Edit mode & preloads the selected member’s information for the user to change/delete. Here’s how we load up an existing member:

// Event-Handler on List page UI.

private void teamList_MouseLeftButtonUp(object sender, MouseButtonEventArgs e)

{

    if (this.teamList.SelectedItem != null)

    {

        Team selectedMember = (Team)this.teamList.SelectedItem;

    

        // We carry the ID of the selected Team Member.

        this.NavigationService.Navigate(new Uri("/AddOrEdit.xaml?id=" + selectedMember.ID, UriKind.Relative));

    }

}

  

// In the Edit page ..

if (this.NavigationContext.QueryString.ContainsKey("id"))

{

    int teamMemberID = Convert.ToInt16(this.NavigationContext.QueryString["id"]);

  

    // Try finding matching Team Member in collection.

    presentTeamMember = teamCollection.First(x => x.ID == teamMemberID);

  

    if (presentTeamMember != null)

    {

        // Pre-Load Data.

        this.txtName.Text = presentTeamMember.Name;

        this.txtTwitterHandle.Text = presentTeamMember.TwitterHandle;                

    }

}

And once we have an existing “Team” member object at hand, update/delete become equally easy by wiring up ApplicationBar Icon buttons from the UI:

private void SaveDataThruODataService()

{

    presentTeamMember.Name = this.txtName.Text.Trim();

    presentTeamMember.TwitterHandle = this.txtTwitterHandle.Text.Trim();

  

    context.UpdateObject(presentTeamMember);

    context.BeginSaveChanges(new AsyncCallback(SaveDoneCB), null);

}

  

private void DeleteDataThruODataService()

{

    context.DeleteObject(presentTeamMember);

    context.BeginSaveChanges(new AsyncCallback(SaveDoneCB), null);

}

The only other interesting UI code to note is that when we want to add a new “Team” member from the second screen, we don't want to see the "Delete" Application Bar icon, right? Essentially, we want the App Bar to be dynamic based on the function of the page. Remember, the ApplicationBar is a part of the Phone shell & not a first-class Silverlight citizen. Here's how we refer to buttons in code:

var DeleteButton = this.ApplicationBar.Buttons[1] as ApplicationBarIconButton;

DeleteButton.IsEnabled = false;

That's it! Now we have a simple Windows Phone application that reads & updates data from an OData Service, which in turn gets reflected in the backend table in SQL Azure.

The Web Front-end

Now, we started out with the premise that we wanted access to the same data through a Windows Phone application, as well as a website, right? With our data in SQL Azure, this is pretty simple to do through an MVC type web application. So, we create a simple MVC project from template & add a few files to get the following Solution structure:

The files we need are highlighted. The code – super simple:

// Our Model.

public class Team

{

    public int ID { get; set; }

    public string Name { get; set; }

    public string TwitterHandle { get; set; }

}

  

// Our DBContext.

public class TeamDBContext : DbContext

{        

    public DbSet Teams { get; set; } 

}

  

// Our Controller.

public class TeamController : Controller

{

   public ActionResult Index()

   {

       using (var db = new TeamDBContext())

       {               

           return View (db.Teams.ToList());

       }

   }

   ....

}

Essentially, we have a Database Context, and simply have the MVC Controller send down a list of “Team” members to the view, which is a Razor view auto-generated through MVC Scaffolding. Now, how does the run-time figure out where to get this Database Context? Glad you asked .. it’s a one liner in the Web.config:



  "TeamDBContext" connectionString="Data Source=.database.windows.net; Initial Catalog=Demo; User Id=you@.database.windows.net; Password=; Encrypt=True; Trusted_Connection=false;" 

       providerName="System.Data.SqlClient"/>



Notice that the Connection String is what defines what “TeamDBContext” means and this is what points the web application back to the SQL Azure server & the exact Database name. That’s it .. hit F5 and navigate to the Team controller. The result?

Voila! We now have a web application pointed to the same global data in our SQL Azure Database and see the data that was pushed from the Windows Phone app. If you implement the CRUD functionality in MVC, you should also be able to update the table data from the website & have it picked up by the Windows Phone application!

As an added cookie, if you have Entity Framework 4.1 installed, you have the “Magic Unicorn” and that means Code-First approach. You may totally start out your solution writing the model class in your web application, without creating a database. When you run the application for the first time, nothing will be found at the Azure server pointed by the Connection String; so the “Demo” database & the “Team” table with the correct schema will be created for you automatically. Then, the Windows Phone app could follow suit just the way we had it. Fun, isn’t it?

Other Mobile Platforms?

So by now, we have a fully-functional Windows Phone application that is leveraging a backend Database hosted inside SQL Azure and we are freely able to perform CRUD operations through the OData Service. All that is great, until your boss demands to see the same data in his iPhone/iPad and a friend desperately wants to utilize the data in his Android application! Well fear not. Simply point them to the OData SDK home (here) and ask them to get the OData client for their respective platforms. These client libraries should function similarly in building proxies to allow operations against the backend OData Service & soon they shall all be able to read/write data from the same data store in Azure. See, we can all live peacefully :)

Conclusion

In this article, we talked about why & how you, as a Windows Phone developer, should consider utilizing Windows Azure as a robust backend for your mobile applications. We saw how easily we could host a central database within SQL Azure & immediately expose the data out as an OData Service. Also, OData services fully support CRUD operations against the backend data and the interoperability of OData makes it a wonderful choice to have the same information be consumed & updated from various platforms.

Thank you very much for reading through this article; hopefully it was somewhat beneficial. If you have any questions or thoughts on how things can be done better in the above context, please feel free to reach out to me through the channels below; I will be happy to get some feedback. Big thank you to SilverlightShow for publishing this article & for all their awesomeness.

About the author

Samidip Basu (@samidip ) is a technologist & gadget-lover working as a Manager & Solutions Lead for Sogeti out of the Columbus OH Unit. Having worked on WP7 since CTP days, he now spends much of his time in spreading the word to discover the full potential of the Windows Phone platform & cloud-based mobile solutions in general. He passionately runs the Central Ohio Windows Phone User Group (http://cowpug.org/ ) and can be found with atleast a couple of hobbyist projects at any time. His spare times call for world travel and culinary adventures with the wife. Find out more at http://samidipbasu.com/ .

Windows Phone 7 Data Access Strategies: Web Services

editorial@silverlightshow.net (Andrea Boschin ) — Wed, 31 Aug 2011 11:43:00 GMT

Don't miss...

($4.99)

All SilverlightShow Ebooks

In the two previous articles of this series I've spoken about a couple of tools that are really useful to retrieve remote resources by the HTTP protocol. Also if WebClient and HttpWebRequest are both complete and easy to use, the problem is that their usage is for sure heavy, because you need to rely on your own protocol made for example of XML files. The process of serializing and deserializing can become very annoying and if you have more than two or three files, the wasted time is unacceptable.

With this problem in mind it is easy to understand that the real answer to this problem are the Web Services, meaning with this term something that is based on a known protocol - obviously built on top of HTTP - and makes easy the process of sharing data between client and server, hiding transport and serialization problems.

Speaking about Web Services in this article would require lot of pages, so I will assume you are already familiar with the concept behind this term and also probably you are familiar with the Windows Communication Foundation that is currently the best way of creating and consuming a Web Service in a Windows environment. Assuming this I will show how to consume a WCF Web Service from Windows Phone 7 and how to configure both the client and server side.

A, B, C...

As you probably already know, working with WCF you have to be aware of three things that uniquely define the Web Service you have to consume: Address, Binding and Contract. Since "Address" says where the service is located, in the form of a Uri, the "Binding" describes how the client and server will speak each other. Serialization and deserialization matter is part of the binding but also the transport: HTTP, HTTPS, and so on. But the most important part is the "Contract" that describes what the service can do. In WCF, a contract is an interface with a bunch of methods - usually called "Operations" - and each one do something with some kind of input and output.

When you call a WCF service from a Windows Phone device, you have some limitations, specifically in the Bindings you can use. Since WP7 is based on Silverlight 3.0 (but the incoming "Mango" release probably will change this someway) you can only use BasicHttpBinding or a special form of Binary XML that makes the communications, more compact. The current version of the operating system does not support TCP transport.

Once you have the "Address" of the service you have to consume, the first thing you have to do is creating a Proxy. The proxy is a client side class that implements the "Contract" of the service and hides to the developer the presence of a Web Service. What it happens is that you call a method on the local class and the proxy take care of serialize request, making the network call, reading the response and deserializes it.

To create the proxy you can left-click the References node of the Windows Phone's project where you want the proxy resides and select "Add Service Reference". This action will start a wizard to configure the proxy.

In the side figure I've already filled the fields of the form but the process is simple; enter the Address and press the "OK" button. The wizard will analyze the contract of the Web Service and it will show the details in the Services and Operations frames. In the lower textbox you can specify the namespace where the proxy class have to be added.

The "Advanced..." button opens a configuration form where you can specify more details about the creation of the proxy. The one I usually change is "Collection Type". it defaults to "ObservableCollection" and I ask always to have an "Array".

When you hit the "OK" button the proxy is created together with a lot of files that you can simply ignore. The sole file you have to know is "ServiceReference.ClientConfig" where it is located the client configuration of the WebService. We will return back to this file later in the article.

The process I've summarized here is good only if you have to consume a single Web Service or different services that are completely insulated each other. But in the common case you have many different services that share some type, you need to rely on a command line utility that is able to receive all the endpoints at a time and generate the proxies, being aware of the common types. The tools is slsvcutil.exe and it is located in the SDK folder at %ProgramFiles(x86)%\Microsoft SDKs\Windows Phone\v7.0\Tools. The tool has many options on the command line you can explore using the -h switch. Here is an example:

@echo off

  

"%ProgramFiles(x86)%\Microsoft SDKs\Windows Phone\v7.0\Tools\SlSvcUtil.exe" ^

    http://localhost:8000/names.svc ^

    /config:ServiceReferences.ClientConfig ^

    /out:Proxies/GeneratedProxies.cs ^

    /n:*,SilverlightPlayground.ServiceProxies ^

    /ct:System.Collections.Generic.List`1 ^

    /enableDataBinding

  

@echo on

If you need to generate more than one proxy, you can add the service's Uris following the first one in the example and then place the configuration switches. Once the tool finished its work, you will find the ServiceReferences.ClientConfig file and a GeneratedProxies.cs file that you have to add to the project. Important is to remember that every time you change something on the service you have to run again the service reference wizard (it has also an update option in the context menu) or the batch.

Consuming the Web Service

The generation tool that I've mentioned generates lot of code. If you open the GeneratedProxies.cs file you will find a long series of classes, according with the number of services you have referenced and the complexity of each one. As an example if the method of a service returns a complex object, the type is added to the generated code. All what you need is this code. It is not required to make any references to the types in the service's assemblies. When you call the proxy, the runtime works mapping the server types to the client copy and vice versa. It is the process of serialization and deserialization.

The most important class in the generated code is the proxy that is something that puts together the name of the service and the "Client" suffix. In the case of the service in the attached code it is NamesServiceClient. This class represents the service and contains all the things you need, to call the methods. In Windows Phone 7, like in Silverlight, the proxy cannot be so transparent as you would like it to be. Due to the asynchronous model of the communications, calling a method imply to subscribe an event that notifies the call completion:

public void GetNames()

{

    NamesServiceClient client = new NamesServiceClient();

    client.GetNamesCompleted += new EventHandler(client_GetNamesCompleted);

}

  

void client_GetNamesCompleted(object sender, GetNamesCompletedEventArgs e)

{

    IEnumerable<string> names = e.Result;

    // do something with resulting names

}

We are back here to an event-driven paradigm so, like with the WebClient class, we have to subscribe the event and get the result in a separated method. In a layered architecture you can apply the same pattern I've used with the WebClient. The NamesServiceClient instance can be used across different calls, so you can have an instance as a global reference in your DataProvider and use it every time is is required. Additionally the proxy supports concurrent calls but you have to handle by your own the returning event to identify the corresponding call:

public override void GetNames(Actionstring>> success, Action fail)

{

    Guid callId = Guid.NewGuid();

    EventHandler handler = null;

    

    handler = (s, e) =>

    {

        if (callId.Equals(e.UserState))

        {

            this.Client.GetNamesCompleted -= handler;

                success(e.Result);

        }

    };

  

    this.Client.GetNamesCompleted += handler;

    this.Client.GetNamesAsync(callId);

}

Again, in the pattern I attach the event handler and I ensure myself to remove the reference once the method returns the result. Here I added a Guid that I use as call identifier. I put it in the "user state". When the service returns a result I check that the "user state" corresponds to the Guid I generated. This prevent that two concurrent calls to the same method will raise a doubled callback to each entry point.

Handling errors and call cancellation

The proxy class also supports the handling of errors and the cancellation of the calls. Differently from WebClient and HttpWebRequest the proxy is aware of application errors raised as exceptions and it is able to deserialize and deserialize them. WCF implements also a FaultException and the proxy is able to correctly handle this type of exceptions, reading also the details of the errors. Since if you have to catch regular exceptions, you have to enable a configuration flag (includeExceptionDetailInFaults), with FaultException you can pass your own exception detail as a FaultContract and provide the error information to display. Given this new requirement and given that you have also to handle network errors, here is the new code:

public override void GetNames(Actionstring>> success, Action fail)

{

    Guid callId = Guid.NewGuid();

    EventHandler handler = null;

  

    handler = (s, e) =>

    {

        if (callId.Equals(e.UserState))

        {

            this.Client.GetNamesCompleted -= handler;

  

            if (!e.Cancelled)

            {

                if (e.Error == null)

                    success(e.Result);

                else

                    fail(this.HandleFault(e.Error));

            }

        }

    };

  

    this.Client.GetNamesCompleted += handler;

    this.Client.GetNamesAsync(callId);

}

  

private Exception HandleFault(Exception exception)

{

    FaultException fault = exception as FaultException;

  

    if (fault != null)

        return new Exception(fault.Detail.Message);

    else

        return exception;

}

In the above code I handle also the cancellation condition. The NamesServiceClient class has an Abort method that breaks all the pending network operations. When this method is called every call will raise the completion event with the Cancelled flag set to true.

Configure for Binary XML binding

At the start of the article I spoken about two available bindings. By default Visual Studio configures the service and the client for BasicHttpBinding that is a simple format that replicates in WCF the protocol used by asmx services. This protocol is SOAP based and it is verbose. For the purpose of reducing the size of the messages, Silverlight 3.0 added a new BinaryXML binding that is also supported by Windows Phone 7. To configure this binding you have to slightly change the configuration on the server and on the client. Here is the configuration for both Basic and Binary binding on the server side:

<system.serviceModel>

    <bindings>

        <basicHttpBinding>

            <binding name="NamesService_basicHttpBinding" allowCookies="True" />

        basicHttpBinding>

        <customBinding>

            <binding name="NamesService_binaryXML">

                <binaryMessageEncoding />

                <httpTransport />

            binding>

        customBinding>

    bindings>

    <behaviors>

        <serviceBehaviors>

            <behavior name="">

                <serviceMetadata httpGetEnabled="true" />

                <serviceDebug includeExceptionDetailInFaults="false" />

            behavior>

        serviceBehaviors>

    behaviors>

    <services>

        <service name="SilverlightPlayground.DataAccessStrategies.Web.Code.NamesService">

            <endpoint address="basic" 

                      binding="basicHttpBinding" bindingConfiguration="NamesService_basicHttpBinding" 

                      contract="SilverlightPlayground.DataAccessStrategies.Web.Code.INamesService" />

            <endpoint address="binary"

                      binding="customBinding" bindingConfiguration="NamesService_binaryXML"

                      contract="SilverlightPlayground.DataAccessStrategies.Web.Code.INamesService" />

        service>

    services>

    <serviceHostingEnvironment aspNetCompatibilityEnabled="True" 

                               multipleSiteBindingsEnabled="true" />

system.serviceModel>

The service configured in this way exposes two endpoint, the one ending with "basic" is configured with BasicHttpBinding and the one ending with "binary" is configured with the Binary XML. This binding is exposed as a customBinding with and . On the client side you have to replicate the same duality:

<system.serviceModel>

    <bindings>

        <basicHttpBinding>

            <binding name="BasicHttpBinding_INamesService"

                     maxBufferSize="2147483647"

                     enableHttpCookieContainer="True"

                     maxReceivedMessageSize="2147483647">

                <security mode="None" />

            binding>

        basicHttpBinding>

        <customBinding>

            <binding name="NamesService_customBinding">

                <binaryMessageEncoding />

                <httpCookieContainer />

                <httpTransport />

            binding>

        customBinding>

    bindings>

    <client>

        <endpoint name="BasicHttp"

                  address="http://localhost:8000/names.svc/basic"

                  binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_INamesService"

                  contract="Services.INamesService" />

        <endpoint name="BinaryXML"

                  address="http://localhost:8000/names.svc/binary"

                  binding="customBinding" bindingConfiguration="NamesService_customBinding"

                  contract="Services.INamesService" />

    client>

system.serviceModel>

Each endpoint has a different name in this configuration (BasicHttp and BinaryXML). This name is useful if you need to use one endpoint or the other. When you create the NamesServiceClient instance you can specify the endpoint name, to read one configuration or the other

this.Client = new NamesServiceClient("BinaryXML");

Using Cookies and Credentials

Cookies and Credentials are also supported by the generated proxy. Differently, when you call a Web Service, you are not able to access Headers and Verbs. Once you created the instance of the proxy class, it exposes a ClientCredentials property, ready to receive the credentials:

this.Client.ClientCredentials.UserName.UserName = "username";
this.Client.ClientCredentials.UserName.Password = "p@ssw0rd";

The use of cookies should not be needed with a Web Service. Every call to the service should be stateless but when you enable AspNetCompatibilityRequirements on the server side, using a CookieContainer you can enable the Session variables and sometimes these may be useful. From my point of view it is better to not use Session variables but I'm aware that someone can take some advantage from it. The proxy exposes a CookieContainer property but you do not need to set the container by yourself. You have only to enable support for cookies in configuration. For BasicHttpBinding this means to set the enableHttpCookieContainer attribute to True as I did on the line 6 of the previous box. For BasicXML instead you have to add, only on the client side, a element in the customBinding between the encoding and the transport (see line 14 of the box)

A step forward

There is not any doubt you have to take in serious consideration the use of a web service if your application is something of advanced. And probably, thanks to WCF, the easy of the creation of a Web Service overwhelm every other networking tool when you need to use it for data access. From my point of view WebClient and HttpWebRequest are both useful when I have to download a generic file, an rss feed or communicate with some kind of legacy system. But when I have under control both the server and client side, the Web Service are for sure the most productive approach.

Windows Phone 7 Data Access Strategies: HttpWebRequest

editorial@silverlightshow.net (Andrea Boschin ) — Tue, 23 Aug 2011 23:56:00 GMT

Don't miss...

($4.99)

All SilverlightShow Ebooks

Download source code

In the previous part of this series I've spoken about WebClient, the simplest class that allows the access to remote resources and I've explained that it is built on top of the HttpWebRequest class. Since WebClient is a class that is made to simplify the access to the HTTP resources, by hiding the details of the call, the HttpWebRequest makes evident the duality of Request/Response that is natural when you deal with HTTP. As we will see, this implies that the HttpWebRequest class gives you a more fine grained control of what is happening but, it also requires more work to accomplish the various tasks required to complete the call.

Request/Response

As I've said when you use the HttpWebRequest class it becomes evident that the HTTP call you are doing is made of two separated parts. Indeed you have to deal with a couple of class instead of one: WebRequest and WebResponse. The WebRequest (HttpWebRequest) represents the very first part of the call, the one that goes from the client to the server, transporting the request header, cookies, credentials, and obviously posted data. After the server received the request, you have to deal with the WebResponse that contains data returned by the server, the response headers, and so on. When you place a call with HttpWebRequest you have to follow the following path:

Create an instance of the HttpWebRequest
If you have to post something get the request stream
Then write posted data to the request stream
Get the response (that is actually what starts the call)
Get the response stream
Read returned data from response stream
Close all thing

What makes things hard is the process of getting the request stream and the response which are both asynchronous, so, in the case you have also to upload something, you have to deal with two asynchronous calls instead of one. Here is the how the HttpWebRequest can be used to retrieve a rss feed; in this case I don't send anything to the server so the asynchronous call is one:

public void GetFeed()

{

    HttpWebRequest request = HttpWebRequest.CreateHttp("http://www.slpg.org/syndication.axd");

    request.BeginGetResponse(new AsyncCallback(HandleResponse), request);

}

public void HandleResponse(IAsyncResult result)

{

    HttpWebRequest request = result.AsyncState as HttpWebRequest;

    if (request != null)

    {

        using(WebResponse response = request.EndGetResponse(result))

        {

            using (StreamReader reader = new StreamReader(response.GetResponseStream()))

            {

                string feed = reader.ReadToEnd();

                // do something with the feed here

            }

        }

    }

}

Please take immediately note of the "using" blocks that are intentionally used every time it is found a class that implements IDisposable like WebResponse and StreamReader. These blocks are useful to release resources that are not used anymore. But in this sample, what is immediately clear, is that the asynchronicity model of this class is callback-based (using the Begin-End pattern) instead of event-based. This implies you have to write lot of code to retrieve the response but for the sake of the application layering, it is better because it does not requires to attach and detach events. Again, the best thing is to follow a pattern to encapsulate the network calls in a isolated layer:

public void GetFeed(Action<string> result)

{

    HttpWebRequest request = HttpWebRequest.CreateHttp("http://www.slpg.org/syndication.axd");

    request.BeginGetResponse(

        a =>

        {

            string data = null;

            using (WebResponse response = request.EndGetResponse(a))

            {

                using (StreamReader reader = new StreamReader(response.GetResponseStream()))

                {

                    data = reader.ReadToEnd();

                }

            }

            Deployment.Current.Dispatcher.BeginInvoke(() => result(data));

        }

        , null);

}

If you carefully read the article on WebClient you have for sure noticed a big difference between this last example and the corresponding example in the other article. You are to be aware that once you return the result, you have to make the thread marshaling to the user interface. This is the very biggest difference between WebClient, where the thread marshaling is made by the class and HttpWebRequest, where you have to make the marshaling by your own.

Since this may appear annoying you have to know that it is probably the best reason to use this class instead of the WebClient, specifically if you have to perform some operations on retrieved data before returning them to the UI thread. As an example if you need to perform a deserialization, with the WebClient this operation is performed on the UI thread, impacting directly the performances of the user interface, but using the HttpWebRequest you can perform deserialization in the network call thread and then move the result to the UI leaving it free to run at the maximum performances during the operation.

Errors handling and Aborting a call

Exceptions handling with HttpWebRequest have the same limitation as the WebClient: you can only intercept exceptions coming from network issues but for application errors you have to rely on your own protocol built on top of the HTTP. This may be an error code returned in the body of the response, a special http header, but the HttpWebRequest will not understand it for you. For the other cases, like timeouts, network faults and so on, you have to rely on exceptions using one or more try-catch blocks.

You can get a number of exceptions by the methods but the most important is the WebException. With this exception you can read the exact reason that caused the fault in the communication. As an example, you can receive a value of RequestCanceled stating that at some point someone has called the Abort() method in the HttpWebRequest. This method causes the immediate cancellation of the request and the situation is handled raising a WebException. Now that we are aware of the various aspects of error handling and cancellation here is the complete code for a call:

public void GetFeed(Action<string> result, Action fail)

{

    HttpWebRequest request = HttpWebRequest.CreateHttp("http://localhost:8000/HttpHandler.ashx");

    try

    {

        request.BeginGetResponse(

            a =>

            {

                try

                {

                    string data = this.ReadResponse(request, a);

                    Deployment.Current.Dispatcher.BeginInvoke(() => result(data));

                }

                catch (Exception ex)

                {

                    this.HandleErrors(ex, fail);

                }

            }

            , null);

    }

    catch (Exception ex)

    {

        this.HandleErrors(ex, fail);

    }

}

private string ReadResponse(HttpWebRequest request, IAsyncResult a)

{

    using (WebResponse response = request.EndGetResponse(a))

        using (StreamReader reader = new StreamReader(response.GetResponseStream()))

            return reader.ReadToEnd();

}

private void HandleErrors(Exception ex, Action fail)

{

    WebException we = ex as WebException;

    if (we != null && we.Status == WebExceptionStatus.RequestCanceled)

        return;

    Deployment.Current.Dispatcher.BeginInvoke(() => fail(ex));

}

In this code you can see two try-catch blocks apparently nested each other. The outer block is responsible of catching the exceptions raised by the BeginGetResponse method, exceptions that are raised in the UI thread before to start the network call. Once the method spawned a new thread to begin the call, the outer block becomes inefficient so I have to put another try-catch inside the lambda expression to catch errors raised in the separated thread. In the HandleErrors method I check if the exception is a WebException and the status is RequestCanceled. In this case the exception is swallowed and it does not return to the caller, due to a user cancellation. In all the other cases the exception is presented to the fail lambda.

Download and Upload progress

Again, following the path of the previous article, there may be the need to display the progress of the network operation. While the WebClient notifies you an event with the global progress of the operation, the HttpWebRequest is not so smart but it requires you to handle directly the situation. The bad news is that you cannot handle the progress of upload because it is not implemented in Silverlight for Windows Phone.

First of all, to notify the progress you have to be aware of the size of the file you are moving. The operation will be cut into little pieces and, on the completion of each chunk, you can update the progress calculating the percentage with the bytes moved and the expected size. To accomplish this task you have to set the AllowReadStreamBuffering to false. Setting this property disables the normal behavior of the HttpWebRequest that usually uses a buffer in memory to optimize the network transfer. Disabling this buffer allows to directly read bytes from the network in small chunks and at each one calculate the remaining download size; something like this:

public void GetHugeFile(Action<string> result, Action fail, Action<double> progress)

{

    HttpWebRequest request = HttpWebRequest.CreateHttp("http://www.slpg.org/syndication.axd");

    try

    {

        request.AllowReadStreamBuffering = false;

        request.BeginGetResponse(

            a =>

            {

                try

                {

                    using (WebResponse response = request.EndGetResponse(a))

                    {

                        int expected = (int)response.ContentLength;

                        using(StreamReader reader = new StreamReader(response.GetResponseStream()))

                        {

                            int read = 0;

                            StringBuilder data = new StringBuilder(expected);

                            char[] buffer = new char[1024];

                            while ((read = reader.Read(buffer, 0, buffer.Length)) != 0)

                            {

                                data.Append(new string(buffer, 0, read));

                                Deployment.Current.Dispatcher.BeginInvoke(() => progress(data.Length * 100.0 / expected));

                            }

                            Deployment.Current.Dispatcher.BeginInvoke(() => progress(100.0));

                            Deployment.Current.Dispatcher.BeginInvoke(() => result(data.ToString()));

                        }

                    }

                }

                catch (Exception ex)

                {

                    this.HandleErrors(ex, fail);

                }

            }

            , null);

    }

    catch (Exception ex)

    {

        this.HandleErrors(ex, fail);

    }

}

Again on Headers, Verbs, Credentials and Cookies

To complete the exploration of the HttpWebRequest class, it remain to discuss the ones I called "advanced topics". Speaking about headers, you have to be aware of the strict separation between WebRequest and WebResponse. If you need to access the headers you are sending to the server you have to use the Headers property on the HttpWebRequest instance, also with custom headers.

request.Headers["x-source-uri"] = http://www.silverlightplayground.org/;

HttpWebRequest has the same limitation on headers you can manipulate, as the WebClient has. As already said you can read about these limits in this page: http://msdn.microsoft.com/en-us/library/system.net.webheadercollection(v=VS.95).aspx. To access the response headers you have the same Headers collection on the WebResponse class.

In the example attached to this article, that I've extended adding the support for HttpWebRequest, you can see that the requests are made setting the Method property. This let you decide the Verb to send to the page and apply the same RESTful paradigm as I did with the WebClient.

public override void AddNames(IEnumerable<string> names, Action success, Action fail)

{

    this.UploadNames(names, "POST", success, fail);

}

public override void DeleteNames(IEnumerable<string> names, Action success, Action fail)

{

    this.UploadNames(names, "DELETE", success, fail);

}

private void UploadNames(IEnumerable<string> names, string method, Action success, Action fail)

{

    HttpWebRequest request = HttpWebRequest.CreateHttp("http://localhost:8000/HttpHandler.ashx");

    request.CookieContainer = this.Cookies;

    request.Method = method;

    try

    {

        request.BeginGetRequestStream(

            a =>

            {

                try

                {

                    using (StreamWriter writer = new StreamWriter(request.EndGetRequestStream(a)))

                        writer.Write(this.Serialize(names));

                    request.BeginGetResponse(

                        b =>

                        {

                            try

                            {

                                string result = this.ReadResponse(request, b);

                                // handle here the result

                                Deployment.Current.Dispatcher.BeginInvoke(() => success());

                            }

                            catch (Exception ex)

                            {

                                this.HandleErrors(ex, fail);

                            }

                        }

                        , null);

                }

                catch (Exception ex)

                {

                    this.HandleErrors(ex, fail);

                }

            }, null);

    }

    catch (Exception ex)

    {

        this.HandleErrors(ex, fail);

    }

}

In the above sample I also demonstrated the use of the CookieContainer. This property is directly exposed by the HttpWebRequest class. Remember that differently from WebClient you can use an instance of HttpWebRequest only once, so it is important you share the same instance of the CookieContainer across different calls if you need to ensure all of them share the same cookies.

And finally if you need to present your credentials to the web server you can again rely on the Credentials property:

request.Credentials = new NetworkCredential("username", "p@ssw0rd");

Making a choice

Speaking for real, I will say that there are very few things that you can do with HttpWebRequest that you cannot do with WebClient. The different features are so subtle that to me the sole reason to decide to use one instead of the other is to deal with performances troubles that you can resolve using the manual thread marshaling in the HttpWebRequest. On the other side if you are not hit by performances problems, probably the WebClient is the better solution for its simplicity.

WP7 for iPhone and Android Developers : From Core Data to LINQ to SQL

editorial@silverlightshow.net (Kevin Hoffman ) — Wed, 03 Aug 2011 00:35:13 GMT

Don't miss...

($2.99)

All SilverlightShow Ebooks

This article is part 9 of a 12-part article series on Windows Phone 7 for iPhone and Android Developers. While many of the previous articles in this series work perfectly fine on Windows Phone 7 and Windows Phone 7.1 (formerly codenamed “Mango”), this article focuses specifically on a feature unique to the 7.1 “Mango” release – LINQ to SQL and on-device SQL database files.

One of the features of the iOS SDK that is often lauded as one of the biggest benefits of the SDK is its support for the Core Data framework. As Apple developers (both Mac and iOS) know, this framework is an object-relational mapping framework that allows for robust queries, relationships between entities, and even storage of binary (BLOB) data as entity attributes. Further, Core Data also allows application developers to read to and write from files such as SQLite files (XML and binary formats are supported on the Mac but only SQLite is supported in iOS).

Xcode 4 lets you visually design your entities, their relationships, and even pre-defined queries (called fetch requests) right within the editor, as shown in this screenshot below:

The similarities between this entity model designer and model designers like those that come with LINQ to SQL and the Entity Framework within Microsoft Visual Studio 2010 are not accidental – all of these frameworks have a single goal in mind: providing a persistence store for an entity model. In the screenshot above, two entities (Scene and Character) are depicted. These entities have a many-to-many relationship to each other.

Note that LINQ to SQL doesn’t natively support many-to-many relationships without the use of an interim or middle-man linking table (e.g. a table called CharacterScenes to support the above example). Core Data models support many-to-many relationships natively and, when using a SQLite database, will actually create the linking table behind the scenes without bothering the developer with those details. Developers coming from Core Data to LINQ to SQL who plan on migrating data models with many-to-many relationships need to be aware of this limitation.

Developers who attempted to build local data-driven (as opposed to data in the cloud) applications for the first release of Windows Phone 7 were limited to using tools like the WCF binary contract serializer to read and write binary files from Isolated Storage. Such limitations are gone and with WP7.1 as developers now have access to virtually all of the robust, powerful features of LINQ to SQL with an underlying SQL database file.

Next, we’ll take a look at how to create data models for Windows Phone 7.1 using LINQ to SQL. Unfortunately, we don’t currently have a visual design surface for phone-based models like we do for enterprise LINQ to SQL models, but I’m hoping that’s just a limitation of the beta. For now, we have to build our models by writing POCO (Plain-Old C# Object) classes and decorating them with enough attributes to allow LINQ to SQL to infer the metadata for the underlying database.

To continue with the sample above of Character entities, let’s create a Character entity that belongs to another entity called World. First, let’s see the child class, Character:

[Table]

public class Character

{        

    private EntityRef world;

  

    public Character()

    {

        this.world = default(EntityRef);           

    }

  

    public void Detach()

    {

        this.world = default(EntityRef);

    }

  

    [Column(IsPrimaryKey = true, IsDbGenerated = false, 

        CanBeNull = false,

        AutoSync = AutoSync.OnInsert)]

    public Guid Id { get; set; }

  

    [Column]

    public Guid WorldId { get; set; }

  

    [Column(IsVersion=true)]

    public byte[] Version { get; set; }

  

    [Association(Name="World_Character", Storage = "world", ThisKey="WorldId", 

        OtherKey="Id", IsForeignKey=true)]

    public World World

    {

        get

        {

            return this.world.Entity;

        }

        set

        {

            this.world.Entity = value;

        }

    }

  

    [Column]

    public string Name { get; set; }

  }

The Character class is decorated with the Table attribute. This means that when the SQL database is created, it will create a table named Character. Next we see that we’ve got an object of type EntityRef. This is, as its name implies, a reference to another entity. In the constructor, we set this value to the default value for an entity ref of that type – this keeps us from throwing exceptions when we access properties on newly created Character objects.

The Detach() method gets called by our code when we are about to update character entities. The reason for this is fairly complicated, but basically we need this method if we are going to save changes to a Character object that belongs to a different data context than the World object to which it belongs. Thankfully you don’t need to worry about those kinds of scenarios just yet.

Now let’s see the parent class, World. In our model, we don’t actually need to grab a list of characters for a world object, since we can filter characters by their WorldId column and so we don’t need a reference to an EntitySet of Character objects. This is where LINQ to SQL starts to show how “close to the metal” it is. Core Data developers may be very put off by the fact that you have to pick and choose when you surface a relationship. Additionally, Core Data developers don’t need to explicitly define identity variables for their entities – the relationships are made available to developers automatically. If I had to make a comparison, I’d say that Core Data provides a model very close to what I would consider a business model whereas LINQ to SQL, despite its “Entity” nomenclature, is very much a data model.

[Table]

public class World

{        

    [Column(IsPrimaryKey = true, IsDbGenerated = false,

       CanBeNull = false,

       AutoSync = AutoSync.OnInsert)]

    public Guid Id { get; set; }

 

    [Column]

    public string Name { get; set; }    

}

This is only half of the work that needs to be done. Once you have your LINQ to SQL objects defined and you have the mapping attributes configured the way you’d like, you need to create a wrapper class called a data context class. Here’s a data context class that exposes properties that can be used to query for Character or World objects:

public class MyDataContext : DataContext

 {

     public MyDataContext()

         : base(ModelConstants.ConnectionString)

     {

  

     }

  

     public Table Characters;

     public Table Worlds;

 }

The MyDataContext class inherits from System.Data.Linq.DataContext (remember to add a reference to System.Data.Linq for your project). The constructor passes in a default connection string. In my case, this is a constant which evaluates to "Data Source=isostore:/WorldsAndChars.sdf". This will tell LINQ to SQL to back our data objects with a SQL file called WorldsAndChars.sdf stored in the Isolated Storage area for our application.

We’re almost there – the next thing we need to do is use our data context to create an empty database the first time the application starts:

using (var dc = new MyDataContext())

{

   if (!dc.DatabaseExists())

   {         

      dc.CreateDatabase();

   }

}

Now that we’ve created our LINQ to SQL objects, we’ve created a wrapper context for those objects, and we’ve created the database programmatically, we’re finally able to start working with those objects. First, we can query the data context:

public static Character[] GetCharacters(Guid worldId)

{

    using (var dc = new MyDataContext())

    {

        var q = from Character c in dc.Characters

                orderby c.Name

                where c.WorldId == worldId

                select c;

        return q.ToArray();

    }

}

Or we can create new characters (also using the data context):

public static void SaveCharacter(Character c)

{

    using (MyDataContext dc = new MyDataContext())

    {

        c.Detach();

        if ((c.Id == null) || (c.Id == Guid.Empty))

        {

            c.Id = Guid.NewGuid();

            dc.Characters.InsertOnSubmit(c);

        }

        else

        {

            dc.Characters.Attach(c, true);

        }

        dc.SubmitChanges();

    }

}

The above method will either create a new character or save an existing one, depending on whether the character exists (its ID has been set). Note the call to c.Detach() – remember that bit earlier where I mentioned that LINQ to SQL doesn’t always like it when you try and save one entity with a data context that is different than the one that loaded it (or its related entities)? Detaching it like this prevents such conflicts. Finally, calling SubmitChanges() on the data context commits all changes made since the last time that data context saved its changes. As a rule, I try and make methods like this that will allow a transient data context to go out of scope as soon as their work is done – this avoids potential multi-threading and multi-context conflicts that might arise from leaving contexts floating around everywhere in my application.

For more information on LINQ to SQL, the best source of information is probably Microsoft’s own documentation for the System.Data.Linq namespace, which contains all of the data mapping attributes that you use to control data storage, metadata, relationships, keys, and column and table properties.

Summary

Core Data is a fantastic framework that allows iOS developers to rapidly build data-driven applications. It gives developers the ability to define data entities, their attributes, and their relationships and persist those entities in a SQLite database. Windows Phone 7.1 gives developers LINQ to SQL and the ability to persist their entities, relationships, and attributes in a SQL database in an Isolated Storage folder.

Quick, easy, robust access to simple object-relational mapping tools gives developers yet another tool in their toolbox for building amazing mobile applications for Windows Phone 7.

Producing and Consuming OData in a Silverlight and Windows Phone 7 application (Part 4)

editorial@silverlightshow.net (Michael Crump ) — Wed, 27 Jul 2011 15:52:00 GMT

Don't miss...

All SilverlightShow Ebooks

This article is Part 4 of the series “Producing and Consuming OData in a Silverlight and Windows Phone 7 application.”.

To refresh your memory on what OData is:

The Open Data Protocol (OData) is simply an open web protocol for querying and updating data. It allows for the consumer to query the datasource (usually over HTTP) and retrieve the results in Atom, JSON or plain XML format, including pagination, ordering or filtering of the data.

To recap what we learned in the previous section:

We began by creating the User Interface and setting up our bindings on our elements.
We added a service reference pointing to our OData Data Service inside our project.
We added code behind to sort and filter the data coming from our OData Data Source into our Silverlight 4 Application.
Finally, we consumed an OData Data Source using Windows Phone 7 (pre-Mango).

In this article, I am going to show you how to create, read, update and delete OData data using the latest Windows Phone 7 Mango release. Please read the complete series of articles to have a deep understanding of OData and how you may use it in your own applications.

Download the source code for part 4

Testing and Modifying our existing OData Data Service

I would recommend at the very least that you complete part 1 of the series. If you have not, you may continue with this exercise by downloading the completed source code to Part 1 and continue. I would also recommend watching the video to part 1 in order to have a better understanding of the OData protocol.

Before we get started, I have good news. The good news is that in Mango you do not have to download extra tools or generate your own proxy classes and import them into Visual Studio like you had to do pre-mango. You will be able to use the “Add Service Reference” like we did in Part 2 (Silverlight 4). Let’s go ahead and get started learning more about OData with Mango.

Go ahead and download the completed source code to Part 1 of this series and load it into Visual Studio 2010. Now right click CustomerService.svc and Select “View in Browser”.

If everything is up and running properly, then you should see the following screen (assuming you are using IE8).

Please note that any browser will work. I chose to use IE8 for demonstration purposes only.

If you got the screen listed above then we know everything is working properly and can continue. If not download the completed solution and continue with the rest of the article.

We are going to need to make one quick change before continuing. Double click the CustomerService.svc.cs file and change the following line from:

   1: config.SetEntitySetAccessRule("CustomerInfoes", EntitySetRights.AllRead);

   1: config.SetEntitySetAccessRule("CustomerInfoes", EntitySetRights.All);

This will simply give our service the ability to create, read, update and delete data.

At this point, leave this instance of Visual Studio running. We are going to use this OData Data Service in the “Getting Started” part. You may also want to copy and paste the address URL which should be similar to the following:

http://localhost:6844/CustomerService.svc/

At this point, we are ready to create our Windows Phone 7 Mango Application. So open up a new instance of Visual Studio 2010 and select File –> New Project.

Select Silverlight for Windows Phone –> Windows Phone Panorama Application and give it the name, SLShowODataP4 and finally click OK.

On the next screen make sure you select “Windows Phone 7.1” as the Windows Phone Platform that you want to target.

Once the project loads, the first thing we are going to do is to add a Service Reference to our CustomerService. Simply right click your project and select “Add Service Reference”…

Type the Address of your service (as shown in the first step) and hit “Go”. You should now see Services and you can expand that box to see CustomerInfoes if you wish. Now go ahead and type a name for the Namespace. We are going to use CustomersModel for the name and click OK.

You may notice a few things happened behind the scene. First the reference to “System.Data.Services.Client” was added automatically for us and you now have a Service Reference.

Now we will need to create the User Interface and write the code behind to pull the data into our application.

Double click on the MainPage.xaml file and replace the contents of <—Panorama item one---> with the following code snippet:



           <controls:PanoramaItem Header="first item">

               

               <ListBox x:Name="lst" Margin="0,0,-12,0" ItemsSource="{Binding}">

                   <ListBox.ItemTemplate>

                       <DataTemplate>

                           <StackPanel Margin="0,0,0,17" Width="432">

                               <TextBlock Text="{Binding FirstName}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

                               <TextBlock Text="{Binding LastName}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

                               <TextBlock Text="{Binding Address}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                               <TextBlock Text="{Binding City}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                               <TextBlock Text="{Binding State}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                               <TextBlock Text="{Binding Zip}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                           StackPanel>

                       DataTemplate>

                   ListBox.ItemTemplate>

               ListBox>

           controls:PanoramaItem>

This xaml should be very straightforward. This ListBox contains a DataTemplate with a StackPanel that each TextBlock is binding to an element from our collection. This includes the FirstName, LastName, Address, City, State and Zip Code.

Let’s go ahead and setup our second Panorama Item page which will include the “Read”, “Add”, “Update” and “Delete” buttons by using the following code snippet.

Double click on the MainPage.xaml file and replace the contents of <—Panorama item two---> with the following code snippet:

<controls:PanoramaItem Header="second item">

                

                <StackPanel>

                    <Button x:Name="btnRead" Content="Read" Click="btnRead_Click"/>

                    <Button x:Name="btnAdd" Content="Add" Click="btnAdd_Click" />

                    <Button x:Name="btnUpdate" Content="Update" Click="btnUpdate_Click" />

                    <Button x:Name="btnDelete" Content="Delete" Click="btnDelete_Click" />

                StackPanel>

            controls:PanoramaItem>

Page 2 should look like the following in the design view.

NOTE: You will want to go ahead and make sure the Click Event handlers are resolved before continuing.

Now that we are finished with our UI and adding our Service Reference, let’s add some code behind to call our OData Data Service and retrieve the data into our Windows Phone 7 Application.

Now would be a good time to go ahead and Build our project. Select Build from the Menu and Build Solution.

Reading Data from the Customers Table.

Go ahead and add the following namespaces on the MainPage.xaml.cs file.

using System;

using System.Data.Services.Client;

using System.Linq;

using System.Windows;

using Microsoft.Phone.Controls;

using SLShowODataP4.CustomersModel;

Lines 1-6 are the proper namespaces that we will need to query an OData Data Source. We have already included our CustomersModel so we are ready to go.

Add the following line just before the MainPage() Constructor.

   1: public CustomersEntities ctx = new CustomersEntities(new Uri("http://localhost:6844/CustomerService.svc/", UriKind.Absolute));

This line just creates a new context with our CustomersEntities (which was generated by using the DataSvcUtil tool that we downloaded earlier) and passes the URI of our data service which is located in our ASP.NET Project that we have running called CustomerService.svc.

Let’s now add code for our Read Button.

private void btnRead_Click(object sender, RoutedEventArgs e)

       {

           //Read from OData Data Source

           var qry = from g in ctx.CustomerInfoes

                     orderby g.FirstName

                     select g;

  

           var coll = new DataServiceCollection();

           coll.LoadCompleted += new EventHandler(coll_LoadCompleted);

           coll.LoadAsync(qry);

  

           DataContext = coll;

       }

Line 4 is the query that we will return records to in our collection. In this particular query, we are going to select all records and order them by the first name.

Lines 8-12 creates a DataServiceCollection which provides notification if an item is added, deleted or the list is refreshed. We have also added a LoadCompleted event that will display a MessageBox if we had an error. It will then Asynchronously load the collection passing the query we specified earlier. Finally, it sets the DataContext of the page to the collection.

If we go ahead and run this application and click on the “Read” button on the second page, we will get the following screen.

Notice how our results are in alphabetical order? That occurred because our query on line 4 above specified to get all the Customers and order them by the FirstName. Pretty easy huh? Let’s step it up a notch and actually add a record to our Customers Table.

Adding a record to the Customers Table.

Adding a record is going to be pretty straight forward since we already have a context with CustomerEntities defined. Go ahead and add the following code snippet:

private void btnAdd_Click(object sender, RoutedEventArgs e)

{

    //Adding a new Customer

    var newCustomer = new CustomerInfo();

    newCustomer.FirstName = "Andy1";

    newCustomer.LastName = "Griffith1";

    newCustomer.Address = "1111 New Address";

    newCustomer.City = "Empire";

    newCustomer.Zip = "34322";

    newCustomer.State = "AL";

  

    ctx.AddObject("CustomerInfoes", newCustomer);

  

    //Code to Add/Update/Delete from OData Data Source

    ctx.BeginSaveChanges(insertUserInDB_Completed, ctx);

}

  

private void insertUserInDB_Completed(IAsyncResult result)

{

    ctx.EndSaveChanges(result);

}

Lines 4-10 are just setting up a new CustomerInfo() object. We are going to add all the required fields to create a new Customer.

Line 12 Adds the specified object to the set of objects that the DataServiceContext is tracking. In this case, we are going to add our newCustomer that we just created to “CustomerInfoes”.

Lines 15-21 Asynchronously submits the pending changes to the OData service collected by the DataServiceContext since the last time changes were saved. The last line called to complete the BeginSaveChanges operation. Now if we click the 1) “Add” button from our second screen then hit 2) “Read” to refresh our screen we shall see the following.

Update a record to the Customers Table.

Now let’s go ahead and update an existing record. In this example, we are going to update the first record titled “Andy Griffith”. We are going to change his address to the value “ New Address”. How creative! Ok, let’s get started.

private void btnUpdate_Click(object sender, RoutedEventArgs e)

       {

           var qry = ctx.CreateQuery("CustomerInfoes").AddQueryOption("$filter", "LastName eq" + " \'" + "Griffith" + "\'");

  

           qry.BeginExecute(r =>

           {

               var query = r.AsyncState as DataServiceQuery;

  

               try

               {

                   var result = query.EndExecute(r).First();

                   result.Address = " New Address";

                   ctx.UpdateObject(result);

  

                   ctx.BeginSaveChanges(changeUserInDB_Completed, ctx);

               }

  

               catch (Exception ex)

               {

                   MessageBox.Show(ex.ToString());

               }

  

               

           }, qry);

       }

  

       private void changeUserInDB_Completed(IAsyncResult result)

       {

           ctx.EndSaveChanges(result);

       }

Lines 1-3 are setting up the query that we are going to pass to the “CustomerInfoes” object. As you can see, we are setting the filter to LastName equals Griffith. You could also run the filter command directly inside a web browser. In this case, it is only going to return one record.

Lines 5-13 Starts an asynchronous network operation that executes the query that we created earlier. Line 11 will return the first element in the sequence. We then specify the new Address value and update the object.

Lines 15-30 Asynchronously submits the pending changes to the OData service collected by the DataServiceContext since the last time changes were saved. Now if we click the 1) “Update” button from our second screen then hit 2) “Read” to refresh our screen we shall see the following.

Deleting a record from the Customers Table.

Now let’s go ahead and delete a existing record. In this example, we are going to update the first record titled “Andy Griffith”. Go ahead and copy and paste the following code snippet for the “Delete” button.

private void btnDelete_Click(object sender, RoutedEventArgs e)

    {

        var qry = ctx.CreateQuery("CustomerInfoes").AddQueryOption("$filter", "LastName eq" + " \'" + "Griffith" + "\'");

  

        qry.BeginExecute(r =>

        {

            var query = r.AsyncState as DataServiceQuery;

  

            try

            {

  

              var result = query.EndExecute(r).First();

              ctx.DeleteObject(result);

  

                ctx.BeginSaveChanges(changeUserInDB_Completed, ctx);

            }

  

            catch (Exception ex)

            {

                MessageBox.Show(ex.ToString());

            }

  

  

        }, qry);

    }

  

    private void changeUserInDB_Completed(IAsyncResult result)

    {

        ctx.EndSaveChanges(result);

    }

Right off the bat you can probably tell, this looks exactly like the update code. You are correct except it has a ctx.DeleteObject where the update statement had a ctx.UpdateObject. Let’s take a look at the code anyways.

Lines 1-3 are setting up the query that we are going to pass to the “CustomerInfoes” object. As you can see, we are setting the filter to LastName equals Griffith. It will only going to return one record.

Lines 5-13 Starts an asynchronous network operation that executes the query that we created earlier. Line 11 will return the first element in the sequence. We then specify that we wish to delete the Customer that matches the filter.

Lines 15-30 Asynchronously submits the pending changes to the OData service collected by the DataServiceContext since the last time changes were saved. Now if we click the 1) “Delete” button from our second screen then hit 2) “Read” to refresh our screen we shall see that “Griffith” has been removed.

Conclusion

At this point, we have seen how you would produce and consume an OData Data Source using the web browser, LinqPad, Silverlight 4 and Windows Phone 7 pre-Mango and now Mango. We have learned how to do some basic sorting and filtering using all the same. Now that you are equipped with a solid understanding of producing and consuming OData Data Services, you can begin to use this in your own applications. I want to thank you for reading this series and if you ever have any questions feel free to contact me on the various souces listed below. I also wanted to thank SilverlightShow.Net for giving me the opportunity to share this information with everyone.

Michael Crump is a Silverlight MVP and MCPD that has been involved with computers in one way or another for as long as he can remember, but started professionally in 2002. After spending years working as a systems administrator/tech support analyst, Michael branched out and started developing internal utilities that automated repetitive tasks and freed up full-time employees. From there, he was offered a job working at McKesson corporation and has been working with some form of .NET and VB/C# since 2003.

He shares his findings in his personal blog: http://michaelcrump.net and he also tweets at:@mbcrump

Handling service exceptions within Silverlight applications

editorial@silverlightshow.net (Gill Cleeren ) — Mon, 18 Jul 2011 17:28:00 GMT

Most LOB applications in Silverlight work with services to get data to the client. Commonly used technologies on the server-side include WCF, WCF RIA Services and REST Services. When all communication with the service goes well and no service exceptions occur, the Silverlight application has nothing to worry about: it will get its data to display to the user. But what happens when things go down the drain on the server? The database can be down, the load on the server might be too high or a third-party service that needs to be invoked can’t be connected to. We can handle this on the server-side but we should be able to let the end-user know what went wrong. Perhaps, since it’s only a temporary problem, we’d like him to try again in a few seconds.

For that reason, we need to be able to capture the faults on the client. Also, during development, it’s vital to work productively that we know what went wrong within our service. The problem is that Silverlight does not get access to this information, being a browser plugin. There are two solutions available to solve this problem. This article shows you how you can get access to this information and also explains which solution should be followed in what situation.

The source code for this article can be downloaded here.

The cause of the problem

If from Silverlight, we are accessing a service and something goes wrong within that service, we would expect to get access from Silverlight to the error returned by the service. This way, we would have enough information to make adjustments to the service code or would know if perhaps the service was not accessible. Sadly, this is not the case. Every time a service returns a status 500 (Internal Server Error), in Silverlight, we see a 404 (Not Found), as can be seen in the screenshot below.

Silverlight says that the service can’t be found, even though we know it is accessible.

The reason for this is a limitation of the browser stack: a browser can only return to a plugin (such as Silverlight) a status 200 and 404. That means that if the state is not 200, whatever the state returned, Silverlight will see a 404. Because of this, we have no access to the service error.

How to solve things

Not all hope is lost though, there’s a solution: we can on the server change the status of the response to 200, if something goes wrong. This response is then available to Silverlight (remember, SL can only access 200 and 404) and we can thus read out the fault information within the Silverlight application.

Implementing this change of status code can be done through a service-side behavior that inspects the SOAP message and converts the status to 200. Note that it’s advised to create a specific endpoint for this purpose with this behavior if your service is going to be accessed from other clients than Silverlight!

Two possible types of faults

With this behavior in place, we actually have 2 types of faults that can be returned from the service, so-called declared faults and undeclared faults.

Undeclared faults are advised to be used in development/debugging scenarios. In this case, all error information from the service is returned to the client. This means that for example a database error including table names might be returned to the client, which is not something you’d want to happen in a production application.

On the other hand, declared faults are faults declared within the service code through the use of a FaultException. We as service code authors can declare these and return in the client code, we can act upon receiving these Faults.

We’ll see how to use both types in the next paragraph.

Implementation on the service-side

With Silverlight 4, when we add a Silverlight-enabled WCF service, Silverlight adds a file called SilverlightFaultBehavior.cs to the project. The generated class inherits from Attribute. I prefer to use a different one, which inherits from BehaviorExtensionElement. The code for this file is similar; it’s shown below.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.ServiceModel.Channels;

using System.ServiceModel.Description;

using System.ServiceModel.Configuration;

using System.ServiceModel.Dispatcher;

using System.ServiceModel;

namespace ServiceExceptionDemo.Web

    public class SilverlightFaultBehavior : BehaviorExtensionElement, IEndpointBehavior

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)

            SilverlightFaultMessageInspector inspector = new SilverlightFaultMessageInspector();

            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(inspector);

        public class SilverlightFaultMessageInspector : IDispatchMessageInspector

            public void BeforeSendReply(ref Message reply, object correlationState)

                if (reply.IsFault)

                    HttpResponseMessageProperty property = new HttpResponseMessageProperty();

                    // Here the response code is changed to 200.

                    property.StatusCode = System.Net.HttpStatusCode.OK;

                    reply.Properties[HttpResponseMessageProperty.Name] = property;

            public object AfterReceiveRequest(ref Message request, IClientChannel channel,

                InstanceContext instanceContext)

                // Do nothing to the incoming message.

                return null;

        // The following methods are stubs and not relevant.

        public void AddBindingParameters(ServiceEndpoint endpoint,

            BindingParameterCollection bindingParameters)

        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)

        public void Validate(ServiceEndpoint endpoint)

        public override System.Type BehaviorType

            get { return typeof(SilverlightFaultBehavior); }

        protected override object CreateBehavior()

            return new SilverlightFaultBehavior();

This class implements the IEndpointBehavior, it’s itself a behavior that through configuration can be added onto a service endpoint. It’s easy to see what this class does: in the BeforeSendReply method, we are checking if the reply contains a Fault and if so, we set the status code to OK (which is 200).

It’s possible to extract this class to a separate class library and reference that project from the service project.

Just putting the behavior in place doesn’t really do a lot! It needs to be used inside the configuration of the service. The code below shows the updated configuration code for the service project.

<system.serviceModel>

  <extensions>

    <behaviorExtensions>

      <add name="silverlightFaults"

           type="ServiceExceptionDemo.Web.SilverlightFaultBehavior, 

           ServiceExceptionDemo.Web, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"

/>

    behaviorExtensions>

  extensions>

  <behaviors>

    <endpointBehaviors>

      <behavior name="SilverlightFaultBehavior">

        <silverlightFaults/>

      behavior>

    endpointBehaviors>

    <serviceBehaviors>

      <behavior name="">

        <serviceMetadata httpGetEnabled="true" />

        <serviceDebug includeExceptionDetailInFaults="true" />

      behavior>

    serviceBehaviors>

  behaviors>

  <bindings>

    <customBinding>

      <binding name="ServiceExceptionDemo.Web.ProductService.customBinding0">

        <httpTransport />

      binding>

    customBinding>

  bindings>

  <serviceHostingEnvironment aspNetCompatibilityEnabled="true"

      multipleSiteBindingsEnabled="true" />

  <services>

    <service  name="ServiceExceptionDemo.Web.ProductService">

      <endpoint address="" binding="customBinding"

                behaviorConfiguration="SilverlightFaultBehavior"

                bindingConfiguration="ServiceExceptionDemo.Web.ProductService.customBinding0"

          contract="ServiceExceptionDemo.Web.ProductService" />

      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

    service>

  services>

system.serviceModel>

Note in this code that we are adding a new BehaviorExtension named SilverlightFaults. This is then added as a new endpoint behavior through service configuration. I also set includeExceptionDetailInFaults to true. This allows me to get all information about the error: WCF will embed the entire exception string in the returned message. This is what’s referred to as an undeclared fault.

Let’s go to the service code. We can now implement the service, including code that returns a service fault. In the service code, a method called GetProducts is added, which is shown below.

[ServiceContract(Namespace = "")]

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

public class ProductService

    [OperationContract]

    [FaultContract(typeof(ProductFault))]

    public List GetProducts(string searchTerm)

        List products = GetAllProducts();

        var results = from p in products

                      where p.ProductName.Contains(searchTerm)

                      select p;

        if (results.Count() == 0)

            ProductFault fault = new ProductFault();

            fault.Message = "No products found.";

            fault.AdditionalInfo = "Perhaps try a different search term.";

            throw new FaultException(fault, "No results");

        return results.ToList();

    private List GetAllProducts()

        return new List()

            new Product(){ProductName="Tea", Price=5, Description="A fine Brittish tea"},

            new Product(){ProductName="Coffee", Price=7, Description="A pack of coffee from Starbucks"},

            new Product(){ProductName="Peanut butter", Price=2, Description="Some great peanut butter"},

            new Product(){ProductName="Hot Cocoa", Price=10, Description="Great for wintery days"},

};

There are several interesting aspects to this code. First, the method is attributed with the FaultContract(typeof(ProductFault)) attribute. This is basically saying that this service method may return a fault of this particular type. Because we are including this attribute here, in the proxy generation, this fault type will be included.

Here, when the user is searching, an error will be returned when no result can be found. We throw therefore a FaultException. With no fault behavior configured, this would result in a 404 within Silverlight. Now however, because of the configured behavior, every response will pass through the code and the response status code will be changed to 200.

The fault is of type ProductFault, which is shown next.

public class ProductFault

    public string Message { get; set; }

    public string AdditionalInfo { get; set; }

Using predefined faults and defining which information is included is known as using declared faults. As mentioned, this is the way to go in production environments.

Let’s now look at how we can effectively use this on the client. After adding a service reference in the Silverlight code, we are invoking the service as follows:

private void SearchButton_Click(object sender, RoutedEventArgs e)

    ProductService.ProductServiceClient proxy = new ProductService.ProductServiceClient();

    proxy.GetProductsCompleted +=

        new EventHandler(proxy_GetProductsCompleted);

    proxy.GetProductsAsync(SearchTextBox.Text);

void proxy_GetProductsCompleted(object sender, ProductService.GetProductsCompletedEventArgs e)

    if (e.Error == null)

        ProductsDataGrid.ItemsSource = e.Result;

    else if (e.Error is FaultException)

        FaultException serviceFault = e.Error as FaultException;

        ErrorTextBlock.Text = serviceFault.Detail.Message + " " + serviceFault.Detail.AdditionalInfo;

    else if (e.Error is FaultException)

        FaultException serviceFault = e.Error as FaultException;

        ErrorTextBlock.Text = serviceFault.Detail.Message;

In the callback, we are checking if an error was returned. If there is one, we can now check for a specific fault type (note that this way, we can have multiple types of faults being returned). Also, we have access to the information about the error after it came back from the service, which wasn’t possible before. The screenshot below shows what happens if we are searching for a product that doesn’t exist.

It’s very interesting to see that when stepping through the code, these exceptions can be seen as well. Here’s what happens in the service code (which we can always see):

However, inside the generated proxy code, we also see this information:

Also interesting to see is what happens if we take a look at the response using Fiddler. Because I set includeExceptionDetailInFaults to true, all error information is included, as can be seen below:

Summary

In this article, we looked at how we can through the use of a behavior have access to faults within Silverlight when talking to services. We saw there are two ways of doing this: using declared or undeclared faults.

About Gill

Gill Cleeren is Microsoft Regional Director (www.theregion.com), Silverlight MVP (former ASP.NET MVP), INETA speaker bureau member and Silverlight Insider. He lives in Belgium where he works as .NET architect at Ordina. Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd Berlin 2010, TechDays Belgium, DevDays NL, NDC Oslo Norway, SQL Server Saturday Switserland, Spring Conference UK, Silverlight Roadshow in Sweden… He’s also the author of many articles in various developer magazines and for SilverlightShow.net. He organizes the yearly Community Day event in Belgium.

He also leads Visug (www.visug.be), the largest .NET user group in Belgium. Gill recently published his first book: “Silverlight 4 Data and Services Cookbook” (Packt Publishing). You can find his blog at www.snowball.be.

Twitter: @gillcleeren

WP7 for iPhone and Android Developers - Local Data Storage

editorial@silverlightshow.net (Kevin Hoffman ) — Mon, 04 Jul 2011 21:29:00 GMT

Don't miss...

($2.99)

All SilverlightShow Ebooks

This is the 8th article in a series of articles that introduce Windows Phone 7 development to developers of other mobile platforms such as iOS and Android. In this article, we’ll talk about some of the various options for storing and retrieving application-specific data on the phone.

When mobile developers build applications, one of the first things they need to decide is how they plan on storing data on the device. When you build a desktop application, this is rarely a concern. Mobile developers typically have less options because the devices have limited resources and, in many cases, the platform SDKs restrict the ways in which the developer can interact with the underlying file system.

For example, when you’re building an application for a mobile device, you can’t simply create and fill random directories wherever you like. In most cases, your application is restricted to operating within a sandbox. In addition to process isolation, this sandbox provides private file storage that is often limited by a maximum storage quota.

iOS developers are lucky in that they get access to Core Data, a framework for storing and querying relational data. Developers can visually model their database and generate Objective-C entity classes which they can use as parent classes for derived functionality. With iOS, Core Data can read and write SQLite database files. With the current version of Windows Phone 7, we have no such luxuries and are limited to using lower level facilities. However, when the “Mango” release of WP7 is made available (currently in Beta 2), developers will be able to build code-first LINQ to SQL database models that are backed by a compact, file-based SQL engine that runs on the phone.

Windows Phone 7 developers can access a private, sandboxed file store called Isolated Storage to read and write arbitrary files, so long as the app doesn’t exceed its allotted quota. In addition to arbitrary files, there is also an API designed to make it easier for developers to read and write configuration settings within the application’s Isolated Storage folder.

Reading and Writing Application Settings

If the information you plan on storing and retrieving can be reduced to a relatively small amount of key-value pairs then you can probably avoid the complexity of working directly with files and instead make use of the IsolatedStorageSettings class. This class provides a wrapper around a file that the SDK can maintain for you, which in turn contains key-value pairs.

To access your application’s settings, you use the ApplicationSettings property of the IsolatedStorageSettings class. Manipulating settings looks very much like adding and removing keys from a dictionary:

var appSettings = IsolatedStorageSettings.ApplicationSettings;

settings.Add("ZombieKillCount", 21);

  

// later on, retrieve a setting

viewModel.ZombieKillCount = (int)appSettings["ZombieKillCount");

You’ll find the IsolatedStorageSettins class in the namespace System.IO.IsolatedStorage. You don’t need to manually save the application settings to isolated storage because they will be saved when the application terminates normally through any of the standard means. If you want to manually save the data to isolated storage then just call the Save() method on the ApplicationSettings object.

You don’t have to just store primitive types like integers and strings. If you really want to, you can store virtually any type of object. However, I won’t even show the sample code for doing so because it is generally considered bad practice. You should keep the settings stored using this API as primitive as possible. If you need to store more complicated data, you should do so using an Isolated Storage File, which we’ll talk about next.

Using Isolated Storage

As mentioned earlier, Windows Phone 7 applications all have their own private sandboxes in which their AppDomain runs in a way that cannot negatively impact other applications. In addition, any storage access made by that application has to go through Isolated Storage. On Windows desktop machines, Isolated Storage provides a means for storing disk without giving applications destructive privilege and the same principle is behind the fact that its use is mandatory (as in, it’s the only option) on WP7. Even in the upcoming “Mango” release, the local SQL databases available to developers are still files stored in Isolated Storage.

In the current version of WP7, the WP7 device emulator has a quirky behavior where it will wipe the contents of isolated storage between application executions. If you run into this behavior, debugging and testing your application can become painful and tedious – at this point you might want to switch to writing against the “Mango” beta, whose simulator appears to be free of such quirks.

Isolated Storage provides an API that looks like a file folder structure. When you obtain a reference to an existing or newly created file in an isolated store, your only option for interacting with that file via Streams. Many of the existing .NET desktop classes and methods for accessing files are just wrappers around the lower level streams API.

The easiest way of reading and writing file-backed data with Isolated Storage is to use binary serialization of object instances and to store and retrieve the binary version of those objects as files. For example, let’s say you have a file that you want to use to store a player’s profile for your game. You might create a class that looks something like this for representing the data:

using System.Runtime.Serialization;

  

namespace MyAwesomeGame.Models

{

    [DataContract]

    public class Gamer

    {

        [DataMember]

        public string Name { get; set; }

  

        [DataMember]

        public string Description { get; set; }

  

        [DataMember]

        public int KillCount { get; set; }

    }

}

Standard object serialization is not available in the current version of WP7. However, because a full implementation of WCF is available (including the binary protocol formats), we do have access to the WCF data contract serializer, which can convert any object into an array of bytes – exactly what we need to talk to an isolated storage file.

Next, we just need to write the code that creates an isolated storage file, converts an object instance into an array of bytes, and stores those bytes in a file. Here are some utility methods in a helper class that read and write object graphs from isolated storage:

namespace IsolatedStorageDemo

{

    public static class IsoStoreHelper

    {

        public static void WriteGraphToFile(string filename, T sourceObject)

        {

            using (IsolatedStorageFile isf =

                IsolatedStorageFile.GetUserStoreForApplication())

            {

                using (IsolatedStorageFileStream stream =

                  new IsolatedStorageFileStream(filename, FileMode.Create, isf))

                {

                    DataContractSerializer dcs = new DataContractSerializer(typeof(T));

                    dcs.WriteObject(stream, sourceObject);

                    stream.Close();

                }

            }

        }

  

        public static T ReadGraphFromFile(string filename) where T:class

        {

            T result = null;

            using (IsolatedStorageFile isf = 

                IsolatedStorageFile.GetUserStoreForApplication())

            {

                using (IsolatedStorageFileStream stream =

                    new IsolatedStorageFileStream(filename, FileMode.OpenOrCreate, isf))

                {

                    if (stream.Length > 0)

                    {

                        DataContractSerializer dcs = new DataContractSerializer(typeof(T));

                        result = dcs.ReadObject(stream) as T;

                    }

                }

            }

  

            return result;

        }

    }

}

Again, you’ve got to keep in mind that even though you can seemingly write unlimited amount of data to the storage file, this is still a mobile device with a limited amount of disk space and each application is only allocated a certain amount of storage. If you find your application needs access to a much larger volume of data, consider storing that data in the cloud and accessing it via web services, which is the topic of the next article in this series.

Summary

Windows Phone 7 represents a fantastic opportunity for developers of all backgrounds to take advantage of an incredibly powerful mobile development platform. In this article, I talked about the two main ways WP7 developers persist data locally on the device – via application settings and via files. Both of these options are backed by Isolated Storage, .NET’s secure, sandboxed, quota-limited storage area.

Working with collections in WCF RIA Services (part 2)

editorial@silverlightshow.net (Kevin Dockx ) — Wed, 11 May 2011 00:00:00 GMT

Don't miss...

All SilverlightShow Ebooks

This is the second part of a two-part series on working with collections in WCF RIA Services.

In the first part of the article series, we’ve learned about the simpler collection types: EntitySet and EntityList. In this part, we’ll dig deeper into the more advanced types: the ICollectionView and the DomainCollectionView.

ICollectionView

The ICollectionView isn’t a new interface: implementations are used as a view over a collection by a number of existing Silverlight controls, like the DataGrid. We now have the ability to use it directly from our ViewModel, to enable binding to an ICollectionView implementation (example implementations available in Silverlight are the CollectionViewSource and PagedCollectionView).

It can be initialized as such:

private ICollectionView CreateView(IEnumerable source)
{
    CollectionViewSource cvs = new CollectionViewSource();
    cvs.Source = source;
    return cvs.View;
}
private ICollectionView _books;
public ICollectionView Books
{
    get
    {
        if (this._books == null)
        {
            this._books = CreateView(this.Context.Books);
        }
        return this._books;
    }
}

When you load Books, this is automatically reflected in this View:

public CollectionViewViewModel()
{
    InstantiateCommands();
    // load books
    Context.Load(Context.GetBooksQuery().Take(10));
}

ICollectionView: adding and removing data.

Adding and removing books should be done by adding or removing them directly on the Context. Again, this will automatically be reflected, as our CollectionViewSource tracks the underlying Entity Set.

So what’s so special about this? Up until now, this isn’t really different from simply using an Entity Set, right? Well, the real power lies in the fact that an ICollectionView allows you to add filters, sorting and grouping directly on the View.

Filtering an ICollectionView

An ICollectionView has a Filter property, which is a Predicate. Let’s rewrite our code a bit, so it looks like this:

private ICollectionView _books;
public ICollectionView Books
{
    get
    {
        if (this._books == null)
        {
            this._books = CreateView(this.Context.Books);
            this._books.Filter = new Predicate<object>(BookCorrespondsToFilter);
        }
        return this._books;
    }
}
public bool BookCorrespondsToFilter(object obj)
{
    Book book = obj as Book;
    return book.Title.Contains("Silverlight");
}

For every book in the collection, the BookCorrespondsToFilter method is executed to check if the Books’ Title contains the word “Silverlight”. If it doesn’t, it won’t be part of the View over the Books Entity Set.

Now, code like this works IF you know in advance what your filter will be. In a lot of applications however, you’d want the user to be able to define the filter himself. So let’s change the code a bit: I’ve added a “filterActive” property, which is set to true when the user clicks the “Add filter” property:

public bool BookCorrespondsToFilter(object obj)
{
    Book book = obj as Book;
    if (filterActive)
    {
        return book.Title.Contains("Silverlight");
    }
    return true;
}

AddFilter = new RelayCommand(() =>
{
    filterActive = true;
});

When you click this button… nothing happens. Why is this?

When you change something to the filter, or you change something to an underlying Book entity (for example: change its title), the ICollectionView implementation will not automatically execute the filter again: the Filter method is only executed when you add an Entity to the underlying Entity Set. This means you have to specifically tell it to recheck the already loaded entities against the new filter. This can be done by calling the Refresh() method on your ICollectionView:

Refresh = new RelayCommand(() =>
{
    Books.Refresh();
});

Now, the View will be recreated, resulting in the filter method getting executed again for each Book in the backing Books Entity Set. Again, this is only necessary when you change the Filter, or when you change a property on an underlying entity which is used in the filter.

Sorting and grouping an ICollectionView

Two more interesting properties exist on an ICollectionView: SortDescriptions and GroupDescriptions. These can be manipulated to change the way your View sorts or groups the underlying entities from the Entity Set.

Sorting can be achieved easily by clicking the column header of the DataGrid you’re binding the ICollectionView to – this will automatically add the necessary Sort Descriptions, and sort your View. Next to that, it can also be achieved through code (interesting when you need to add sorting to a View which is bound to, for example, a ListBox, an thus doesn’t have column headers to click) as such:

AddSort = new RelayCommand(() =>
{
    Books.SortDescriptions.Add(new SortDescription("Title", ListSortDirection.Ascending));
});

Grouping your collection can be done in a similar way:

AddGrouping = new RelayCommand(() =>
{
    Books.GroupDescriptions.Add(new PropertyGroupDescription("Author"));
});

This results in a sorted, grouped View of your data:

Do keep in mind that grouping your collection will disable UI virtualization – so beware when working with large datasets, as grouping them will diminish performance quite fast. For large datasets which require grouping: always combine this with paging.

The ICollectionView is a great collection type to use when you need sorting, filtering, grouping, … on your collection. However, it only works on in-memory collections, meaning all your data has to be on the client. This is suitable for a lot of scenarios, but for some this is not feasible. For these scenarios, have a look at the following paragraph: the DomainCollectionView.

DomainCollectionView

A lot of business applications work with large result sets: hundreds, thousands or even millions of records that need to be sorted, filtered, grouped, … In these scenarios, the ICollectionView isn’t a feasible solution, as it requires all the data to be on the client. We need a collection type that allows for server-side sorting, filtering and, most importantly: paging.

This is where the DomainCollectionView comes into play, as it takes care of those concerns. The DomainCollectionView can be found in the WCF RIA Services Toolkit, in the Microsoft.Windows.Data.DomainServices assembly (the assembly is included in the sample solution). Setting it up requires a little more work than the other collection types, but it’s still quite easy once you get the hang of it. The DomainCollection gets initialized with a Source and a Loader (default: the CollectionViewLoader).

public DomainCollectionView Books
{
    get { 
        return this.view; 
    }
}

The Source component defines the source entities for your View – it can be any IEnumerable, but typically this is a collection type which implements INotifyCollectionChanged (EntityList is often used):

this.source = new EntityList(Context.Books);

The Loader takes care of loading the data. When you use the CollectionViewLoader, which is the default, you pass in two callbacks: OnLoad, and OnLoadCompleted, respectively defining what should happen when data must be loaded, and what should happen when a load operation is completed (you could also use a simple load operation instead of the CollectionViewLoader if you want to).

this.loader = new DomainCollectionViewLoader(
  this.OnLoadBooks,
  this.OnLoadBooksCompleted);

private LoadOperation OnLoadBooks()
{
    return this.Context.Load(this.query.SortPageAndCount(this.view));
}
private void OnLoadBooksCompleted(LoadOperation op)
{
    if (op.HasError)
    {
        op.MarkErrorAsHandled();
    }
    else if (!op.IsCanceled)
    {
        this.source.Source = op.Entities;
        if (op.TotalEntityCount != -1)
        {
            this.Books.SetTotalItemCount(op.TotalEntityCount);
        }
    }
}

As you can see, OnLoadBooks makes sure the query is executed including sorting (Sort Descriptions), Paging (only the correct page gets loaded), and a total count (needed for the DataPager).

When the books have been loaded, the Source collection is set to the loaded entities, and the TotalItemCount is set via TotalEntityCount.

… and with these two components, the DomainCollectionView is initialized as such:

this.view = new DomainCollectionView(loader, source);

All that’s left now is triggering the initial load, which can be done as such (as you can see, the page size is set to 5):

using (this.view.DeferRefresh())
{
    this.view.PageSize = 5;
    this.view.MoveToFirstPage();
}

(DeferRefresh() allows us to defer the refreshing of the view until all operations in the using statement are executed)

So, in essence, what happens when you page, sort, … (anything that should trigger a View refresh) is that the Loader is executed and loads the data. Once this is done, the Source property gets updated, which in turn notifies the View it is updated, and the control your View is bound to reflects these changes.

(note: if you’re already using the April version of the WCF RIA Services Toolkit, SortPageAndCount has been replaced by SortAndPageBy)

DomainCollectionView: adding and removing data.

It’s possible to add and remove data on the client by manipulating the View (and thus the underlying Entity List), with code as such:

AddBook = new RelayCommand(() =>
{
    // you can add books like this, but DCV is server side oriented: to get correct 
    // behaviour, you should add it to the Context and submit the changes, after which
    // the next query will fetch the book you just added.
    Book book = Books.AddNew() as Book;
    book.Author = "Kevin Dockx";
    book.ASIN = "123456";
    book.Title = "Silverlight for dummies";
});
DeleteBook = new RelayCommand(() =>
{
    // deleting an item can be done like this, but should be done directly on the context
    // & submitted to the server
    Books.RemoveAt(0);
});

However, this will result in a View which is out of sync with your current Filters, Sort Descriptions, …: you’ll end up with more or less items in your View than there should be according to the pagesize, or you’ll end up with unsorted items, unfiltered items, … and this is very normal: after all, the DomainCollectionView is designed to work on server-side entities, and by manipulating the collection on the client, you’re trying to manipulate the DomainCollectionView to work in a way it wasn’t designed to work.

The correct way to add or remove entities is by adding or removing them on the server, eg: add an Entity to your Context (or remove one from it), submit the changes to your server, and refresh the DomainCollectionView.

DomainCollectionView: Filtering, Sorting and Grouping your data.

Now, how do you filter data using this approach? Pretty easy actually: you add the necessary Where-clause to your EntityQuery, as such:

AddFilter = new RelayCommand(() =>
{
    // filters in DCV should be done by adding a Where clause to the query, as DCV is mainly used for
    // server side logic
    this.query = Context.GetOrderedBooksQuery().Where(b => b.Title.Contains("Silverlight"));
    this.view.MoveToFirstPage();
});

This leaves sorting and grouping. Sorting is provided out-of-the-box: clicking a column header will result in Sort Descriptions being added to the Books collection, which will be taken into account the next time data is fetched – and clicking a column header will automatically refetch the data.

In some applications, a requirement is to move to the first page of the collection when sorting is applied. If something like that is needed, you could write an event handler as such:

INotifyCollectionChanged notifyingSortDescriptions =
(INotifyCollectionChanged)this.Books.SortDescriptions;
notifyingSortDescriptions.CollectionChanged +=
    (sender, e) =>
    {
           this.view.MoveToFirstPage();
    };

Just as with the ICollectionView, you can also add sort descriptions to the DomainCollectionView in code:

AddSort = new RelayCommand(() =>
{
    Books.SortDescriptions.Add(new SortDescription("Title", ListSortDirection.Ascending));
    Books.Refresh();
});

Adding group descriptions is done in a comparable way:

AddGrouping = new RelayCommand(() =>
{
    Books.GroupDescriptions.Add(new PropertyGroupDescription("Author"));
    Books.Refresh();
});

Bringing it all together, we end up with a server-side pageable, sorted, grouped collection:

Conclusion

As of WCF RIA Services SP1, new collection types have been added (and others have been changed), allowing for great integration with MVVM, from better binding options to a server-side pageable and sortable collection type. If you’re serious about using WCF RIA Services in a LOB context with MVVM, looking into these new collection types is a must.

About the author

Kevin Dockx lives in Belgium and works at RealDolmen, one of Belgium's biggest ICT companies, where he is a technical specialist/project leader on .NET web applications, mainly Silverlight, and a solution manager for Rich Applications (Silverlight, Windows Phone 7 Series, WPF, Surface). His main focus lies on all things Silverlight, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a Silverlight enthusiast, he's a regular speaker on various national and international events, like Microsoft DevDays in The Netherlands, Microsoft Techdays in Portugal and Belgium, or on BESUG events (the Belgian Silverlight User Group). Next to that, he also authored a best-selling Silverlight book, Packt Publishing's Silverlight 4 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on Silverlight, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/, and of course he can also be found on Twitter @KevinDockx

Working with collections in WCF RIA Services (part 1)

editorial@silverlightshow.net (Kevin Dockx ) — Tue, 10 May 2011 00:00:00 GMT

Don't miss...

All SilverlightShow Ebooks

This is the first part of a two-part series on working with collections in WCF RIA Services.

Introduction

A lot of business applications today are built with WCF RIA Services (which should come as no surprise, as it’s a really powerful, extensible framework). However, the collection type support could have been better. Often, you’d simply resort to fetching your entities and adding them to an ObservableCollection in the completed event of your load operation. This still works, but in the first Service Pack for WCF RIA Services quite a few enhancements to existing collection types have been made, and new ones have been added. These allow you to make it easier to work with WCF RIA Services in an MVVM context: we now have collections which automatically track your DomainContext, collections which allow you to add filters, sorting & even grouping, and there’s a server-side pageable DomainCollectionView. In this article, we’ll have a look at these enhancements & new types, and the scenarios in which they can prove useful.

This article will look into 4 ways of working with your data from WCF RIA Services: the EntitySet (enhanced), the EntityList (new), the CollectionView (enhanced) and last but not least, the DomainCollectionView (new). It is accompanied by an example project & full source code, which you can download here.

SP1 for WCF RIA Services is included in Visual Studio 2010 SP1, which can be found here.

EntitySet

The EntitySet is a basic collection type you can use in your WCF RIA Services application, for binding from your ViewModel. It’s an unordered collection with few options for customizing what it returns, but therefore it’s a simple, quick and easy solution if you need to view all the entities of a specific type which have been loaded through your DomainContext.

In the example application, I’m binding a ListBox to a property, Books:

Have a look at the following code:

/// 
/// The Books property
/// 
public EntitySet Books
{
    get
    {
        return Context.Books;
    }
}

As you can see, Books is an EntitySet of type Book, and simply refers to Context.Books, of which 10 are loaded in the constructor:

public EntitySetViewModel()
{
    InstantiateCommands();
    // load books
    Context.Load(Context.GetBooksQuery().Take(10));
}

When we load more data, as such:

LoadMoreBooks = new RelayCommand(() => 
{
   Context.Load(Context.GetBooksQuery());
});

more entities of type Book are added to the correct EntitySet: Context.Books, resulting in more Books in our ListBox. In other words: when data of type Book is loaded by the DomainContext, it’s added to the Context.Books EntitySet.

EntitySet: adding and removing data.

How do you add or remove data from an EntitySet? Have a look at the following code for adding a Book:

AddBook = new RelayCommand(() =>
{
    Context.Books.Add(new Book() { 
        Author = "Kevin Dockx"
        , ASIN = "123456"
        , Title = "Dummy book" });
});

and the following code for removing a Book:

DeleteBook = new RelayCommand(() =>
{
    Context.Books.Remove(Context.Books.FirstOrDefault());
});

This will result in Books being added or removed from the Books EntitySet, which is immediately visible in our ListBox. When you submit the changes to the server, this will result in the corresponding Insert / Delete operations being executed on our DomainService.

EnityList

The next collection type we’re looking into is a new one: the EntityList. It can be found in the WCF RIA Services Toolkit, in Microsoft.Windows.Data.DomainServices (assembly is included in the example code, you don’t need to download the toolkit if you don’t want to). In essence, it is an observable collection which is backed by an Entity Set. The advantage of this, and reason why you might want to use it, is that this allows us to get a view of a subset of entities of a specific type, loaded through your DomainContext into the backing Entity Set. A typical EntityList property definition looks as such:

private EntityList _books;
public EntityList Books
{
    get
    {
        if (this._books == null)
        {
            this._books = new EntityList(
              this.Context.Books);
        }
        return this._books;
    }
}

An Entity List has a Source property, which defines the entities it should contain:

public EntityListViewModel()
{
    InstantiateCommands();
    // load books
    this.Books.Source = Context.Load(Context.GetBooksQuery().Take(10)).Entities;
}

With these two pieces of code, your Entity List is initialized & ready to be used.

It gets interesting once you start loading more entities of type Book: these are NOT automatically reflected in our Entity List. This is by design: the same subset you initialized it with is used (which is exactly what allows us to get a view on a part of the books loaded in the Entity Set via the Domain Context instead of all of them). If you want to get your Entity List to track more books, you should set the Source property of the list again:

LoadMoreBooks = new RelayCommand(() =>
{
    this.Books.Source = Context.Load(Context.GetBooksQuery()).Entities;
});

EntityList: adding and removing data.

Adding a new entity of type Book is typically done in one of two ways: you can either add it to the Context, or add it to the Entity List itself. This results in different behavior, which you can view in the example application. When the following code is executed:

AddBook = new RelayCommand(() =>
{
    Context.Books.Add(new Book() { 
        Author = "Kevin Dockx"
        , ASIN = "123456"
        , Title = "Dummy book" });
});

a new Book is added to the Context. But as the Entity List does not automatically track this (remember: the subset of items tracked is what’s set on the Source property, not every book loaded in the context), our ListBox still only shows the entities in the Entity Lists’ Source collection.

When the following code is executed:

AddBookToEntityList = new RelayCommand(() =>
{
    Books.Add(new Book() { 
        Author = "Kevin Dockx"
        , ASIN = "123456"
        , Title = "Dummy book" });
});

A new book is added to the Entity List (Books) itself, and this is reflected in our ListBox. Behind the screens, this book is added to the backing Entity Set if it didn’t exist yet. If it was already available in the backing Entity Set, it isn’t added to the set, it’s just added to our Entity List. Submitting your changes to the server will result in the correct Insert method being executed.

Removing a Book behaves a bit different: when you remove the Book from the backing Entity Set on the Context, this is reflected in the Entity List:

DeleteBook = new RelayCommand(() =>
{
    Context.Books.Remove(Context.Books.FirstOrDefault());
});

When you remove a Book from the Entity List, this Book is also removed from the backing Entity Set, meaning a submit operation will result in the correct Delete method being called.

DeleteBookFromEntityList = new RelayCommand(() =>
{
    Books.Remove(Books.FirstOrDefault());
});

This concludes part one – stay tuned for part two, which will cover the more advanced collection types: the ICollectionView & DomainCollectionView.

About the author

Producing and Consuming OData in a Silverlight and Windows Phone 7 application (Part 3)

editorial@silverlightshow.net (Michael Crump ) — Tue, 05 Apr 2011 01:01:00 GMT

Don't miss...

All SilverlightShow Ebooks

This article is Part 3 of the series “Producing and Consuming OData in a Silverlight and Windows Phone 7 application.”.

To refresh your memory on what OData is:

To recap what we learned in the previous section:

We began by creating the User Interface and setting up our bindings on our elements.
We added a service reference pointing to our OData Data Service inside our project.
Finally, we added code behind to sort and filter the data coming from our OData Data Source into our Silverlight 4 Application.

In this article, I am going to show you how to consume an OData Data Source using Windows Phone 7. Read the complete series of articles to have a deep understanding of OData and how you may use it in your own applications.

See the video tutorial
Download the source code for part 3 | Download the slides

Testing the OData Data Service before getting started…

Hopefully you have completed part 1 and 2 of the series, if you have not you may continue with this exercise by downloading the completed source code to Part 2 and continue. I would recommend watching the video to part 1 and part 2 in order to have a better understanding of where you can add OData to your own applications.

Go ahead and load the SLShowODataCompleted project inside of Visual Studio 2010, and look under Solution Explorer. Now right click CustomerService.svc and Select “View in Browser”.

If everything is up and running properly, then you should see the following screen (assuming you are using IE8).

Please note that any browser will work. I chose to use IE8 for demonstration purposes only.

If you got the screen listed above then we know everything is working properly and can continue. If not download the completed solution and continue with the rest of the article.

At this point, leave this instance of Visual Studio running, we are going to use this OData Data Service in the “Getting Started” part. You may also want to copy and paste the address URL which should be similar to the following:

http://localhost:6844/CustomerService.svc/

Downloading the tools…

In order to retrieve the data from an OData Data Source into Windows Phone 7, we are going to need to download the OData WP7 Library from CodePlex.

So, go ahead and navigate to http://odata.codeplex.com/.

We are only interested in the binaries, so click on the Downloads page then look for Other Available Downloads and select ODataClient_BinariesAndCodeGenToolForWinPhone.zip as shown below.

After the download completes, you will have the following files:

An explanation is provided below:

DavaSvcUtil.exe – is the utility that will create our class file from our OData Service.
Readme.txt – provides a sample command line for creating the class file from the Netflix OData Data Service.
System.Data.Services.Client.dll and System.Data.Services.Design.dll are the class libraries that we will add to our Windows Phone 7 Project.

Getting Started

Now that we have tested our OData Data Service and downloaded the tools, let’s get started by creating the proxy that our Windows Phone 7 Application will use.

We will need to go to a command prompt in order to generate our proxy. If you are using Windows 7 then you can quickly get to a command prompt by click Start –> and typing command in the search box.

Once you have a command prompt, simply navigate to the directory in which you extracted the directory to and type the following command:

datasvcutil /uri:http://localhost:6844/CustomerService.svc/ /out:.\CustomersModel.cs /Version:2.0 /DataServiceCollection

(Note: You will need the URI of the OData Data Service that we talked about in the first section of this article. I have bolded the paragraph at the top of this article that describes this.)

Quick Tip: You may also want to create a batch file and copy/paste the line above into it to quickly generate proxies in the future.

After this is complete, your screen should look similar to the following:

Notice that we have 0 errors and 0 warnings. If you have an error then step through each part of this tutorial again to make sure you have not left anything out. If all else fails, you can download a completed solution by scrolling to the top of this article.

If we navigate back into the folder that we extracted the .zip into, we will find a new file called CustomersModel.cs. This is our proxy that we will add to our Visual Studio 2010 Project.

Note: You will also note that I created a .bat file called “createclassfile.bat” to quickly generate this proxy again the future.

At this point, we are ready to create our Windows Phone 7 Application. So open up a new instance of Visual Studio 2010 and select File –> New Project.

Select Silverlight for Windows Phone –> Windows Phone Panorama Application and give it the name, SLShowODataP3 and finally click OK.

Once the project is loaded, the first thing we will need to do is add a reference to the System.Data.Services.Client.dll that we unpacked earlier.

Navigate to the directory containing the System.Data.Services.Client.dll file and double click it or select OK.

Now we will need to add the proxy that the DataSvcUtil.exe tool created.

Right click your project and select Add then Existing Item.

Navigate to the directory containing the CustomersModel.cs file and double click it or select Add.

Now we will need to create the User Interface and write the code behind to pull the data into our application.

Double click on the MainPage.xaml file and replace the contents of <—Panorama item one---> with the following code snippet:



<controls:PanoramaItem Header="first item">

    

    <ListBox x:Name="lst" Margin="0,0,-12,0" ItemsSource="{Binding}">

        <ListBox.ItemTemplate>

            <DataTemplate>

                <StackPanel Margin="0,0,0,17" Width="432">

                    <TextBlock Text="{Binding FirstName}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

                    <TextBlock Text="{Binding LastName}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

                    <TextBlock Text="{Binding Address}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                    <TextBlock Text="{Binding City}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                    <TextBlock Text="{Binding State}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                    <TextBlock Text="{Binding Zip}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                StackPanel>

            DataTemplate>

        ListBox.ItemTemplate>

    ListBox>

controls:PanoramaItem>

Now that we are finished with our UI and adding our Service Reference, let’s add some code behind to call our OData Data Service and retrieve the data into our Windows Phone 7 Application.

Now would be a good time to go ahead and Build our project. Select Build from the Menu and Build Solution. Now we can Double click on the MainPage.xaml.cs file and add the following code snippet, after replacing the MainPage() Constructor.

public MainPage()

{

    InitializeComponent();

    this.Loaded += new RoutedEventHandler(MainPage_Loaded);

}

  

private void MainPage_Loaded(object sender, RoutedEventArgs e)

{

    var ctx = new CustomersEntities(new Uri("http://localhost:6844/CustomerService.svc/"));

    var coll = new DataServiceCollection(ctx);

    lst.ItemsSource = coll;

  

    coll.LoadCompleted += new EventHandler(coll_LoadCompleted);

  

    var qry = "/CustomerInfoes";

    coll.LoadAsync(new Uri(qry, UriKind.Relative));

}

  

void coll_LoadCompleted(object sender, LoadCompletedEventArgs e)

{

    if (e.Error != null)

    {

        MessageBox.Show(e.Error.Message);

    }

}

Lines 1-5 is the standard code generated except for the Loaded event. The Loaded Event created a new Event Handler called Main_Page Loaded.

Line 9 creates a new context with our CustomersEntities (which was generated by using the DataSvcUtil tool that we downloaded earlier) and passes the URI of our data service, which is located in our ASP.NET Project that we have running called CustomerService.svc.

Line 10 creates a DataServiceCollection which provides notification if an item is added, deleted or the list is refreshed. It is expecting a collection that was also created using the DataSvcUtil tool.

Line 11 sets the ItemSource of our ListBox to the collection.

Lines 15 simply creates a query that returns all records in our collection. We will modify this shortly to create a where and an orderby example.

Finally lines 19-25 are checking for an error and displaying a MessageBox. Of course, in a production application you may want to log that error instead of interrupting the user with a message they shouldn’t be concerned with.

If we go ahead and run this application, we would get the following screen.

Let’s add a query to filter the data. So go back to your MainPage.xaml.cs file and change this line:

 1: var qry = "/CustomerInfoes";

 1: var qry = "/CustomerInfoes?$filter=ID gt 3&$orderby=FirstName";

Now if we run this project you will notice that we only have 2 results returned and ordered by the FirstName. So in this example, Craig is listed first.

If you stop and notice that we are not using LINQ to produce the query where we were earlier in the Silverlight 4 Application. Instead we are writing the query manually. That is because this early implementation of OData on the Windows Phone 7 does not support the LINQ method in the current release. But do not worry as this will probably be addressed in a later release.

Conclusion

At this point, we have seen how you would produce and consume an OData Data Source using the web browser, LinqPad, Silverlight 4 and Windows Phone 7. We have learned how to do some basic sorting and filtering using all the same. Now that you are equipped with a solid understanding of producing and consuming OData Data Services, you can begin to use this in your own applications. I want to thank you for reading this series and if you ever have any questions feel free to contact me on the various souces listed below. I also wanted to thank SilverlightShow.Net for giving me the opportunity to share this information with everyone.

Michael Crump is an MCPD that has been involved with computers in one way or another for as long as he can remember, but started professionally in 2002. After spending years working as a systems administrator/tech support analyst, Michael branched out and started developing internal utilities that automated repetitive tasks and freed up full-time employees. From there, he was offered a job working at McKesson corporation and has been working with some form of .NET and VB/C# since 2003.

He shares his findings in his personal blog: http://michaelcrump.net and he also tweets at:@mbcrump