Dan Wahlin's WebLog

Pros and Cons of the Sprint Instinct Phone

2008-06-26T20:03:00Z

There’s been a lot of hype over Apple’s new iPhone 3G coming out on July 11th as well as Sprint’s recently released Instinct phone. I was originally going to switch over to AT&T and get the iPhone but it meant switching my wife over as well since we need to be able to call each other without using plan minutes. After evaluating the cost of switching carriers we decided it wasn’t worth it since we’d have to pay $400 to get out of our Sprint contracts and my wife recently bought the PPC-6800 Windows Mobile phone which wasn’t cheap. We’ve been very happy with Sprint’s network in our area as well.

Before getting the Instinct I had a PPC-6700 so I had to choose between going away from a Windows Mobile phone to a totally different type of touch screen phone that wasn’t based on Windows. With a Windows Mobile phone you have full control over just about anything you want which is nice if you’re a power user. But, the flexibility does come at a price. I also had the problem of not being able to answer calls on occasion, having to reboot almost daily, poor battery life, plus a few others. Truth be told, I really liked my Windows Mobile phone overall and would buy another one. But, after thinking things through more I came to the conclusion that I mainly used my PPC-6700 for calls, text messaging and the Web and that all of the other bells and whistles were rarely used. I decided to give the Instinct a try since I really liked the touch screen when I tried out the demo version at the Sprint store and liked some of the features it had such as built-in GPS and streaming TV/radio support.

Here’s what I really like about the Sprint Instinct:

Visual Voice Mail – I’ve always hated skipping through message after message to get to the one I wanted to listen to. Visual voice mail lets me see my messages just like emails, rewind and fast-forward messages just by sliding my finger on the screen, and deleting messages that I know I don’t need to listen to quickly and easily.
GPS Navigation – The Instinct has great GPS navigation capabilities. 2-D and 3-D views are available, voice navigation (which includes announcing street names), directions, etc.
Nice Form Factor – The Instinct fits into my hands much better than the PPC-6700 I had before and is really light…yet feels solid. I suspect those with a Motorola Q or similar models won’t notice that much of a difference, but coming from a “brick” it’s really nice.
Great Touch Screen – The touch screen on the Instinct is really, really nice. It’s much better than I was expecting and provides “haptic” feedback. Basically you get a little vibration each time you click something successfully on the screen. Very nice!
Fast Download Speeds – From what I’ve heard, Sprint’s EV-DO Rev A network hasn’t officially been turned on yet (last I heard that would happen in July sometime) but the download speeds have been really good. Good enough that I can stream music or TV from home using Orb quite easily (if you’re going to use Orb with Instinct check out this post).
POP/IMAP Email Access – Some of the early reviews I saw said that you could only integrate with Web-based email accounts like Hotmail or GMail. That’s not true at all. I’m able to successfully access POP or IMAP email accounts easily and get nice notifications when an email arrives.
Speech to Action – Need to find a gas station or restaurant that’s close to where you are? Want to call or text someone? The Instinct has integrated “speech to action” features that integrate with Live Search, the phone, text messaging, etc. Say the business name you want and instantly get access to directions, maps, etc. (assuming it can find the place of course). The voice recognition doesn’t require training and has worked well for me so far. It can be trained for additional accuracy too through the settings dialog.
Traffic – I carpool to downtown Phoenix now so I’m not as worried about traffic as I used to be, but the Instinct’s GPS features also allow traffic information to be viewed including accidents, average freeway speeds, etc. Haven’t used that feature a ton but did try it out twice and it seemed fairly accurate.
Fast Access to News/Sports/Weather – The Instinct provides nice news and weather viewers to get information about all kinds of things. Radar maps are also available for the weather.
Solid Bluetooth Support – My PPC-6700 had Bluetooth support but I had to turn it off and on each time I got in my truck so that it would properly sync. The Instinct’s Bluetooth support is much, much better. It syncs perfectly every time with my system and can also be used with stereo Bluetooth headphones (which I don’t have…so I don’t know how well that feature works).
TV/Radio - I don’t watch TV much, but the Instinct makes it easy to watch a wide variety of TV shows on the device and provides many radio stations as well. The quality of the streamed music has been great even while driving. I listened to a station while driving for about 30 minutes last night with only a few hiccups. As mentioned earlier, I use Orb to stream TV or music from my home PC to my Instinct as well…I highly recommend Orb. All of this should get even better once the EV-DO Rev A network hits the airwaves.
Java Based – Because the Instinct uses Java behind the scenes a lot of custom apps and games can be run on it. There are precious few applications out there right now for the Instinct (although I have found some games that work fine). Sprint is running a developer contest so I suspect we’ll see a flood of apps coming out soon. I’m a Microsoft .NET developer but since there are a ton of mobile Java applications out there I’m guessing many will be ported to the Instinct. Time to brush up on my Java some.
SD Card – Music and other items can be stored on an SD card (up to 8gig).
Battery Life – For people that don’t have Windows Mobile phones this probably won’t be a big deal. My PPC-6700 had horrible battery life though so it’s nice to have a phone that lasts a long time even when watching TV or streaming music.

Here’s what I don’t love about the phone:

