Atualizando o Cliente Diretamente

Ao usar o sistema de mensagens WebSockets, é possível atualizar elementos de UI do cliente diretamente. Isso elimina a necessidade de enviar uma requisição Ajax ao servidor para cada atualização e pode reduzir o tráfego HTTP em sistemas com muitas sessões. Essa abordagem é particularmente útil quando você precisa atualizar a UI do cliente com frequência em intervalos curtos (por exemplo, uma ou duas vezes por segundo). Em tais cenários, a abordagem convencional (onde cada mensagem de socket provoca uma requisição Ajax) pode causar tráfego intenso com muitas sessões concorrentes.

Para uma aplicação web típica você provavelmente não precisará atualizar o cliente diretamente — você pode simplesmente atualizar o cliente escrevendo um handler de evento apropriado para o evento OnBroadcastMessage. Entretanto, se você precisa atualizar a UI do cliente regularmente e com frequência, ou a parte atualizada é muito pequena, você pode chamar BroadcastMessage com a opção boClientOnly. Isso impede que o cliente envie uma requisição Ajax ao servidor. A mensagem deve ser tratada em um evento JavaScript do lado do cliente chamado socketmessage.

Abaixo analisamos a demonstração denominada "WebSocket - Client Update".

Existe um componente TUniThreadTimer colocado em ServerModule que gera mensagens WebSocket de forma assíncrona.

clip0248

1

Atualização no lado do cliente (boClientOnly)

Handler do evento do timer no servidor:

Server: UniThreadTimer1Timer

procedure TUniServerModule.UniThreadTimer1Timer(Sender: TObject);
begin
  BroadcastMessage('update',
                   [
                     'value', Random(1000)
                   ],
                   [boClientOnly]);
end;

Uma mensagem chamada update é enviada para todos os clientes existentes com um argumento chamado value que é um inteiro aleatório entre 0 .. 999. O timer está ajustado para enviar uma mensagem uma vez por segundo. A boClientOnly opção garante que a mensagem será processada somente no lado do cliente e nenhuma requisição Ajax será disparada para este evento.

Handler de evento JavaScript do lado do cliente:

Client: form.socketmessage

function form.socketmessage(sender, msg, params, eOpts)
{
  if (msg == 'update') {
      MainForm.UniLabel1.setText(params.value);
  }
}

Executar a demonstração faz com que o rótulo do cliente seja atualizado uma vez por segundo com o valor aleatório:

clip0250

2

Atualização no lado do servidor (sem boClientOnly)

Para comparação, remova a boClientOnly opção no servidor e não trate a mensagem no cliente. Em vez disso, use um handler de broadcast no lado do servidor para atualizar a UI.

Handler do evento do timer no servidor (sem boClientOnly):

Server: UniThreadTimer1Timer (no boClientOnly)

procedure TUniServerModule.UniThreadTimer1Timer(Sender: TObject);
begin
  BroadcastMessage('update',
                   [
                     'value', Random(1000)
                   ]);
end;

Remova ou esvazie o handler de evento do lado do cliente:

Client: form.socketmessage (vazio)

function form.socketmessage(sender, msg, params, eOpts)
{
}

Adicione um handler do lado do servidor para atualizar o rótulo:

Server: UniFormBroadcastMessage (MainForm)

procedure TMainForm.UniFormBroadcastMessage(const Sender: TComponent;
  const Msg: string; const Params: TUniStrings);
begin
  if Msg = 'update' then
    UniLabel1.Caption := Params['value'].AsString;
end;

Do ponto de vista do usuário o resultado é o mesmo — o rótulo é atualizado uma vez por segundo:

clip0249

A principal diferença é que, com o evento no lado do servidor, um evento Ajax é gerado para cada atualização e para cada cliente ativo. O mesmo resultado frequentemente poderia ser alcançado colocando um UniTimer no formulário e atualizando o rótulo no seu handler de timer sem usar WebSockets. Portanto, em cenários com atualizações frequentes e pequenas onde a escalabilidade é uma preocupação, a atualização no lado do cliente (usando boClientOnly e tratando a mensagem em socketmessage) é a abordagem preferida.

Use boClientOnly e o tratamento socketmessage no lado do cliente quando você precisar de atualizações frequentes e pequenas para muitos clientes — isso evita gerar uma requisição Ajax por atualização e ajuda na escalabilidade.