I received a mail from Mindscape stating that their product called Raygun was coming along nicely and if I was interested in trying it out and blogging my finding. I would receive a bunch of t-shirts to hand out during user group events. So here’s me, writing my findings of RayGun (which is actually a cool product) and hoping to receive free t-shirts, the things I do for community

RayGun

So what is RayGun? RayGun plugs into your apps and sends errors to the server. You as the developer receive an email stating that a new error has been found.

What’s great here is that you can resolve the error here with one click, the second link will open the error details on the site and immediately change its status to Resolved.

If you view the error you get all the information that you expect from a service like Raygun. Information about the device that the error occurred on, the used resolution (always 800x480 for Windows Phone as that is the base resolution, all apps are upscaled from there but it still reports as 800x480) and of course the complete stacktrace.

You can even view RAW data in JSON format.

You can add comments to errors, assign people to them, all in all RayGun feels very complete. The mail arrived immediately after the error was thrown, shows up nicely on the dashboard, both the Windows Phone emulator and my Lumia 920 over 3G reported the error perfectly.

Implementing RayGun

Implementing RayGun in your app is very straigthforward, go to http://www.raygun.io and register for a trial account (pricing can be found here http://raygun.io/pricing). Once your account is registered you arrive at a page that tells you the steps to integrate RayGun with your app.

Nifty feature here is that your api key is integrated in the sample code that they give you, so it’s just copy/paste. It may sound stupid but I really liked that sense of detail.

First thing we need to do is add RayGun through NuGet.

Bit weird here is that a readme file pops open stating that for Windows Phone I need to Reference the "Mindscape.Raygun4Net.WindowsPhone.dll but NuGet is smart enough to reference the correct DLL depending on the platform that you’re developing for.

Second step is adding a property of the RayGunClient to App.xaml.cs and instantiating it with the api key.

And for the initial setup there’s one step left. In the Application_UnhandledException method add the actual call to the RayGun servers (line 4).

Since the RayGunClient in this example is a static property in App.xaml.cs you can reuse it anywhere in your project. You can even start creating completely custom errorlogs by passing in a RayGunMessage instance in the Send method.

Conclusion

RayGun works as advertised, no problem there at all. The dashboard looks great, is easy to navigate and shows all the necessary information. Crash reports arrive really fast and have nice little details like a one-click link to resolve an error. Small mistake in the readme file that opens when adding the NuGet package can be forgiven (who reads readme files anyway?)

Will it be a great success? I don’t know. There’s quite a lot of competition out there, services that offer the same stuff as Mindscape does with RayGun but often times they are either free or provide a limited free service for hobby developers. Personally, I feel that MindScape should include a free price plan as well, limited in such a way that it’s only suitable for hobby projects of course since everyone needs to make a living. But those hobby developers can create buzz around the product so that professionals will pick up on it as well.

By the way, this post only talks about the Windows Phone part of RayGun but it supports a wide array of platforms like ASP.net, JavaScript, PHP, Ruby on rails, Java and ColdFusion.

So all in all, great product, works as advertised! If you want a t-shirt come to the next MADN user group event after the summer break and hopefully we’ll have some to hand out!

As I was working on a Windows Phone 8 project I needed a pivot that could hide its title, giving back some screen real-estate when needed. The basic pivot that is included in the Windows Phone SDK doesn’t have this kind of behavior so it was a great opportunity to try out custom controls in Windows Phone. I’ve build custom controls in XAML before but never based on an existing one, so fun times ahead. Let me start by showing a side-by-side comparison between both views of my pivot.

don’t mind the overlapping textblock and button, point is that when the button is clicked, the title of the pivot disappears.

Building a XAML custom control

It’s quite easy to build a custom control in XAML as long as you follow the guidelines. It requires you to add a folder called Themes and in the folder a file called generic.xaml. The generic.xaml file is a resource dictionary, no code behind file is needed. Do follow the naming conventions exactly or your control won’t work. Next step is adding a class that inherits from ContentControl (or a control that already inherits from ContentControl). The project for my ExtendedPivot looks like this

The project type is a WP8 class library containing two custom controls, one for the pivot and one for the pivot items.

Extending the pivot

Since I only want to add a functionality to an existing control, the Pivot, my ExtendedPivot class inherits from Pivot instead of CustomControl.