Internet Browser – The Internet browser built-into the Instinct works fine for many sites and provides a way to zoom in and out and easily scroll down to different parts of a site. However, it’s nothing compared to the Opera Mini browser. Unfortunately, the Opera Mini browser doesn’t currently work on the Instinct. I suspect it will in the future given all of the interest in the device but we’ll have to wait and see. The built-in browser can only be viewed in landscape mode which is annoying at times as well.
Load Issue (minor issue) – The phone normally boots up really fast when I turn it all the way off. However, there have been 2 times where the load screen sat there for 5+ minutes. After some time it loads fine, but it’s annoying when it has the temporary hang.
Ring tones – I always use custom MP3 ring tones and although the Instinct includes some nice ones, there’s no built-in way to add your own custom ring tones. However, you can go to http://www.myxer.com and take care of that quite easily. Myxer provides a simple way to upload a music file (or wallpaper), adjust which parts you want to be your ring tone and then download it on your phone. Read more about making custom ring tones here.
No Voice Recording – I like to write and record music in my spare time and frequently used a program on my PPC-6700 to record song ideas I had so that I didn’t forget them. I haven’t found a way to do voice recording on the Instinct yet although it certainly has the technology in place. Time to write an application that can do that I guess.
TV/Radio Doesn’t Stream Sometimes – I mentioned earlier that I really like the TV and radio support built-into the Instinct. On a few occasions I would try to watch a TV show or stream a radio station and get nothing. I suspect it was a network issue at the time or something along those lines. The TV/radio features seem to work great overall though.
No Themes/Skins – The Instinct only comes with 1 theme which can’t be changed at this point. I’m surprised they didn’t offer several themes/skins. If someone wants a more iPhone looking interface then that should certainly be possible (I do like the overall interface of the iPhone much better….seems cleaner). I’m hoping that Sprint or a 3rd party company will release different themes that can be used on the phone.

I have 30 days to try out the Instinct and if I don’t end up liking it I’ll turn it in for a PPC-6800. However, at this point I’m really happy with it and although there are a few annoyances (what product doesn’t have them though?) I’m planning on keeping it at this point. For a first version device they did an amazing job and I think Sprint has a winner on their hands. It’s no iPhone killer in my opinion having played with some friends’ iPhones in the past, but once they make a better browser available it’ll definitely blur the lines between the two devices.

Already on Twitter and interested in getting live updates about blog posts and other information? Subscribe to my Twitter feed at http://www.twitter.com/DanWahlin.

Pushing Data to a Silverlight Client with a WCF Duplex Service – Part II

2008-06-19T21:34:21Z

In Part 1 of this series on pushing data to a Silverlight client with a WCF polling duplex service I demonstrated how service contracts and operations can be defined on the server. WCF has built-in support for duplex communication (two-way communication between a service and a client) but does require a reference to System.ServiceModel.PollingDuplex.dll to make it work with Silverlight. This assembly is provided in the Silverlight SDK and is currently in “evaluation” mode (the Silverlight go-live license doesn’t apply to it). With the polling duplex model the Silverlight client does poll the service to check if any messages are queued so it’s not as “pure” as the sockets option available in Silverlight when it comes to pushing data from a server to a client. However, it offers much greater flexibility when compared to sockets since it isn’t limited to a specific port range and works over HTTP.

Let’s take a look at how a Silverlight client can send and receive messages from a polling duplex WCF service and what types of messages are sent between the two.

Understanding Polling Duplex Messages

A polling duplex service communicates with a Silverlight client using WCF Message types. This provides complete control over the data sent between the client and the service and allows communication between the two to be loosely coupled. The downside of this is that messages must be manually serialized/deserialized by the client and service since the WSDL type information uses the xs:any element. Here’s what the service’s WSDL types section looks like (notice the inclusion of the xs:any element) when a service uses the Message type as a parameter for an operation:

<xs:schema elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/Message" xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  xmlns:tns="http://schemas.microsoft.com/Message">
<xs:complexType name="MessageBody">
  <xs:sequence>
    <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"/>
  </xs:sequence>
</xs:complexType>
</xs:schema>

An example of using the WCF Message type in a WCF service is shown next. Details about this code were covered in Part I of this series.

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Threading;

namespace WCFPushService
{
    public class GameStreamService : IGameStreamService
    {
        IGameStreamClient _Client;
        Game _Game = null;
        Timer _Timer = null;
        Random _Random = new Random();

        public GameStreamService()
        {
            _Game = new Game();
        }

        public void GetGameData(Message receivedMessage)
        {

            //Get client callback channel
            _Client = OperationContext.Current.GetCallbackChannel<IGameStreamClient>();

            SendData(_Game.GetTeamData());
            //Start timer which when fired sends updated score information to client
            _Timer = new Timer(new TimerCallback(_Timer_Elapsed), null, 5000, Timeout.Infinite);
        }

        private void _Timer_Elapsed(object data)
        {
            SendData(_Game.GetScoreData());
            int interval = _Random.Next(3000, 7000);
            _Timer.Change(interval, Timeout.Infinite);
        }

        private void SendData(object data)
        {
            Message gameDataMsg = Message.CreateMessage(
                MessageVersion.Soap11,
                "Silverlight/IGameStreamService/ReceiveGameData", data);

            //Send data to the client
            _Client.ReceiveGameData(gameDataMsg);
        }
    }
}

Creating a Silverlight Duplex Polling Receiver Class

Calling and receiving data in Silverlight requires a fair amount of code to be written. Before showing the code to interact with a polling duplex service it’s important to understand the general steps involved. Here’s what you need to do to send and receive data in a Silverlight client:

