Dzisiaj trochę więcej szczegółów na temat, jak można wywoływać metody w Hub API. W ostatnim wpisie, zaimplementowaliśmy klasę, która wykonuje metodę po wszystkich klientach (broadcast). SignalR ma ogromne możliwości i istnieje wiele innych wzorców.

Dla przypomnienia broadcast wygląda następująco:

public void SendMessage(string message)
{
  Clients.All.newMessage(string.Format("{0}: {1}",DateTime.Now,message));
}

Clients posiada kilka metod, służących do wysyłania wiadomości w różnych sposób. Na przykład, aby wykonać metodę wyłącznie po stronie klienta, który wysłał zapytanie do serwera można:

public void SendMessage(string message)
{
  Clients.Caller.newMessage(string.Format("{0}: {1}",DateTime.Now,message));
}

Innymi słowy, gdy przeglądarka wywołuje SendMessage, newMessage zostanie wykonane wyłącznie w tej przeglądarce (a nie jak wcześniej we wszystkich podłączonych klientach).

Inną ciekawą konstrukcją jest wywołanie metody we wszystkich klientach, oprócz tego który zainicjował połączenie (wywołał metodę serwerową):

public void SendMessage(string message)
{
  Clients.Others.newMessage(string.Format("{0}: {1}",DateTime.Now,message));
}

Istnieje opcja wywołania metody dla określonego nazwą (string) połączenia:

Clients.Client("connectionID").newMessage(string.Format("{0}: {1}",DateTime.Now,message));

Analogicznie, wszystkie połączenia oprócz tych przekazanych jako parametr:

public void SendMessage(string message)
{
  Clients.AllExcept("connectionID1","connectionId2").newMessage(string.Format("{0}: {1}",DateTime.Now,message));
}

Jeśli znamy nazwę użytkownika (IUserIdProvider), możemy wywołać metodę po stronie klienta, który używa określonego loginu:

public void SendMessage(string message)
{
  Clients.User("user1").newMessage(string.Format("{0}: {1}",DateTime.Now,message));
}

Bardzo ciekawym rozwiązaniem są grupy. Umożliwiają one implementacje wzorca polegającym na publish\subscribe. Dzięki grupom, można wywoływać metody, wyłącznie w tych klientach, które nalezą do konkretnej grupy.

public void SendMessage(string message)
{
  Clients.Group("group_name").newMessage(string.Format("{0}: {1}",DateTime.Now,message));
}

Powyższy kod wywoła newMessage w klientach należących do group_name. Pozostaje pytanie, jak dodać użytkownika (połączenie) do grupy? Wystarczy:

public class MyFirstHub : Hub
{
   public void AddToGroup(string groupName)
   {
       Groups.Add(Context.ConnectionId, groupName);
   }
   public void RemoveFromGroup(string groupName)
   {
       Groups.Remove(Context.ConnectionId, groupName);
   }
}

Add automatycznie stworzy grupę jeśli takowa nie istnieje. Kod dodaje połączenie skojarzone z klientem, który wywołuje właśnie serwerową metodę.

Powyższy kod jest jednak nie do końca poprawny. Zaglądając do dokumentacji, zobaczymy:

 Task Add(string connectionId, string groupName);

Oznacza to, że jest to metoda asynchroniczna. W praktyce, wywołanie powyższego kodu, zwróci rezultat natychmiast, mimo, że nie ma pewności, że połączenie zostało dodane do konkretnej grupy.

Z tego względu dużo lepiej jest:

public class MyFirstHub : Hub
{
   public async void AddToGroup(string groupName)
   {
       await Groups.Add(Context.ConnectionId, groupName);
   }
   public async void RemoveFromGroup(string groupName)
   {
       await Groups.Remove(Context.ConnectionId, groupName);
   }
}

W ostatnim poście również wspomniałem, że należy dodać następującą referencję:

<script src="~/signalr/hubs"></script>    

Tak naprawdę, jest to referencja do automatycznie wygenerowanego kodu JavaScript. Sprawdźmy, co dokładnie jest wygenerowane:

/*!
 * ASP.NET SignalR JavaScript Library v2.1.0
 * http://signalr.net/
 *
 * Copyright Microsoft Open Technologies, Inc. All rights reserved.
 * Licensed under the Apache 2.0
 * https://github.com/SignalR/SignalR/blob/master/LICENSE.md
 *
 */

/// <reference path="..\..\SignalR.Client.JS\Scripts\jquery-1.6.4.js" />
/// <reference path="jquery.signalR.js" />
(function ($, window, undefined) {
    /// <param name="$" type="jQuery" />
    "use strict";

    if (typeof ($.signalR) !== "function") {
        throw new Error("SignalR: SignalR is not loaded. Please ensure jquery.signalR-x.js is referenced before ~/signalr/js.");
    }

    var signalR = $.signalR;

    function makeProxyCallback(hub, callback) {
        return function () {
            // Call the client hub method
            callback.apply(hub, $.makeArray(arguments));
        };
    }

    function registerHubProxies(instance, shouldSubscribe) {
        var key, hub, memberKey, memberValue, subscriptionMethod;

        for (key in instance) {
            if (instance.hasOwnProperty(key)) {
                hub = instance[key];

                if (!(hub.hubName)) {
                    // Not a client hub
                    continue;
                }

                if (shouldSubscribe) {
                    // We want to subscribe to the hub events
                    subscriptionMethod = hub.on;
                } else {
                    // We want to unsubscribe from the hub events
                    subscriptionMethod = hub.off;
                }

                // Loop through all members on the hub and find client hub functions to subscribe/unsubscribe
                for (memberKey in hub.client) {
                    if (hub.client.hasOwnProperty(memberKey)) {
                        memberValue = hub.client[memberKey];

                        if (!$.isFunction(memberValue)) {
                            // Not a client hub function
                            continue;
                        }

                        subscriptionMethod.call(hub, memberKey, makeProxyCallback(hub, memberValue));
                    }
                }
            }
        }
    }

    $.hubConnection.prototype.createHubProxies = function () {
        var proxies = {};
        this.starting(function () {
            // Register the hub proxies as subscribed
            // (instance, shouldSubscribe)
            registerHubProxies(proxies, true);

            this._registerSubscribedHubs();
        }).disconnected(function () {
            // Unsubscribe all hub proxies when we "disconnect".  This is to ensure that we do not re-add functional call backs.
            // (instance, shouldSubscribe)
            registerHubProxies(proxies, false);
        });

        proxies['myFirstHub'] = this.createHubProxy('myFirstHub'); 
        proxies['myFirstHub'].client = { };
        proxies['myFirstHub'].server = {
            addToGroup: function (groupName) {
                return proxies['myFirstHub'].invoke.apply(proxies['myFirstHub'], $.merge(["AddToGroup"], $.makeArray(arguments)));
             },

            removeFromGroup: function (groupName) {
                return proxies['myFirstHub'].invoke.apply(proxies['myFirstHub'], $.merge(["RemoveFromGroup"], $.makeArray(arguments)));
             }
        };

        return proxies;
    };

    signalR.hub = $.hubConnection("/signalr", { useDefaultPath: false });
    $.extend(signalR, signalR.hub.createHubProxies());

}(window.jQuery, window));

Jak widać, plik zawiera głównie proxy. Dzięki niemu, możemy w łatwy sposób w JavaScript wywołać kod C# znajdujący się na serwerze:

 proxies['myFirstHub'].server = {
            addToGroup: function (groupName) {
                return proxies['myFirstHub'].invoke.apply(proxies['myFirstHub'], $.merge(["AddToGroup"], $.makeArray(arguments)));
             },

            removeFromGroup: function (groupName) {
                return proxies['myFirstHub'].invoke.apply(proxies['myFirstHub'], $.merge(["RemoveFromGroup"], $.makeArray(arguments)));
             }
        };

W poprzednim poście przedstawiłem framework SignalR oraz niskopoziomową klasę PersistentConnection. Zwykle jest ona trudna w użyciu i dlatego w praktyce dużo częściej korzysta się z Hub API.  Jak sama nazwa wskazuje, stanowi on koncentrator czyli miejsce gdzie składujemy metody zarówno wykonywane po stronie serwera jak i klienta. Dzięki niemu możemy wywołać metodę C# (serwer) jak i JavaScript (klient). Umożliwia on zatem komunikacje obustronną.

Spróbujmy zatem przerobić przykład z poprzedniego postu, aby używał Hub zamiast PersistentConnection. Najpierw oczywiście usuwamy MyFirstConnection i zastępujemy ją hub’em:

public class MyFirstHub : Hub
{
   public void SendMessage(string message)
   {
       Clients.All.newMessage(string.Format("{0}: {1}",DateTime.Now,message));
   }
}

Nasz hub ma jedną metodę teraz – Send Message. Proszę zauważyć, że All jest typu dynamic i dlatego możemy jakąkolwiek metodę wykonać. Metody są definiowane w JavaScript dlatego naturalne jest, że taka metoda nie zostanie automatycznie wykryta przez VS.

Powyższy kod jest implementacją serwerowej metody  SendMessage.  Po odebraniu wiadomości jest ona wysyła do wszystkich klientów (broadcast). newMessage musi zatem zostać zdefiniowana w JavaScript po stronie klienta:

<script type="text/javascript">
    $(function () {

        var myFirstHub = $.connection.myFirstHub;
        myFirstHub.client.newMessage = function (message) {
            $('#messages').append('<li>' + message + '</li>');
        };

        $.connection.hub.start();
        
        $("#broadcast").click(function () {
            myFirstHub.server.sendMessage($('#msg').val());
        });

    });
    </script>

<input type="text" id="msg" />
<input type="button" id="broadcast" value="broadcast" />

<ul id="messages"></ul>

Najpierw tworzymy hub’a a potem za pomocą obiektu server możemy wysyłać wiadomości do serwera. Analogicznie, istnieje możliwość definiowania metod po stronie klienta, które mogą być wykonywane przez serwer.

Należy koniecznie dodać referencje do automatycznie wygenerowanych hubów w JS:

<script src="~/Scripts/jquery-1.10.2.js" type="text/javascript"></script>
<script src="~/Scripts/jquery.signalR-2.1.0.js" type="text/javascript"></script>
<script src="~/signalr/hubs"></script>    

Na zakończenie wystarczy tylko zmapować hub’a do URL:

[assembly: OwinStartupAttribute(typeof(WebApplication9.Startup))]
namespace WebApplication9
{
    public partial class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            ConfigureAuth(app);
            app.MapSignalR();
        }
    }
}

W kolejnej części zajmiemy się bardziej szczegółowo wywoływaniem metod w SignalR.

Aplikacje webowe przeszły rewolucje od czasów pierwszych stron internetowych. Przez długi czas, aplikacje webowe opierały się na prostym schemacie zapytania i odpowiedzi. Wpisując jakiś adres w przeglądarce, generowany był po prostu dokument. Nie było możliwości interakcji. Nawigacja do innej strony, skutkowała przeładowaniem całej strony.

Później pojawił się AJAX, czyli wykonywanie metod usługi w tle. Był to na pewno krok do przodu ponieważ nie było potrzebne już przeładowanie całej strony, aby odświeżyć jakiś tylko fragment. Niestety wciąż była to komunikacja jednokierunkowa, od przeglądarki do serwera. W przeciwnym kierunku byłoby to możliwe wyłącznie poprzez przeładowanie całej strony. Nie istniał wtedy sposób na  łatwe powiadomienie przeglądarki, że stan bazy danych zmienił się.

Możliwe były oczywiście pewne obejścia. Najczęściej przeglądarka odpytywała serwer, czy są już jakieś zmiany, które powinny być odzwierciedlone w przeglądarce. Oczywiście w aplikacjach czasu rzeczywistego nie jest to perfekcyjne rozwiązanie, ponieważ wiąże się z dużym obciążeniem łącza i wynikającymi z tego opóźnieniami.

Dzisiaj na szczęście mamy inne, lepsze rozwiązania. Nie będę opisywał w tym poście szczegółów, ponieważ, chcę najpierw skupić się na samym framework’u SignalR, a potem dopiero prześledzimy jego internale.

W skrócie, tzw. Web Socket API umożliwia pełną komunikację między przeglądarką a serwerem. Możliwe jest zatem dzięki Web Socket, że klient wysyła w tle wiadomość do serwera (nic nadzwyczajnego) oraz serwer do przeglądarki (i to jest nowość). Jest to ogólny standard i nie ma nic wspólnego z ASP.NET. Ponadto, nie jest on wyłącznie ograniczony do przeglądarek internetowych. Działa zwykle na porcie 80 (korzystne dla firewalls itp.).

