Monday, October 14, 2013

SignalR - Part 2 - Hello, Server

In my previous blog post, I discussed the concepts of SignalR and why you should be interested as a developer. Hopefully I sold you. But if I didn’t, I think getting in and writing some code will help.

Here’s the basic scenario, and sort of our “SignalR 101” demo. I want a simple chat application for a site. I want to create a form and allow someone to broadcast a message to everyone else connected to the page.

In addition, I’d like to store that information in a database so people can see the most recent 10 messages. And, while we’re at it, I’d like to make sure the UI highlights new messages.

But let’s walk before we run. Let’s start by broadcasting messages to all connected users. And right now I just want to get the server side (or hub) set up and ready to go.

First step – get SignalR. SignalR is available as a NuGet package. So just fire up the NuGet manager and search for SignalR. You’ll just need the first package.

image

The result is one of the main reasons to use NuGet. First, you’ll notice it grabs all the prerequisites for us. Second, it opens a text file with the next steps.

The first step that’s called out is to add a line of code to our global.asax file. This little line will find all of our SignalR hubs and make them available. That one little line will also generate a dynamic bit of JavaScript for us that contains the JavaScript methods for the client to use. The readme.txt file calls out the reference that needs to be made to that dynamic file.

Long story short, we need to do what the readme.txt file says. Since we’re just focused on the server side right now, we’re just going to make our global.asax file look like this:

protected void Application_Start()

{

   // Register the default hubs route: ~/signalr

   RouteTable.Routes.MapHubs();

   // normal code below

}

And that’s it. That’s the server configuration part. That’s everything that needs to be done for the automatic step down that I talked about in the previous blog post. And we can turn our attention to making our actual implementation.

Let’s create our hub first. You can see it listed below.

using Microsoft.AspNet.SignalR;

using System;

 

namespace SignalRBlog.Hubs

{

   public class MessageHub : Hub

   {

      public void SendNewMessage(String message)

      {

         Clients.All.UpdateMessages(message);

      }

   }

}

Take a look at it. Notice if there’s anything special. I’ll give you a hint – there really isn’t. Well, one thing. But on the whole there isn’t.

And that’s the beauty of SignalR. I create the code I need to create, focus on the features I need to implement, and let SignalR take care of the details.

Let’s break things down. First you’ll notice the inheritance. The Hub class is inside the Microsoft.AspNet.SignalR namespace and is the base for all hubs. That is what the register method will focus in on when registering our hubs, and it’s what makes the Clients object (and a few others) available.

Second, you’ll notice the basic SendNewMessage method. Nothing fancy there. Just a public method, taking a String parameter, and returning void. Programming 101.

And finally we get to the real SignalR code – the Clients object. The Clients object gives us access to everyone that’s currently connected. As we’ll see in later blog posts we can use that object to target certain sets of users. But for right now we want to broadcast our message to everyone. The property of Clients that will give us all users is imaginatively named All.

All is a dynamic object. It does represent all users and allows me to call a method on all users. But it’s a dynamic object. Here’s the thing – SignalR doesn’t know what methods we may want to call or what it is we’re going to want to be able to do. As a result it uses a dynamic object which allows us to add on the methods we’re going to need on the fly. At a later point we’ll have to register that method on the client, but that’s the next blog post.

So, here’s what we’ve got. We’ve added SignalR to our project. We’ve added the call to our global.asax file to register the dynamic JavaScript that’s needed. And we created our hub with our first method that can be called from the client. What’s next? Well, to create the client! And that’s the next blog post.

1 comment: