Są trzy rodzaje użytkowników czekających, aż twoja aplikacja im coś powie: ten, który patrzy na stronę, ten, którego firmowe proxy nie przepuszcza WebSocketu, oraz ten, który zamknął przeglądarkę dwie godziny temu. sgcWebSockets 2026.10 obejmuje wszystkie trzy.
Proxy, które nie przepuszcza WebSocketu
Server-Sent Events to zwykłe HTTP: GET, które pozostaje otwarte, i strumień tekstu. Nic po drodze nie może mieć nic przeciwko temu. Silnik sgcHTML może teraz przenosić w ten sposób swoje aktualizacje zamiast przez WebSocket, a strona może sama zdecydować:
FEngine.SSE.Enabled := True;
FEngine.SSE.Endpoint := '/events';
FEngine.SSE.PostEndpoint := '/events/send';
FEngine.SSE.ReplaySize := 100;
FTemplate.Transport := htAuto; { htWebSocket, htSSE or htAuto }Przy htAuto strona otwiera WebSocket, a gdy się nie da, sama przechodzi na strumień zdarzeń. Bufor powtórki sprawia, że czytelnik, który był chwilę odłączony, dostaje aktualizacje, które przegapił, zamiast dziury.
Część warta podkreślenia: to działa ze zwykłym serwerem HTTP. Wypychanie aktualizacji do strony w ogóle nie wymaga już serwera WebSocket.
Użytkownik, który zamknął przeglądarkę
Web Push dociera do przeglądarki, która nie jest na twojej stronie, a nawet do takiej, która w ogóle nie działa. Strona subskrybuje, twoja aplikacja zapisuje subskrypcję tam, gdzie trzyma swoje dane, a jedno wywołanie wysyła powiadomienie:
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');Biblioteka jest właścicielem protokołu: zaszyfrowanego ładunku, podpisu VAPID, TTL i nagłówka pilności. Twoja aplikacja jest właścicielem przechowywania, przez trzy zdarzenia, ponieważ to, gdzie żyją subskrypcje, jest decyzją, którą możesz podjąć tylko ty. Subskrypcja wycofana przez usługę push wraca przez OnSubscriptionExpired, żebyś mógł ją usunąć.
Komponent, który wybiera między nimi
Posiadanie dwóch kanałów jest użyteczne tylko wtedy, gdy coś między nimi wybiera. Komponent powiadomień robi to teraz: użytkownik, który patrzy na stronę, dostaje powiadomienie w stronie, a ten, który nie patrzy, dostaje web push, gdy aplikacja mówi, że jest to dozwolone. Jedno powiadomienie, jedno wywołanie, i użytkownik nie zostaje poinformowany dwukrotnie.
Oraz dwa komponenty wokół niego
Skrzynka powiadomień. Dzwonek z odznaką nieprzeczytanych i powiadomieniami jednego użytkownika, z oznaczaniem jako przeczytane i czyszczeniem, dzięki czemu przegapione powiadomienie nie jest powiadomieniem utraconym.
Tabela preferencji powiadomień. Gdzie człowiek zaznacza, jak ma do niego docierać każdy rodzaj powiadomienia. To część, którą każdy odkłada na później, i ta, która chroni cię przed kłopotami z ludźmi, którzy nie prosili o wypychane powiadomienia.
Oba działają w każdej edycji, przez WebSocket albo przez Server-Sent Events.
Edycje
Server-Sent Events, skrzynka i tabela preferencji są częścią sgcHTML. Sam Web Push, część docierająca do zamkniętej przeglądarki, wymaga SGC_WEBPUSH, czyli edycji Enterprise i All-Access.
Aktualizacja
Wszystko tutaj jest domyślnie wyłączone. Istniejąca strona zachowuje swój transport WebSocket i renderuje ten sam znacznik, dopóki nie ustawisz Transport, nie przypiszesz WebPush albo nie upuścisz jednego z dwóch nowych komponentów na formularzu.
Czytaj dalej
- Uruchom swoją aplikację Delphi wewnątrz ChatGPT i Claude
- Zamień zrzut ekranu w stronę internetową Delphi
- sgcWebSockets 2026.10, wszystko inne w tej wersji
Zobacz wideo
Jest na ten temat krótkie wideo na kanale eSeGeCe.
Pytania, uwagi lub pomoc przy migracji? Skontaktuj się z nami — otrzymasz odpowiedź od osób, które napisały ten kod.