Partage via

Client Java ASP.NET Core SignalR

  • Article

Par Mikael Mengistu

Le client Java permet de se connecter à un serveur ASP.NET Core SignalR à partir du code Java, y compris les applications Android. Comme le client JavaScript et le client .NET, le client Java permet de recevoir et d'envoyer des messages à un hub en temps réel. Le client Java est disponible dans ASP.NET Core 2.2 et versions ultérieures.

L'exemple d'application de console Java référencé dans cet article utilise le client Java SignalR.

Affichez ou téléchargez l’exemple de code (procédure de téléchargement)

Installer le package client Java SignalR

Le fichier JAR signalr-7.0.0 permet aux clients de se connecter aux hubs SignalR. Pour trouver le dernier numéro de version du fichier JAR, consultez les résultats de la recherche Maven.

Si vous utilisez Gradle, ajoutez la ligne suivante à la section dependencies de votre fichier build.gradle :

implementation 'com.microsoft.signalr:signalr:7.0.0'

Si vous utilisez Maven, ajoutez les lignes suivantes à l'intérieur de l'élément <dependencies> de votre fichier pom.xml :

<dependency>
    <groupId>com.microsoft.signalr</groupId>
    <artifactId>signalr</artifactId>
    <version>1.0.0</version>
</dependency>

Se connecter à un hub

Pour établir un HubConnection, le HubConnectionBuilder doit être utilisé. L'URL du concentrateur et le niveau de journalisation peuvent être configurés lors de la création d'une connexion. Configurez toutes les options requises en appelant l'une des méthodes HubConnectionBuilder avant build. Démarrez la connexion avec start.

HubConnection hubConnection = HubConnectionBuilder.create(input)
        .build();

Appeler les méthodes du concentrateur à partir du client

Un appel à send invoque une méthode hub. Transmettez le nom de la méthode hub et tous les arguments définis dans la méthode hub à send.

hubConnection.send("Send", input);

Notes

L'appel de méthodes de concentrateur à partir d'un client est uniquement pris en charge lors de l'utilisation du service SignalR Azure en mode par défaut. Pour plus d’informations, consultez la section Foire aux questions (référentiel GitHub azure-signalr).

Appeler des méthodes client depuis le hub

Utilisez hubConnection.on pour définir des méthodes sur le client que le concentrateur peut appeler. Définissez les méthodes après la construction mais avant de démarrer la connexion.

hubConnection.on("Send", (message) -> {
    System.out.println("New Message: " + message);
}, String.class);

Ajouter une journalisation

Le client Java SignalR utilise la bibliothèque SLF4J pour la journalisation. Il s'agit d'une API de journalisation de haut niveau qui permet aux utilisateurs de la bibliothèque de choisir leur propre implémentation de journalisation spécifique en introduisant une dépendance de journalisation spécifique. L'extrait de code suivant montre comment utiliser java.util.logging avec le client Java SignalR.

implementation 'org.slf4j:slf4j-jdk14:1.7.25'

Si vous ne configurez pas la journalisation dans vos dépendances, SLF4J charge un journal de non-opération par défaut avec le message d'avertissement suivant :

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Cela peut être ignoré en toute sécurité.

Notes de développement Android

En ce qui concerne la compatibilité du Android SDK pour les fonctionnalités client SignalR, tenez compte des éléments suivants lorsque vous spécifiez votre version cible du Android SDK :

Configurer l'authentification par jeton du porteur

Dans le client Java SignalR, vous pouvez configurer un jeton de support à utiliser pour l'authentification en fournissant une "fabrique de jetons d'accès" au HttpHubConnectionBuilder. Utilisez withAccessTokenFactory pour fournir une RxJava Unique<Chaîne>. Avec un appel à Single.defer, vous pouvez écrire une logique pour produire des jetons d'accès pour votre client.

HubConnection hubConnection = HubConnectionBuilder.create("YOUR HUB URL HERE")
    .withAccessTokenProvider(Single.defer(() -> {
        // Your logic here.
        return Single.just("An Access Token");
    })).build();

Passer des informations de classe en Java

Lors de l'appel des méthodes on, invoke ou stream de HubConnection dans le client Java, les utilisateurs doivent transmettre un objet Type plutôt qu'un objet Class<?> pour décrire tout générique Object transmis à la méthode. Un Type peut être acquis en utilisant la classe TypeReference fournie. Par exemple, en utilisant une classe générique personnalisée nommée Foo<T>, le code suivant obtient Type :

Type fooType = new TypeReference<Foo<String>>() { }).getType();

Pour les non-génériques, tels que les primitives ou d'autres types non paramétrés comme String, vous pouvez simplement utiliser le .class.

Lorsque vous appelez l'une de ces méthodes avec un ou plusieurs types d'objets, utilisez la syntaxe des génériques lors de l'appel de la méthode. Par exemple, lors de l'enregistrement d'un gestionnaire on pour une méthode nommée func, qui prend comme arguments une chaîne et un objet Foo<String>, utilisez le code suivant pour définir une action pour imprimer les arguments :

hubConnection.<String, Foo<String>>on("func", (param1, param2) ->{
    System.out.println(param1);
    System.out.println(param2);
}, String.class, fooType);

Cette convention est nécessaire car nous ne pouvons pas récupérer des informations complètes sur les types complexes avec la méthode Object.getClass en raison de l'effacement de type en Java. Par exemple, appeler getClass sur un ArrayList<String> ne renverrait pas Class<ArrayList<String>>, mais plutôt Class<ArrayList>, ce qui ne donne pas suffisamment d'informations au désérialiseur pour désérialiser correctement un message entrant. Il en va de même pour les objets personnalisés.

Limitations connues

  • Le transport de secours et le transport des événements envoyés par le serveur ne sont pas pris en charge.
  • Le transport de secours et le transport des événements envoyés par le serveur ne sont pas pris en charge.
  • Seul le protocole JSON est pris en charge.
  • Seul le protocole JSON est pris en charge.
  • Seul le transport WebSockets est pris en charge.
  • La diffusion en continu n'est pas encore prise en charge.

Ressources supplémentaires