Er zijn drie soorten gebruikers die wachten tot je applicatie hen iets vertelt: degene die naar de pagina kijkt, degene wiens bedrijfsproxy geen WebSocket doorlaat, en degene die de browser twee uur geleden heeft gesloten. sgcWebSockets 2026.10 dekt alle drie.
De proxy die geen WebSocket doorlaat
Server-Sent Events zijn gewone HTTP: een GET die open blijft en een stroom tekst. Niets onderweg kan er bezwaar tegen maken. De sgcHTML-engine kan zijn updates nu op die manier versturen in plaats van via een WebSocket, en de pagina kan zelf laten beslissen:
FEngine.SSE.Enabled := True;
FEngine.SSE.Endpoint := '/events';
FEngine.SSE.PostEndpoint := '/events/send';
FEngine.SSE.ReplaySize := 100;
FTemplate.Transport := htAuto; { htWebSocket, htSSE or htAuto }Met htAuto opent de pagina een WebSocket en valt zelf terug op de event stream wanneer dat niet lukt. De replay-buffer zorgt ervoor dat een lezer die even niet verbonden was, de gemiste updates alsnog krijgt, in plaats van een gat.
Het deel dat het benadrukken waard is: dit werkt met de gewone HTTP-server. Updates naar een pagina pushen vereist helemaal geen WebSocket-server meer.
De gebruiker die de browser heeft gesloten
Web Push bereikt een browser die niet op je pagina is, en zelfs een die niet draait. De pagina abonneert zich, je applicatie slaat het abonnement op waar het zijn data ook bewaart, en één aanroep verstuurt de melding:
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');De library bezit het protocol: de versleutelde payload, de VAPID-handtekening, de TTL en de urgency-header. Je applicatie bezit de opslag, via drie events, want waar abonnementen leven is een beslissing die alleen jij kunt nemen. Een abonnement dat de pushdienst heeft ingetrokken, komt terug via OnSubscriptionExpired, zodat je het kunt verwijderen.
Het component dat tussen de twee kiest
Twee kanalen hebben is alleen nuttig als iets ertussen kiest. Het meldingencomponent doet dat nu: een gebruiker die naar de pagina kijkt, krijgt de melding in de pagina, en een die dat niet doet krijgt een web push, wanneer de applicatie zegt dat dat is toegestaan. Eén melding, één aanroep, en de gebruiker wordt niet twee keer op de hoogte gebracht.
En de twee componenten eromheen
Een meldingeninbox. Een bel met een ongelezen-badge en de meldingen van één gebruiker, met lezen en wissen, zodat een gemiste melding geen verloren melding is.
Een meldingsvoorkeurentabel. Waar iemand aanvinkt hoe elk type melding hem bereikt. Het is het onderdeel dat iedereen uitstelt, en het onderdeel dat je uit de problemen houdt met mensen die niet hebben gevraagd om gepusht te worden.
Beide werken in elke editie, via WebSocket of via Server-Sent Events.
Edities
Server-Sent Events, de inbox en de voorkeurentabel maken deel uit van sgcHTML. Web Push zelf, het deel dat een gesloten browser bereikt, heeft SGC_WEBPUSH nodig, dat zijn de edities Enterprise en All-Access.
Upgraden
Alles hier staat standaard uit. Een bestaande pagina behoudt zijn WebSocket-transport en rendert dezelfde markup totdat je Transport instelt, een WebPush toewijst of een van de twee nieuwe componenten op een formulier plaatst.
Lees verder
- Voer je Delphi-app uit binnen ChatGPT en Claude
- Verander een screenshot in een Delphi-webpagina
- sgcWebSockets 2026.10, al het overige uit deze release
Bekijk het
Er is een korte video hierover op het eSeGeCe-kanaal.
Vragen, feedback of hulp bij migratie? Neem contact op — je krijgt antwoord van de mensen die de code hebben geschreven.