Alcance um navegador fechado, a partir do Delphi

8 de outubro de 2026 · Componentes

Existem três tipos de usuário esperando que sua aplicação lhes diga algo: o que está olhando para a página, aquele cujo proxy corporativo não deixa passar um WebSocket, e o que fechou o navegador duas horas atrás. O sgcWebSockets 2026.10 cobre os três.

O proxy que não deixa passar um WebSocket

Server-Sent Events são HTTP simples: um GET que permanece aberto e um fluxo de texto. Nada no caminho pode objetar a isso. O motor sgcHTML agora pode transportar suas atualizações dessa forma em vez de por um WebSocket, e a página pode ser instruída a decidir por conta própria:

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

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

Com htAuto a página abre um WebSocket e recorre por conta própria ao fluxo de eventos quando não consegue. O buffer de replay faz com que um leitor que ficou desconectado por um instante receba as atualizações perdidas nesse meio-tempo, em vez de um buraco.

A parte que merece destaque: isso funciona com o servidor HTTP simples. Enviar atualizações a uma página não exige mais o servidor WebSocket.

O usuário que fechou o navegador

O Web Push alcança um navegador que não está na sua página, e até mesmo um que não está em execução. A página se inscreve, sua aplicação armazena a inscrição onde quer que guarde seus dados, e uma única chamada envia a notificação:

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');

A biblioteca é dona do protocolo: o payload criptografado, a assinatura VAPID, o TTL e o cabeçalho de urgência. Sua aplicação é dona do armazenamento, por meio de três eventos, porque onde as inscrições ficam guardadas é uma decisão que só você pode tomar. Uma inscrição que o serviço de push aposentou volta por meio de OnSubscriptionExpired para que você possa descartá-la.

O componente que decide entre os dois

Ter dois canais só é útil se algo escolher entre eles. O componente de notificação agora faz isso: um usuário que está olhando para a página recebe a notificação na página, e um que não está recebe um web push, quando a aplicação diz que isso é permitido. Uma notificação, uma chamada, e o usuário não é avisado duas vezes.

E os dois componentes ao redor dele

Uma caixa de entrada de notificações. Um sino com um selo de não lidas e as notificações de um usuário, com marcar como lida e limpar, de modo que uma notificação perdida não seja uma notificação desaparecida.

Uma tabela de preferências de notificação. Onde uma pessoa marca como cada tipo de notificação deve chegar até ela. É a parte que todo mundo adia, e a que te livra de problemas com pessoas que não pediram para receber notificações push.

Ambos funcionam em todas as edições, por WebSocket ou por Server-Sent Events.

Edições

Server-Sent Events, a caixa de entrada e a tabela de preferências fazem parte do sgcHTML. O próprio Web Push, a parte que alcança um navegador fechado, exige SGC_WEBPUSH, que são as edições Enterprise e All-Access.

Atualização

Tudo isso vem desativado por padrão. Uma página existente mantém seu transporte WebSocket e renderiza o mesmo markup até que você defina Transport, atribua um WebPush ou solte um dos dois novos componentes em um formulário.

Assista ao vídeo

Há um vídeo curto sobre isso no canal da eSeGeCe.

Dúvidas, feedback ou ajuda com a migração? Entre em contato — você receberá uma resposta das pessoas que escreveram o código.