Reference Assemblies and Namespaces

Reference System.ServiceModel.dll and System.ServiceModel.PollingDuplex.dll in your Silverlight project. Additional details on where to find the System.ServiceModel.PollingDuplex.dll assembly used by Silverlight can be found here.
Import the System.ServiceModel and System.ServiceModel.Channels namespaces.

Create a Factory Object

Create a PollingDuplexHttpBinding object instance and set the PollTimeout and InactivityTimeout properties (both were discussed in Part 1).
Use the PollingDuplexHttpBinding object to build a channel factory.
Open the channel factory and define an asynchronous callback method that is called when the open completes.

Create a Channel Object

Use the factory class to create a channel that points to the service’s HTTP endpoint.
Open the channel and define an asynchronous callback method that is called when the open completes.
Define a callback method that is called when the channel closes.

Send/Receive Messages

Create a Message object and send it asynchronously to the service using the channel object. Define an asynchronous callback method that is called when the send completes.
Start a message receive loop to listen for messages “pushed” from the service and define a callback method that is called when a message is received.
Process data pushed by the server and dispatch it to the Silverlight user interface for display.

Now that you’ve seen the fundamental steps, let’s take a look at the code that makes this process work. The following code shows a class named PushDataReceiver that encapsulates the factory and channel classes and handles all of the asynchronous operations that occur. The class allows an object of type IProcessor to be passed into it along with a service URL, service action and initial data to send to the service (if any). The IProcessor object represents the actual Silverlight Page class used to update data on the user interface in this case. As data is received the Page class’s ProcessData() method will be called.

using System;
using System.Net;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Threading;
using System.IO;
using System.Xml.Serialization;

namespace SilverlightPushClient
{
    public interface IProcessor
    {
        void ProcessData(object receivedData);
    }

    public class PushDataReceiver
    {
        SynchronizationContext _UiThread = null;
        public IProcessor Client { get; set; }
        public string ServiceUrl { get; set; }
        public string Action { get; set; }
        public string ActionData { get; set; }

        public PushDataReceiver(IProcessor client, string url, string action, string actionData)
        {
            Client = client;
            ServiceUrl = url;
            Action = action;
            ActionData = actionData;
            _UiThread = SynchronizationContext.Current;
        }

        public void Start()
        {
            // Instantiate the binding and set the time-outs
            PollingDuplexHttpBinding binding = new PollingDuplexHttpBinding()
            {
                PollTimeout = TimeSpan.FromSeconds(10),
                InactivityTimeout = TimeSpan.FromMinutes(1)
            };

            // Instantiate and open channel factory from binding
            IChannelFactory<IDuplexSessionChannel> factory =
                binding.BuildChannelFactory<IDuplexSessionChannel>(new BindingParameterCollection());

            IAsyncResult factoryOpenResult =
                factory.BeginOpen(new AsyncCallback(OnOpenCompleteFactory), factory);
            if (factoryOpenResult.CompletedSynchronously)
            {
                CompleteOpenFactory(factoryOpenResult);
            }
        }

        void OnOpenCompleteFactory(IAsyncResult result)
        {
            if (result.CompletedSynchronously)
                return;
            else
                CompleteOpenFactory(result);
        }

        void CompleteOpenFactory(IAsyncResult result)
        {
            IChannelFactory<IDuplexSessionChannel> factory =
                (IChannelFactory<IDuplexSessionChannel>)result.AsyncState;

            factory.EndOpen(result);

            // The factory is now open. Create and open a channel from the channel factory.
            IDuplexSessionChannel channel =
                factory.CreateChannel(new EndpointAddress(ServiceUrl));

            IAsyncResult channelOpenResult =
                channel.BeginOpen(new AsyncCallback(OnOpenCompleteChannel), channel);
            if (channelOpenResult.CompletedSynchronously)
            {
                CompleteOpenChannel(channelOpenResult);
            }
        }

        void OnOpenCompleteChannel(IAsyncResult result)
        {
            if (result.CompletedSynchronously)
                return;
            else
                CompleteOpenChannel(result);
        }

        void CompleteOpenChannel(IAsyncResult result)
        {
            IDuplexSessionChannel channel = (IDuplexSessionChannel)result.AsyncState;

            channel.EndOpen(result);

            // Channel is now open. Send message
            Message message =
                Message.CreateMessage(channel.GetProperty<MessageVersion>(),
                 Action , ActionData);
            IAsyncResult resultChannel =
                channel.BeginSend(message, new AsyncCallback(OnSend), channel);
            if (resultChannel.CompletedSynchronously)
            {
                CompleteOnSend(resultChannel);
            }

            //Start listening for callbacks from the service
            ReceiveLoop(channel);
        }

        void OnSend(IAsyncResult result)
        {
            if (result.CompletedSynchronously)
                return;
            else
                CompleteOnSend(result);
        }

        void CompleteOnSend(IAsyncResult result)
        {
            IDuplexSessionChannel channel = (IDuplexSessionChannel)result.AsyncState;
            channel.EndSend(result);
        }

        void ReceiveLoop(IDuplexSessionChannel channel)
        {
            // Start listening for callbacks.
            IAsyncResult result = channel.BeginReceive(new AsyncCallback(OnReceiveComplete), channel);
            if (result.CompletedSynchronously) CompleteReceive(result);
        }

