It’s been a good while since I last worked on porting Comic Cloud from Windows 8 to Windows Phone. If you can still remember, the goal was to maximize code reuse by using PCL wherever possible.

Part 3 will be the last part in this series, I’m currently holding a fully functional Windows Store app and a Windows Phone 8 app that can navigate pages and sent a search query to the api using a shared service layer. Theoretically everything is shared between the two platforms except the views, which makes sense. But it still required quite a lot of tinkering to get it to work.

PCL is improving

Microsoft is working hard on bringing as many libraries to PCL as they possibly can. In part 2 of the series I already mentioned the portable HttpClient, that library finally gave us a uniform way of doing HTTP requests on multiple platforms. Between part 2 and this part Microsoft has released the PCL version of their Azure Mobile Services SDK (beware! this one has breaking changes if you’re coming over from the platform specific SDK).

Changes in my project

I decided not to use the PCL version of WAMS yet because it has breaking changes and it doesn’t help me get rid of some platform specific projects, so no real use there yet.

What I wanted to achieve for demoing purpose was to get the search functionality working on the phone. The search function on the Windows Store app uses a BlockingCollection (MSDN link) This is a thread safe collection, meaning I can safely prefetch data from one thread while loading data on the other thread. My entire search service is relying on this class (it’s an implementation of the consumer/producer pattern by the way), only problem: Windows Phone doesn’t have the BlockingCollection class. So I could either abstract the search service, change it entirely or implement my own version of the BlockingCollection. The last option seemed like the hardest one to do so I went for it. I’m not entirely sure if I got the exact same functionality of the real BlockingCollection (it does lack some methods and properties, I only implemented what I needed for my app) but here it is

It’s basically a Queue with some lock statements, it does work for me but I’m not responsible for any accidents that might occur

Sharing ViewModels

All my viewmodels are in a PCL library, managed to get that to work in part 1. The ViewModelLocator can’t be made portable since some using statements are different and the WP8 version might need some other classes then the win8 version. I decided to add the Windows Store ViewModelLocator as a link into the Windows Phone 8 project, adding in some pre-processor directives made it work like a charm (I make this sound easy but it did take some time to get it just right).

The pre-processor directives make the class look a bit dirty but it does get the job done.

At this point the WP8 app started and showed me the mainpage, with the mainviewmodel being its datacontext. Now I wanted to add an appbar with a searchbutton, a few problems there:

• the default appbar is not bindable (solved with Cimbalino)
• the mainviewmodel doesn’t have a command to navigate to the searchpage since Windows Store uses the Search charm

I decided to take the quick and dirty solution here so I added a normal appbar with a button and a navigation statement in code behind. The SearchPage has SearchViewModel as datacontext. In Windows Store it was normal for the SearchText property to be immediately holding a value since it came from the Search charm, not the case in WP8. Small change to the viewmodel so that it doesn’t fire its Search function when SearchText is empty or null. This was the result after all my hard work

Mission accomplished!

Conclusion

PCL still has a long way to go but it is improving, and for some cases it can actually already be very useful (for example to share model classes over different platforms).

I would however advice against going for maximum code reuse, it all sounds great but the reality is very different. I had to make a lot of decisions, change quite a lot of architecture and even add missing classes (like the BlockingCollection).

My advice if you want to build a multiplatform app: use PCL to share your model, maybe even some small framework with helper classes, but build a custom implementation of service layers and viewmodels for each platform, it will save you a lot of hassle and probably even time. If you do decide to go for maximum code reuse, make sure that you really really think about it when you design your architecture, make sure that every little thing has an abstraction better one interface too many than having to rewrite a class.

Here’s a comparing screenshot between the solution before and after adding the WP8 project and refactoring everything.

Ever since I started playing with XAML based technologies (which actually isn’t that long ago) I’ve been looking into the MVVM (Model – View – ViewModel) pattern. I stumbled across MVVM Light pretty soon and liked the way it worked. Turns out I’m not the only one that likes it, there’s a whole set of developers, both hobby and professional, that really love this set of libraries. MVVM Light is, according to the author, not a framework but a set of libraries that take care of the plumbing to set up an MVVM structure and provide some extra helper classes to make life easier.

MVVM Light has changed a lot in its history, some elements were dragged out, others dragged in. Fact remains that it’s a fast, easy to use and lightweight framework. The author, Laurent Bugnion, does a great job of listening to the people that use MVVM Light, incorporating requested features and helping developers out. While talking to some of my fellow developers I’ve noticed a few times that there are certain elements of MVVM Light that others hadn’t heard of, and the same goes in the other direction. I’ve learned a lot of new things about MVVM Light just from talking with other users. Thinking about that gave me the idea of this blogpost and since those “10 things about…” posts seem to be popular, this was my chance. So here are my top 10 hidden gems of MVVM Light that you might have missed.

1. The MVVM Light installer

This one might seem a bit obvious, but in this NuGet driven world we would forget the added benefit of an installer. MVVM Light has an MSI installer that not only installs the binaries on your drive but it also provides project and itemtemplates in Visual Studio, along with a list of snippets. In case the Visual Studio 2012 update 2 removed your templates, reinstall the VSIX from C:\Program Files (x86)\Laurent Bugnion (GalaSoft)\Mvvm Light Toolkit\Vsix that should put the project templates back in place.

2. Constructor injection

This one is just awesome, and is actually a feature that can be found in most DI frameworks. MVVM Light uses SimpleIoc to register viewmodels and service classes at application launch (or during the app lifetime). Constructor injection means that you can specify a parameter in a class his constructor. When that class gets instantiated SimpleIoc will try to find a registered class of the same type as the parameter, when it finds one, that instance will get injected as the parameter of the constructor. Here’s an example, let’s say that in the ViewModelLocator, we register a navigation service.

We state here that we want to register an INavigationService in the IOC container, when it creates the instance we want it to be of type NavigationService. This “record” in the IOC container doesn’t have an instance yet, it gets instantiated when we fetch it from the container the first time. There are some occasions where you would want to create an instance of a class immediately when it gets registered. the Register<T> function of SimpleIoc has an overload to do just that.

Just pass in true as a parameter and it will create an instance right there and then.

Now we want to use the NavigationService in the MainViewModel.

SimpleIoc will search for a registered class of type INavigationService and will inject it in this constructor. This saves us the hassle of manually contacting the IOC container and requesting the correct instance.

WARNING: do be careful with this, the order in which you register your classes with the IOC container can be important, especially when using the overload to create instances. If I would create the MainViewModel before the NavigationService is registered I would get a nullreference exception. So be aware of that.

3. SimpleIoc to simple? replace it!

The SimpleIoc library works great and is a cool, lightweight addition to MVVM Light, but it is actually really lightweight. It is a very realistic scenario that for larger apps the SimpleIoc just won’t do (or you’re like me and want to try out how hard it is to replace it with another one). In this example I’m going to replace SimpleIoc with AutoFac, another well known and very powerful IOC service.

First of all, we’re going to need the AutoFac libraries and the extra library that allows us to use the ServiceLocator, just like SimpleIoc does. So either from the package manager console or from the UI, add the CommonServiceLocator extra for AutoFac, the AutoFac libraries are a dependency so they’ll get installed as well. I’m using a brand new Windows Phone 8 project for this, started from the MVVM Light project template.

The only place we’ll need to change some code is in the ViewModelLocator.

This is the new ViewModelLocator constructor, I’ve put the old SimpleIoc code in comments so it’s easy to compare

And that’s it, we declare a ContainerBuilder, set it as the LocatorProvider. The container is then used to register everything we need. The SimpleIoc overload that creates an instance upon registering would look something like this in AutoFac.

That’s it, constructor injection should still work exactly like before with SimpleIoc.

4. Built-in messages

MVVM Light has something called the messenger, it registers classes as listeners and can send messages to them. This is commonly used to do communication between viewmodels. Generally I would create a message class for each type of message that I want to send, but MVVM Light has some build in messages that we can use.

GenericMessage<T>(T content) A message that can contain whatever of type T.

NotificationMessage(string notification)a message that contains a notification. this might be
used to send a notification to a notification factory that will show the message in the preferred way.

There’s also a NotificationMessage<T>(T notification) should you need it.

The next one is NotificationMessageAction(string notification, Action callback) basically the same as the NotificationMessage but you can add a callback action that will fire once the message is received. This one also has the generic implementation just like NotificationMessage.

DialogMessage(string content, Action<MessageBoxResult> callback) 
This message is meant to ask the user to input something and it will return the result of that input in the 
MessageBoxResult. MessageBoxResult is an enum that lives in System.Windows

The DialogMessage class inherits from GenericMessage<string>

PropertyChangedMessage(T oldValue, T newValue, string propertyName)
The PropertyChangedMessage is meant to use like the RaisePropertyChanged implementation. This is great when multiple 
viewmodels need to respond to a changed property.

Be careful when registering listeners, try to use as many different types of messages as makes sense. You don’t want a wrong listener to receive a message because it happens to listen to the same type of message. To register a listener do this:

5. Portable libraries

MVVM Light is available on every XAML based platform. And it comes with a portable version now. The portable version is a separate library on NuGet.

If you decide to use the portable version, make sure that every project in your solution that needs the MVVM Light libraries references the portable version. It does not work together with the “normal” MVVM Light libraries. When you use the PCL version, you can put your viewmodels in a separate, portable library and share them over, for example, a Windows Store and a Windows Phone app.

6. Event to Command behavior

MVVM Light has an ICommand implementation called RelayCommand that can be used to bind commands to actions. Like for example a button in XAML has a Command property that can be bound to an ICommand on its datacontext, so that when the button is clicked the ICommand will fire. Unfortunately not every XAML UI element has a bindable command property for every event that they can trigger and that’s where EventToCommand comes into play. With EventToCommand you can bind any event from a XAML UI element to an ICommand in the viewmodel.

First we’ll need two namespaces in our XAML page

Let’s say that we want to use the Tap event on a stackpanel.

Line 3 specifies the event that we want to handle, note that this is a string so be aware of typos. Line 4 binds the actual command and can even pass a parameter to the ICommand implementation.

The NavigateAway method has this signature

The parameter will be the word “Edit” in this case as that’s what we’ve specified in the XAML. We can even pass the eventargs from the event to the Command by changing line 4 from the XAML snippet to this

Windows Store applications don’t have these behaviors out of the box so you won’t be able to use EventToCommand there unless you install the Win8nl toolkit from NuGet. Joost Van Schaik has build his own implementation of behaviors in WinRT and thanks to his efforts (and of some other people that have helped in the project) we can now use EventToCommand in WinRT.

7. DispatcherHelper

Since .net 4.5 we have the await/async keywords and being the good little citizens that we are we do a lot of stuff async now. That means if we want to update something that lives on the UI thread we’ll need the Dispatcher class to marshall our action to that thread. Normally we don’t have access to the Dispatcher from our viewmodel classes. MVVM Light contains a DispatcherHelper that will execute an action on the UI thread when needed.

The DispatcherHelper gets initialized in the App.xaml.cs in the InitializePhoneApplication method (in a WP8 project that is).

DispatcherHelper also has a RunAsync method. The difference with the CheckBeginInvokeOnUI is that the CheckBeginInvokeOnUI will first check if it’s already on the UI thread, if it is it will just execute the action, if it isn’t it will call the RunAsync method.

8. Blendable

MVVM Light has complete Blend support, meaning you can drag and drop properties from the viewmodel onto the view to generate a binding, or you can generate design time data based on the datacontext and so on. I’m really not that good in Blend so I’m not going into detail about this one, just remember that MVVM Light was build with Blend in mind.

9. Open Source

This one you probably knew but MVVM Light is completely open source. http://mvvmlight.codeplex.com/ is the place to be if you want to dive into the source code.

10. Laurent is on Twitter and he’s a nice guy

Laurent Bugnion, the founder of MVVM Light, is on Twitter! https://twitter.com/LBugnion he’s a great guy to chat with and very eager to help out anyone who needs help.

Conclusion

MVVM Light is a great library with a few hidden gems. In this article I’ve discussed 8 very interesting ones that can make your life as a developer easier. I’ve included two more extra items because 10 is a prettier number than 8

Porting a real win8 app to WP8 – part 1

In part one of my adventure I described the architecture of my app and how I managed to move all viewmodels into a PCL (portable class library) but I didn’t use them yet. The main consensus of part one was that I needed to do quite some refactoring and add a lot of abstractions to the project in order to move over viewmodels to PCL projects. In part 2 I’ll describe how I got the viewmodels to work and how I re-enabled page navigation in the Windows 8 version. And with a bit of luck in part 3 I’ll be talking about the Windows Phone 8 version of this app.

A small note on part 1

I wasn’t very happy with part 1 since I needed to create some extra layers and abstractions. Since then the Microsoft Techdays have come and gone and with that two very interesting sessions that made me rethink some stuff. The session were from Laurent Bugnion (his blog, his Twitter) (the creator of the awesome MVVM Light toolkit) and Gill Cleeren (his blog, his Twitter) (a Belgian Silverlight MVP, RD and Win8 enthusiast). From Laurent I learned some tips and tricks concerning the ViewModelLocator class and specifically how to correctly use it in a portable library (more on that in part 3 since I haven’t implemented it yet). Gill gave a session on advanced MVVM tactics and one sentence kept vibrating in my mind “an extra class doesn’t cost a thing” next to that his demo app was filled with layers of abstractions way beyond the extra layers I needed to add to get the project to build again. After that session I felt reassured that I was going down a pretty good path with the revised architecture I had build in part 1. If you want to take a look at that session yourself, the recording of the SilverlightShow version is available here.

About part 2

The last couple of days I found some spare time to mess around with the project again. I’m now at the stage where the Windows Store app is using the portable ViewModels and the navigation is working properly. Those parts are what I’ll discuss here.

Using the ViewModels

Having the portable ViewModels ready it was time to switch to them. I deleted every viewmodel that was still in my client project, except for the ViewModelLocator, that one will be moved later. I registered the new abstraction layers in the ViewModelLocator, making sure that this only happened at runtime, not at designtime and tried to build the app. I couldn’t believe my eyes when I saw the message “Build succeeded”. I replaced the viewmodels in my client project with the ones in the portable library and it still builds! In case you’re interested, this is what’s getting registered in my ViewModelLocator at this time.

Everything in the else block gets registered only at runtime. The viewmodels themselves can get registered at designtime just in case I ever want to incorporate designtime test data (something I really should do actually). Notice that some ViewModel registrations get passed a boolean parameter? The Register method of SimpleIoc has an optional parameter stating whether or not the object should get instantiated immediately. Since some viewmodels are listening for messages from the Messenger class in MVVM Light they need their instance right of the bat so they can register as listeners.

I tried to run the app, it started and data was coming in, I could use the button to show the search charm but no navigation was working. That made sense since all navigation commands are now going to ISomePage instead of SomePage and those interfaces weren’t doing anything yet. So I had to make every page implement the correct interface and put together a way to navigate to the correct page from the interface.

Implementing the interface is easy enough (they’re all just empty interfaces). Next problem was that those interfaces are inside of a folder called View in the ViewModel PCL and they need to be known in the Framework.WinRT project (that’s where the NavigationService lives). So I’ve added another PCL called it ComicDB.View and moved all interfaces there. (I couldn’t reference the ViewModel project in the Framework project, it would create a circular dependency). After adding all references everything was building again but still no navigation. To get this to work I changed the Navigate method on the NavigationService from this

to this

The Navigate method passes everything to the NavigateToPage method that tries to resolve a registered instance of the passed in type, should this fail it throws an ActivationException, in that case just try to navigate. This allows us to navigate to pages that don’t use any interface. Once we get the instance out of the IOC we get its type and pass that into the navigate command of the frame. Obviously, before this starts working we need to register the pages in the IOC and that happens in the ViewModelLocator.

So to finish this part 2 of, here’s the complete constructor of my ViewModelLocator

It registers all my api and service layers, all my views that have an interface and all viewmodels.

Part 2 conclusion

After a rough start in Part 1 it seems that this experiment has forced me to improve my code by making me add some abstractions. This makes for easier reusable code, both on the same platform as on other platforms. The DEV branch of my app project is once again a fully functional Windows Store app that reacts and behaves exactly as the one that’s in the store right now. The next step is to refactor out the ViewModelLocator and then it should be about time to start work on the Windows Phone version. See you in part 3!

A few weeks ago the first version of my Windows 8 app (finally) hit the store (download it here).  From the start I wanted to port this application to Windows Phone 8 as well but I didn’t keep that in mind when developing the app. Some time ago, the portable HttpClient was released in a beta version and to me that was the perfect time to see how useful the portable class libraries (PCL) really are.

Most of the information available on the internet on sharing code between Windows Store and Windows Phone apps have those really small basic projects, good stuff to get started, but I want to port an entire, finished project to another platform. Perfect content for some blog posts so I’ll be documenting my progress here on my blog, hopefully it will be to some use.

The app

The app is called Comic Cloud and is a continuation of my very first Windows Phone 7 app ever. It allows users to search for anything related to comic books (volumes, issues, artists, characters, locations, …) and provides a whole bunch of information on the topic. The data comes from a community driven website (think Wikipedia for comics) called ComicVine. They have a great REST API with great documentation so that was perfect. On the other hand, and this is new in the Windows 8 version, users can start tracking their own collection of comic books and keep track of which issues in their collection are already read. This data is saved on Azure by using the awesome Azure Mobile Services, authentication happens with the Microsoft Account (single sign-on). So researching and collection are the two keywords of the application. Since the API is REST based, I make extensive use of the HttpClient class to make the API calls.

Architecture

As for architecture, all libraries are Windows Store class libraries and then off course there’s the app itself, written in C# and XAML. This image shows the projects and their dependencies.

(The app was called ComicDB in its begin stages, the namespaces stayed but the app title was changed to Comic Cloud)

The solution exists of five projects, first there’s the app itself using MVVM Light, win8nl for winRT behaviors (written by Joost van Schaik), MarkedUp for analytics, Callisto for settings fly-out, the Live SDK for the User class and the Telerik RAD controls for their controls (obviously).

The Model project contains all classes, there’s the ComicVine classes (thank God for paste JSON as class…) and some classes for RSS feeds and links.

Since I want to limit the amount of data stored in my WAMS database, I only save the userID and the link to the ComicVine API for each item. For that I needed a second version of some classes, that’s what the DTO project is for.

The framework is a project that I can reuse in other projects without changing anything, all classes that are app independent. Things like the RestClient (providing generic CRUD functions), the GroupInfoList for grouped gridviews, navigationservice to navigate between pages and so on. The ComicVineHelper is an extension method that changes the casing of some object to be compatible with the way the ComicVine API works. All these classes are implementing interfaces, so that will be a big plus when I start porting.

The SDKBroker takes all the different services I use and puts them together in one big SDK that’s easy to use from the app.

The idea

So the idea was to take all those libraries, put them in PCL libraries and reference them from both the Windows Store app and the Windows Phone app. Next to that I wanted to use the portable version of MVVM Light to share my viewmodels over both projects as well. Turns out that, as usual, a good idea is stopped by technical limitations.

The problem

The problem is the difference between Windows 8 and Windows Phone, they don’t share their entire codebase. Meaning I can’t reuse all my code in a PCL. Also the Azure Mobile Services SDK has no portable version, so same problem there.

The solution is abstractions, create an interface for every class that isn’t compatible with the PCL projects and implement them in a platform specific library. The PCLs I’m using only target .net 4.5, winRT and WP8 so a lot of problems are already taken care of by not selecting WP7.X compatibility.

The road so far

