Le pack Realtime UI de sgcUI

TsgcUIPresenceModel conserve les utilisateurs et leur statut (en ligne, absent, occupé ou hors ligne) avec un texte de statut. Les contrôles d'avatar suivent le modèle, donc un changement de statut repeint d'un coup chaque avatar et chaque indicateur de cet utilisateur.

• Le modèle de présence reçoit ses changements par AddOrUpdate et SetStatus dans le code, ou par un message en direct par changement.
• Un avatar, un groupe d'avatars avec une pastille « +N » pour les utilisateurs qui ne tiennent pas, et un indicateur de présence avec le point de statut et le texte de statut.
• Le flux d'activité de sgcDashboard lit le même modèle, donc chaque acteur affiche son avatar et son statut.

Produit

sgcUICore, partagé par chaque produit sgcUI

Delphi et C++Builder

TsgcVCLAvatar, TsgcVCLAvatarGroup, TsgcVCLPresenceIndicator et leurs jumeaux TsgcFMX

Édition

Toutes les éditions, Community comprise, messages de présence en direct compris

Aide : Présence et Avatars et indicateur de présence.

TsgcDashboardActivityModel enregistre chaque activité comme un acteur, un verbe et un objet, avec les champs modifiés. Le flux d'activité et la piste d'audit sont deux vues du même modèle.

• Flux d'activité : l'activité la plus récente d'abord, avec des heures relatives et l'avatar de chaque acteur issu du modèle de présence.
• Piste d'audit : un tableau dont les lignes se déplient sur les champs modifiés.
• Les deux sont des contrôles autonomes et aussi des tuiles d'activité et d'audit pour un tableau de bord.

Produit

sgcDashboard

Delphi et C++Builder

TsgcVCLActivityFeed, TsgcVCLAuditTrail, TsgcVCLDashboardActivityTile, TsgcVCLDashboardAuditTile et leurs jumeaux TsgcFMX

Édition

Toutes les éditions, Community comprise. Les messages d'activité en direct relèvent de l'édition Enregistrée.

Aide : Flux d'activité, Messages d'activité en direct, Tuile d'activité et Tuile d'audit.

• La source ne se connecte, ne s'abonne et n'envoie jamais. L'URL, les identifiants, TLS et la reconnexion appartiennent au client, et le crochet survit à une reconnexion par le WatchDog.
• Une source alimente plusieurs modèles par ses liaisons, donc une seule connexion peut piloter tout un écran. Une liaison peut déballer une enveloppe d'application, et ton propre gestionnaire de l'événement du client se déclenche toujours.
• Les modèles sont toujours appelés dans le thread principal. Les messages qui arrivent dans un thread de socket sont mis en file d'attente et appliqués en une seule visite au thread principal, dans l'ordre d'arrivée.
• Le pont est entrant uniquement. Quand l'utilisateur lit ou ferme une notification, l'application envoie sa propre trame par le même client.

Les quatre formes de message

Il n'y a pas de nouveau protocole. Chaque modèle lit le message en direct de son flux : un objet JSON par changement, avec un membre type qui nomme le flux et un membre op.

{"type":"presence","op":"upsert","user":{"id":"u7","presence":"away","statusText":"Lunch"}}
{"type":"notification","op":"add","notification":{"id":"n2","title":"Build 812 passed","severity":"success"}}
{"type":"activity","op":"add","item":{"id":"a20","actorId":"u7","verb":"updated","objectName":"Invoice INV-17"}}
{"type":"log","op":"append","entry":{"level":"warning","source":"api","message":"Slow query"}}

oSource := TsgcUILiveSource_MQTT.Create(Self);
oSource.Client := MQTT;
// une liaison par modèle, choisie par son topic
oBinding := oSource.Bindings.Add;
oBinding.Target := PresenceModel;
oBinding.Topic := 'ops/presence';
oBinding := oSource.Bindings.Add;
oBinding.Target := NotificationModel;
oBinding.Topic := 'ops/notifications';
oBinding := oSource.Bindings.Add;
oBinding.Target := ActivityModel;
oBinding.Topic := 'ops/activity';
oBinding := oSource.Bindings.Add;
oBinding.Target := LogModel;
oBinding.Topic := 'ops/log/+';
// la source ne s'abonne jamais : abonne-toi dans OnMQTTConnect du client
MQTT.Subscribe('ops/#');

Les sources en direct relèvent uniquement de l'édition Enregistrée et demandent sgcWebSockets, comme chaque pont sgcWebSockets de sgcUI. Sans serveur, ou dans un build Community, l'application appelle à la place l'API de chaque modèle : AddOrUpdate et SetStatus du modèle de présence, Add ou Post du modèle de notifications, Add du modèle d'activité et Append du modèle de journal.

Lis la rubrique d'aide sur les sources en direct

• Modèles : TsgcUIPresenceModel (espace de noms esegece.sgcUICore), TsgcNotificationModel et TsgcNotificationPreferences (esegece.sgcNavigation), TsgcToolbarBadgeLink (esegece.sgcToolbar), TsgcDashboardActivityModel (esegece.sgcDashboard) et TsgcGridLogModel avec TsgcGridLogLink (esegece.sgcGrid).
• Contrôles : TsgcWinFormsAvatar, TsgcWinFormsToastManager, TsgcWinFormsNotificationInbox, TsgcWinFormsActivityFeed, TsgcWinFormsAuditTrail et les autres contrôles, chacun avec son jumeau TsgcWpf et TsgcAvalonia.
• Sources en direct : TsgcUILiveSource_WebSocket, TsgcUILiveSource_MQTT et TsgcUILiveSource_SSE dans le package esegece.sgcUICore.sgcWebSockets, édition Enregistrée uniquement.
• Les packages Community gratuits sur NuGet, comme esegece.sgcNavigation.Community et esegece.sgcGrid.Community, laissent de côté les mêmes parties que les builds Delphi Community.
• La démo .NET a des hôtes WinForms, WPF et Avalonia au-dessus d'un projet partagé avec les modèles, le simulateur et l'auto-test.

Aide : Packages .NET et Pack Realtime UI.