Conexao Remota React Native - Componentes e Persistencia REST

Conexão Remota com React Native Prof Alexandre Paixão false Descrição Componentes e recursos para conexão remota presentes no framework de desenvolvimento para dispositivos móveis React Native Propósito Conhecer os componentes as ferramentas e as técnicas inerentes ao desenvolvimento de aplicativos mobile utilizando o framework React Native que façam uso de recursos de conexão remota Preparação Para acompanhamento do conteúdo e da codificação dos exemplos a serem apresentados ao longo deste conteúdo será necessária a utilização de uma IDE Integrated Development Environment sendo recomendado o Visual Studio Code software gratuito Além disso será preciso configurar o ambiente de desenvolvimento e testes onde diferentes configurações e ferramentas poderão ser usadas Para mais detalhes a respeito dessa etapa o site oficial do React Native poderá ser consultado Objetivos Módulo 1 Componentes para conexão em rede Listar os principais componentes para conexão em rede Módulo 2 Persistência remota com controle de acesso na arquitetura REST Aplicar a persistência remota usando a arquitetura REST com controle de acesso Módulo 3 Modelo Oine First Descrever o modelo Offline First Um software e consequentemente um aplicativo é composto por diversas funcionalidades que no que tange à visão dos programadores são representadas por códigosfonte dependendo do paradigma de programação utilizado separados em classes métodos ou funções cada um com a sua responsabilidade Introdução 1 Componentes para conexão em rede Ao nal deste módulo você será capaz de listar os principais componentes para conexão em rede Introdução Antes de conhecermos alguns componentes para acesso a recursos em rede é importante contextualizar os tipos de recursos que No modelo cliente X servidor temos os códigos responsáveis pela interação com o usuário cliente ou frontend e os responsáveis pelo processamento pelas regras de negócio conexão com bancos de dados etc o servidor ou backend Nesse sentido podemos dizer que um aplicativo mobile seguindo as melhores práticas pode conter tanto códigos de frontend quanto de backend Neste conteúdo serão discutidos tais aspectos no que tange à comunicação do aplicativo com recursos externos e quanto a possuir em si a lógica que normalmente fica no backend modelo Offline First Inicialmente serão listados os componentes da linguagem React Native para conexão em rede prosseguindo com a aplicação prática da persistência remota com controle de acesso utilizando uma API REST Por fim será apresentado o modelo Offline First normalmente são consumidos em um aplicativoaplicação Nesse sentido e não limitados a eles podermos citar os seguintes exemplos dentre outros Login Validação de credenciais de acesso Consumo de dados armazenados em bancos de dados ou em APIs de terceiros Consumo de recursos disponíveis por meio de APIs de terceiros Persistência de dados Em cada um dos exemplos citados nosso aplicativo seguindo o mesmo modelo de uma página Web executará o fluxo composto por realizar uma requisição seguido do recebimento tratamento e na maioria das vezes da exibição do seu retorno Tais requisições poderão ser feitas a APIs ou WebServices sejam eles SOAP ou REST ou menos comum diretamente a scripts escritos em linguagens de programação de back end e disponíveis por uma URL Componentes para conexão No framework React Native está disponível nativamente um componente que permite a conexão com recursos remotos o Fetch API também disponível no JavaScript em ambiente Web Por meio do Fetch é possível consumir e enviar dados utilizando os diferentes métodos HTTP GET POST etc e em diferentes formatos JSON XML texto puro etc Além desse componente nativo estão disponíveis bibliotecas como a Axios uma das mais utilizadas entre outras A seguir será demonstrada a utilização da Fetch API e da Axios Fetch API Como mencionado a Fetch API é uma biblioteca disponível nativamente em React Native para o consumo de recursos externos O fragmento de código a seguir mostra a sintaxe de uma requisição simples a uma API REST utilizando tal componente Javascript No exemplo podemos ver a sintaxe da Fetch API ao recuperar os recursos de uma API Rest Nesse caso foi utilizado o método HTTP GET e setado a partir do objeto response o método json informando o tipo de dado a ser transferido Em seguida o retorno foi atribuído ao state data utilizado como datasource do componente FlatList Enviando dados em uma conexão remota O próximo exemplo demonstrará a utilização da Fetch API para o envio de dados utilizando o método HTTP POST para um endpoint REST Vamos ao fragmento de código Javascript Note que para requisições POST há pequenas diferenças na sintaxe do Fetch método HTTP definido pelo parâmetro method cabeçalho da requisição e o tipo de dado a ser transferido definidos pelo parâmetro header e Accept definição dos dados a serem enviados formatados como string JSON e definidos pelo parâmetro body Outros recursos da Fetch API Além dos recursos demonstrados nos exemplos anteriores uma requisição GET e outra POST a Fetch API dispõe de uma série de outros parâmetros e funcionalidades Logo para se aprofundar visite a sua documentação a partir do site oficial do React Native Biblioteca Axios Além da Fetch API há outras bibliotecas disponíveis em React Native para a conexão e utilização de recursos remotos Entre elas destacase a Axios Antes de usarmos essa biblioteca precisaremos realizar sua instalação Para isso execute o comando a seguir ou o equivalente com o seu gerenciador favorito de dependências npm install axios Atenção Cabe ressaltar que a Axios e outras bibliotecas fazem uso da API nativa XMLHttpRequest Vejamos um exemplo utilizando Axios o mesmo exemplo de GET mostrado anteriormente Javascript Ao analisarmos o código podemos perceber que em linhas gerais o funcionamento da biblioteca Axios é semelhante ao da Fetch Uma diferença a ser destacada é a Response Schema repare que no caso de sucesso é usado no método setData ou responsedata O objeto Response tem a seguinte estrutura Javascript Cada um desses parâmetros pode ser acessado conforme mostrado a seguir Javascript Realizando uma requisição POST com Axios A exemplo do que vimos com a requisição GET a requisição POST utilizando Axios é bastante similar à realizada com a Fetch API Veja o fragmento a seguir Javascript Dica Após executado o método a resposta response poderá ser tratada conforme visto no método GET Gerenciando múltiplas instâncias Axios Normalmente em um projeto real é comum realizarmos diversas chamadas para o mesmo endpoint recurso externo Nesses casos é conveniente criarmos e utilizarmos uma única instância do Axios e então importarmos tal instância em todos os lugares em que precisarmos de uma conexão com o recurso remoto em questão O fragmento de código abaixo demonstra como criar uma instância e em seguida é possível ver como importar tal instância no script em que ela será utilizada Javascript Javascript Repare que no último fragmento de código no lugar de importar diretamente a biblioteca Axios é feita a importação do componente declarado no código imediatamente anterior ou seja axiosintanciajs Com isso a chamada ao recurso externo é feita por meio da instância denominada instanciaaxios à qual a importação do axiosinstanciajs foi atribuída Componente Fetch API para conexão com recursos remotos No vídeo a seguir abordaremos as funcionalidades do componente Fetch API do React Native incluindo demonstração de GET E POST Falta pouco para atingir seus objetivos Vamos praticar alguns conceitos Questão 1 A respeito do consumo de recursos remotos utilizando React Native é correto afirmar Parabéns A alternativa C está correta Seguindo as boas práticas um aplicativo deve ser capaz de funcionar de forma Offline Entretanto mesmo tendo tal prática em mente é usual além de fundamental adicionar a um App recursos disponíveis de forma remota como o consumo ou a persistência de A Em termos de performance é recomendado que todo aplicativo tenha em si mesmo de maneira embarcada todos os recursos de que precisa para funcionar B O consumo de recursos externos pode tornar o aplicativo inseguro já que não é possível controlar a lógica existente neles C A utilização de recursos externos adiciona robustez a um aplicativo tornando possível a interação com outras aplicações e a consequente utilização de outras funcionalidades sem que seja necessário programálas D Embora a utilização de recursos externos por meio de uma conexão remota forneça mais funcionalidades a um aplicativo em React Native há uma limitação que impede que recursos do tipo SOAP sejam consumidos E O funcionamento do modelo de requisição versus resposta é diferente entre o utilizado no ambiente web e o utilizado em aplicativos mobile dados por exemplo A partir desses recursos é possível criar aplicativos mais leves e desacoplados uma vez que não será necessário contemplar de forma embarcada todas as lógicas necessárias para o seu funcionamento Questão 2 Marque a opção abaixo que corresponda aos componentes disponíveis em React Native para a conexão remota Parabéns A alternativa A está correta O React Native possui nativamente alguns componentes para a realização de conexões remotas como o objeto XMLHttpRequest e a Fetch API Além desses há também algumas bibliotecas disponíveis como a Axios A XMLHttpRequest Fetch API e Axios B AJAX e Javascript C JSON XML YAML HTML e texto puro D POST GET PUT e DELETE E Http e Https 2 Persistência remota com controle de acesso na arquitetura REST Ao nal deste módulo você será capaz de aplicar a persistência remota usando a arquitetura REST com controle de acesso Entendendo o que é REST Antes de tratarmos da aplicação prática da persistência remota é importante conhecermos um pouco mais sobre o REST Essa sigla cujo significado em português é Transferência de Estado Representacional do inglês Representational State Transfer pode ser definida como uma abstração da arquitetura da Web composta por um conjunto de princípios restrições e definições cuja principal função é permitir a comunicação entre diferentes aplicações Em termos mais técnicos REST é uma arquitetura de software usada para a criação de serviços web WebServices que permitem o acesso e a manipulação de recursos chamados recursos Web identificados por suas URLs Veja este exemplo de requisição REST Exemplo GET httplocalhostusuarios No exemplo temos o verbo HTTP usado na requisição GET a URL do recurso requisitado composta pelo endereço httplocalhost o recurso usuarios Ao analisar essa requisição podemos entender que está sendo solicitada uma listagem de usuários Veja este novo exemplo Exemplo POST httplocalhostusuarios data nome alexandre Aqui temos uma requisição hipotética cuja função é demonstrar os componentes de uma requisição que utiliza o verbo HTTP POST Nesse caso no lugar de recuperar informações como realizado no primeiro exemplo é realizada a persistência de um dado Vamos aos detalhes da requisição Verbo HTTP POST URL do recurso httplocalhost Recurso usuários Dados representados pela variável data e em formato de string JSON nome alexandre Requisições e Respostas na arquitetura REST Em linhas gerais e conforme visto nos exemplos podemos dizer que essa arquitetura faz uso do modelo Cliente x Servidor de um lado temos o cliente que realiza uma requisição e do outro lado temos o Servidor que recebe processa e devolve uma resposta Nesse processo de requisição e resposta temos entre outros componentes os verbos HTTP o cabeçalho da requisição e o formato de transmissão de dados Em REST utilizase por padrão o formato JSON A string nome alexandre é um exemplo desse formato composto por par ou pares de chave valor Logo tanto a requisição quando envia dados do Cliente para o Servidor como a resposta fazem uso dele Persistindo dados remotamente com React Native Para realizar a persistência de dados em um aplicativo escrito com o framework React Native faremos uso dos componentes para conexão em rede vistos anteriormente Logo alguns exemplos e também boas práticas no que diz respeito ao envio de requisições e tratamento de respostas em caso de sucesso ou não serão demonstrados Antes de continuarmos cabe ressaltar que os códigos referentes ao lado Servidor ou seja os códigos da API que receberá as nossas requisições não serão apresentados uma vez que tal assunto foge ao escopo de nosso conteúdo Entretanto não se preocupe serão demonstradas algumas bibliotecas para funções específicas e que são disponibilizadas gratuitamente por seus fornecedores Enviando dados para uma API REST Inicialmente vamos usar o mesmo código visto no módulo 1 em que uma requisição POST é submetida Para facilitar o entendimento segue a descrição da requisição Componente para conexão remota axios lembrese de adicionálo ao projeto npm install axios Método HTTP Post URL do recurso externo httpsreqbincomechopostjson recurso de teste que devolve como resposta uma mensagem de sucesso Dados enviados string JSON contendo as chaves Id Customer Quantity e Price Javascript A resposta da requisição está disponível na primeira instrução then por meio do objeto response Mediante essa instrução e da instrução catch tratamos o retorno da requisição realizada tanto em termos de sucesso quanto em termos de erro Atenção Tratar os possíveis erros de uma requisição é fundamental para fornecer a melhor experiência possível ao usuário Do contrário e caso aconteça um erro sem que o tratemos o usuário ficará com a sensação de que a requisição não foi realizada ou que está demorando muito podendo inclusive desistir de utilizar o APP em virtude desses fatores Outra prática importante é fornecer um elemento visual que informe ao usuário que a requisição está sendo processada Normalmente utilizamos a imagem conhecida como loading ou mesmo uma mensagem textual com tal informação Olhando o código podemos controlar a exibição desse elemento por meio do state isLoading definido como true no momento que a requisição é iniciada e como false quando ela é finalizada A API remota utilizada nesse exemplo retorna uma simples mensagem success true É comum termos APIs que retornam um objeto mais complexo como a representação de um novo recurso que tenha sido persistido por meio de nossa requisição um novo usuário por exemplo Em ambas as situações podemos tanto tratar o retorno apenas verificando dentro do próprio componente utilizado para conexão o retorno como o utilizar para exibição em algum outro componente de nossa aplicação No código o retorno é inserido dentro do state data que é utilizado no componente Com isso o retorno será exibido diretamente na tela do aplicativo Persistindo dados com Autenticação O exemplo de persistência demonstrado no exemplo anterior é totalmente funcional Entretanto dificilmente um recurso REST remoto é disponibilizado para utilização sem que seja necessário autenticar o usuário que está consumindoo Em termos de autenticação há vários formatos disponíveis para proteger APIs como autenticação básica HTTP Basic Auth autenticação por Token HTTP Bearer Tokens OAuth2 etc entre outros Veremos no próximo exemplo como realizar uma requisição POST para um novo recurso utilizando autenticação com Bearer Token Dica Para executar o código seguinte e realizar chamadas para API gorestcoin é necessário acessar o site e criar gratuitamente um token de acesso Após isso substitua o token fictício constante no código pelo seu token Alguns comentários prévios sobre o código A constante token armazena o token fornecido pela API Lembrese de substituir seu valor pelo seu próprio token antes de executar o código Na requisição do Axios foi adicionado um novo parâmetro headers por meio do qual entre outras informações podemos incluir o tipo de autenticação usado O retorno da API mostrado logo depois do código em caso de sucesso consiste em uma nova instância do recurso usuário que criamos por meio de nossa requisição contendo os dados dele Javascript Javascript Utilizando o método PUT Por convenção embora não seja uma regra na conexão com recursos REST utilizamos o método POST para a persistência de dados e o método PUT para a atualização Em termos práticos o método POST funcionaria nas duas situações Para fins de prática e já tendo visto um exemplo de requisição POST veremos a seguir um exemplo utilizando o PUT Vamos ao código precedido de alguns comentários Perceba que o método HTTP foi alterado para o PUT A URL contém uma path variable conforme definido pela API onde o código do usuário a ser alterado deve ser informado esse código foi retornado na requisição anterior no momento de sua criação No parâmetro data foi passado um JSON semelhante ao utilizado no método POST No exemplo a chave name foi alterada A exemplo da requisição anterior também foi passado como parâmetro o token para acesso ao recurso remoto Como resultado da requisição será retornada uma string JSON mostrada logo após o código contendo os dados atualizados do usuário ou seja seu name Javascript Javascript Controle de Acesso com OAuth2 Os últimos exemplos de conexão remota vistos fizeram uso de autenticação via Bearer Token para acessar e consumir uma API externa Esse controle de acesso é um recurso muito utilizado além de necessário e importante para proteger e controlar o acesso a APIs e recursos O método até aqui utilizado consiste na obtenção de um Token diretamente junto ao provedor do recurso e do seu envio nas requisições Além desse modelo há outros sendo o mais utilizado o OAuth2 O OAuth2 costuma ser denido como framework de segurança como protocolo como estrutura de autorização entre outras formas Independentemente disso e considerando que sua definição mais apropriada é a de Framework de Autorização contando inclusive com uma RFC própria a RFC6749 é importante no que tange ao processo de desenvolvimento de aplicativos mobile e mais especificamente à comunicação deles com recursos remotos entendermos a estrutura do OAuth2 e como implementálo Nesse sentido vamos começar pelos papéis existentes no OAuth2 Isso nos ajudará a entender a separação de responsabilidades ou seja a perceber que parte da lógica ficará no aplicativo e qual parte dela ficará no servidor que possui os recursos que desejamos acessar RFC Uma RFC do inglês Request for Comments é uma série de publicações com a finalidade de documentar padrões serviços e protocolos oficiais da internet sendo mantida pela IETF Internet Engineering Task Force Denição de Papéis no OAuth2 No OAuth2 existem quatro papéis O donoproprietário do recurso O Cliente O Servidor de Recurso O Servidor de Autorização No primeiro papel temos o recurso que desejamos consumir No segundo Cliente temos o nosso aplicativo Os papéis seguintes se destinam a controlar o acesso do Cliente ao Recurso Uma das grandes diferenças e quiçá vantagem do modelo OAuth2 é permitir o acesso a recursos mediante tokens sem que seja necessário por exemplo utilizar credenciais como usuário e senha Além disso é comum determinar um tempo de vida útil para cada token Logo o acesso aos recursos fica condicionado à obtenção e contínua validação dele Esquemas para Utilização do OAuth2 Além dos papéis o OAuth2 possui ainda alguns diferentes esquemas e fluxos de utilização É por meio desses esquemas e de seus respectivos fluxos que saberemos como desenvolver nosso aplicativo a fim de consumir um recurso externo Logo tal escolha não depende somente do desenvolvedor do aplicativo mas também do fornecedor do recurso Outro ponto importante é que cada esquema traz algumas implicações para a arquitetura do aplicativo como o manuseio e armazenamento de informações sensíveis como senhas de usuários A especificação OAuth2 estabelece quatro fluxos de autorização Autorização por Código Nesse fluxo o token de acesso é obtido a partir de um servidor de autorização que age como intermediário entre o cliente e o fornecedor do recurso Logo em vez de fornecer o token diretamente ao cliente mediante solicitação o fornecedor o redireciona para um servidor de autorização que por sua vez autentica tanto o fornecedor quanto o cliente fornecendo a este último o código de acesso token Fluxo Implícito Tratase de uma simplificação do fluxo anterior otimizado e implementado normalmente para rodar em navegadores web Nesse fluxo ao interagir em uma página web o cliente recebe diretamente um token de acesso sem que seja gerado nenhum código de autorização intermediário e que posteriormente precisaria ser usado para então obter o token Credenciais de Senha do Proprietário do Recurso Com a utilização desse fluxo o token é obtido mediante a utilização de credenciais normalmente usuário e senha fornecidas pelo proprietário do recurso Tal fluxo é recomendado apenas quando existir um alto grau de confiança entre as partes ou quando outros tipos de fluxos não estiverem disponíveis Credenciais do Cliente A especificação do OAuth2 define as Credenciais do Cliente como um fluxo que engloba quaisquer outros fluxos de autenticação não definidosexplicitados anteriormente Um exemplo de uso poderia contemplar uma prévia definição entre o Cliente e o Fornecedor de quais recursos estariam disponíveis podendo ser acessados diretamente com credenciais do próprio Cliente Padrão AppAuth A RFC6749 que contém as regras do Framework OAuth2 possui uma seção específica para tratar a interação entre aplicativos mobile e servidores de autenticação Em tal seção a 9 estão previstas duas abordagens embedded useragent e external useragent Além disso mais recentemente foi criada outra especificação a RFC8252 Oauth 20 for Native Apps Tal RFC apresenta uma série de recomendações como sugestões a serem seguidas pelos desenvolvedores a fim de garantir a segurança e o controle de acesso no consumo de recursos remotos Logo a leitura dessa especificação é fortemente recomendada Controle de Acesso na Prática Vimos até aqui tanto a aplicação prática quanto alguns aspectos técnicos e teóricos sobre o controle de acesso em aplicativos mobile para o consumo de recursos remotos Além disso existem inúmeros recursos disponíveis para implementação e uso de controle de acesso em React Native a saber Serviço de autenticação vinculado ao Google Firebase plataforma do Google para criação de aplicativos móveis Plataforma comercial com plano gratuito que fornece serviços de autenticação e autorização Plataforma comercial com plano gratuito que fornece serviço de gerenciamento de acesso seguro Plataforma opensource e também disponível de forma comercial como serviço que fornece serviço de gerenciamento de acesso e identidade Biblioteca de bridge que facilita a comunicação com provedores de acesso OAuth2 Arquitetura REST com controle de acesso no Google Firebase Authentication Auth0 FusionAuth Keycloak Reactnativeappauth React Native No vídeo a seguir destacaremos os pontos relevantes da arquitetura REST incluindo uma demonstração de envio de dados para uma API REST Falta pouco para atingir seus objetivos Vamos praticar alguns conceitos Questão 1 Considerando o cenário em que uma conexão remota é estabelecida para a persistência de dados o cadastro de um novo produto assinale a alternativa abaixo que corresponda aos elementos que deverão estar presentes na requisição A Os dados do produto e o endereço do recurso externo B Os dados do produto o endereço do recurso externo o tipo de dado a ser transferido e um state para armazenar o retorno da requisição C Os dados do produto o tipo de dado a ser transferido o endereço do recurso externo e o método HTTP D Um componente React Native para realizar a conexão os dados do produto a definição do tipo de dado a ser transferido o endereço do recurso externo e a definição do método HTTP E Um componente React Native para realizar a conexão os dados do produto o endereço do Parabéns A alternativa E está correta Para realizar a persistência de dados por meio de uma conexão remota o React Native dispõe de alguns recursosbibliotecas como a Fetch API e o Axios As requisições realizadas por meio desses componentes possuem certa similaridade sendo alguns parâmetros obrigatórios como os dados a serem persistidos o endereço do recurso remoto a definição do método HTTP além do próprio componente de conexão em si Em termos de formato de transmissão de dados ele pode ser omitido sendo usado por padrão o formato JSON Questão 2 Imagine o cenário em que uma requisição é realizada a partir de um aplicativo mobile para um recurso remoto que exija a autenticação para acesso a seus serviços Qual o retorno da requisição dentro do aplicativo mobile caso o token ou as credenciais de acesso não sejam enviados na requisição ou estejam errados recurso externo e a definição do método HTTP A O retorno esperado recuperação ou persistência de dados será obtido uma vez que existe uma relação de confiança previamente estabelecida entre o aplicativo e a conexão remota B Será exibido na tela um alerta informando que não foi possível se conectar com o servidor remoto C Caso a requisição seja tratada em um bloco catch ou com códigológica equivalente a ele será possível obter o erro HTTP correspondente normalmente o código 401 Unauthorized ou uma mensagem personalizada implementada no lado servidor que indique que não foi possível realizar a conexão A partir daí será possível interagir com o usuário do aplicativo informando o ocorrido Parabéns A alternativa C está correta As tarefas que consomem recursos remotos que necessitam ou não de autorização precisam ser tratadas individualmente pelo desenvolvedor do aplicativo para o caso de ocorrência de falhas Considerando que o fluxo de disparo de erro é de responsabilidade do fornecedor do recurso tornase necessário entender a API utilizada além da realização de testes em todos cenários possíveis sucesso ou falha para conhecimento de suas respectivas respostas 3 Modelo Oine First Ao nal deste módulo você será capaz de descrever o modelo Oine First D Após o envio da requisição e a ocorrência da falha de acesso a tela do aplicativo ficará branca mostrando que não há nenhuma informação a ser exibida E Por padrão os componentes de conexão remota do React Native executam uma rotina preestabelecida em casos de erros de conexão remota que leva o usuário para a páginatela principal do aplicativo exibindo uma mensagem de erro padrão na tela Aplicativos Online e Oine Nos módulos anteriores foram apresentados os componentes para conexão em rede e persistência de dados para a construção de aplicativos mobile utilizando React Native Nesse sentido partimos do princípio em todos os cenários vistos que os recursos remotos estarão sempre disponíveis ou que os dispositivos nos quais nossos aplicativos serão instalados estarão sempre conectados à internet independentemente do tipo Comentário Por mais que a infraestrutura de telecomunicações esteja avançando e muito ao longo dos anos ainda nos deparamos com situações em que ficamos com nossos dispositivos móveis offline Nesses casos o que acontece com os aplicativos que temos instalados Caso ainda não tenha feito faça um teste Em sua maioria os aplicativos param de funcionar Para contornar essa situação existe um modelo denominado Offline First cuja principal função é a de permitir que um aplicativo que faça uso de recursos remotos funcione normalmente estando ou não conectado à internet Ao longo deste módulo o modelo Offline First será descrito assim como as técnicas que nos permitirão utilizálo em nosso processo de desenvolvimento A Arquitetura Oine First Em termos conceituais podemos dizer que um aplicativo desenvolvido seguindo os princípios da Arquitetura Offline First é um aplicativo que funciona de modo semelhante independentemente de possuir ou não conexão com a internet Devemos ter em mente que cada aplicativo tem sua própria arquitetura seus próprios requisitos e suas funcionalidades Nesse sentido podemos ter aplicativos nos quais por uma decisão estratégica a arquitetura Offline First não será aplicada Em outros casos podemos ter uma implementação híbrida ou seja alguns recursos funcionariam seguindo os princípios da arquitetura e outros não E por fim podemos ter os aplicativos totalmente funcionais independentemente de estarem ou não conectados No momento de planejamento do aplicativo tenha em mente que há técnicas que podem ser utilizadas para a criação seguindo a arquitetura em questão e que sua utilização não é obrigatória tratandose de uma recomendação que traz alguns benefícios mas que também gera preocupações e código extra Fluxo do modelo Oine First Os aplicativos criados utilizando esse modelo devem seguir um fluxo padrão em seu funcionamento Ao serem iniciados os aplicativos devem verificar se o dispositivo possui acesso à internet Em caso negativo o aplicativo deverá usar um banco de dados embarcado que fica salvo e disponível apenas no dispositivo de cada usuário para armazenar os dados provenientes das ações do usuário assim como disponibilizar uma série de dados que serão necessários para o seu funcionamento O aplicativo deve monitorar constantemente o status de conexão do dispositivo para que tão logo l t à i t t j Outro ponto importante nesse fluxo é incluir uma etapa de recuperação de dados remotos e inserção no banco embarcado a fim de que esses dados fiquem disponíveis localmente Tal processo deve ser executado no primeiro instante em que se verifique possuir conexão com o servidor remoto e deve ser repetido de tempos em tempos uma boa dica é executálo junto com o processo de sincronização que então envolverá não somente a sincronização dos dados locais no servidor remoto mas também a atualização dos dados locais com base nos externos Construindo um aplicativo utilizando o modelo Oine First O fluxo apresentado acima indica quais recursos e componentes precisaremos possuir nos aplicativos que implementem a arquitetura Offline First Em linhas gerais precisaremos de um componente para controlar a disponibilidade da conexão à internet de um banco de dados embarcado e de um componente que realize a sincronização entre os dados salvos localmente com o recurso remoto Em React Native existem algumas bibliotecas que nos permitem ter todos esses recursos A seguir veremos algumas opções de componentes para a realização das tarefas citadas a fim de estabelecer um ponto de partida para o desenvolvimento de um aplicativo que siga o modelo Offline First Banco de Dados Embarcado ele se encontre com acesso à internet seja executado o processo de sincronização no qual os dados armazenados no banco embarcado serão sincronizados com o banco de dadosrecurso remoto Em termos de banco de dados embarcado ou seja de um banco de dados que seja disponibilizado juntamente com o aplicativo há várias opções disponíveis incluindo bancos relacionais e não relacionais A escolha de qual utilizar normalmente seguirá uma série de fatores A dica aqui é pesquisar opções que já possuam ferramentas que permitam a sincronização remota Seguem algumas opções entre as mais utilizadas com React Native AsyncStorage SQLite Firebase Realm PouchDB Watermelon DB Dica O Realm e o Watermelon possuem mecanismos de sincronização Comece estudando essas duas opções e em seguida pesquise as características dos demais O exemplo seguinte apresenta o código correspondente a uma classe ProdutoSchema equivalente a uma tabela em um banco de dados relacionais mas implementada no modelo do Realm Database Realizar a persistência local consiste em criar esse tipo de classes mediante as quais definimos que dados desejamos armazenar e que serão utilizadas para a persistência e recuperação de dados no banco embarcado Javascript Lógica de Backend no Aplicativo Uma característica dos aplicativos que aplicam o modelo Offline First é possuir uma estrutura normalmente vista em aplicaçõesAPIs que ficam no backend Tal estrutura diz respeito aos modelos de dados normalmente chamados models ou entities e cujo exemplo vimos anteriormente muito usados na técnica chamada ORM Mapeamento Objeto Relacional e responsáveis por representar os dados a serem manipulados Os detalhes dessa modelagem fogem ao escopo deste conteúdo Logo é recomendado que você obtenha maiores informações a seu respeito antes de codificar o seu aplicativo Gerenciador de Estados Recomendação Embora não se trate de um componente obrigatório pode ser interessante utilizar um gerenciador de estados na aplicação a fim de controlar e centralizar os dados em um store que fique disponível em todas as telas da aplicação O benefício dessa centralização vem do fato de que em vez de termos que nos preocupar em recuperar os dados de diferentes componentes podemos ter acesso a eles a partir de um único lugar Em relação às opções para gerenciamento de estados temos o Context e o Redux Este último é uma biblioteca externa que fornece as mesmas funcionalidades do Context mas que oferece mais recursos Controle das Funcionalidades Oine versus Online Para a implementação das funcionalidades responsáveis por permitirem que nosso aplicativo funcione tanto Online quanto Offline existem duas principais bibliotecas disponíveis em React Native Reactnativeoine Reduxoine Essas duas bibliotecas utilizam o Redux e proveem uma série de funcionalidades como permitir que seja verificado de tempos em tempos se o aplicativo possui ou não conexão com a internet além da definição dos métodos a serem executados em cada situação Veja o fragmento a seguir em que é definido um método para persistência de dados que faz uso de Redux actions Javascript O fluxo definido no código acima segue uma ordem de execução inicialmente é executada a ação effect responsável por salvar os dados através da conexão remota Se essa ação for executada com sucesso então a ação commit é acionada Caso o aplicativo esteja offline a biblioteca reduxoffline provê os métodos necessários para se aguardar o estabelecimento da conexão a fim de se persistir os dados Em Com isso os dados serão revertidos ao estado anterior ao momento em que o fluxo foi iniciado Além disso por meio dessa ação é possível adicionar uma rotina de caso de falha ou seja caso não seja possível se conectar o método rollback é acionado notificação ao usuário informando que não foi possível realizar a operação online pedindo a ele que tente novamente quando a conexão for reestabelecida Outras considerações sobre o Modelo Oine First Ao longo deste módulo os conceitos do modelo Offline First e algumas técnicas para sua aplicação foram apresentados A ideia na apresentação desse conteúdo foi introduzir o assunto e destacar alguns dos cuidados que devemos tomar na construção de nossos aplicativos Entretanto é importante ressaltar que há outras questões a serem consideradas em nosso dia a dia A seguir algumas dessas questões serão listadas e apresentadas brevemente Tenha em mente que um aplicativo normalmente é multiusuário Logo ao persistir um dado localmente para posterior sincronização lembrese de identificar o usuário que está manipulando cada informação Sem isso você poderá ter vários problemas de consistência de dados Caso você não tenha acesso em termos de programação à API ou às APIs remotas utilizadas por seu aplicativo tome o cuidado de estudar as suas documentações a fim de melhor planejar a aplicação do modelo Offline First Isso é importante porque as diferentes maneiras como as APIs são implementadas podem trazer impactos para o seu aplicativo Além disso lembrese de que você estará reproduzindo parte do modelo de dados utilizado na API de forma local Logo eventuais mudanças no Autenticação de Usuários e Aplicativos Multiusuários Estrutura da API remota modelo remoto implicarão a necessidade de atualização no modelo local Essa técnica consiste em tornar mais fluída a interação dos usuários com os aplicativos sobretudo quando os aplicativos dependem do consumo de recursos remotos e mais ainda quando tais recursos não estiverem online Em linhas gerais a interface otimista consiste em fazer parecer ao usuário que a aplicação é mais rápida do que de fato é Para ficar mais fácil de entender veja o exemplo do aplicativo do Instagram Nesse aplicativo mesmo que você esteja offline é possível curtir publicações Quer dizer a resposta da interface indica imediatamente que determinada publicação foi curtida uma vez que o ícone que indica o sucesso de tal ação é modificado imediatamente após tocado Entretanto essa mudança na interface não significa que de fato essa informação foi persistida Por outro lado a satisfação do usuário foi garantida cabendo ao aplicativo implementar então a persistência real e também informar posteriormente ao usuário caso ela por algum motivo não tenha sido realizada de fato Interface Otimista O modelo Oine First no React Native Os pontos relevantes e de atenção no desenvolvimento de um aplicativo utilizando o modelo Offline First serão abordados no vídeo a seguir Falta pouco para atingir seus objetivos Vamos praticar alguns conceitos Questão 1 Em relação à implementação do Modelo Offline First em aplicativos escritos com o framework React Native é correto afirmar que A O React Native provê mecanismos nativos capazes de por si só tornarem possível a implementação do modelo Offline First B O Modelo Offline First é antes de mais nada um modelo conceitual que descreve os cuidados a serem tomados na construção de um aplicativo que utilize recursos remotos Em React Native tanto os componentes para conexão remota como os demais envolvidos na implementação do modelo precisam ser instalados de forma adicional C A implementação do modelo Offline First em React Native traz consigo algumas preocupações incluindo a plataforma Android ou iOS para a qual implementaremos nosso aplicativo Parabéns A alternativa B está correta A codificação de um aplicativo usando o Modelo Offline First consiste na combinação de uma estratégia bem definida e na escolha dos componentes que permitam a aplicação eficiente da estratégia em questão Em linhas gerais não é possível aplicar o modelo utilizando apenas os componentes nativos do React Native sendo necessário instalar bibliotecas adicionais Questão 2 Podemos dizer que um aplicativo foi codificado utilizando o Modelo Offline First quando D A principal limitação para a implantação do modelo Offline First em aplicativos escritos com React Native é a dependência do recurso remoto a ser utilizado Logo é correto afirmar que não é possível tornar qualquer aplicativo em um aplicativo que utilize o modelo em questão E A grande vantagem de se aplicar o modelo Offline First usando React Native é que ao escrevermos localmente os mesmos códigos existente na API remota tornamos nosso aplicativo mais robusto e totalmente independente de recursos remotos A consome recursos disponíveis remotamente possui um mecanismo para verificar a existência de conexão à internet possui um banco de dados embarcado possui mecanismo para sincronização bidirecional de dados B utiliza mecanismos de gestão de dados e um store para a centralização de todos os dados de que faz uso C possui um banco de dados embarcado Em outras palavras todo aplicativo que possui um banco de Parabéns A alternativa A está correta O conceito de Modelo Offline First se aplica a situações em que há o consumo de recursos externos a partir de um aplicativo Logo se um aplicativo não faz uso de recursos remotos não há por que falar no modelo em questão Além disso outras características do Modelo Offline são a existência de mecanismos para a verificação constante da conexão a utilização de um banco de dados embarcado e a sincronização bidirecional de dados Considerações nais Ao longo deste conteúdo foram apresentados os recursos do framework React Native para a realização de conexão remota tendo em vista o consumo de recursos externos Nesse sentido foram listados os componentes tanto nativos como bibliotecas externas que permitem a conexão em rede e a persistência de dados Além disso tanto de maneira prática como conceitual foram aplicados e descritos alguns mecanismos de controle de acesso inerentes ao processo de consumo de recursos externos Por fim foi descrito o Modelo Offline First por meio do qual aplicações mobile que fazem uso de conexão remota podem ser escritas a fim de permitirem o seu uso normal com ou sem conexão à internet dados embarcado é um aplicativo que faz uso do modelo Offline First D possui em si lógica e código normalmente encontrado no backend E possui uma interface otimista por meio da qual todas as ações são executadas de maneira ágil melhorando a experiência do usuário Podcast Ouça o podcast a seguir no qual trataremos da utilização dos tópicos abordados no desenvolvimento mobile com React Native Explore Visite a documentação oficial do React Native disponível no seu website Conheça a especificação técnica que estabelece o modelo OAuth 20 disponível no website IETF Datatracker Veja também a especificação que trata da aplicação do OAuth2 em Aplicativos disponível no website IETF Datatracker Referências DENNISS W BRADLEY J OAuth 20 for Native Apps Internet Engineering Task Force IETF Best Current Practice United States October 2017 Material para download Clique no botão abaixo para fazer o download do conteúdo completo em formato PDF Download material O que você achou do conteúdo Relatar problema