Canais Comunicacionais

Todos os seres vivos, de uma forma ou de outra, ao relacionarem-se com outros, comunicam e/ou colaboram. Conseguir comunicar ou colaborar é um ato inerente a seres que de alguma forma também interpretam não só o outro ser com quem se relacionam, mas o contexto ou o ambiente em que essa relação se vai estabelecer. Os canais comunicacionais permitem a participação efetiva do utilizador no tratamento de qualquer assunto em qualquer momento. No sentido de tornar o utilizador ativo e de dotar este sistema da eficácia necessária, foi desenvolvido um conceito de comunicação Humano-Humano, assente em três pressupostos essenciais:

⎯ Existir abstração total do meio utilizado para comunicar, isto é, o canal utilizado deve ser “transparente” para o utilizador, não existindo a “consciência” de que se está a utilizar um serviço em particular.

⎯ Integração com plataformas de comunicação existentes – a quantidade de plataformas que permitem

comunicar e os diferentes tipos de comunicação que disponibilizam são vastos. Pretende-se, por isso, contrariar essa perspetiva de que cada plataforma tem de ter os seus próprios canais comunicacionais e mostrar que é possível integrar, em ambiente web, canais comunicacionais já existentes.

⎯ Garantia de comunicação no momento em que esta é necessária: por vezes, devido à falta de meios e

ao que os canais comunicacionais existentes disponibilizam, não é possível contactar no imediato, o que pode causar grande constrangimento. Devido a essa falta de garantia, pretende-se aqui apresentar um modelo que possa garantir que é possível contactar a pessoa no imediato.

O modelo adotado tem como fundamento principal a realização de um mapeamento dos canais disponibilizados, seguido de uma escolha da melhor opção tendo em conta o meio selecionado (texto; voz; vídeo). O sistema é dotado de uma capacidade de decisão através da realização de uma avaliação de disponibilidade em relação aos canais registados pelo utilizador. A Figura 36 mostra o que se pretende com este sistema, oferecendo a tal abstração quanto ao canal que está verdadeiramente a ser utilizado.

Figura 36 - Mapeamento de Canais Comunicacionais (H2H)

Para tal, e para simulação dos vários canais, foi desenvolvida uma página de perfil de utilizador, onde pode disponibilizar credenciais de acesso a plataformas existentes e que fornecem canais comunicacionais próprios, tais como WhatsApp37 e Hangouts38. Além disso, também é possível registar o contacto telefónico tendo em vista a utilização de serviços como o Short Message Service (SMS) e chamadas telefónicas. Apesar da presença de encriptação destes dados, obviamente que no futuro o objetivo passa por aceder a estes dados através de um protocolo de autorização (ex.: oAuth³⁹).

37 https://www.whatsapp.com/

38 https://hangouts.google.com/

Sabendo da existência de múltiplos canais de comunicação e da dificuldade em definir apenas uma plataforma comunicacional em toda a rede, a proposta aqui apresentada passa pela reutilização de canais existentes, mas tornando-os invisíveis para o utilizador final. Além dessa reutilização, também se pretende aqui garantir uma comunicação eficaz.

Para demonstrar este comportamento, foi desenvolvido um conjunto de processos em relação à comunicação através de mensagens de texto. Os canais utilizados para este tipo de comunicação passaram pela integração de comunicação disponibilizada pela Google (Hangouts) através do protocolo XMPP, assim como pela integração do serviço Twilio40, tendo em vista o envio de SMS.

Antes de avançar para os processos de envio e receção de mensagens, é importante voltar a referir que foi implementada uma “vinculação” a um evento no dashboard, através da API Pusher, tendo em vista as atualizações de estado de cada utilizador relacionado (quanto à disponibilidade de comunicação através da web) e a aceleração no processo de decisão em relação à escolha do canal a usar. Como esta verificação apenas

assenta sobre o canal Google (XMPP) implementado, o evento designa-se de “updateXMPPContactsStatus”

(Código 24).

Código 24 - Evento de Atualização de Estado (Online/Offline)

Caso o utilizador tenha disponibilizado os dados da sua conta Google, sempre que faça login ou logout na rede, todos os utilizadores relacionados recebem essa alteração de estado através da presença deste listener. O mesmo acontece se o utilizador entrar ou sair numa plataforma da Google ou outra plataforma “não-Google” que integre os seus canais comunicacionais. Além disso, e de forma a acelerar o processo de envio de uma mensagem, existe um registo do lado do cliente sobre os canais de cada utilizador quanto à ordem preferencial de comunicação e estado atual de cada canal (neste caso só é registado o estado do canal Google). Estes dados permitem que a decisão do lado do servidor seja mais rápida, visto que não precisa de realizar verificações de estado que estão constantemente a ser atualizadas do lado do cliente. O processo de envio de uma mensagem de texto, após esta ser redigida e a ação de envio tenha sido realizada (pedido ao servidor com dados sobre os canais do recetor), é o seguinte:

1. Verificação dos canais disponíveis por parte do remetente da mensagem;

2. Realização do matching entre os canais do remetente e do recetor. Vista a utilização de canais via web “externos” à rede, é necessário que a mensagem seja enviada e recebida pelos mesmos canais, ou seja, caso algum canal do remetente seja igual ao canal preferencial do recetor e caso seja um canal presente na web e o recetor esteja online, a mensagem é enviada por esse canal. Mas caso isso não seja possível, então são percorridas todas as outras opções, tais como, outros canais na web (caso esteja o recetor esteja online e faça matching com algum canal do remetente), SMS, e-mail, até que a mensagem seja enviada. Visto que no protótipo foi implementado um canal XMPP e um serviço de envio de SMS, caso o recetor esteja representado com o estado “online” significa que está disponível para uma

comunicação nesse canal XMPP (web). No envio da mensagem, se o remetente também beneficiar de

40 https://www.twilio.com/

uma conta que se ligue ao mesmo canal XMPP, a mensagem é por aí enviada, senão é enviada por SMS (caso esteja disponível o contacto telefónico do recetor) ou, por último, através do e-mail. De maneira a oferecer uma visão mais simples sobre o processo de envio, é apresentado um diagrama de atividades na Figura 37.

Figura 37 - Processo de envio de mensagem de texto

Quanto ao processo de receção de mensagens de texto, neste caso só implementado através do canal XMPP,

existe no dashboard uma “vinculação” a um evento (através da API Pusher) que “dispara” sempre que uma

mensagem é recebida – “onTextMessagereceiveXMPP” (Código 25).

Código 25 - Evento de Receção de Mensagem de Texto

Isto acontece devido a um processo que executa no servidor e que está atento a atualizações que ocorram no canal XMPP (estado dos utilizadores e mensagens), visto que cada vez que o utilizador faz login na rede,é também realizado o login do mesmo nos canais, iniciando esse processo de “escuta”. De notar que este processo termina caso o utilizador faça logout na rede. O desenvolvimento deste processo foi auxiliado pela biblioteca

XMPPHP41 (Código 26).

41 https://code.google.com/archive/p/xmpphp/

Código 26 - Processo de "escuta" de eventos em relação a uma conta de utilizador (XMPP)

Nesta lógica de comunicação e tendo em consideração o estado das plataformas atuais, a existência de vários tipos de aplicações (web, mobile), disponibilizadas pelas plataformas comunicacionais integradas, constituem outra vantagem para este modelo. Caso haja preferência pela utilização de uma certa aplicação, o utilizador não fica restringido a estar com o login realizado na rede federada, e consegue na mesma comunicar com todos os outros utilizadores que estejam ou não com login realizado nessa mesma rede federada. Ou seja, este modelo, além de oferecer a “transparência” na utilização dos canais dentro da rede, não força a sua utilização, concedendo liberdade ao utilizador na sua escolha aplicacional, embora dessa forma possa não seguir os modelos apresentados anteriormente, como o de ter tudo o que necessita no mesmo dashboard.

Por fim, temos a implementação do envio de SMS como um canal de recurso à falha dos canais web, à exceção do e-mail (colocado, preferencialmente, em último lugar). Como referido anteriormente, este canal foi implementado através da integração de um Cloud Based Service designado de Twilio.

O Twilio é um serviço que permite o envio de SMS e a realização de chamadas de voz/vídeo através da Cloud. A integração desta API é realizada com segurança, isto é, na sua utilização é necessário indicar dois parâmetros: o Account SID e o Auth Token. Com isto, é possível o serviço reconhecer a conta que está a ser utilizada. Dentro da lógica de comunicação desenvolvida, caso não seja possível enviar uma mensagem de texto para um dos canais preferenciais em relação ao SMS, o sistema trata de “despachar” a mensagem de texto através do serviço Twilio, fazendo chegar um SMS ao recetor da mensagem. No Código 27, é possível visualizar a integração do Twilio tendo em vista o envio de um SMS.

Código 27 - Integração do Serviço Twilio