Following is a great post by Yochay Kiriaty on a project I’ve done involving WPF, Silverlight, Windows Phone 7 and Windows Azure.
If you’re interested in more details, make sure you come to my presentation at the coming SDP 2011 conference.
The Flashcards.show application has been around for few months now. It is mostly used as a developer’s reference and demo for showing specific and cool Windows 7 features. While the first version of the Flashcards let you create all kinds of decks and then consume these cards in the form of games, you could not share any of the great cards you created with anyone else except by sending the deck file itself via email..
Figure 1: Flashcards.Show in “Game” mode
With that in mind, we started working on Flashcards.Show version 2. Our goal was to enable seamless and easy sharing of decks among users across different computers. The idea was simple, upload the deck to the cloud, and let the user send a message to whomever the user wants to share the deck with. That message will include a link for the receiving party to click on to launch a web browser and run a Silverlight application that can “play” the shared deck. The Silverlight application dynamically downloads the shared deck and displays that single deck just as it would be displayed on the WPF application. At this point the user can launch any of the 3 games: Learning, Matching, or Memory, with the same user experience as the WPF application.
Figure 2: Flashcards.Show memory game running in IE as Silverlight application
Note: The shared decks have a few limitations. The deck size can’t exceed 5MB and we don’t allow video or audio. All restrictions are functional and not technical. We didn’t want to get into too deep of a development cycle.
So far so good, we have a WPF application that can share decks through the cloud and a Silverlight application that can play these decks. The next logical step was to try and run the Silverlight application on Windows Phone. Since one of Windows Phone development models is Silverlight, there is a good chance the app will run. So we tried. As you can see it works!
Figure 3: Flashcards.Show running on the Windows Phone emulator
The Flashcards.Show application runs on Windows Phone as a Silverlight application and can display the same deck that the WPF application shared with the web Silverlight. The same content and the same games can be played on Windows, on the web running Silverlight, and on Windows Phone.
So there you have it – a single application that run on three different platforms backed by Windows Azure as the supporting cloud service. The nice thing about the entire Flashcards.Show implementation is our ability (by design) to share a lot of code and resources between WPF, Silverlight, and Windows Phone.
Figure 4: Flashcards.Show high level architecture
How does it work?
The Flashcards.Show application is built from two main components:
- The suite of client applications – WPF for Windows, Silverlight for web, and Windows Phone
- The cloud piece, a series of web services running on Windows Azure backed by Azure storage.
In this series of posts, we will NOT explain the cloud part, but will focus on the Silverlight and Windows Phone implementations.
When you download the Flashcard.Show version 2 source code, you will find a single Visual Studio solution file (FlashCardsSolution) that contains 10 different projects:
- FlashCards.UI.Phone – Contains the Windows Phone application, including the different pages and resources
- FlashCards.UI.SL – Contains the Silverlight application, including the different pages and resources
- FlashCards.UI.WPF – Contains the main Windows application, including both modes, Admin and Game
- FlashCards.ViewModel.Phone – Contains the View-Model piece of the MVVM architecture that is used in the Windows Phone application
- FlashCards.ViewModel.SL – Contains the View-Model piece of the MVVM architecture that is used in the Silverlight application
- FlashCards.ViewModel.WPF – Contains the View-Model piece of the MVVM architecture that is used in the Windows application
- FlashCardsServices – Contains the Windows Azure project that references the services that are deployed with it
- FlashCardsServices.Contracts – Contains the definition of the services use by the various Flashcards.Show applications
- FlashCardsServices.Entities – Contains the model of the supporting web services
- FlashWCFWebRole – Contains the web services that the different Flashcards.Show applications use
Looking at the above list, you might be asking yourself, what are the duplications between the different ViewModel projects and the UI projects?
To start with, we have to compile for the target platform (Windows, Silverlight, and Windows Phone), you have no other option but to compile to the required target CLR. For a little bit of background, please watch Shawn Burke’s “3-Screen Coding: Sharing code between Windows Phone, Silverlight, and .NET”. This sample, doesnt use the library Shawn is referring to in his talk, but it would sure make our life easier.
However, that doesn’t mean we just have to duplicate code. This is especially true in regards to the ViewModel (part of MVVM) piece of the application. Since all clients basically share the same model, they all have the same logic and display the same games and screen flow. Therefore, as you can see from the figure on the left, the WPF view-model (FlashSards.ViewModel.WPF) is the main view model we are using, and the phone’s view-model (FlashSards.ViewModel.Phone) and Silverlight view-model (FlashSards.ViewModel.SL) simply link to the relevant view model files. As you can see from the image, little arrows indicate that the relevant files are linked (click on the image to the left to see a larger version of it). This shows that we are maintaining a single view-model for all clients.
The UI is a little bit trickier. The difference between Silverlight 3 and WPF 4 runtimes are such that in our case, it is easier to simply rewrite the Silverlight application (remember, we choose to target SL3 to make the porting to Windows Phone easier). The FlashCards.UI.SL is a Silverlight project that mimics a lot of the WPF functionality, but with Silverlight capabilities.
You can still leverage all of your .NET and WPF skills as you write the Silverlight XAML and use data binding. We deliberately targeted Silverlight 3 and not Silverlight 4 because Windows Phone Silverlight runtime is version 3. The reason is simple; we wanted the easiest possible port from Silverlight to Windows Phone. And the outcome was just that, a super easy port from Silverlight to Windows Phone. It took about 3 days to make the Silverlight application run on Windows Phone.
As you can see from the figure to the left, most of the Windows Phone UI project- FlashCards.UI.Phone files are links (including the folders that are collapsed in image #6.). The links point to the Silverlight web application implementation FlashCards.UI.SL.
The files that could not be linked are those under Views. These files include XAML that is directly related to the way we display the specific pages on the phone. The phone’s form-factor is much smaller, and therefore we can fit fewer objects into it. With that in mind the implementation of the XAML was similar but not identical.
Unlike regular C# code, XAML doesn’t support of #ifdef, therefore we had to write new XAML for all the views in the game. But even then we could copy large parts of the already existing XAML.
At this stage I am not going to jump into the details of the implementation, mainly because there are a lot of them. You are more than welcome to download the source code, which includes documentation. You can also watch a short video on C9.
I want to thank Arik Poznanski who helped drive the second phase of Flashcards.show.
Follow Windows Phone announcements on Twitter at WP7DEV
Follow Yochay on Twitter
(Post edited by Barbara Alban)
[end of cross-post]
That’s it for now,