5. Conclusão

Construímos a seguinte aplicação cliente/servidor:

Para chegar à versão final do código, tivemos de explicar vários aspetos dos frameworks AngularJS e Spring 4. Este documento pode, portanto, ser utilizado para aprender a utilizar estes dois frameworks. O parágrafo 1.3 explica onde encontrar os códigos e como os utilizar.

Demonstrámos que a aplicação cliente/servidor era utilizável em diversos ambientes:

• como uma aplicação web clássica;
• como um binário executável em emuladores Android;

Mais uma vez, este tutorial não é exaustivo no que diz respeito ao estudo dos dois frameworks. No caso do Angular, seria certamente necessário apresentar as ferramentas de teste que o acompanham. Os testes são etapas indispensáveis na criação de uma aplicação. As ferramentas associadas ao Angular permitem automatizá-los e incluí-los num processo de integração contínua.

Deste trabalho, retenho dois pontos:

• a criação do serviço web Spring foi moderadamente complicada. Desde o início, conhecia bem os conceitos do Spring. Só encontrei dificuldades com a segurança do serviço web e, mais tarde, com a gestão dos cabeçalhos HTTP CORS, duas áreas que desconhecia;
• a criação do cliente Angular foi muito mais complexa por várias razões:
  • Não tinha conhecimentos suficientes sobre a linguagem JavaScript e as suas possibilidades;
  • tive dificuldade em compreender como funcionava a programação assíncrona no navegador. Raciocinava como se estivesse num servidor, onde essa assincronia é obtida através da utilização simultânea de vários threads. No navegador, existe apenas um thread, e as tarefas assíncronas são processadas sucessivamente e não em paralelo. Mais concretamente, as tarefas assíncronas podem ser executadas em paralelo (por exemplo, múltiplas solicitações HTTP), mas os eventos que elas geram quando concluídas são, por sua vez, processados sequencialmente. Não há, portanto, execução simultânea para gerir, com os inúmeros problemas que isso acarreta;
  • O Angular é um framework rico, com inúmeros conceitos (MVC, diretivas, serviços, escopo dos modelos, etc.). A sua aprendizagem é demorada;
  • O Angular não impõe um método de desenvolvimento específico. Assim, para chegar ao mesmo resultado, é possível utilizar diferentes arquiteturas. Isto é confuso. Sinto-me mais à vontade com frameworks fechados, onde todos utilizam os mesmos padrões de conceção (design patterns). Por isso, procurei constantemente reproduzir os padrões de conceção que utilizo no lado do servidor. Estou satisfeito com o resultado, pois considero-o reproduzível. Era isso que procurava. Mas não sei de todo se me afastei ou não das «boas práticas» do Angular;

Serge Tahé, julho de 2014.