Background

As discussed before, Windows Phone Mango brought the socket support to Windows Phone app developers. Unfortunately  the platform doesn’t provide secure sockets (SSL socket) out of the box. Many applications nowadays require SSL socket and for example many IRC servers only allow secure socket connections.

Solution

Fortunately it is possible to get the SSL Socket support to Windows Phone with the help of an excellent OSS library “Bouncy Castle”. Bouncy Castle isn’t officially available for the Windows Phone but it’s possible to modify the code so that required parts for the SSL Socket support are available.

I have modified the code and packaged it with the SocketEx –library I blogged about a little while ago. Here’s an example of how to open a SSL Socket using the SocketEx:

        private SecureTcpClient CreateConnection()
        {
            var connection = new SecureTcpClient(serverAddress, serverPort);

            return connection;
        }

The SecureTcpClient inherits from the TcpClient so you should be able to just replace the TcpClient where needed.

Advanced usage

The SecureTcpClient works as wrapper around the TcpClient and Bouncy Castle. If more control is needed, you can create a normal connection through TcpClient and then “elevate” it to secure:

            var connection = new TcpClient("server", 443);

            var handler = new TlsProtocolHandler(connection.GetStream());
            handler.Connect(new LegacyTlsClient(new AlwaysValidVerifyer()));

This way it’s possible to for example to add some validation to the certificate the server sends. Other option is to provide the TlsClient to the SecureSockectConnection:

            var tlsClient = new LegacyTlsClient(new AlwaysValidVerifyer());
            var connection = new SecureTcpClient(serverAddress, serverPort, tlsClient);

Supported protocols

SecureTcpClient supports the TLS 1.0 (“SSL 3.1”) protocol. The following cipher suits are supported:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

The client supports the simple TLS handshake where the server but not the client is authenticated. With some work it should be possible to get the SSL 3.0 support to Bouncy Castle, but TLS should be enough in most of the situations.

Sample and source code

The source code for SocketEx is available from GitHub. It comes with two examples: One for TcpClient and one for SecureTcpClient.

NuGet

SocketEx.SecureTcpClient is also available from NuGet as a package SocketEx.SSL.

As introduced last week, Wensus is a Windows Phone analytics service for the Windows Phone app developers. Here’s some more screenshots from the data the service provides:

Error details:

Full list of reviews with a search:

Beta testing:

As previously mentioned, Wensus is currently in private beta testing. If you would like to join the beta, just send an email.

Link: www.wensus.com

Wensus is a Windows Phone Analytics service for the Windows Phone application developers. It’s not just some generic analytics service but a service aimed 100% for the Windows Phone developers.

Here’s some screenshots from just few of the data points that Wensus provides:

Application usage data

User reviews

Crash reports

And a daily email which summarizes this and much more. The data is always up-to-date, so you can track your app's success without having to wait days for the latest data.

Wensus is currently in private beta testing. We would be happy to get your feedback, so if you’re interested, send us an email and we’ll provide you instructions on how to join the beta.

TcpClient is a class in .NET Framework which “provides simple methods for connecting, sending, and receiving stream data over a network”. TcpClient hides the details of working with sockets and it’s a simple way to open connections and work with TCP. Unfortunately, TcpClient is not available in Windows Phone version of .NET Framework.

SocketEx.TcpClient – Unofficial, only little tested TcpClient for Windows Phone

SocketEx.TcpClient is a MIT-licensed TcpClient for Windows Phone which aims to make working with Windows Phone sockets easy. Compared to the TcpClient in full .NET Framework, SocketEx.TcpClient isn’t 100% compatible and some of the features aren’t implemented at all.

Please note that the library works in a synchronous blocking mode. This means that if you use the TcpClient directly from the UI-thread, you will block the UI from updating.

The library hasn’t gone through an exhaustive testing so there may be issues. The code is based on the “Crystalbyte Networking for Silverlight” project, available from the CodePlex. Almost all of the code is from that neat library, but I adjusted it a little to get it working with Windows Phone and fixed out some threading issues.

The usage

With SocketEx.TcpClient you don’t work with the low-level Socket and SocketAsyncEventArgs-classes. Instead you create a new TcpClient and then operate its stream using either a StreamReader or a StreamWriter. This is easier than it sounds.

I’ve previously written about how to operate with the built-in Socket and SocketAsyncEventArgs classes.

• Windows Phone Sockets: How To open a Connection
• Windows Phone Sockets: How to receive a message
• Windows Phone Sockets: How to send a message

Now, let’s do those same examples with SocketEx.TcpClient.

SocketEx.TcpClient – How To Open a Connection

We can open the connection by passing the server address and server port as parameters to TcpClient.

            var serverAddress = "www.google.fi";
            var serverPort = 80;

            var connection = new TcpClient(serverAddress, serverPort);

SocketEx.TcpClient – How To Receive a Message

To read a message we need a StreamReader.

            var connection = CreateConnection();
            var stream = connection.GetStream();

            var reader = new StreamReader(stream);

            string message;
            while ((message = reader.ReadLine()) != null)
            {
                Debug.WriteLine(message);
            }

SocketEx.TcpClient – How To Send a Message

To write a message we need a StreamWriter.

            var connection = CreateConnection();
            var stream = connection.GetStream();

            using (var writer = new StreamWriter(stream))
            {
                var request = "GET / HTTP/1.1rnHost: " + serverAddress + "rnConnection: Closernrn";

                writer.WriteLine(request);
            }

Project’s home and sample app

The SocketEx.TcpClient lives in GitHub. The repository contains the TcpClient and a sample app which uses it.

Nuget

Easiest way to get started with SocketEx is to use NuGet. The package name is SocketEx.

Binary

The binary version of SocketEx is available for download from GitHub.

Continuing our exploration of doing navigation in a WinRT XAML Metro-app, there’s one more crucial difference when the page navigation in WinRT is compared to the Windows Phone 7’s page navigation: The navigation cache. In the WP7 world, the page’s life time can be summarized with these three bullets (thanks to Peter Torr):

• Forward navigation always creates a new instance
• Pages that are removed from the back stack are released
• Pages on the back stack are always cached

Contrast this with the WinRT-world where, by default, a new instance of a page is always created. This means that even when you’re navigating back, a new page instance is created.

Testing navigation cache

We can test the navigation cache by using the “Grid Application” template which comes with the Visual Studio 11. Let’s create a new app based on it. The app contains three pages:

• ItemDetailsPage
• GroupedItemsPage
• GroupDetailsPage

Of which the GroupedItemsPage is the landing page of the app. Let’s modify that page’s constructor to write some debug info and then run the app. When navigating forward to GroupDetailsPage and then back, this is the output:

Two instances of the same page has been created: One when navigating forward to this page and one when we navigated back to the same page. This is a big difference when compared to the WP7-platform where navigating back always uses the same instance of a page.

Adjusting page cache: NavigationCacheMode

Fortunately we’re able to modify this functionality. Every page has a property called NavigationCacheMode which can be used to change how the navigation caching works on that particular page. The NavigationCacheMode has three possible values. From MSDN:

Also the Frame-object, which handles navigation for us, has a property called CacheSize which “Gets or sets the number of pages in the navigation history that can be cached for the frame.”

Testing navigation cache: NavigationCacheMode.Required

Let’s modify GroupedItemsPage so that we set it’s cache mode to “Required”:

<common:LayoutAwarePage
    x:Name="pageRoot"
    x:Class="Application8.GroupedItemsPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:Application8"
    xmlns:data="using:Application8.Data"
    xmlns:common="using:Application8.Common"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    NavigationCacheMode="Required"
    mc:Ignorable="d">

And then let’s re-run our previous test. This time only one instance of the page is created:

But what happens if we modify the GroupDetailsPage’s (the page where we navigate to) cache mode to Required? After navigating two times forward to the page, we can see that only one instance was created:

This means that NavigationCacheMode affects both navigating backward and navigating forward.

How to mimic Windows Phone 7 navigation model

Is it possible to completely mimic the Windows Phone 7 navigation model? I’m not sure at this point. It could be possible if the platform had support for removing a page from it’s navigation history (similar to NavigationService.RemoveBackEntry). Maybe using this functionality in combination with the NavigationCacheMode-property could provide a similar navigation model.

The navigation cache is also an interesting aspect to think of when using the MVVM pattern. With WP7 platform we’ve used to think only about VM’s life time (singleton vs. per request) but with navigation cache we can also tweak the page’s life time. This may open up new opportunities.