We’ll start with the constructor, Line 14 is necessary when developing a custom control, it sets the style of the control to the style defined in generic.xaml (we’ll get to that style in a minute). Lines 6 – 10 are a property that will be used by the DependencyProperty. The DependencyProperty (lines 3-4) is a property that we can bind a value to when using the control in a project, it might seem a bit overwhelming at first but there’s a great snippet in VS2012 to easily write them. Basically, the parameters for the Register function are a name, the type of the property, the owner type (type of the control where you’re declaring the DP) and some metadata.

The get and set method of the normal property use the DP to get and set values through databinding.

generic.xaml

This is the style for the ExtendedPivot as declared in generic.xaml

Basically, I’ve created a xaml page in some very basic Windows Phone project, right-clicked it, selected Edit Template > Edit a copy. This gives you a copy of the template for the Pivot. I copied that template in the generic.xaml style. The ContentControl at Lines 23-28 show the title in the pivot. I added the Visiblity property here and bound it to the HeaderVisibility property in the ExtendedPivot class. To bind a property in a style you need to use the TemplateBinding keyword instead of the normal Binding one.

Don’t forget to set TargetType to the type of your custom control.

Using the custom control in an app

The control is ready, now it’s time to use it. Create a new Windows Phone app and reference the project or DLL of the custom control. This is the MainPage of the sample app.

Line 4 defines the namespace that holds the ExtendedPivot. Line 20 puts the control on the actual page. Notice that we bind the HeaderVisibility property of our control. I defined the datacontext of this page in code behind to be of type MainViewModel. MainViewModel implements INotifyPropertyChanged and only holds one property of type Visibility, that property is bound to the ExtendedPivot’s HeaderVisibility.

The Button in the pivot will switch the HeaderVisibility between Collapsed and Visible, this happens in the code behind of this page.

Not really the best way of writing a Windows Phone app but it’s just for making the point

Conclusion

Extending a Windows Phone control isn’t hard as long as you follow the naming conventions, adding some extra functionality is as easy as copying the xaml template and adding some dependency properties.

The sample code can be found on my SkyDrive

Today I delivered a session at Europe’s biggest free multimedia conference. The session was an introductory session on Windows Phone 8. As promised during the session, here are the slides

The demos can be found on my SkyDrive

In case you’re interested in the session but couldn’t make it to Multi-mania, I’ve delivered this talk before as an MSDN webcast and there’s a recording of that session.

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

While SQLce is still a viable solution in Windows Phone 8 to have some form of local database we also have an official SQLite implementation available. So why use SQLite when we can just keep using SQLce? Because Windows 8 only support SQLite and if you ever want to port over your app it would be nice not to have two versions of local databases to maintain. In this post I’ll explain how to implement a SQLite database into an MVVM Light Windows Phone 8 project (there is an unofficial Windows Phone 7 SQLite version as well but I have no idea how stable / buggy that is). I’ll be using Tim Heuer’s SQLite .net wrapper so we can use LINQ to SQLite instead of writing SQL queries manually (hooray for intellisense ). Let’s kick things off by creating an empty Windows Phone 8 app.

SQLite

Before we can use SQLite, we’ll need to install the SDK. Click here (official SQLite download page) to download the VSIX file and install it into Visual Studio.

NuGet fun

Before we can write any code we’ll need some NuGet packages. Use these commands in the Package Manager Console.

Install-Package MvvmLight

Install-Package sqlite-net

Install-Package WPtoolkit

Install-Package Cimbalino.Phone.Toolkit

Changing target platform

SQLite is a C++ library, meaning that it should be compiled against the architecture that the app will be running on. On Windows 8 that means creating separate packages for ARM and x86. On Windows Phone 8 that means switching from Any CPU to ARM when running on a device or when creating your XAP. When you’re running your app on the emulator the target platform needs to be set to x86.

Moving files around

When you  install the MVVM Light package it will add some folder structure and some files. I like to adjust this a bit more by adding a View folder and moving the MainPage into that view. That means that the startup page has to change as well. Open up the WMAppManifest.xml and change it like on the screenshot.

At this stage I couldn’t build the project because of a whole bunch of compile errors in the sqlite-net files. If you get the same problem (by the time you read this, it might be fixed), download the sqlite-net source from GitHub and from your project, add a reference to your local sqlite-net repo/lib/wp7/Community.CsharpSqlite.WinPhone.dll and that should fix it right up. Also, add a folder “Model” to the project so that our MVVM folder structure is complete.

The demo app

The app that we’ll be creating today is an app to keep track of tasks, which seems to be the new “Hello, World!”. We’ll start with the model, and work our way up to the view from there. Our class is called “Task” that means we’ll have to be careful that we use Model.Task instead of System.Threading.Task but we’ll manage.

The “Task” class implements INotifyPropertyChanged so that controls that are bound to its properties get updated like good citizens. Now for the annotations, those come from sqlite-net and mark this class as a table in the database. The same goes for the annotations on the Id property, that property is marked as being the primarykey and being an autoincremented value. If you have a property that you don’t want in the database, add the [Ignore] attribute and there won’t be any column generated for it. Now that we have a model we can start working on the service, the class that will do all the SQLite communication. (Yes we could do all this in the viewmodel but it’s called seperation of concerns ). And to do this the right way we’ll start by creating an interface for the service.

Those are all the basic CRUD (Create, Read, Update, Delete) that we can (should be able to) perform on any datacontainer. Here’s the implementation

Hmm looks like I forgot to mention something, go to App.xaml.cs and add this property

Keep App.xaml.cs open, we’ll need it in a minute. In the DataService class we’re calling all the CRUD methods provided to us by sqlite-net. We can get a list of all records in a table by calling .Table<T>().ToListAsync() or do any of the other CRUD operations by just calling the function and passing in the modified POCO. Really easy and quite powerful.

Let’s jump back to App.xaml.cs, there should be an empty function called Application_Launching. In this function we’ll need to check if the database exists, open a connection to it if it exists or create it first and then open the connection.

Unfortunately, there is no DataBaseExists() function like in SQLce so I choose to do it the quick and dirty way. I try to get the database, which is basically a file in the ApplicationData, if the file doesn’t exist it will throw a FileNotFoundException and that’s where I call the CreateDB() method.

Line 3 creates the database while line 5 creates the Task table in the database. When all that’s in place, we’re ready to move to the viewmodels.

ViewModel

Not much to say here, we all know what a viewmodel is, so here is the MainViewModel.

The IDataService field is what we’ve defined just a minute ago, it gets instantiated through the constructor. INavigationService comes from the Cimbalino toolkit, it allows us to do page to page navigation from within the viewmodels. There’s a property of IList<Task> that one will hold all the available tasks, they are loaded at startup, also newly added tasks will be put in that list. There’s a property of type Task, his properties will be bound to the input fields on the new task form, when the user clicks save the property will be pushed to the dataservice to save it in the database. Talking about the save button, there are two RelayCommands (MVVM Light’s implementation of ICommand). One is for saving a new property and the second one is for navigating to the detail page when a task is selected. In the constructor both fields are set and the Task property is initialized, setting the date to today. Since our datepicker will be bound to this property it will automatically be set to today’s date. Loading all the tasks needs to be done asynchronous, since the constructor can’t be marked as async we’ll put the service call in a synchronous method and call that one from the constructor, that way we can use the async / await keywords. Saving a task is as easy as calling the SaveTask function on IDataService and adding the new task to the list, and reinitializing it afterwards to clear all the fields. You might want to think about adding some check here in case something goes wrong while saving to the DB (have it return a boolean for example), I’ll just be living on the edge here and assume this never fails . For navigating to the detail page we’ll add a command to the SelectionChanged event of our LongListSelector. We use the MVVM Light messenger, some sort of implementation of the Observer pattern, to send over the selected item to anyone registered to listen to a message of type TaskSelectedMessage. The TaskSelectedMessage class is pretty basic.

The class inherits from MessageBase, which is a class in the MVVM Light library, it has one property that is set in the constructor (that’s just to make life a bit easier).

In the MainViewModel, when the SelectionChanged event fires we send a message of this type containing the selected item, once the message is on its way we use the INavigationService to navigate to the detail page.

Here’s the  viewmodel for the editpage.

The same fields can be found here (I could put them in a base class, would be cleaner but who cares about clean code anyway? – well you should all care!). One property in this viewmodel, to hold the selected task and bind its properties to the view. A few commands for update and delete, they just call their respective functions on the DataService passing in the selected Task. The interesting part here is in the constructor. The fields get set and we register the viewmodel to listen if the messenger has a message of type TaskSelectedMessage, if it does set the task in the message to the property. However, the viewmodel by default gets instantiated when we navigate to the view meaning that the message has left the building before the receiver has registered as a receiver so it won’t arrive. Let’s fix that shall we? When you’ve added the MVVM Light libraries through NuGet (or you used the MVVM Light project templates) there should be a ViewModelLocator class in your ViewModel folder. This class registers your viewmodels in the TinyIoc container. Registering those viewmodels has an overload that, when set to True, creates an instance of each viewmodel at application launch, meaning that the viewmodels register themselves on the messenger before any message can be send. Here are my viewmodel registrations (from the ViewModelLocator constructor).

MainViewModel won’t get instantiated at registration but EditViewModel will. So that’s a problem solved. Next piece of the puzzle are those constructor parameters in the viewmodels. They get resolved by dependency injection, we register the correct types here in the ViewModelLocator and when the viewmodel constructor is called, the correct instances will get injected automagically.

Take this for example, when we are in design mode (Blend for example) we can load an IDataService implementation that returns dummy data so that we can style our views very easily (code gets executed when running at designtime so even when you’re not using dummy data it’s a good idea to register these types in an if-block to prevent design time errors).

What everything in place, let’s have a look at the xaml and hook everything up. We’ll start with the MainPage.xaml and since XAML has a tendency of growing quite large, I’ll chop it in pieces. First thing a page needs in an MVVM scenario is a DataContext, meaning our ViewModel. This can be set from code behind (DataContext = new MainViewModel()) but that would just null out every use of the ViewModelLocator. We’ll set the datacontext from XAML.

The key here is DataContext="{Binding Main, Source={StaticResource Locator}}" this says to the view that its datacontext is bound to a property called Main and that property lives in a resource called Locator (that resource is defined in App.xaml). Now for the page itself, the page consists of a pivot control with two pivot pages, one for entering new tasks and one for viewing a list of all the tasks that have been created so far.

First thing in this snippet is a behavior for a bindable appbar button. The default appbar is not bindable, meaning that you can’t bind the buttons Command property to an ICommand on your viewmodel. This wasn’t the case in WP7 and it still isn’t in WP8, bit of a pain. Luckily, Cimbalino toolkit gives us an ApplicationBarBehavior, allowing us to bind our ICommands to the appbar, the only trade off we need to make is that the appbar buttons won’t be visible at design time but that’s a small trade-off in my opinion. We’ll add one button in the appbar, bind it to the SaveNewTaskCommand RelayCommand in MainViewModel and appoint it the save icon. Then there’s the pivot control, first pivotitem contains a stackpanel with a textbox for entering a task title and a datepicker (courtesy of the Windows Phone Toolkit) both are bound to properties of the NewTask property on the MainViewModel. Don’t forget to set the bind mode to TwoWay so that we can update the properties from our view. The second pivot item contains a list of all the tasks. Now, in WP8 they advice us to use the LongListSelector instead of the listbox that’s all great but at least make it behave more like a listbox and not some crippled dependency property missing piece of ****. The problem lies in the SelectedItem property, myself and many other XAML devs usually create a SelectedTask property and bind it to the SelectedItem property of the ListBox, the setter of that SelectedTask property would then be used to navigate to the detailspage. That was a clean, fast solution but the LongListSelector’s SelectedItem property is not a dependency property, meaning it cannot be bound so that’s not a viable solution anymore. Second option would be to bind an ICommand to the SelectionChanged event, again a no-go. There are some implementations of the LongListSelector floating around on the internet that has a bindable SelectedItem property so that would be a solution, another one is to add an EventToCommand behavior and binding the SelectionChanged event to the MainViewModel in the behavior (that’s right Windows 8 devs, we Windows Phone devs still get behaviors out of the box). I’m going with the EventToCommand solution, only thing I haven’t solved here is that when we navigate to the detail page, navigate back to the mainpage and click the same task again it won’t do anything anymore since that item still is the selected item so the selection doesn’t change and the event doesn’t fire. A solution here would be to use the messenger to send a message to the code behind of the view to set the SelectedItem property of the LongListSelector to null.

tl;dr version: LongListSelector kind off sucks but it can be solved.

The LongListSelector is bound to the Tasks collection, the ItemTemplate is defined in the resources part of the page

That gives the list a nice look (as far as I can tell that is, I really really suck at designing apps…)

Last part on this page is the appbar itself, the button are defined using the Cimbalino toolkit but we need to actually put an appbar on the page, this sits between the resources and the LayoutRoot grid.

And that’s it for the MainPage, on to the final part of this post, the EditPage.xaml

First, the datacontext

Then the appbar buttons, again using Cimbalino (these need to sit in the LayoutRoot grid)

And then there’s the controls

That’s all pretty much the same as in the MainPage. And with that our small SQLite POC is finished.

Conclusion

In this post I’ve discussed SQLite in a Windows Phone 8 app. What you should take away from this is that as of Windows Phone 8 SQLite is a first class citizen, even more so when using the excellent sqlite-net library. Don’t forget to switch the platform when running on emulator or on a device, this is necessary because SQLite is a C++ library. I’ve also talked a bit about MVVM Light and the way I use it, I don’t claim that this is the best / only way to use the excellent MVVM implementation by Laurent Bugnion but it is one I feel comfortable with and that gives me great results. If you have any questions / remarks, feel free to drop a comment!

UPDATE:

for the LongListSelector, you can also use an extension of the control instead of defining a trigger, see http://stackoverflow.com/questions/14586521/bind-viewmodel-to-item-from-longlistselector-in-datatemplate/14600157#14600157 for more detail.
thanks for the tip Glenn (link to Glenn’s Twitter)!

Some time ago Nokia launched a pretty impressive, almost magical app called “Photobeamer” (exclusive for the Nokia Lumia range). This is one of those apps that look very impressive and magical at first but when you start to think about it it’s not really that hard to figure out how this works. I thought about it and decided to hack together a copy of this.

If you have no clue what Photobeamer is all about, check out this video from Pocketnow

Disclaimer

Small remark about this video before we get started. The Nokia Photobeamer caches every image for about 30 days, meaning that if you select the same picture again it appears almost instantly, that’s what happens in this video. We will get nowhere near that performance since my concept here doesn’t do any caching. Also, they are streaming the image to the server (hence the fact that the picture is blurry at first and sharpens up later) we will just send over the entire image at once.

Puzzle pieces

All right, let’s get started. We need a few pieces to complete this puzzle. We need a Windows Phone app, we’ll need a service that takes care of sending the right picture to the right client and we’ll need a web client to display the QR code and the picture.

This schematic shows the pieces and their roles

The steps are:

• webclient generates unique ID (guid)
• webclient registers a group on the server with that ID
• webclients uses ID to generate QR code
• user launches Windows Phone app
• user selects picture
• user scans QR code to get the generated ID
• phone app joins the group with the ID
• phone app deserializes the picture
• phone app sends the picture to the other group members
• webclient receives picture, serializes it again and shows it

Lots of steps but it’s easier to build as you might think. We’ll start with the service as that’s the glue to hold everything together.

SignalR