        void OnReceiveComplete(IAsyncResult result)
        {
            if (result.CompletedSynchronously)
                return;
            else
                CompleteReceive(result);
        }

        void CompleteReceive(IAsyncResult result)
        {
            //A callback was received so process data
            IDuplexSessionChannel channel = (IDuplexSessionChannel)result.AsyncState;

            try
            {
                Message receivedMessage = channel.EndReceive(result);

                // Show the service response in the UI.
                if (receivedMessage != null)
                {
                    string text = receivedMessage.GetBody<string>();
                    _UiThread.Post(Client.ProcessData, text);
                }

                ReceiveLoop(channel);
            }
            catch (CommunicationObjectFaultedException exp)
            {
                _UiThread.Post(delegate(object msg) { System.Windows.Browser.HtmlPage.Window.Alert(msg.ToString()); }, exp.Message);
            }
        }

        void OnCloseChannel(IAsyncResult result)
        {
            if (result.CompletedSynchronously)
                return;
            else
                CompleteCloseChannel(result);
        }

        void CompleteCloseChannel(IAsyncResult result)
        {
            IDuplexSessionChannel channel = (IDuplexSessionChannel)result.AsyncState;
            channel.EndClose(result);
        }
    }
}

When the PushDataReceiver class’s Start() method is called by Silverlight it creates a channel factory instance which is used to create a channel instance. The CompleteOpenChannel() callback method shown previously then sends an initial message to the service endpoint and encapsulates the data to be sent in a WCF Message object. The message data is then sent along with the proper service action to call on the server. After the initial message is sent a receive loop is started (see the ReceiveLoop() method) which listens for any messages sent from the server to the client and processes them accordingly. Once a message is received the CompleteReceive() method is called and the message data is routed back to the Silverlight Page class.

Processing Data Using the XmlSerializer Class

The PushDataReceiver class shown earlier dispatches data received from the server back to the Silverlight Page class for processing. Data sent from the server is in XML format and multiple techniques can be used to process it in Silverlight ranging from the XmlReader class to LINQ to XML functionality to the XmlSerializer class. I chose to use the XmlSerializer class to process the data since it provides a simple way to map XML data to CLR types with a minimal amount of code. Although you can create the CLR classes that XML data maps to by hand, I chose to create an XSD schema and use .NET’s xsd.exe tool to generate code from the schema for me. The xsd.exe tool provides a simple way to generate C# or VB.NET code and ensures that the XML data will be successfully mapped to the appropriate CLR type’s properties. An example of using the tool is shown next:

xsd.exe /c /namespace:SomeNamespace Teams.xsd

The /c switch tells the tool to generate classes (as opposed to strongly-typed DataSets) while the /namespace switch allows you to control what namespace is added into the auto-generated code. Other switches are available which you can read more about here.

One of the XSD schemas used to generate C# code with xsd.exe is shown next:

<?xml version="1.0" encoding="utf-16"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Teams">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" name="Team">
          <xs:complexType>
            <xs:sequence>
              <xs:element maxOccurs="unbounded" name="Player">
                <xs:complexType>
                  <xs:attribute name="ID" type="xs:string" use="required" />
                  <xs:attribute name="Name" type="xs:string" use="required" />
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute name="Name" type="xs:string" use="required" />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Note: If you use the xsd.exe tool to generate classes that will be used in a Silverlight client you’ll have to remove a few lines that don’t compile from the auto-generated code. The xsd.exe tool generates code designed to run on the full version of the .NET framework but with a few minor modifications you can also use the code with Silverlight. Simply remove the namespaces and attributes that the compiler says are invalid from the auto-generated code.

Once data is received by the Silverlight client from the WCF polling duplex service it’s processed by a method named ProcessData() (the method called by the PushDataReceiver class) in the sample application. ProcessData() uses the XmlSerializer class to deserialize XML data into custom Teams and ScoreData objects (the Teams and ScoreData classes were generated from XSD schemas using the xsd.exe tool mentioned earlier).

public void ProcessData(object receivedData)
{
    StringReader sr = null;
    try
    {
        string data = (string)receivedData;
        sr = new StringReader(data);
        //Get initial team data
        if (_Teams == null && data.Contains("Teams"))
        {
            XmlSerializer xs = new XmlSerializer(typeof(Teams));
            _Teams = (Teams)xs.Deserialize(sr);
            UpdateBoard();
        }

        //Get updated score data
        if (data.Contains("ScoreData"))
        {
            XmlSerializer xs = new XmlSerializer(typeof(ScoreData));
            ScoreData scoreData = (ScoreData)xs.Deserialize(sr);
            //ScoreDataHandler handler = new ScoreDataHandler(UpdateScoreData);
            //this.Dispatcher.BeginInvoke(handler, new object[] { scoreData });
            UpdateScoreData(scoreData);
        }
    }
    catch { }
    finally
    {
        if (sr != null) sr.Close();
    }
}

As team and score data is pushed from the server to the client it’s updated on the Silverlight interface as shown next:

The complete code for the application including the WCF duplex polling service and the Silverlight client can be downloaded here.

Already on Twitter and interested in getting live updates about blog posts and other information? Subscribe to my Twitter feed at http://www.twitter.com/DanWahlin.

Pushing Data to a Silverlight Client with a WCF Duplex Service - Part I

2008-06-16T23:31:00Z