I wanted to start out by replacing MVVM Light with the PCL version. This turned out to be easier said than done, the initial project was started from the MVVM Light template so I threw out the references to MVVM Light and added the PCL version through NuGet. Visual Studio went quite mad and started throwing all sorts of weird build errors, I eventually found out that the win8nl library also includes the MVVM Light assemblies and those conflicted with the PCL versions. But I needed the win8nl assembly for the eventtocommand behaviors in WinRT so that posed a big problem. Luckily there’s the winRTBehaviors assembly that contains the logic to do behaviors but it doesn’t include the actual eventtocommand one. The solution was to go to the Codeplex site of win8nl and copy the behavior classes from there and put them in my framework project. One problem solved.

The next step was to add a PCL for the Framework and SDKBroker projects, the Model was already a PCL so that one could stay as it was. The PCL libs got named ComicDB.Framework and ComicDB.SDKBroker, they contain a combination of interfaces and classes. Everything that couldn’t be made portable was abstracted into an interface and implemented in platform specific libraries called ComicDB.Framework.WinRT and ComicDB.SDKBroker.WinRT. The classes that needed abstraction were the NavigationService, Network helper, WAMS service class and Service helper. Thanks to the new portable HttpClient assembly I could copy my RestClient class to a PCL without any adjustments.

With some tinkering I got the project to build and run again and I saw that it was good. The time had come to move my ViewModels over to a PCL. I added a new PCL project called ComicDB.ViewModel (same namespace as my VMs already had) and added the portable MVVM Light version. The ViewModelLocator can’t be moved since it needs to register all the correct interface implementations into the IOC container, so I’ll have a separate Locator class for Win8 and WP8. As I started moving ViewModels I quickly ran into a navigational problem, my viewmodels have navigation logic and the pages they are navigating to aren’t known in the PCL. To solve this I’ve created an interface for every page and set that as navigational target, I don’t know if this will work but I’ll find out soon enough and put it in part 2 if this diary.

Navigational problem solved, on to the next one. Two of my viewmodels could show toast notifications, I use the notifications helper classes from MSDN to get this done but the notification classes aren’t portable (and they really don’t need to be since Windows Phone doesn’t support in-app toasts, the C4F toolkit fixes that luckily) so I created an IMessageAPI interface that has a PopToast() method. In FrameWork.WinRT it shows a build-in toast just like the app used to do.

Hey remember that we have to do everything async now and that we can call the Dispatcher to execute something on the UI thread? Not happening in a PCL… MVVM Light contains a DispatcherHelper that checks if an action needs to be executed on the UI thread and actually executes it there when needed, except in the PCL version. So IDispatcher was born.

With that done I got my project to build again and to run but it’s currently still using the old viewmodels, I expect a whole bunch of new problems when I try to change it to the PCL versions, but that will be for part 2.

What’s next

In part 2 I hope to make the app use the PCL version of the viewmodels and I’ll start working on the Windows Phone project.

Conclusion

PCL projects sound very good in theory but in reality they are a great PITA to work with. Portable HttpClient and portable MVVM Light make them useful but you’ll have to right loads of extra code, abstractions and helper classes to get to something that looks like build once run on two platforms. I could’ve given up and just rebuild everything in a separate solution for WP8 but I want to see how far I can take this and document it along the way.

That said, I have no idea when part 2 will be live, that depends on when I can gather the courage to reference the viewmodel project

There are plenty of blogposts, tutorials, videos, books and many more out there that talk about searching, sharing settings and if you’re lucky even printing. But the Devices charm can be used for something way cooler than printing some pages, it can trigger the Play To contract.

The Play To contract can share media like music, video and pictures to other devices on your network, be it other Windows 8 devices or even Xbox 360 consoles. Being a comic geek I the first thing on my mind when reading about the Play To contract was “this would be awesome to stream comics from my pc to my Xbox” and so a challenge was born and accepted on the same day. An evening or two of hacking later I’m proud to say that I did it and it’s really easy, just like everything that involves charms (Microsoft really did a good job on allowing us to integrate our apps with the OS here). Most of the time putting this thing together went to building the actual comic viewer, but enough talk, let’s take a look at how it’s done. First let me show you how it looks like, we’ll start with the app itself.

Pretty empty so far, if we load a digital comic (only .cbz format supported in this demo) and select the Devices charm we get this.

That’s right! that’s Captain America himself, including Bucky. And oh yeah, the xbox shows up in the Devices charm as well. After selecting the xbox from the list of devices we get this.

And here it is playing on my TV (yes that’s a Sony, because Microsoft doesn’t build televisions yet )

Pretty cool eh? Let’s check under the hood.

First, a digital comic mostly exists in either .cbz or .cbr format. They’re actually nothing more then a zip or a rar file (Comic Book Zip and Comic Book Rar). Since WinRT has the ZipArchive class we can support .cbz out of the box, for cbr format we would need to find a library that supports rar files but that’s outside the scope of this post.

First the XAML, the main control here is a FlipView, that allows for touch and mouse support out of the box. The FlipView is bound to a collection of bitmap images that get loaded from the digital comic. Next to the FlipView there’s also an appbar containing the load file button and a textblock that shows the connection to other devices.

   1: <common:LayoutAwarePage.BottomAppBar>

   2:     <AppBar IsOpen="True" Background="#FF1A76B6">

   3:         <StackPanel Orientation="Horizontal">

   4:             <Button Click="OpenButton_Click" Style="{StaticResource OpenFileAppBarButtonStyle}" />

   5:         </StackPanel>

   6:     </AppBar>

   7: </common:LayoutAwarePage.BottomAppBar>

   8:  

   9: <Grid Style="{StaticResource LayoutRootStyle}">

  10:     <Grid.RowDefinitions>

  11:         <RowDefinition Height="140"/>

  12:         <RowDefinition Height="*"/>

  13:     </Grid.RowDefinitions>

  14:  

  15:     <TextBlock x:Name="ConnectionText" TextWrapping="Wrap" Text="Not connected" Margin="38,18,766,571" 

  16:                Grid.Row="1" Style="{StaticResource SubheaderTextStyle}"/>

  17:  

  18:     <FlipView x:Name="FlipImage" Margin="0,3,0,0" Grid.RowSpan="2" SelectionChanged="FlipImage_NextImage">

  19:         <FlipView.ItemTemplate>

  20:             <DataTemplate>

  21:                 <Image Source="{Binding}" />

  22:             </DataTemplate>

  23:         </FlipView.ItemTemplate>

  24:     </FlipView>

  25:  

  26:     <Grid>

  27:         <Grid.ColumnDefinitions>

  28:             <ColumnDefinition Width="Auto"/>

  29:             <ColumnDefinition Width="*"/>

  30:         </Grid.ColumnDefinitions>

  31:         <Button x:Name="backButton" Click="GoBack" IsEnabled="{Binding Frame.CanGoBack, ElementName=pageRoot}" 

  32:                 Style="{StaticResource BackButtonStyle}"/>

  33:         <TextBlock x:Name="pageTitle" Grid.Column="1" Text="{StaticResource AppName}" 

  34:                    Style="{StaticResource PageHeaderTextStyle}"/>

  35:     </Grid>

  36: </Grid>

The FlipView template is just a simple Image control, nothing special in the XAML, the magic is in the code behind.

First some fields that we’ll need later on

   1: private List<BitmapImage> _pages;

   2: private bool _isConnected;

   3: private Image _current;

We’re going to take a look at how to load the cbz file first, I’ll go over this quickly as the main focus of this post is the PlayTo contract.

   1: private async void OpenButton_Click(object sender, RoutedEventArgs e)

   2: {

   3:     _pages = new List<BitmapImage>();

   4:  

   5:     _pages = await OpenZip();

   6:  

   7:     if (_pages.Count > 0)

   8:         FlipImage.ItemsSource = _pages;

   9: }

All we do in the button’s eventhandler is initializing the field that will hold all the pages, call the function that will load the file and if it contains any items it will set the FlipView’s itemssource to that list. Next up: the function to load the comic.

   1: async Task<List<BitmapImage>> OpenZip()

   2: {

   3:     FileOpenPicker openPicker = new FileOpenPicker();

   4:     List<BitmapImage> comic = new List<BitmapImage>();

   5:  

   6:     openPicker.SuggestedStartLocation = PickerLocationId.ComputerFolder;

   7:     openPicker.FileTypeFilter.Add(".cbz");

   8:  

   9:     var storageFile = await openPicker.PickSingleFileAsync();

  10:     // Create stream for compressed files in memory

  11:     using (MemoryStream zipMemoryStream = new MemoryStream())

  12:     {

  13:         using (IRandomAccessStream zipStream = await storageFile.OpenAsync(FileAccessMode.Read))

  14:         {

  15:             // Read compressed data from file to memory stream

  16:             using (Stream instream = zipStream.AsStreamForRead())

  17:             {

  18:                 byte[] buffer = new byte[1024];

  19:                 while (instream.Read(buffer, 0, buffer.Length) > 0)

  20:                 {

  21:                     zipMemoryStream.Write(buffer, 0, buffer.Length);

  22:                 }

  23:             }

  24:         }

  25:  

  26:  

  27:         // Create zip archive to access compressed files in memory stream

  28:         using (ZipArchive zipArchive = new ZipArchive(zipMemoryStream, ZipArchiveMode.Read))

  29:         {

  30:             // For each compressed file...

  31:             foreach (ZipArchiveEntry item in zipArchive.Entries)

  32:             {

  33:                 if (item.Name.EndsWith(".jpg", StringComparison.OrdinalIgnoreCase))

  34:                 {

  35:                     byte[] imageInBytes;

  36:  

  37:                     using (MemoryStream ms = new MemoryStream())

  38:                     {

  39:                         var stream = item.Open();

  40:                         stream.CopyTo(ms);

  41:                         imageInBytes = ms.ToArray();

  42:                     }

  43:  

  44:                     BitmapImage bImg = new BitmapImage();

  45:                     await bImg.SetSourceAsync(new RandomStream(imageInBytes));

  46:  

  47:                     comic.Add(bImg);

  48:                 }

  49:             }

  50:         }

  51:     }

  52:  

  53:     return comic;

  54: }

We start by initializing the FileOpenPicker, allowing our user to select the comic he/she wants to read. We add a suggested location where the FileOpenPicker should start and add the filetypes it should look for. The PickFileAsync method shows the actual filepicker to the user, the user selects the cbz file he wants and it gets loaded into the storageFile variable. The file gets read in as an IRandomAccessStream. We need that stream to create a ZipArchive instance. Once we have that we can loop through all files in that zip archive. Each .jpg file in that zip archive gets read into a byte array that we then convert into a bitmap by using RandomStream, an implementation of IRandomAccessStream (if you want to see the implementation, the project is attached to this post at the bottom). The bitmap image then gets added to the list. When they’re all done the list gets returned to the caller.

That’s it for loading the comic, let’s take a look at the sharing to other devices in your network.

We need to initialize the PlayTo contract, I’ll be doing this from the constructor

   1: public MainPage()

   2: {

   3:     InitializeComponent();

   4:  

   5:     var playToManager = PlayToManager.GetForCurrentView();

   6:     playToManager.SourceRequested += PlayToManagerOnSourceRequested;

   7:     playToManager.SourceSelected += PlayToManagerOnSourceSelected;

   8: }

PlayToManager is the class that we need, we get this for free from the WinRT framework. The GetForCurrentView() method returns an instance of the PlayToManager class bound to this page. Once we have the instance we attach an eventhandler to the SourceRequested and the SourceSelected events. The SourceRequested event will fire as soon as the user hits the Devices charm, this is where we’ll prepare the first media element for streaming. The SourceSelected event fires when the user selects a source, obviously.

   1: private async void PlayToManagerOnSourceRequested(PlayToManager sender, PlayToSourceRequestedEventArgs args)

   2: {

   3:     var deferral = args.SourceRequest.GetDeferral();

   4:  

   5:     await Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =>

   6:         {

   7:             var firstImage = GetChildren(FlipImage).First();

   8:  

   9:             // Provide Play To with the first image to stream.

  10:             args.SourceRequest.SetSource(firstImage.PlayToSource);

  11:             _current = firstImage;

  12:             deferral.Complete();

  13:         });

  14:  

  15: }

The OnSourceRequested eventhandler needs to be marked as async. First we get the deferral, then we need to run some async code, Dispatcher.RunAsync is the same as calling an async method with await on this line. The PlayTo contract works with certain XAML controls. In our case we need the Image control, that’s why we’ve set the itemtemplate of the FlipView to be an Image. We’ll take a look at the GetChildren() method in a minute, for now just know that it returns a list of all Image controls inside the FlipView. We take the first element in the returned list and that’s the element that we’ll stream to the device. The arguments have a property of type PlayToSourceRequest, that one has a SetSource function that takes in a PlayToSource object and that’s a property of the Image control. We set the current image to the _current field and mark the deferral as complete.

Phew that was quite some work. Don’t worry, the hard part is over (yes this was really the hard part). Now a quick look at that GetChildren() function.

   1: private List<Image> GetChildren(DependencyObject parent)

   2: {

   3:     var list = new List<Image>();

   4:  

   5:     for (int i = 0; i < VisualTreeHelper.GetChildrenCount(parent); i++)

   6:     {

   7:         var child = VisualTreeHelper.GetChild(parent, i);

   8:         var item = child as Image;

   9:         if (item != null)

  10:             list.Add(item);

  11:  

  12:         list.AddRange(GetChildren(child));

  13:     }

  14:  

  15:     return list;

  16: }

The function takes in a DependencyObject and starts walking through its visual tree. We try to cast each item as an Image, if that cast fails the variable will contain null, a quick check there and if it isn’t null we add it to the list which we then return.

The OnSourceSelected is only used to set the name of the selected source to the textblock

   1: private async void PlayToManagerOnSourceSelected(PlayToManager sender, PlayToSourceSelectedEventArgs args)

   2: {

   3:     _isConnected = true;

   4:  

   5:     await Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =>

   6:         ConnectionText.Text = string.Format("Connected to {0}", args.FriendlyName));

   7: }

And that’s enough to stream the first image, when you run this code and select the Devices charm the first page of the comic should show up on your device. All there’s left now is to go back and forward in the comic. In the app itself this already works, the FlipView takes care of navigating between the pages. Before we start developing this we need to make a small halt and take a look at how the FlipView actually works. First thought in my head was “okay this is easy, I just get all the image controls in the FlipView and I’m golden”. That was a big nono. The itemspanel of a FlipView is actually a VirtualizingStackPanel, meaning that at any given time there are maximum three Image controls inside the FlipView, usually previous-current-next. As soon as we navigate to another page the FlipView automatically loads in the next item in line. This can easily be seen by using a handy tool called XamlSpy. XamlSpy allows us to view the entire visual tree of any XAML based application. When we view the default visual tree of a FlipView after loading a comic we get this.

