CLEAN + MVVM

CLEAN + MVVM

1. 1) PRESENTER

   • - Camada responsável pela UI da nossa aplicação; - É aqui que o Clean e o MVVM se misturam. 
   • MVVM
     • VIEW (Activity/Fragmet)
       • - Camada responsável pela interface (views/activity/fragment) e pela interação com o usuário. Então, além de mostrar as informações para o usuário, essa camada também tem a missão de capturar todas as informações que o usuario fornece;  - Também é nessa camada que nós conseguimos manipular os estados da nossa aplicação.  - Aqui na VIEW teremos um objeto do nosso VIEWMODEL para que a gente consiga fazer o OBSERVER, que é deixar a nossa VIEW observando a cada nova informação surgida lá no nosso VIEWMODEL a gente vai conseguir capturar e atualizar nossa lista com as informações novas fornecidas, consequentemente, a tela será atualizada - PROCESSO DE ATUALIZAÇÃO DE DADOS:   6) Vai receber os dados novos vindo do ViewModel e atualizar a tela;
     • VIEWMODEL
       • - Camada responsável por interpretar as informações que o usuário fornece. Também responsável por preparar as informações que a camada de View vai apresentar para o usuário;  - Esta camada também é responsável por saber qual será o estado que a nossa camada de View deve estar em determinado momento.  - -Aqui na VIEWMODEL teremos um objeto do nosso USERCASE (DOMAIN) para que a gente consiga receber as informações repassadas da camada de Domain, e, depois, converter essas informações (usando um map, igual fizemos la no Repository) para um objeto que possa ser conhecido pela VIEW (pois repassaremos para lá essas infos) - PROCESSO DE ATUALIZAÇÃO DE DADOS:  5) Vai receber o response em forma de objeto repassado pela camada Domain ,  vai  interpretar esse resultado e entender qual deve ser o próximo estado da nossa aplicação . Em seguida ele vai armazenar essa informação que veio do Domain (em forma de objeto) em uma variável  (OBSERVABLE) que esta sendo OBSERVADA pela a nossa camada VIEW (OBSERVER). Ao perceber que há esse novo dado, a reação é enviar para a VIEW ;
     • ADAPTER
     • MODEL

2. 2) DOMAIN

   • - Camada responsável pela regra de negócio da nossa aplicação. Ou seja, essa camada vai pegar as informações e ver se ela está compatível com a regra de negocio. - Um detalhe  muito importante dessa camada é que aqui nos não devemos jamais trabalhar com elementos do tipo VIEW (TextView, RecyclerView e etc), esses elementos devem estar somente lá no PRESENTER. As informações vinda das VIEWS devem chegar aqui no DOMAIN sempre (SEMPREEEE) no formato de STRING (NUNCA VINDO A VIEW DIRETAMENTE). Isso se deve porque a camada DOMAIN deve ser totalmente independente da camada PRESENTER, pois no final das contas, a sua UI pode ser alterada, mas a sua regra de negocio NÃO! Por isso não pode haver essa dependência entre elas, JAMAIS! - PROCESSO DE ATUALIZAÇÃO DE DADOS:   4) Vai receber o response repassado pela camada Data e repassa-lo como um objeto para a camada ViewModel;
   • USECASE
     • Vai receber o response "convertido" e repassado pela camada Data atraves do Construtor do Repository (metodo que a gente usou pra converter o Response). Em seguida, vai repassa-lo como um objeto para a camada ViewModel;
   • MODEL
     • É onde fica todas as informações da regra de negocio. Ex:     data cass Category (     val id: String,    val name: String,    val thumb: String,    val description : String )  

3. 3) DATA

   • - Camada responsável pelos dados. É aqui que fica armazenada as informações da nossa aplicação, pois quando falamos de "dados' , não estamos falando apenas de banco de dados, mas também de qualquer coisa que possa prover uma informação para a aplicação (app); - Com o que foi dito acima, chegamos então a conclusão que, além de banco de dados, a camada Data é responsável por buscar informações do nosso SERVIDOR ou qualquer outro lugar que possa ter alguma informação que nosso app venha a precisar. - PROCESSO DE ATUALIZAÇÃO DE DADOS:  1) Vai fazer o REQUEST (requisição) ao servidor por meio de um objeto de REQUEST e esperar a resposta (response);  3) Vai receber o Response do Servidor e  envia-lo para a camada Domain através de um objeto que essa camada Domain reconheça;
   • REPOSITORY
     • - É onde é feito tudo de fato. É aqui que chamaremos nossa API e o nosso construtor do Model para que atingirmos nosso objetivo. -  O nosso Repository espera como parâmetro um objeto da nossa API. Com esse Objeto agora dentro do nosso Repository nos iremos acessar o seu  Response e passar ele pra dentro de uma variavel chamada "resullt"  (exemplo de nome) usando o "parseReponse()"; - Em seguida pegamos essa variavel  "result" que contem o Responde e faremos uma condicional para saber se ocorreu tudo bem (sucesso) ou se deu tudo errado (falhou).  - Se deu tudo certo, então iremos fazer a seguinte opração: val categoryResponseList =  result.value.category; - essa variavel "categoryResponseList" nunca pode sair daqui!! nunca pode ser mandado para a camada de dominio! Por isso, iremos fazer um mapeamento e para converter esse "categoryResponseList" passando ele para o construtor la do Model, por exemplo:  categoryResponseList.map {         it.toCategory( )       } - Voce pode fazer essa conversão de diversas maneiras, essa é apenas uma delas. O importante mesmo é que sua camada de Domain jamais conheça o seu objeto de Response, a forma que você fará isso é você quem escolhe.  - Mas porque o nossso Response nao pode sair do nosso repository? Simples, se ocorrer alguma mudança no seu servidor...você teria que realizar essa mudança em todos os objetos Response que você espalhou pelo projeto. Porém, com um unico objeto Response localizado aqui no Repository, quando ocorrer essas mudanças irão ocorrer apenas na camada de Data e vc irá modificar em um unico lugar. 
   • API
     • - Aqui dentro teremos nossa API, que é uma INTERFACE. É chamando ela que iremos fazer a nossa requisição junto ao servidor lá no Repository - a API é composta por um @GET e  um Response. Esse "Resposta" dela será uma lista. 
   • MODEL
     • - É aqui dentro que iremos criar o nosso modelo de RESPONSE. Nos iremos passar todas as informações que serão necessárias receber como parâmetros. - quando essas informações vierem nos iremos passa-las para um construtor 

4. SERVIDOR REMOTO/LOCAL

   • Este é o banco de dados   - PROCESSO DE ATUALIZAÇÃO DE DADOS:    2) Vai receber o REQUEST da camada Data e retornar com um RESPONSE;