Silverlight provides several different ways to access data stored in remote locations. Data can be pulled from Web Services and RESTful services and even pushed from servers down to clients using sockets (see my previous articles on sockets here, here and here). Silverlight 2 Beta 2 introduces another way to push data from a server to a client using Windows Communication Foundation (WCF) and HTTP. WCF's support for duplex service contracts makes this possible and opens up unique opportunities for pumping data to Silverlight clients. In this first part of a two part series I'll demonstrate how a WCF push service can be created and cover the steps to get a sample service up and running. The second article will focus on the client and show how to communicate with a WCF duplex service and listen for data that's sent.

Many of the WCF services out there follow the simple request-response mechanism to exchange data which works well for many applications. However, in addition to standard HTTP bindings, WCF also supports several others including a polling duplex binding made specifically for Silverlight which allows a service to push data down to a client as the data changes. This type of binding isn't as "pure" as the push model available with sockets since the Silverlight client does poll the server to check for any queued messages, but it provides an efficient way to push data to a client without being restricted to a specific port range. Once a communication channel is opened messages can be sent in either direction. The Silverlight SDK states the following about how communication works between a Silverlight client and a duplex service:

"The Silverlight client periodically polls the service on the network layer, and checks for any new messages that the service wants to send on the callback channel. The service queues all messages sent on the client callback channel and delivers them to the client when the client polls the service."

Creating Contracts

When creating a WCF duplex service for Silverlight, the server creates a standard interface with operations. However, because the server must communicate with the client it also defines a client callback interface. An example of defining a server interface named IGameStreamService that includes a single service operation is shown next:

[ServiceContract(Namespace = "Silverlight", CallbackContract = typeof(IGameStreamClient))]
public interface IGameStreamService
{
    [OperationContract(IsOneWay = true)]
    void GetGameData(Message receivedMessage);
}

This interface is a little different from the standard WCF interfaces you may have seen or created. First, it includes a CallbackContract property that points to the client interface. Second, the GetGameData() operation is defined as a one way operation. Client calls are not immediately returned as a result of setting IsOneWay to true and are pushed to the client instead. The IGameStreamClient interface assigned to the CallbackContract is shown next. It allows a message to be sent back to the client by calling the ReceiveGameData() method.

[ServiceContract]
public interface IGameStreamClient
{
    [OperationContract(IsOneWay = true)]
    void ReceiveGameData(Message returnMessage);
}

Creating the Service

Once the server and client contracts are defined a service class can be created that implements the IGameStreamService interface. The following code creates a service that simulates a basketball game (similar to the one I demonstrated for using Sockets with Silverlight) and sends game updates to a Silverlight client on a timed basis.

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Threading;

namespace WCFPushService
{
    public class GameStreamService : IGameStreamService
    {
        IGameStreamClient _Client;
        Game _Game = null;
        Timer _Timer = null;
        Random _Random = new Random();

        public GameStreamService()
        {
            _Game = new Game();
        }

        public void GetGameData(Message receivedMessage)
        {

            //Get client callback channel
            _Client = OperationContext.Current.GetCallbackChannel<IGameStreamClient>();

            SendData(_Game.GetTeamData());
            //Start timer which when fired sends updated score information to client
            _Timer = new Timer(new TimerCallback(_Timer_Elapsed), null, 5000, Timeout.Infinite);
        }

        private void _Timer_Elapsed(object data)
        {
            SendData(_Game.GetScoreData());
            int interval = _Random.Next(3000, 7000);
            _Timer.Change(interval, Timeout.Infinite);
        }

        private void SendData(object data)
        {
            Message gameDataMsg = Message.CreateMessage(
                MessageVersion.Soap11,
                "Silverlight/IGameStreamService/ReceiveGameData", data);

            //Send data to the client
            _Client.ReceiveGameData(gameDataMsg);
        }
    }
}

The service first creates an instance of a Game class in the constructor which handles simulating a basketball game and creating new data that can be sent to the client. Once the client calls the service's GetGameData() operation (a one-way operation), access to the client's callback interface is retrieved by going through the OperationContext object and calling the GetCallbackChannel() method. The teams involved in the game are then created on the server and pushed to the client by calling the SendData() method. This method calls the Game object's GetTeamData() method. Although not shown here (but included in the sample code), the GetTeamData() method generates an XML message and returns it as a string. The SendData() method then creates a WCF Message object, defines that SOAP 1.1 will be used (required for this type of communication) and defines the proper action to be used to send the XML data to the client. The client's ReceiveGameData() operation is then called and the message is ultimately sent to the client.

Once the client receives the team data the server will start sending simulated score data on a random basis. When the Timer object created in the initial call to GetGameData() fires the _Timer_Elapsed() method is called which gets updated score information and pushes it to the Silverlight client by calling the SendData() method.

Creating the Service Factory

Once the service class is created a service factory can be created along with a service host. The factory is responsible for creating the appropriate host while the host defines the service endpoint. An example of creating service factory and host classes is shown next:

using System;
using System.ServiceModel;
using System.ServiceModel.Activation;
using System.ServiceModel.Channels;
using System.ServiceModel.Configuration;

namespace WCFPushService
{
    public class PollingDuplexServiceHostFactory : ServiceHostFactoryBase
    {
        public override ServiceHostBase CreateServiceHost(string constructorString,
            Uri[] baseAddresses)
        {
            return new PollingDuplexServiceHost(baseAddresses);
        }
    }

    class PollingDuplexServiceHost : ServiceHost
    {
        public PollingDuplexServiceHost(params System.Uri[] addresses)
        {
            base.InitializeDescription(typeof(GameStreamService), new UriSchemeKeyedCollection(addresses));
        }

        protected override void InitializeRuntime()
        {
            // Define the binding and set time-outs
            PollingDuplexBindingElement bindingElement = new PollingDuplexBindingElement()
            {
                PollTimeout = TimeSpan.FromSeconds(10),
                InactivityTimeout = TimeSpan.FromMinutes(1)
            };

            // Add an endpoint for the given service contract
            this.AddServiceEndpoint(
                typeof(IGameStreamService),
                new CustomBinding(
                    bindingElement,
                    new TextMessageEncodingBindingElement(
                        MessageVersion.Soap11,
                        System.Text.Encoding.UTF8),
                    new HttpTransportBindingElement()),
                    "");

            base.InitializeRuntime();
        }
    }
}

This code was pulled directly from the Silverlight SDK example which provides a great starting point for creating WCF/Silverlight polling duplex services. The service factory class (PollingDuplexServiceHostFactory) creates a new instance of the service host class (PollingDuplexServiceHost) within the CreateServiceHost() method. The service host class then overrides the InitializeRuntime() method and creates a PollingDuplexBindingElement instance which defines the client's polling and inactivity timeouts. The Silverlight SDK states the following about the PollingDuplexBindingElement class's PollTimeout and InactivityTimeout properties:

"The PollTimeout property determines the length of time (in milliseconds) that the service holds a poll from the client before returning. The InactivityTimeout property determines the length of time (in milliseconds) that can elapse without any message exchange with the client before the service closes its session."

The PollingDuplexBindingElement class is located in an assembly named System.ServiceModel.PollingDuplex.dll which is part of the Silverlight SDK. You'll need to reference the assembly in your WCF project as well as the System.ServiceModel.Channels namespace to use the PollingDuplexBindingElement class. Once the binding element is created a call is made to the host object's AddServiceEndPoint() method which references the PollingDuplexBindingElement object and the server's IGameStreamService interface to create a custom binding that uses HTTP under the covers for message exchange.

Once the factory and service classes are created the factory can be referenced in the service's .svc file in the following manner:

<%@ ServiceHost Language="C#" Factory="WCFPushService.PollingDuplexServiceHostFactory" %>

Looking through all of the code you can see that there's definitely some initial setup work required to get a Silverlight callable WCF duplex service created. Since the client does have to poll the service to check for queued messages you may wonder what the benefit is over writing a manual polling Silverlight client that calls a WCF service. Microsoft's Scott Guthrie was kind enough to provide additional details on that subject. Here's what he had to say:

"The duplex support does use polling in the background to implement notifications – although the way it does it is different than manual polling. It initiates a network request, and then the request is effectively “put to sleep” waiting for the server to respond (it doesn’t come back immediately). The server then keeps the connection open but not active until it has something to send back (or the connection times out after 90 seconds – at which point the duplex client will connect again and wait). This way you are avoiding hitting the server repeatedly – but still get an immediate response when there is data to send."

When the client polls in the background it sends the following message to the server:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
        <wsmc:MakeConnection xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702">
            <wsmc:Address>
                http://docs.oasis-open.org/ws-rx/wsmc/200702/anoynmous?id=7f64eefe-9328-4168-8175-1d4b82bef9c3
            </wsmc:Address>
        </wsmc:MakeConnection>
    </s:Body>
</s:Envelope>

In the next article I'll demonstrate how to call a WCF polling duplex service and listen for data in a Silverlight 2 application. An example of the Silverlight interface that will be discussed is shown next:

In the meantime, you can download the Silverlight 2 Beta 2 sample application including the WCF service and Silverlight client here.

Interested in getting live updates about blog posts and other information? Subscribe to my Twitter feed at http://www.twitter.com/DanWahlin.

Creating a Silverlight 2 Client Access Policy Socket Server

2008-06-09T06:57:00Z

Silverlight 2 provides built-in support for sockets which allows servers to push data to Silverlight clients. By using this feature clients can avoid polling the server on a timed basis to ensure that clients are kept up-to-date. If you're new to the socket features built-into Silverlight 2 you'll want to read my previous posts to get additional details about how data can be pushed from a server to a client:

Silverlight 2 Beta 2 (and beyond) checks for a client access policy before accessing sockets located on host domain or cross-domain servers. An example of a client access policy for sockets is shown next:

<?xml version="1.0" encoding ="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from>
        <domain uri="*" />
      </allow-from>
      <grant-to>
        <socket-resource port="4530" protocol="tcp" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

This XML code allows Silverlight to access a TCP socket on port 4530. A range of ports can be specified in the port attribute if needed (ex: 4530-4532). Before Silverlight tries to call a server with a socket, it makes a call to the target server on port 943 to check the client access policy and see if the server allows socket connections. This helps minimize various types of hacker attacks. If a client access policy is available on the server and the policy allows access to the port the client is trying to call, processing of the socket code continues and Silverlight tries to connect. If not, the client will be unable to connect due to access being denied by Silverlight.

An example of creating a client access policy socket server that Silverlight can connect to on port 943 is shown next:

using System;
using System.Collections.Generic;
using System.Text;
using System.Net;
using System.Net.Sockets;
using System.IO;
using System.Threading;
using System.Reflection;
using System.Configuration;

namespace PolicySocketServices
{
    class PolicySocketServer
    {
        TcpListener _Listener = null;
        TcpClient _Client = null;
        static ManualResetEvent _TcpClientConnected = new ManualResetEvent(false);
        const string _PolicyRequestString = "<policy-file-request/>";
        int _ReceivedLength = 0;
        byte[] _Policy = null;
        byte[] _ReceiveBuffer = null;

        private void InitializeData()
        {
            string policyFile = ConfigurationManager.AppSettings["PolicyFilePath"];
            using (FileStream fs = new FileStream(policyFile, FileMode.Open))
            {
                _Policy = new byte[fs.Length];
                fs.Read(_Policy, 0, _Policy.Length);
            }
            _ReceiveBuffer = new byte[_PolicyRequestString.Length];
        }

        public void StartSocketServer()
        {
            InitializeData();

            try
            {
                //Using TcpListener which is a wrapper around a Socket
                //Allowed port is 943 for Silverlight sockets policy data
                _Listener = new TcpListener(IPAddress.Any, 943);
                _Listener.Start();
                Console.WriteLine("Policy server listening...");
                while (true)
                {
                    _TcpClientConnected.Reset();
                    Console.WriteLine("Waiting for client connection...");
                    _Listener.BeginAcceptTcpClient(new AsyncCallback(OnBeginAccept), null);
                    _TcpClientConnected.WaitOne(); //Block until client connects
                }
            }
            catch (Exception exp)
            {
                LogError(exp);
            }
        }

        private void OnBeginAccept(IAsyncResult ar)
        {
            _Client = _Listener.EndAcceptTcpClient(ar);
            _Client.Client.BeginReceive(_ReceiveBuffer, 0, _PolicyRequestString.Length, SocketFlags.None,
                new AsyncCallback(OnReceiveComplete), null);
        }

        private void OnReceiveComplete(IAsyncResult ar)
        {
            try
            {
                _ReceivedLength += _Client.Client.EndReceive(ar);
                //See if there's more data that we need to grab
                if (_ReceivedLength < _PolicyRequestString.Length)
                {
                    //Need to grab more data so receive remaining data
                    _Client.Client.BeginReceive(_ReceiveBuffer, _ReceivedLength, 
                        _PolicyRequestString.Length - _ReceivedLength,
                        SocketFlags.None, new AsyncCallback(OnReceiveComplete), null);
                    return;
                }

                //Check that <policy-file-request/> was sent from client
                string request = System.Text.Encoding.UTF8.GetString(_ReceiveBuffer, 0, _ReceivedLength);
                if (StringComparer.InvariantCultureIgnoreCase.Compare(request, _PolicyRequestString) != 0)
                {
                    //Data received isn't valid so close
                    _Client.Client.Close();
                    return;
                }
                //Valid request received....send policy data
                _Client.Client.BeginSend(_Policy, 0, _Policy.Length, SocketFlags.None, 
                    new AsyncCallback(OnSendComplete), null);
            }
            catch (Exception exp)
            {
                _Client.Client.Close();
                LogError(exp);
            }
            _ReceivedLength = 0;
            _TcpClientConnected.Set(); //Allow waiting thread to proceed
        }

        private void OnSendComplete(IAsyncResult ar)
        {
            try
            {
                _Client.Client.EndSendFile(ar);
            }
            catch (Exception exp)
            {
                LogError(exp);
            }
            finally            
            {
                //Close client socket
                _Client.Client.Close();
            } 
        }

        private void LogError(Exception exp)
        {
            string appFullPath = Assembly.GetCallingAssembly().Location;
            string logPath = appFullPath.Substring(0, appFullPath.LastIndexOf("\\")) + ".log";
            StreamWriter writer = new StreamWriter(logPath, true);
            try
            {
                writer.WriteLine(logPath,
                    String.Format("Error in PolicySocketServer: "
                    + "{0} \r\n StackTrace: {1}", exp.Message, exp.StackTrace));
            }
            catch { }
            finally
            {
                writer.Close();
            }
        }
    }
}

Looking through the code you'll see that it uses the TcpListener class to listen for incoming client connections. Once a client connects the code checks the request for the following value:

<policy-file-request/>

Silverlight automatically sends this text to the policy file socket once it connects. If the request contains the proper value the code writes the contents of the client access policy back to the client stream (see the OnReceiveComplete() method). Once the policy file is received, Silverlight parses it, checks that it allows access to the desired port, and then accepts or rejects the socket call that the application is trying to make.

An example of the Silverlight GameStream socket application I created to demonstrate the fundamentals of using sockets is shown next. The code for the application can be downloaded here.

If you're brand new to Silverlight 2 and are interested in getting started with it check out the following video tutorials:

Silverlight 2.0 Video Tutorials

Part 1: Creating "Hello World" with Silverlight 2 and VS 2008	Tutorial	Video Tutorial
Part 2: Using Layout Management	Tutorial	Video Tutorial
Part 3: Using Networking to Retrieve Data and Populate a DataGrid	Tutorial	Video Tutorial
Part 4: Using Style Elements to Better Encapsulate Look and Feel	Tutorial	Video Tutorial
Part 5: Using the ListBox and DataBinding to Display List Data	Tutorial	Video Tutorial
Part 6: Using User Controls to Implement Master/Details Scenarios	Tutorial	Video Tutorial
Part 7: Using Templates to Customize Control Look and Feel	Tutorial	Video Tutorial
Part 8: Creating a Digg Desktop Version of our Application using WPF	Tutorial	Video Tutorial

