Definições de linguagem e bibliotecas

Pontos-chave:

• Questionário inicial para o time;
• Conhecimento geral do time em Flutter;
• Execelente compatibilidade entre Flutter e Firebase.

Escolhas:

• Tecnologia: Flutter;
• Linguagem: Dart;
• Frameworks: Firebase.

Antes de começar o desenvolvimento do projeto foi feito um questionário para o time para quantificar o conhecimento dos alunos em diversas tecnologias, frameworks e bancos de dados para determinar quais as tecnologias que seriam mais fáceis de acordo com o conhecimento geral da equipe.

O time optou por utilizar a tecnologia Flutter juntamente com a linguagem Dart para criação do aplicativo mobile devido a familiaridade de alguns integrantes do time com a tecnologia e pelo fato de que os stakeholders indicaram a necessidade de desenvolvimento de uma versão Android e uma versão iOS, cenário no qual o Flutter é uma ótima opção.

Para desenvolvimento do backend o time escolheu utilizar o framework Firebase devido a familiaridade de alguns integrantes com a framework e pelo fato de que o Firebase fornece diversos recursos prontos, como: Persistência, Autenticação e Notificações, recursos esses que atendem perfeitamente a demanda do projeto, tirando a complexidade do backend e trazendo o maior esforço da equipe para desenvolvimento das funcionalidades principais.

Arquitetura Frontend

Para desenvolvimento do projeto foi escolhido o padrão arquitetural MVP(Model View Presenter) como forma de organização e definição das responsabilidades de cada camada do programa. O padrão MVP foi escolhido por ser uma arquitetura com uma menor curva de aprendizado comparada a arquiteturas que dependem diretamente de conceitos de programação reativa. Além disso, o padrão arquitetural MVP possui uma boa modularização dos componentes e consequentemente uma melhor testabilidade do sistema.

Módulos do Sistema:

• Model: Camada onde ficam contidos as classes dos objetos que manipulamos ao longo do projeto. Normalmente são os objetos provindos do banco de dados.

• View: Parte visual da aplicação (telas), sua responsabilidade é exibir as informações para o usuário, chamar a camada de presenter para acessar algum dado e reagir as diferentes interações que o usuário pode exercer na tela (ex: toque de um botão).

• Presenter: Camada responsável por fazer a comunicação entre a view e as classes de serviços. A Presenter tem como responsabilidade fazer as chamadas das funções dos respositories, processar o retorno dos dados para mostrar apenas o que é necessário exibir e, por ultimo, tem a responsabilidade de chamar as funções da view para atualização da parte visual.

• Repository: Camada responsável por realizar a conexão com a API, sua função é fazer as chamadas para a API (através de métodos HTTP) e retornar sucesso/erro para a presenter controlar o que será apresentado.

• Routes: Classe responsável por ter uma referência para todas as rotas de navegação do app, facilitando assim a mudança entre as telas.

Design System:

• Components: Contém todos os componentes que serão reutilizáveis ao longo do projeto. (ex: Botão principal)

• App theme: Nesse arquivo está contido a definição do theme exibido pelo aplicativo. Através desse arquivo é possível personalizar diversas configurações (cores principais, fontes e etc) que serão utilizados pelo app.

• Colors: Definição das cores utilizadas ao longo do projeto. Esse arquivo tem como objetivo centralizar as cores do projeto, provendo assim, um maior controle quando alguma cor for alterada, no qual reflete em todos os items que utilizam aquela cor.

• Strings: Valores String literais utilizados no projeto. Esse arquivo tem como objetivo centralizar a declaração das strings utilizadas no projeto, tornando assim mais fácil a manipulação dos valores e consequentemente evita o uso de literais dentro do código.

• Font family: Definição das fontes utilizadas ao longo do projeto. Esse arquivo tem como objetivo centralizar as fontes do projeto, provendo assim, um maior controle quando alguma fonte for alterada, no qual reflete em todos os items que utilizam aquela fonte.

Diagrama do Sistema:

Maneira que as camadas do sistema se comunicam. Primeiramente, a camada de View tem acesso a camada de Routes, podendo assim, realizar a navegação para as outras views (telas). Dentro da camada de View, estará contida uma instância da classe Presenter e, através dela, serão feitas as chamadas das funções que irão manipular os dados e a interface estabelecida pela view (através dessa interface irá ser feita a comunicação para atualização da view). Já na camada de Presenter estará contida a instância do Firebase e toda lógica envolvida para realizar as chamadas.

Convenções

• Usaremos camelCase como padrão de nomenclatura de métodos e variáveis;
• Nome dos membros private de classe devem iniciar com _ (peculiaridade da linguagem Dart);
• O nome das intefaces definidas (classes abstratas) devem ser pré-fixados com 'I';
• O nome das models deve ser pós-fixado com a palavra "Model";