W HTTML 5 API do dyspozycji są tzw. Serer-Sent Events. Dzięki nim, serwer może powiadomić przeglądarkę o zmianach. Jest to jednak komunikacja również jednokierunkowa, od serwera do klienta.

SignalR jest z kolei frameworkiem dla ASP.NET ułatwiającym pisanie aplikacji czasu rzeczywistego, czyli takich gdzie nie chcemy przeładowywać całej strony bo dane zmieniają się w czasie “rzeczywistym”. Oczywiście kluczowym mechanizmem w takiej scenariuszu jest powiadomienie klientów o zmianach na serwerze. Można oczywiście bezpośrednio korzystać z Web Socket czy HTTML 5 SSE. Problem w tym, że część przeglądarek nie wspiera Web Socket ani SSE. SignalR za nas dostarczy warstwę abstrakcji, czyli wykorzysta najlepszą, dostępną aktualnie technologie.

Jeśli przeglądarka i serwer dostarczają Web Socket, to zostanie on oczywiście wykorzystany bo jest jedynym w pełni dwukierunkowym sposobem komunikacji. W przeciwnym razie HTML 5 SSE  może zostać użyty. W najgorszym przypadku, po prostu stary mechanizm odpytywania zostanie wykonany. Dzięki SignalR, programista ma jeden framework i nie interesuje go, co dokładnie przeglądarka wspiera. Framework dobierze najlepszą technologie jaka jest aktualnie dostępna. Programista  korzysta zawsze z tego samego API.

W SignalR do dyspozycji mamy dwa typy połączeń. PersistentConnection oraz HubAPI. Pierwszy z nic jest bardziej niskopoziomowy i dlatego dzisiaj nim zajmiemy się. W przyszłym wpisie pokażę Hub API.

Zaczynamy oczywiście od instalacji SignalR z NuGet:

NuGet zainstaluje pakiet, w którego skład wchodzą m.in. skrypty JS, biblioteki DLL oraz zostanie również wygenerowany Startup:

[assembly: OwinStartupAttribute(typeof(WebApplication9.Startup))]
namespace WebApplication9
{
    public partial class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            ConfigureAuth(app);
        }
    }
}

Na razie o Startup nie musimy martwić się. Stwórzmy nasze pierwsze połączenie:

public class MyFirstConnection:PersistentConnection
{
   protected override Task OnReceived(IRequest request, string connectionId, string data)
   {
       return Connection.Broadcast(data);
   }
}

Przeładowujemy tutaj OnReceived, metodę, która jest wywołana, gdy któryś z klientów wyśle jakąś wiadomość. Następnie tą samą wiadomość, przekazujemy do pozostałych (broadcast).

Pora na kod JS, czyli stronę klienta (przykład z dokumentacji SignalR):

$(function () {
        var connection = $.connection('/echo');

        connection.received(function (data) {
            $('#messages').append('<li>' + data + '</li>');
        });

        connection.start().done(function() {
            $("#broadcast").click(function () {
                connection.send($('#msg').val());
            });
        });

    });

Jak widzimy, mamy tutaj kod, polegający na zewnętrznych bibliotekach np. metoda $.connection. Musimy zatem podłączyć bibliotekę jquery.signalR-2.1.0, która została zainstalowana w ramach pakietu SignalR (NuGet). Oprócz tego, musimy dodać referencje do jQuery:

<script src="~/Scripts/jquery-1.10.2.js"></script>
<script src="~/Scripts/jquery.signalR-2.1.0.js"></script>

Ostatnia rzecz jaka nam pozostała to mapowanie. Powyższy przykład, używa metody echo, która nie jest jeszcze zdefiniowana. Można zobaczyć w $.connection, że odwołujemy się do /echo, ale póki co nie zaimplementowaliśmy tego. Wystarczy, że zmapujemy /echo do naszego połączenia MyFirstConnection we wspomnianej wcześniej klasie Startup:

public partial class Startup
{
   public void Configuration(IAppBuilder app)
   {
       ConfigureAuth(app);
       app.MapSignalR<MyFirstConnection>("/echo");
   }
}

Po uruchomieniu aplikacji, szybko przekonamy się, że wpisując dane w oknie jednej przeglądarki, zostaną one rozesłane do pozostałych, podłączonych klientów (broadcast).