Arik Poznanski's Blog : Windows Azure

3-Screens Development using WPF, SL and WP7 - SDP 2011 Conference

arik — Wed, 16 Mar 2011 17:59:00 GMT

Yesterday I’ve delivered my lecture titled “3-Screens Development using WPF, SL and WP7” in the SDP 2011 conference.

In this lecture I’ve presented the application FlashCards.Show which has 3 clients in WPF, Silverlight and Windows Phone 7.

I showed how to share the code base between the different clients using:

MVVM
Adding files as links
Preprocessor symbols
OOP
Portable Library tools

Then I showed a few features that exist in WPF and don’t exist in Silverlight, and how one can overcome this gap.

Specifically I showed how to:

Implement Commands in Silverlight 3
Implement ClipToBounds property
Implement a DataTemplateSelector replacement

I want to thank all the people who came to my lecture today.
I really enjoyed it and I hope you too.

You can download the PowerPoint presentation and the demos here.

In addition you can find more references on porting from WPF to Silverlight in the following posts:

Porting from WPF to Silverlight- The Missing Pieces, Part 1
Porting from WPF to Silverlight- The Missing Pieces, Part 2

I will post again when my lecture will be available to view on Sela College Channel.

That’s it for now,
Arik Poznanski.

Flashcards.Show – Planning a Cross-Platform Solution

arik — Sun, 13 Mar 2011 23:02:11 GMT

Following is another post by Yochay Kiriaty on a project I’ve done for Microsoft 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 (in two days!).

[Cross-posted from http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/03/03/flashcards-show-planning-a-cross-platform-solution.aspx]

I recently blogged about Flashcards.Show Version 2 for WPF, Silverlight, and Windows Phone, which features the Flashcards.Show application. I’m not going to (again) review the app, but I do want to talk about how we developed the application and the design the code base to support multiple clients.

The first version of Flashcards.Show was a Windows (WPF) application. This app was originally designed by IdentityMine, and used a few Windows 7 features such as multi-touch and taskbar integration. While the first version was great, we wanted to increase its value by enabling users to share the decks that they are creating. Therefore, when we set to work on version 2, we sought both functional and technological solutions to enable ease of use for the deck-sharing scenarios, as well as ease of development and maintenance of the code.

Ease of use for a deck-sharing scenario is achieved by enabling users to simply click one button to start the sharing process, and another to send the deck. Behind the scenes, the application communicates with Windows Azure Flashcards services and uploads the deck. To keep it simple, we chose to use the default email client application as the means for sending the email. The pre-populated email that is generated includes a link to a Silverlight player that lets the email recipients view and interact with the attached deck. If you want to experience it first hand, you can try by clicking this link. The email also includes information on how to download the deck to your Windows Phone application and how to install (using ClickOnce) the WPF application.

Sharing Code between WPF, Silverlight and Windows Phone

After we designed deck sharing, our next step was to build the Silverlight viewer. We knew that we were going to target Windows Phone as the next platform, and therefore our first decision was to make sure the runtimes are compatible. This drove the decision to build the viewer as a Silverlight 3 rather than Silverlight 4 application. While this decision costs us a few days of hard work to implement SL4 features in SL3 code, it paid off during the Windows Phone development phase.

The second decision was to share as much code base as possible, which we did. The Flashcards.Show source code includes a solution file that includes all the “client” (WPF, Silverlight, and Windows Phone) projects. If you’re interested, you can find another solution file that includes all Flashcards.Show projects, including Windows Azure in the WindowsAzureService folder (once you extract the zip file). . For now, we’ll focus on the client projects:

FlashCards.ViewModel.WPF – Contains the View-Model piece of the MVVM architecture that is used in the Windows application
FlashCards.ViewModel.SL – Contains the View-Model piece of the MVVM architecture that is used in the Silverlight application
FlashCards.ViewModel.Phone – Contains the View-Model piece of the MVVM architecture that is used in the Windows Phone application
FlashCards.UI.WPF – Contains the main Windows application, including both modes, Admin and Game
FlashCards.UI.SL – Contains the Silverlight application, including the different pages and resources
FlashCards.UI.Phone – Contains the Windows Phone application, including the different pages and resources

Looking at the above list, you might be asking yourself if there are duplications between the different ViewModel projects and the UI projects. To start with, we have to compile for the target framework. The assembly that is used for WPF ViewModel .NET 3.5 is not supported by Silverlight or Windows Phone. In addition to the Silverlight assembly, Silverlight 3 also is not fully supported by Windows Phone. Therefore you have no other option but to compile to the required target CLR.

But there is more to it than this, especially in regard to the ViewModel project. Since all clients basically share the same data model, they all have the same application logic, display the same games, and follow the same game rules. Therefore both the Silverlight and Windows Phone view-model projects include links to most of the FlashCards.ViewModel.WPF view-model project. The WPF view-model contains the data model for the deck of cards (cardDeck.cs), which is comprised of individual cards (cardPair.cs), which again are comprised of two sides of a card (card.cs). The model includes metadata (MetaData) information about the types of items (text, image, sound, video, URL) placed on each card. The games logic is also part of the view-model as you can see in the LearningGameViewModel.cs and the MatchingGameViewModel.cs. Feel free to further explore the code.

If you review the Flashcards.ViewModel.SL and Flashcards.ViewModel.Phone projects, you’ll see that they are virtually identical, and the code files in each of these projects simply contain links to the original WPF view-model files.

However, a more careful review of the Flashcards.ViewModel.SL reveals some differences. For example, the Silverlight view-model doesn’t have the Taskbar.cs file, since it doesn’t integrate with the Windows 7 taskbar as the WPF application does. The Silverlight version also doesn’t include the DeckPackaging.cs file, since we don’t allow the Silverlight viewer to edit and upload decks to the Windows Azure service.

We omit files and classes of features that are not functional in the Silverlight and Windows Phone solutions. You might want to note that the Flashcards.ViewModel.Phone is identical to the Silverlight view-model.

But there are additional changes that reflect the differences between the different platforms. In the view-model projects, you can find them in the MainViewModel.cs file. The WPF and Silverlight versions of this file are quite different from each other. The Windows Phone code is embedded into the Silverlight project and we use WINDOWS_PHONE and SILVERLIGHT conditional compile time symbols to distinguish between the two. Reviewing the MainViewModel.cs file, you’ll notice compile time conditional statements such as: #if WINDOWS_PHONE

The reason we decided to use compile time symbols instead of creating a complete new copy of the MainViewModel.cs file in the phone project is due to the simple fact that while there are differences between the two, they are small and relatively easily encapsulated.

For example, the Windows Phone application can save decks in local store, a feature we are not using in Silverlight (although possible). This introduces a completely new set of features, like getting a deck from isolated storage over the network, which can be encapsulated for the Windows Phone implementation, and abstracted from the main view-model logic. We simply make sure the main view-model receives the required information for its internal data model, and when the code compiles and runs on Windows Phone, we make sure we wrap the additional functionality in such a way that it is transparent to the main view-model logic.

For example, the StartLoading function is implemented for Silverlight and Windows Phone. While the code is similar in nature, In the Windows Phone implementation you’ll notice that we need to jump through extra hoops. For example, in the webClient_OpenReadCompleted method (called…), we don’t just return a stream back to the view-model, we also write the deck to the isolated storage. During the write time, we show a progress report, because such operations on a Windows Phone can take some time.

Another example is the private _instance_PropertyChanged method that is used in Windows Phone to control the navigation between the application pages, where in the Silverlight version we simply swap in and out user controls instead of complete pages.

Lesson Learned

Make your data model technology-agnostic as possible
In your view-model, separate the way you handle data (the model) and the flow (screen, pages, etc.) of the application (the view) within your application logic. This will make it easier to introduce different behaviors and code for different platforms, just as we did for Windows Phone and SL

Sharing UI (XAML) Is Difficult

This brings us to the next topic of sharing UI and XAML. While sharing the View-Model is relatively straightforward, sharing the UI, is a completely different story.

To start with, there is no #if def support for XAML. Therefore, you can’t use compile time symbols to control which XAML code end up in which project. Next, the namespaces are different. WPF uses a System.Windows.Window, whereas Silverlight uses System.Windows.Controls.UserControl. But even if you successfully overcome the namespace problem, there is a bunch of functionality in WPF4 that is not in Silverlight 3 (remember we chose SL3 for ease of migration to Windows Phone). Therefore, we end up rewriting most of the Silverlight application. With that said, you can still leverage all of your .NET and WPF skills as you write the Silverlight XAML, using data binding, date templates, and such. However, I really hope Shawn’s work on 3-Screen Coding Is Here: Portable Library Tools allow you to target multiple .NET platforms with one binary will help reduce such friction in the near future.

While converting the WPF solutions to support Silverlight 3 was a pain, 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.

If you look at the FlashCards.UI.Phone project, you’ll find that most of the files are links to the Silverlight UI project. The differences are visible when we check the displaying screens. In Windows Phone Silverlight application there is only one way to display data – inside a Windows Phone Page. Therefore the Windows Phone and Silverlight solutions differ in that way. But even here, the Silverlight and Windows Phone versions are very similar.

For example, the Windows Phone LearningPage.xaml includes a LearningGame user control (LearningGame.xaml). If you look at the Silverlight LearningGame.XAML, you’ll find the same user control. While we had to copy the XAML file and make some changes to fit the smaller screen, the core of the control, its behavior, and the code behind are very (very) similar. Therefore, even if we did end up copying XAML files, the core functionality remains the same.

Lessons Learned

Unfortunately, we can’t really share XAML code
Some controls can be reused

Bottom Line

Obviously, there is no single silver bullet solution to sharing code across multiple platforms. With that said, while working on this project, we learned that there is a lot of room to navigate the platform’s limitations.

Using MVVM in your WPF/SL solution makes it easier to share the model. Your application data models, logic and any request to the server side backend can and should be shared.
As for your UI, well, that really depends on the complexity of your design, and how closely you want your implementation to be dependent upon the platform form factor, like the phone’s small screen. However, even here there is some flexibility.

You are more than welcome to download the project source code, which includes some documentation. And please watch a short video on C9 demoing the 3 client applications. As usual, your feedback is most welcome.

I want to thank Arik Poznanski, from Sela group, who helped drive the second phase of Flashcards.show.

Follow Windows Phone announcements on Twitter at WP7DEV

Follow Yochay on Twitter

Get started with free tools, free training, and free Jump Start video course

(Post edited by Barbara Alban)

[end of cross-post]

That’s it for now,
Arik Poznanski

Flashcards.Show Version 2 for the Desktop, Browser, and Windows Phone

arik — Fri, 04 Mar 2011 21:15:38 GMT

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.

[Cross-posted from http://windowsteamblog.com/windows/b/developers/archive/2011/02/17/flashcards-show-version-2-for-the-desktop-browser-and-windows-phone.aspx]

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.

If you want to download the application, feel free to use the Flashcards.Show ClickOnce install. If you want access to the code, please visit Flashcards on MSDN Code Gallery.

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

Get started with free tools, free training, and free Jump Start video course

(Post edited by Barbara Alban)

[end of cross-post]

That’s it for now,
Arik Poznanski

PDC 2010, Day 1: Keynotes: Windows Azure

arik — Thu, 28 Oct 2010 18:12:00 GMT

Windows Azure and PaaS

President of Microsoft's Server and Tools Business, Bob Muglia, comes to the stage.
He starts by reviewing the different types of cloud computing:

Software as a Service (SaaS)
Platform as a Service (PaaS)
Infrastructure as a Service (IaaS)

Then he dives in to the the advantages of PaaS vs. todays platforms:

In today’s platform you must deal with server, VM, network, storage and your application. Whereas in PaaS you only think of the application (no infrastructure).
In today’s platform you must take care of your servers, apply patches, service releases, new upgrades and their possible consequence on your application. Whereas in PaaS this is all done for you and Microsoft will stay compatible when upgrading their service infrastructure.
In today’s platform you need to write lot’s of code for compose your helper services yourself to make them work. Whereas in PaaS, you got a list of existing services provided by Microsoft that you can use.
In today’s platform every problem has solutions that are different in many ways: network topology, operating system, storage, etc.. Whereas in PaaS the solution is always standardized, at lease from these perspectives.
In today’s platform you need to plan your solution for peak load. Whereas in PaaS you can scale on-demand.
In today’s platform you build the application to avoid & recover from failure. Whereas in PaaS you build your application to expect and withheld failure.

Windows Azure is the operating system for PaaS.It manages the underling hardware and provides services.

Some More Windows Azure News

All the services that are now available in the cloud will be made available to the private cloud.

Microsoft is making their cloud open to anyone. That means that java is a first class citizen on Windows Azure. You can also build Windows Azure applications using eclipse. Support for dynamic languages like PHP and Ruby exists.

Now there is a showcase by Chris Ford from Pixar Animation Studios that shows how they use Microsoft’s cloud and integrate it into their main, award-winning, rendering engine.

The reason you need cloud computing for the render process in the first place is that rendering takes lot’s of CPU processing. For example, if the movie Toy Story 3 was rendered on a single CPU, it would take approximately 277 years to finish the rendering.

Pixar chose Windows Azure for its cloud solution for the following reasons:

Scalability – They need lot’s of computers for doing this type of cloud.
Sustainability – They need the solution to be available two years later.. not every company can do such promises.
It works – Microsoft cloud simply works.

More Applications to the Cloud

Bob Announce:

Windows Azure Virtual Machine Role – Allows to easily move a Windows Server 2008 R2 image into the cloud.
Server Application Virtualization – Wraps the application and deploy to azure

New features in the coming version of Windows Azure

Extra small instance
Remote Desktop
Full IIS support
Virtual Network
Multiple administrators

Now came Mark Russinovitch to present a demo that uses some of these applications. Mark shows how to use the new Windows Azure management console and how to customize installation of a role to the machine.

New TFS

Bob Muglia announce that next year Microsoft will provide TFS as a service.
The demo is presented by Brian Harry which showed us that basically, after you configure your account over the web, the user gets the same UX like with the regular TFS and it also includes support for continues integration over the cloud, etc.

New and Updated Services

The following services are either new or updated:

Windows Azure AppFabric:

Access Control Service
Caching
Service Bus

SQL Azure

Reporting
DataCenter

We saw a demo by Don Box and Jonathan Carter that uses some of these new services.

Also announcing: Windows Azure MarketPlace which includes DataCenter, and a Composition Service that supports WF.

That’s it for now,
Arik Poznanski.