Resolvi por curiosidade estudar o método estático RqlStatement.parseRqlStatement. No Javadoc da classe, pude observar que existem duas formas de utilizar o método com passagem de String para representar o RQL, algo muito comum quando estamos no mundo ATG e seus infindáveis properties de configuração. As duas formas podem ser vistas abaixo:

RqlStatement.parseRqlStatement(rql);

e

RqlStatement.parseRqlStatement(rql, cacheRqlStatement);

Quero focar meus esforços em apresentar a diferença entre esses dois métodos. Quando utilizado RqlStatement.parseRqlStatement(rql), o que realmente acontece é a execução do parse sem manter o objeto convertido em cache. Para deixar claro, esse cache é interno a classe.

Já no segundo método, o Javadoc descreve o processo da seguinte maneira:

"Parses an RqlStatement from the given String. If pCacheRqlStatement is true, then the RqlStatement that is created from this operation will be saved in an internal cache with the String pStatement as the key. The next time this same string is passed to parseRqlStatement, the cached RqlStatement will be returned, so we don't have to re-parse the same string over and over again. Only use this method for statements that you'll definitely be re-using over again, and if the code you're using does NOT cache the statement already".

Isso quer dizer que ao utilizar o segundo método ganha-se a possibilidade de armazenar no cache interno do RqlStatement uma referência do objeto convertido, não sendo necessário efetuar novamente a conversão do mesmo pela própria classe.

Para se ter uma ideia do impacto disso, montei 2 testes com JUnit: 1 sem cache e 1 com cache (informando o segundo parâmetro como true). Na imagem abaixo, pode-se ver como é alarmante a diferença entre ambos os processos quando temos 1 milhão de iterações. Sem cache o processo leva 62 segundos, mas com cache leva apenas 0,843 segundos.

Sendo assim, o melhor caminho seria utilizar RqlStatement.parseRqlStatement(rql, true), favorecendo a performance dos processos, otimizando o tempo em novas chamadas ao parse que possuam o mesmo parâmetro de RQL, não sendo necessário armazenar referências convertidas em atributos de classe, pois a classe RqlStatement faz isso.

Talvez você se sinta inclinado a querer a possibilidade de limpar esse cache quando quizer. Esse geralmente é um controle que Desenvolvedores do mundo ATG gostam de ter. Entretanto, lhe afirmo que esse não é um cache perigoso, daqueles que você realmente precisa limpar, pois algo foi atualizado em banco e agora a aplicação precisa refletir. Não! Esse é um cache interno a classe RqlStatement. Se o RQL for alterado por um properties dinâmico, tudo que a classe irá fazer na próxima iteração é armazenar o novo RQL convertido, sendo que o anterior não será mais utilizado.

Gostou? Compartilhe esse post =)

A API de Notificações permite que páginas web controlem a apresentação de notificações do sistema para o usuário final. Essas notificações estão em um nível acima da janela atual da página web, isso permite que elas sejam apresentadas mesmo que a guia não esteja selecionada, ou que você esteja utilizando um programa/aplicativo diferente. A API foi projetada para possui total compatibilidade com sistemas de notificação existentes nas diferentes plataformas.

Em plataformas compatíveis, existem dois passos muito simples para lançar notificações:

Solicitando permissão ao usuário

A solicitação de permissão para envio de notificações é um passo muito interessante. Que mundo seria esse se as notificações estivessem livres para uso desenfrado por todos os sites? Seria o carnaval eterno na web (acho que de qualquer forma isso já está acontecendo com alguns sites). Para evitar o problema clássico do uso sem limites, a API foi criada com uma premissa básica: notificações precisam ser ativadas pelo usuário final.

O seguinte código lança a solicitação de permissão, que nada mais é do que um popup, parecido com um tooptip ou popover, onde existe uma pergunta e as opções de resposta: permitir ou bloquear.

Notification.requestPermission();

Quando solicitar?

Depende. Gosto de pensar que essa decisão tem a ver com "se colocar no lugar do usuário". A maioria dos sistemas solicita a permissão ao carregar a página, mas tudo vai depender do tipo de conteúdo e do público alvo. Pense comigo, o conteúdo pode chamar mais atenção do usuário que a solicitação e ela acabar sendo ignorada. Quando uma solicitação é ignorada ela mantém o status default, ou seja, notificações não serão lançadas. O público alvo pode resultar no mesmo problema, pois se o seu sistema atinge pessoas que tem pouco ou nenhum conhecimento do que seria uma notificação elas podem simplesmente ignorar ou até bloquear (status "denied") a solicitação. Por padrão, os browsers não efetuam múltiplas solicitações de permissão se o usuário já bloqueou a primeira.

Lançando notificações

Após obter a permissão do usuário, seu sistema está apto a lançar notificações. O status da API está "granted" e criar uma notificação é muito simples:

new Notification(title, options);

title: Na notificação, o title fica na parte superior, com mais destaque;
options: Existem diversas opções de configuração, porém as que você realmente precisa conhecer são body e icon. O body recebe um texto mais descritivo, mais longo que o title, e que será apresentado no centro da notificação. Já o icon é uma url de uma imagem para ser apresentada na esquerda da notificação.




Isso é o suficiente para sua notificação ser apresentada ao usuário =)

Na imagem demonstrada acima você pode observar um exemplo de notificação existente no Queiroz.js. Já falei do Queiroz.js aqui no blog. No Queiroz.js, utilizo as notificações para avisar aos usuários de que alguns determinados horários do dia estão próximos de chegar. Isso ajuda consideravelmente o usuário que pode estar efetuando atividades em outras janelas, mas mesmo assim verá a notificação. Esse é um exemplo real, e foi utilizado exatamente da mesma forma que explico acima.

Você deseja que o usuário aceite a permissão, pois ele entende aquilo e sabe do que se trata, ou você simplesmente quer que ele aceite e viva com uma notificação que pode se tornar algo muito estressante e gerar críticas ruins? A maioria dos sites não se importa com a resposta para essa pergunta. Não seja mais um nesse grupo.