New Features in Silverlight 2 Beta 2

2008-06-04T18:03:00Z

Bill Gates and S. Somasegar announced several new features at TechEd for Silverlight Beta 2 that are great additions to the existing functionality. Here's a list of the highlights in Beta 2:

UI Framework: Beta 2 includes improvements in animation support, error handling and reporting, automation and accessibility support, keyboard input support, and general performance. This release also provides more compatibility between Silverlight and WPF.
Rich Controls: Beta 2 includes a new templating model called Visual State Manager that allows for easier templating for controls. Other features include the introduction of a TabControl, text wrapping and scrollbars for TextBox. DataGrid additions include Autosize, Reorder, Sort, performance increases and more. Most controls are now in the runtime instead of packaged with the application.
Networking Support: Beta 2 includes improved Cross Domain support and security enhancements, upload support for WebClient, and duplex communications (“push” from server to Silverlight client).
Rich Base Class Library: Beta 2 includes improved threading abilities, LINQ-to-JSON, ADO.NET Data Services support, better support for SOAP and other improvements to make networking and data handling easier.
Deep Zoom: Beta 2 introduces a new XML-based file format for Deep Zoom image tiles as well as a new MultiScaleTileSource that enables existing tile databases to utilize Deep Zoom. Better, event driven notification for zoom/pan state is another improvement in Silverlight 2 Beta 2.

Check out Scott Guthrie's blog for a complete list of features and additional details: http://weblogs.asp.net/scottgu/archive/2008/06/06/silverlight-2-beta2-released.aspx

I'll be posting more about the new features soon....stay tuned! In the meantime, here's where you can get Silverlight 2 Beta 2: http://silverlight.net/GetStarted/

My Latest Silverlight Articles

2008-05-30T00:00:00Z

Over the past few months I've been writing articles for the .NET Insight insight newsletter covering various ASP.NET AJAX concepts. You can read those article here. I've wrapped up that series and have started writing about Silverlight 1.0. Each week (or so) a new article will be published and I'll update them here so check back. The articles are designed to be focused and concise and get straight to the topic without a lot of fluff.

A video of a talk I gave on integrating Silverlight with ASP.NET AJAX and Web Services can be viewed here for those who are interested.

If you're interested in learning more about Silverlight 2.0 you can view 8 video tutorials that I put together here.

Desert Code Camp Is This Saturday (May 31st)

2008-05-29T21:10:21Z

Arizona's Desert Code Camp is this Saturday (May 31st) at the University of Advanced Computing building. Here's the address:

University of Advancing Technology
2625 W. Baseline Road (map)
Tempe, Arizona 85283

It looks like there are a lot of great talks scheduled covering everything from iPhone development to game development to line of business applications.

I'll be giving a talk titled Integrating Data Into Silverlight 2 Applications (slides and code here) on behalf of Interface Technical Training which is scheduled to start at 11:20 AM and run for about an hour. I'll cover several different things in the talk such as:

Cross-domain policy files
Calling WCF and ASMX Services with Silverlight 2
Getting data from RESTful services
Data streaming options
Binding data to controls
Socket support in Silverlight 2 (an example of the sample socket application is shown next)

Swing on by if you have some time Saturday. Desert Code Camp is completely free so it's a great way to learn about different topics if you or your company is on a tight budget.

A Software Developer Trying to Get In Shape with the Wii Fit??

2008-05-28T23:56:34Z

We interrupt this tech blog for a quick (and pointless) message about trying to get in shape....

Back in high school and college I played a lot of sports so it was pretty easy to stay in shape without really trying much. Those years have definitely passed. Now that I'm getting older and sit staring at the computer hour upon hour (I'll bet my fingers are in good shape from typing so much though!) writing .NET programs it's not so easy so I've recently starting using my Total Gym machine and running more.

My family recently bought the new Wii Fit since it sounded like a fun way to play some games while burning a calorie or two. It's actually been very fun (my wife and kids love it and compete a lot) and we've enjoyed some of the yoga, strength and aerobic exercises in addition to the built-in games. I always thought yoga looked like a waste of time but now I realize how out of shape and inflexible I really am and that yoga is actually much, much harder than it looks. I'm only on the beginner levels on Wii Fit and already groaning about it stretching me too much. Even with the groaning, I really like the Wii Fit although it's no substitute for my Total Gym and running exercises from what I've seen so far.

Moving on....I ordered a rechargeable battery with my Wii Fit which came separate in the mail from Amazon.com a few days back. Keep in mind that the whole purpose of Wii Fit is to get you in better shape and make you more flexible. However, here's the coupon that I received along with the Wii Fit battery in the packaging:

I don't know about you, but I'm thinking someone's not coordinating the marketing effort too well! I doubt that the fried chicken sandwich, fries and Coke (maybe it's diet) are going to help with my Wii Fitness plan (although the sandwich isn't quite as bad as I thought for the fat content). Back to more Wii Fit yoga, strength and aerobics exercises so I can prepare for my southern style chicken sandwich with fries and a non-diet Coke! :-)