Since we need some form of real-time communication I’ve decided to use SignalR. A snippet from the SignalR page that describes its functionality (http://signalr.net/):

ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is "real-time web" functionality? It's the ability to have your server-side code push content to the connected clients as it happens, in real-time.

You may have heard of WebSockets, a new HTML5 API that enables bi-directional communication between the browser and server. SignalR will use WebSockets under the covers when it's available, and gracefully fallback to other techniques and technologies when it isn't, while your application code stays the same.

All we need to get started is an empty web project and a nuget package use the package manager or the GUI

SignalR, at the time of writing, is in Release Candidate, so we need to include prerelease versions in Nuget or you won’t find signalR at all. (although it’s prerelease, SignalR is working really well so no worries)

Before we start building the service we need to add some method calls in Global.asax.cs in the Application_Start method.

The MapHubs() makes sure that the service calls are rerouted to the correct functions. The EnableAutoRejoiningGroups() is something that we need to do in this RC2 version but it will go away in RTM, see my StackOverflow question for more information.

SignalR uses the concept of Hubs, a hub is a class that contains all the service calls. Add a class called ImgHub to a folder called Hubs in the empty web project.

That’s really not a lot of code for a service. First, every hub in a SignalR project needs to inherit from Microsoft.AspNet.SignalR.Hub. Next to that, every public method we declare in this class will be callable from the clients. First method is Create(), this takes in the unique ID that will be generated by the webclient in a minute. That ID is used to create a group. SignalR tries to add the connectionId from the client to a group with the guid as groupname. If that group doesn’t exist yet it will create it. The second method is ShareImage. This will take in the deserialized image (as a byte array) and that same guid again. Now we need to send that byte array to other clients so we call Clients.OthersInGroup, other options are Clients.All, Clients.Groups, Clients.Others, Clients.Caller, Clients.AllExcept. Plenty of choices but OthersInGroup suits our needs the best. The OthersInGroup returns a dynamic object, we can attach anything we want here. We want to call ReceiveImage() on the client, that method isn’t declared anywhere but since the object is dynamic the compiler won’t give us any trouble. And finally there’s a Leave() method allowing us to leave a group should it be needed.

The SignalR project can be hosted on any webhost that supports .net, for this demo I’ve used Windows Azure Websites.

Webclient

1/3th done, the second part is the webclient. This is a normal website using asp.net webforms. It’s responsible for generating the ID, passing it to SignalR to create the group, get a QR code and receive the image.

First thing we need is the project, second is a SignalR client and the SignalR Javascript library (yes we’ll be needing Javascript and no I’m not proud of this…)

First some HTML code, the Default.aspx page is nothing fancy, it will only show the QR code.

Notice the imagehandler.ashx reference? That’s a generic handler that will take care of generating the QR code and passing it into this img tag. Generic handler is a file type that you can add through Visual Studio, here’s the code for imagehandler.ashx.

We’re getting our guid from the session object (how it got there, we’ll see in a minute) that’s why we need the IRequiresSessionState interface. The ProcessRequest method we get from IHttpHandler and will get executed when the handler is called. So we first get the guid from the session, then we’ll build a url to qpi.qrserver.com, an api that takes in a value and generates a QR code from that value. We use WebClient to get the data from that url, the byte array that we receive from it will be our generated QR code, we write it to the outputstream of the page’s context and set the type to be an image/JPEG. There should be some error handling here if you’re using this for production code (sometimes the qrserver API takes to long and times out).

Next, we’ll have a look at Default.aspx.cs.

Not much going on, we generate a new Guid and set it to the current session object.

Now, let’s have a look at connection the webclient to the signalR server and getting ready to receive the image.

Warning: the next part contains javascript code…

In Default.aspx we add this script

First, we need to add jquery and the SignalR javascript library to our page. The third included script comes from wherever you host your SignalR service. The /signalr/hubs/ will be a proxy in javascript that contains the methods in the hub, allowing us to use them from our clients (try browsing to that url and have a look inside the javascript). $.connection comes from the SignalR javascript library, we set the correct url and get the correct hub. We’ll also use a bit of inline asp.net to get the guid from the session. Remember in the SignalR part that we called ReceiveImage on the dynamic object? Line 13 is where we declare a callback handler on that method call. We set the received value, which will be a byte array, to a hidden field and POST the form. Those handlers need to be set before we call the start() method on the hub. <yourhub>.client is where all your client side callbacks are registered. <yourhub>.server is where all server side methods can be called, those methods are loaded from the /signalr/hubs/ proxy. On line 20 we start the connection to the hub, once we’re connected we’ll call the create method and pass the guid in to create and join the group.

We’ll need a second page in this webclient to actually show the image. Only one element on the page, an img element.

The img element uses a second generic handler that will take care of deserializing the byte array back into an image.

We’ll get the byte array from the session object. SignalR encodes arrays with Base64 encoding so we need to decode that first, once that’s done we can just write the byte array into the outputstream as a JPEG, just like we did with the QR code. Onto the ImagePage.aspx.cs to see how the byte array goes into the session object

We get our POST values from Request.Form, look for the hidden field called hiddenByteArray and place its value in the session.

We now have our service and one client complete, all that’s left is building a Windows Phone application that connects to that same group on that same service and send the picture over.

Windows Phone client

For this we’ll need a Windows Phone 8 project as SignalR has no official support for Windows Phone 7. Make sure that you have the latest version of Nuget installed or it won’t find the correct SignalR assembly for Windows Phone 8 (thanks David Fowler for pointing this out).

Add the SignalR.Client assembly to the project. Here’s the XAML for the MainPage.

I use one of the default textboxes in the page’s header for a connection status. In the content grid we place a rectangle filled with a VideoBrush, this will be used to scan the QR code, Let’s have a look at the code for the WP app.

First we declare some fields

I’ll explain these when we encounter them. Now for the page’s constructor

First we initialize a PhotoCamera instance. _previewVideo is the VideoBrush set in the rectangle, we set its source to the PhotoCamera instance. On line 8 we state that when the hardware camera button is half pressed we focus the camera, just a small helper for when the app has troubles reading the QR code. The next part is calling the PhotoChooserTask, this task gives us access to the albums and pictures on the device. We’ll need a timer as well, every timer tick we’ll check if the camera preview window contains a QR code. We’ve declared some event handlers in this constructor, let’s go over them one by one. We’ll start with the OnPhotoCameraInitialized.

We get the resolution’s width and height and turn the flash off. The PhotoCameraLuminanceSource on line 7 is a custom class that will provide us with a previewbuffer that we can fill. Here’s the class

The class inherits from LuminanceSource which comes from the Google zxing project. Zxing is a library to decode QR and barcode images, it has a .NET port on codeplex (http://zxingnet.codeplex.com/) that port is what I use in this project and that’s where the LuminanceSource comes from. That’s also where the QRCodeReader class lives.

Next event handler that we attached in the constructor is the photoChooserTask_Completed

If the task returns succesfully we’ll set the chosen photo, which arrives here as a stream, to the _imgStream field and we start the timer. Now on every timer tick (every 250 milliseconds in this example) we will scan the previewbuffer for QR codes.

First thing we do here is checking if we already have a guid, if we do we stop the timer and send the image to the SignalR service. If _guid is still null we’ll get the previewbuffer and try to decode it, if there’s no QR code in the previewbuffer it will throw an exception, hence the empty catch block. When we can decode  we’ll go to the SendImage() method.

If there’s no active connection, we’ll call the SetupSignalRConnection() method. if there is and we are connected we copy the imagestream into a MemoryStream and we invoke the ShareImage() method on the SignalR server, passing in the memorystream, converted into a byte array, and the guid we got from the qr code.

Now for the connection to the server.

We instantiate a new HubConnection with the url to the service as parameter. We generate a proxy for the hub we want to use and we call the start() method on the connection. It will connect to the hub, get the javascript proxy and translate it into a .net proxy. We then invoke the Create() method and pass in the guid so that our Windows Phone client joins the same group as the web client. The ConnectionOnStateChanged event handler is only used to update the textblock on the page to show whether or not we’re connected.

And that’s it, we can now start sending images to any device with a browser and an internet connection.

Conclusion

In this post I’ve tried to demystify the magic from Nokia’s Photobeamer app. It is a really cool app but when you take it apart, it’s not that magical. Like a lot of impressive looking tech it just combines a bunch of existing techs into something no one else thought of.

The code in this article is all my own, I have no clue how the Nokia app actually works and what technology they are using, I’m only mimicking their behavior.

Update: I've uploaded the project to Github https://github.com/NicoVermeir/photobeamerclone

Imagine this, you’re somewhere you’ve never been before and you need your phone to navigate you home but you need a quick getaway and don’t have time to enter the address manually. Or you’re taking the boy/girl of your dreams home after a great date and want to impress them with some technological stuff (because geeks are the new sexy). In both scenarios NFC can come to the rescue. In this article I’m going to explain how you can program an NFC tag to launch your navigation app and navigate you home. (NOTE: this has been tested on a Nokia Lumia 920 with Nokia Drive).

First, the prerequisites. We need an NFC capable Windows Phone 8 device with navigation software. We also need a blank, NDEF formatted, writable NFC tag (I got mine from RapidNFC). We’ll also need a dataconnection to fetch our coordinates (only for writing the NFC tag).

Next, the pieces of the puzzle. In this case there are three things that need to be taken care of. First we need to be able to enter an address in an app and get the longitude/latitude coordinates for that address. Second, we need to write the instruction for launching the navigations app and navigating to those coordinates to an NFC tag and third we need our phone to actually launch the app and navigate to the received coordinates. Now to make that last part work we only need to make sure we have an NFC capable phone, have NFC enabled in Settings and that we have navigational software installed.

Enough planning, let’s get to work. First the UI, I‘m going with two TextBlocks, one to enter the address and one that will show the coordinates just to see if that worked. I also need two buttons, one for fetching the coordinates and one for writing the NFC tag. Here’s the XAML

With this as the final result

How this works, we enter an address in the top TextBox and click the “Get Coordinates” button. This will use the Microsoft.Phone.Maps functionality to translate that address into coordinates, those coordinates will show up in the bottom TextBox. When we click the “Write NFC tag” button the app will wait for a writable NFC tag, once that’s detected the data will be written on it. All it takes then is a tap on the tag and the phone will take you home.

Before we dive into code we need to add some capabilities. Using the Maps namespace and using NFC requires two capabilities, double-click the WMAppManifest.xml file and select these capabilities.

This will keep us away from any UnauthorizedExceptions.

On to the code we go, we’ll start with declaring some private fields.

After that, we go to the “Get Coordinates” button.

First thing we need to do is verify if an address was actually entered in the TextBlock. When that’s verified we declare a GeocodeQuery and initialize it with a new GeoCoordinate and pass the address as a SearchTerm. When the query completes we check if there’s a result. The query should return a result of type IList<MapLocation> the first element in the list is the one we need, and from this first item we need the GeoCoordinate property, we’ll put that one in the _coordinate field. We call the QueryAsync() method on GeocodeQuery to get the result. For some reason QueryAsync returns void, meaning we can’t just await it. We need to do this the oldschool way and use the QueryCompleted event handler.

With that, the first part of our puzzle is solved. We can go from an address to a coordinate. Now we just need a way to get this coordinate and the navigation app launch instruction onto an NFC tag. Let’s have a look at what happens when the “Write NFC tag” button is clicked.

There’s some NFC magic going on here. First we instantiate a ProximityDevice instance and activate the proximity provider. If, at that point, _device is null it means that the Windows Phone device either has no NFC capabilities or they are disabled in Settings > Tap & Send. If _device is not null we have successfully initialized NFC. Line 13 is a bit special. We call the SubscribeForMessage() method on the ProximityDevice. What happens is, when the NFC provider reads a tag it sends a message, we subscribe to the “WritableTag” message because it’s the only thing we can use in this case. If you want a complete list of all supported message types, have a look at MSDN.Since the subscription doesn’t live on the UI thread we need to use the Dispatcher in order to update the TextBlock that hold the status. The WriteTag() method gets called when a writable NFC tag is detected.

This method is the piece of magic that glues all pieces together. We start by setting the Uri that will launch when the tag is tapped. “ms-drive-to” means we need whatever app is registered to the drive-to command (you can also get walking directions by using “ms-walk-to”) the rest of the string are parameters we’re passing into that app. We are passing the coordinates into the app, passing those in means that the app knows we want to navigate and where we want to go. We also need a DataWriter with Utf16LE encoding (this is the encoding needed for writing uri messages to NFC tags). We fill the buffer of the DataWriter with the uri string we’ve constructed a second ago and we publish it through the ProximityDevice as a binary message. The PublishBinaryMessage() method takes in a messagetype and an implementation of IBuffer, provided by the DataWriter in this case. In an overload the method also takes a method that fires when the publish is completed, we use this event handler to update our UI.

That’s all folks, with a bit of tinkering we’ve combined two possibilities of the Windows Phone 8 platform in a very cool, almost “magical” trick. I've got my NFC sticker in my car, impressing people wherever I go and now you can all be as cool as I am you’re welcome.

To finish of, some action shots of the app.

Coordinates detected

Tapped a programmed tag

Navigation started

Today I did my second MSDN webcast, this time about the brand new Windows Phone 8 SDK. I had great fun doing this, I knew what to expect so I went in relaxed and just enjoyed it. This time even the audio and recording went fine (had no sound for the first five minute last time). The recording is being edited the coming days and should be on Channel9 somewhere next week I think, I’ll update this post when it’s online.

Until then, my demos can be found on SkyDrive and my slides are on SlideShare.

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