Desafio foi proposto pelo Instituto de Pesquisas Eldorado. Consiste em consumir a API do GitHub e extrair informações básicas sobre os repositórios relacionados a linguagem Swift e seus respectivos pull requests. Todos os Widgets, foram escolhidos de acordo com sua equivalência na versão nativa no IOS, conforme essa sessão da documentação oficial do Flutter.

Considerações iniciais:

• UISegmentedControl equivale ao CupertinoSegmentedControl.
• CollectionView/TableView equivale a ListView.
• Core Data é equivalente ao SQFlite.

Tabela de conteúdos

• Direferenciais implementados
• Instruções de Uso
• Telas
• Sobre o uso biblioteca de terceiros
• Estrutura do projeto (MVC)

Direferenciais implementados

• Documentação no código
• Paginação das listas: carregar lista de repositórios por demanda na rolagem da tela
• Testes (TDD)
• Cancelamento da requisição ao sair da tela onde ela foi chamada.

Instruções de Uso

• Tenha o flutter SDK, instalado em sua máquina.
• Selecione o Device que será usado para o teste, recomendo o AVD Manager do Android Studio.
• Clone o repositório e execute o comando flutter run na pasta raiz do repositório.

Telas

Sobre o uso biblioteca de terceiros

• Dio: Biblioteca responsável por fazer as chamadas de API, á escolha dessa lib se deu principalmente pela facilidade de implementar interceptores em 3 momentos da requisição:
  • onRequest: chamado antes de realizar a requisição.
  • onResponse: chamado quando o app tiver uma reposta do servidor.
  • onError:. chamado quando acontecer um erro em qualquer etapa anterior.

• GetX: Biblioteca em que sua principal utilidade é no gerenciamento de estado da aplicação. Possui legibilidade e performance muito boa, permitindo separar bem a lógica das visualizações do app.

• SqFlite: De acordo com a documentação do flutter, esse seria SGBD mais próximo ao CoreData do IOS.

Estrutura do projeto

O padrão escolhido foi o MVC, para facilitar a comparação da lógica do aplicativo entre a linguagem Swift e o framwerol Flutter.

Pois como o Flutter, possui o estilo de UI declarivo é comum que a view e a lógica acabem se tornando levemente acopladas. Tendo isso, as regras de renderização ficaram dentro das classes de Controllers, exceto de Widgets locais (animações simples e loading de botões). .

• /lib

  • main.dart: ponto de entrada do aplicativo.

  • /model: (regras de negócio, comunicação com API e com o Banco de Dados).

    • /dao: (classes reponsáveis pela conexão com o banco de dados).
    • /API: (classes reponsáveis pela conexão com a API).
    • /Entity: (são os objetos que possuem as regras da estrutura das entidades envolvidas na aplicação).

  • /view: (todas as telas e componentes).

    • /shared_components: (componentes globais a toda aplicação).
    • /pull_view: (componentes referentes a tela de visualização das pulls requests).
      • /widgets: _ (componentes utilizados referentes a pull_screen.dart)_.
    • /repository_view: (componentes referentes a tela de listagem de todos os repositórios).
      • /widgets: _ (componentes utilizados referentes a repository_screen.dart)_.
    • /home_screen.dart: tela inicial do app.

  • /controller:

    • /pull_controller: classe responsável por gerir as entidades que rerpresentam a pull, com sua respectiva view.
    • /repository_controller: classe responsável por gerir as entidades que rerpresentam os repositories , com sua respectiva view.

Feito por: Julio Rennan