Raggiungi un browser chiuso, da Delphi

· Componenti
Raggiungi un browser chiuso, da Delphi

Ci sono tre tipi di utente in attesa che la tua applicazione dica loro qualcosa: quello che sta guardando la pagina, quello il cui proxy aziendale non lascia passare un WebSocket, e quello che ha chiuso il browser due ore fa. sgcWebSockets 2026.10 copre tutti e tre.

Il proxy che non lascia passare un WebSocket

I Server-Sent Events sono HTTP semplice: una GET che resta aperta e un flusso di testo. Niente lungo il percorso può obiettare. Il motore sgcHTML ora può trasportare i suoi aggiornamenti in questo modo invece che tramite un WebSocket, e alla pagina si può dire di decidere da sola:

FEngine.SSE.Enabled := True;
FEngine.SSE.Endpoint := '/events';
FEngine.SSE.PostEndpoint := '/events/send';
FEngine.SSE.ReplaySize := 100;

FTemplate.Transport := htAuto;   { htWebSocket, htSSE or htAuto }

Con htAuto la pagina apre un WebSocket e passa da sola al flusso di eventi quando non ci riesce. Il buffer di replay fa sì che un lettore rimasto disconnesso per un momento riceva gli aggiornamenti persi nel frattempo, invece di un buco.

La parte che vale la pena sottolineare: questo funziona con il server HTTP semplice. Inviare aggiornamenti a una pagina non richiede più affatto il server WebSocket.

L'utente che ha chiuso il browser

Web Push raggiunge un browser che non è sulla tua pagina, e persino uno che non è in esecuzione. La pagina si iscrive, la tua applicazione memorizza l'iscrizione ovunque tenga i suoi dati, e una singola chiamata invia la notifica:

uses
  sgcHTML_WebPush;

FWebPush := TsgcHTMLWebPush.Create(Self);
FWebPush.Enabled := True;
FWebPush.VAPIDPublicKey := ReadSetting('vapid.public');
FWebPush.VAPIDPrivateKey := ReadSetting('vapid.private');
FWebPush.Subject := 'mailto:info@example.com';
FWebPush.OnSaveSubscription := DoSaveSubscription;
FWebPush.OnLoadSubscriptions := DoLoadSubscriptions;
FWebPush.OnDeleteSubscription := DoDeleteSubscription;

FEngine.WebPush := FWebPush;

FWebPush.Send('user-42', 'Order 1042 shipped',
  'It left the warehouse this morning.', '/orders/1042');

La libreria possiede il protocollo: il payload cifrato, la firma VAPID, il TTL e l'header di urgenza. La tua applicazione possiede la memorizzazione, tramite tre eventi, perché dove vivono le iscrizioni è una decisione che solo tu puoi prendere. Un'iscrizione che il servizio push ha ritirato torna tramite OnSubscriptionExpired così puoi eliminarla.

Il componente che sceglie tra i due

Avere due canali è utile solo se qualcosa sceglie. Il componente di notifica ora lo fa: un utente che sta guardando la pagina riceve la notifica nella pagina, e uno che non lo è riceve un web push, quando l'applicazione dice che è consentito. Una notifica, una chiamata, e l'utente non viene avvisato due volte.

E i due componenti attorno ad esso

Una casella di notifiche. Una campanella con un badge di non lette e le notifiche di un utente, con segna come letta e svuota, così una notifica mancata non è una notifica persa.

Una tabella delle preferenze di notifica. Dove una persona spunta come le arriva ogni tipo di notifica. È la parte che tutti rimandano, ed è quella che ti tiene fuori dai guai con chi non ha chiesto di ricevere notifiche push.

Entrambi funzionano in ogni edizione, tramite WebSocket o tramite Server-Sent Events.

Edizioni

Server-Sent Events, la casella e la tabella delle preferenze fanno parte di sgcHTML. Web Push stesso, la parte che raggiunge un browser chiuso, richiede SGC_WEBPUSH, ovvero le edizioni Enterprise e All-Access.

Aggiornamento

Tutto questo è disattivato di default. Una pagina esistente mantiene il proprio trasporto WebSocket e renderizza lo stesso markup finché non imposti Transport, assegni un WebPush o trascini uno dei due nuovi componenti su un form.

Continua a leggere

Guardalo in video

C'è un breve video su questo sul canale eSeGeCe.

Domande, feedback o aiuto per la migrazione? Mettiti in contatto — riceverai una risposta dalle persone che hanno scritto il codice.