As you can see, we only have three FlipViewItems here. When we change the FlipView’s paneltemplate to this

   1: <FlipView x:Name="FlipImage" Margin="0,3,0,0" Grid.RowSpan="2" SelectionChanged="FlipImage_NextImage">

   2:     <FlipView.ItemsPanel>

   3:         <ItemsPanelTemplate>

   4:             <StackPanel />

   5:         </ItemsPanelTemplate>

   6:     </FlipView.ItemsPanel>

   7:     <FlipView.ItemTemplate>

   8:         <DataTemplate>

   9:             <Image Source="{Binding}" />

  10:         </DataTemplate>

  11:     </FlipView.ItemTemplate>

  12: </FlipView>

and we load the same comic in XamlSpy we get this result

Quite the difference I would say. The VirtualizingStackPanel is lighter on memory usage, since some comics can be quite large we’ll stick to the default template.

Now that we have that cleared out, let’s take a look at what happens when we browse to the next page of the comic.

   1: private async void FlipImage_NextImage(object sender, SelectionChangedEventArgs e)

   2: {

   3:     if (!_isConnected) return;

   4:  

   5:     await Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =>

   6:         {

   7:             var current = GetChildren(FlipImage)[1];

   8:  

   9:             _current.PlayToSource.Next = current.PlayToSource;

  10:             _current.PlayToSource.PlayNext();

  11:             _current = current;

  12:         });

  13: }

First, this code does not need to be executed when we’re not connected to any device, if we are we need to run the next block of code asynchronously. First the code fetches all the available Image controls inside the FlipView, we save a reference to the middle one because that one is the one currently shown in the FlipView. The field _current contains the image currently shown on the external device, we need to set that field’s PlayToSource.Next property. That property always needs to be set on the current image before the PlayNext() method is called. Once that’s set we call the aforementioned PlayNext() method. That method will sent the control that is set to the PlayToSource.Next property to the connected device. To end we set the image control that was just send to the device to the _current field so that it can be called upon on the next run.

In this post I have shown how you can share media content from your Windows Store application to an external device like the Xbox 360. The project used in this post can be downloaded from my SkyDrive

That Microsoft loves his communities is no secret. The past months we literally drowned in hackathons, trainings, competitions and many more Windows 8 related. And it doesn’t look like it’s stopping any time soon! On November 23th Microsoft Belgium organizes the Windows App Day, a day stuffed to the top with sessions divided into two tracks, one for developers and one for designers. And the best part? It’s not only for Windows 8! Windows Azure and my all time favorite platform, Windows Phone 8 will be represented as well.

So if you’re in or around Belgium on November 23th and feel like spending the day with our great community feel free to drop by. There might even be some very cool announcement concerning people that are into Windows 8 development… drop by to get the full story (and start thinking about that one killer app)!

Details:

When: Friday 23 November 2012, 9AM to 6PM

Where: ALM Meeting Point

Filip Williotstraat 9

2600 Antwerp (Berchem)

All details: http://www.microsoft.com/belux/msdn/windows-app-day/default.aspx

Yesterday was Community Day, the biggest community driven event in Belgium.

I did a talk there about porting over a Windows Phone 7 app to Windows 8. It was very exciting, I never spoke to such a crowd before, let alone hooked up my portable to a cinema beamer.

The talk itself went pretty well but I did suffer from demo failure, what was really odd since the demo worked perfectly an hour earlier. I researched the error after the talk and it seems that in a Windows 8 Metro app the path to the manifest file is an absolute path for some reason. I suddenly remembered that I moved the solution to another folder right before the talk, so it was my own fault. Reminder to self: never move a folder before doing a talk.

Anyway, it was a great day, I've met some nice people, had fun discussions and attended an App clinic on UI (thanks Lesley for the useful information!). See you next year community day!

Download my slides and demos here.

Tomorrow we will get the first details of the next Windows Phone version. A moment I've been waiting for since the first details of Apollo (the codename for WP8) started showing up. That said, I feel like a kid the evening before Christmas, staring at presents unable to open them or to take a peek inside.

What do I expect from the keynote? I expect announcements concerning new resolutions, multi-core CPU's, private marketplace, IE10, NFC, Wallet, new camera features, swappable SD cards.

Those are the most obvious things and I'm pretty sure that we'll hear about 95% of them tomorrow. Besides this I hope to hear from WP 7.7 or even better, existing devices will get a complete upgrade to WP8.

And let's not forget the dev related stuff, WP8 will run on WinRT, the kernel used in Windows 8, allowing devs to share 99% of apps between Windows Phone, Windows 8 and maybe even Xbox. I also hope for beta SDK availability tomorrow at the event and a release date set at about the same time as Windows 8 (around October). Maybe we'll even get some early access to the Smartglass SDK, that would be a whole lot of epicness.

No matter how it turns out, I'm pretty confident that it will be awesome. I'm already looking forward to using the complete WinRT ecosystem, but even more to developing apps that plug into each and every WinRT client.

I'll be following the livestream with our User Group's board and our friends at Microsoft while enjoying some beer and pizza, so setting is perfect. I'll also be spamming Twitter, so keep an eye on it there.

BEWARE: everything I talked about in this post is my own opinion, I have no knowledge of what effectively will be shown at tomorrow's keynote.