| ... | ... | @@ -18,7 +18,12 @@ Esta seção irá abordar a arquitetura selecionada para o Backend e Frontend ex |
|
|
|
- [Firebase](#firebase)
|
|
|
|
- [Integração](#integração)
|
|
|
|
- [Diagrama de Comunicação](#diagrama-de-comunicação)
|
|
|
|
- [Diagrama do Sistema](#diagrama-de-sistema)
|
|
|
|
- [Padrão Arquitetural Front-end](#padrão-arquitetural-front-end)
|
|
|
|
- [Módulos do Sistema](#módulos-do-sistema)
|
|
|
|
- [Design System](#design-system)
|
|
|
|
- [Estrutura](#estrutura)
|
|
|
|
- [Features](#features)
|
|
|
|
- [Shared](#shared)
|
|
|
|
|
|
|
|
# Tecnologias
|
|
|
|
|
| ... | ... | @@ -70,6 +75,77 @@ Abaixo está representado graficamente como funciona a comunicação do front-en |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Diagrama do Sistema
|
|
|
|
# Padrão Arquitetural Front-end
|
|
|
|
Para o projeto em questão, foi definida uma arquitetura chamada de MVVM para desenvolvimento com o Flutter, utilizando apenas as chamadas ao nosso Firebase, visto que ele já possui um back-end pronto.
|
|
|
|
|
|
|
|
## Módulos do Sistema:
|
|
|
|
A Arquitetura MVVM para projetos mobile é um padrão arquitetural que desacopla o que realmente é interface do usuário com o que é parte lógica. Esse padrão é definido em três módulos integradas:
|
|
|
|
|
|
|
|
**Model** é a camada que representam os dados de domínio do sistema, sendo completamente independente das outras duas camadas e que muitas vezes possui lógica acoplada.
|
|
|
|
|
|
|
|
**View** é a camada que representa a parte visual da aplicação, ou seja, a parte que realiza a interação com o usuário do sistema, ela, como a camada de Model, é totalmente independente das outras duas camadas, sendo alimentada, quando necessária pela camada ViewModel.
|
|
|
|
|
|
|
|
**ViewModel** é a camada que representa a parte lógica da aplicação, sendo ela responsável por intermediar a View e a Model. Ela é responsável por fazer as chamadas ao back-end, fazer mapeamento dos dados vindos dele para o Model e alimentar a View e vice-versa, receber dados vindos da View mapear para um Model e após fazer a integração com o Firebase.
|
|
|
|
|
|
|
|
Para o projeto em contexto utilizamos nomenclaturas diferentes que representam essas camadas dentro do Flutter, com exceção da Model.
|
|
|
|
|
|
|
|
A View é traduzida como **nome da feature mais o sufixo de screen**, que, como o nome já diz, representa uma tela daquela feature. Exemplo.: **HomeScreen**.
|
|
|
|
|
|
|
|
A ViewModel foi modificada em duas camadas diferentes, uma camada que realiza a conexão direta com o backend e uma camada de lógica da aplicação, que mapeia os objetos da Model para a View e da View para o Model. A camada que realiza a conexão com o Firebase é traduzida pelo **nome da feature seguida do sufixo repositor**, como por exemplo, **LoginRepository**, já a camada que faz a intermediação entre a View e a Model é traduzida com o **nome da feature e o sufixo controller** pois ela representa o controle e a integração entre essas outras duas camadas. Exemplo.: **StudentListController**.
|
|
|
|
|
|
|
|
Para facilitar o gerenciamento de estados da aplicação, utilizamos dentro do projeto o **Provider**. O Provider no Flutter representa um estado global, onde ele provê para todos os Widgets (Componentes do Flutter) o conteúdo armazenado nele, centralizando assim todo o estado da aplicação.
|
|
|
|
|
|
|
|
|
|
|
|
Abaixo podemos ver visualmente através de um diagrama como ficou a implementação do **padrão arquitetural** do Flutter:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Design System
|
|
|
|
O design system apresenta formas facilitadas de gerenciar e implementar o padrão arquitetural descrita acima.
|
|
|
|
|
|
|
|
## Estrutura
|
|
|
|
O projeto foi estruturado com duas pastas principais, **Features** e **Shared**.
|
|
|
|
No inicio do projeto encontramos a classe Main, que inicializa toda a aplicação e também a classe Routes, onde estão armazenadas todas as rotas do sistema:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Features
|
|
|
|
As features representam todas as funcionalidades do sistema.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cada feature possui conteúdos internos (Components por exemplo) que são apenas relevantes a ela e não a toda a aplicação.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Shared
|
|
|
|
A Pasta Shared contém todos os arquivos compartilhados do sistema, onde todos os componentes, repositórios, telas, controladores e estados podem usufruir.
|
|
|
|
|
|
|
|
Também, contém arquivos relevantes que permitam centralizar informações compartilhadas como por exemplo:
|
|
|
|
|
|
|
|
* **Assets**: Contém todos as imagens/audios/gifs que serão reutilizáveis ao longo do projeto.
|
|
|
|
|
|
|
|
|
|
|
|
* **Components**: Contém todos os componentes que serão reutilizáveis ao longo do projeto. (ex: Botão principal)
|
|
|
|
|
|
|
|
|
|
|
|
* **Models**: Contém todos os Models que serão comuns a aplicação. (ex: GradeModel)
|
|
|
|
|
|
|
|
|
|
|
|
* **State**: Contém todos estados que são comuns e compartilhados na aplicação. (ex: GradeController);
|
|
|
|
|
|
|
|
|
|
|
|
* **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.
|
|
|
|
|
|
|
|
|
|
|
|
* **Constants**: 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.
|
|
|
|
|
|
|
|
|
|
|
|
* **Styles**: Definição das estilos utilizadas ao longo do projeto. Esse arquivo tem como objetivo centralizar os estilos do projeto, provendo assim, um maior controle quando algum estilo for alterada, no qual reflete em todos os items que utilizam aquela fonte.
|
|
|
|
|
|
|
|
|
|
|
|
|
