Calling a server-side Hub method

After learning how to perform a connection and customize the transport strategy, let's move to the natural next step: calling a server-side Hub method. We are going along the same path as the one we took in Chapter 3, Using the JavaScript Hubs Client API; therefore, this recipe will match what we did in the Calling a server-side Hub method recipe in that chapter. When we compare both the recipes, we can see one big difference between them: the .NET Hubs API does not have a concept of dynamic proxy. We'll see how we can call a remote Hub using a more general-purpose API than the magical one that we saw for the JavaScript client. Such a type of generic proxy indeed exists in the context of the JavaScript client, too; we will see that in detail later in the book.

Getting ready

For this recipe, we will use EchoHub exposed in the Calling a server-side Hub method recipe from Chapter 3, Using the JavaScript Hubs Client API, which must therefore be started before testing the code from this recipe.

How to do it…

Let's create a console application project as described in the Introduction section, and let's name it Recipe22. Then, let's modify the code of the Program.cs file by performing the following steps:

  1. We first prepare the basis for our code as follows:
    using System;
using System.Threading.Tasks;
using Microsoft.AspNet.SignalR.Client;

static void Main(string[] args)
{
    Do().Wait();
}
static async Task Do()
{
    const string url = "http://localhost:39492";
    var connection = new HubConnection(url);

    ...
}

    Please make sure the port number (39492) matches the one used by the server project that we are using. For more detail about what's going on here, please check the previous recipes of this chapter.

  2. Now, we need to create a proxy for the remote hub with the following code:
    var echo = connection.CreateHubProxy("echo");

    The CreateHubProxy() method creates a proxy object (echo) referencing the remote Hub whose name has been passed as the argument of the call. This reference will allow us to perform remote calls and, as we'll see in future recipes, to specify the functions to be called back from the server-side code.

  3. We are ready to connect to our Hub using the following line of code:
    await connection.Start();

    This code is asynchronously initiating the connection and, as we already saw in earlier recipes, we then wait for its completion thanks to the await keyword.

  4. When the connection is ready, we can call any method exposed by the remote Hub with the following code:
    var response = await echo.Invoke<string>("Say", "hello!");

    We use the echo reference that we took earlier to call the Invoke() method on it. The Invoke() method receives as its first argument the name of the remote method to call (Say), followed by a params array containing the arguments required by the method itself (in this case, the message to echo). Invoke() is a generic method whose type argument is the type of the expected return value. Of course, Invoke() is also an asynchronous method, so we can await it when calling it, and the response will be available asynchronously.

  5. We eventually print the response and wait for the user to press Enter before exiting the application. The following code facilitates this action:
    Console.WriteLine(response);
Console.ReadLine();

When running this code, the client will connect asynchronously to EchoHub. It will wait for the connection to be available and then perform a remote call. It will then wait for the response to be available and print it.

How it works…

The remote invocation is based on dynamic information and it's resolved at runtime. We specify the method to be called by its name, and we have no specific type representing the actual Hub that we are contacting; hence, there's no way to check whether our call is correct at compile time. We have to make sure everything matches the definition of the method on the Hub (name, number and type of the arguments, and type of the return value) while writing the code, and then let SignalR resolve it at runtime. If that's the case the call will succeed and we will receive the corresponding return value asynchronously, as usual with SignalR.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset