iOS: utilizando Server Driven UI no aplicativo

Server Driven UI no iOS - Apresentação

Olá, boas-vindas a mais um curso de iOS na Alura!

Audiodescrição: Ândriu Coelho é um homem branco de barba e cabelos castanhos-claros. Usa uma camiseta azul-escura com o logo da Alura. Ao fundo, uma parede lisa com iluminação degradê do rosa ao azul. Na lateral esquerda, um vaso de planta e à direita uma prateleira com itens de decoração.

O objetivo desse curso é darmos continuidade ao estudo de escalabilidade de apps iOS.

Estudaremos a Server Driven UI, no português Interface orientada ao servidor. Essa é uma técnica muito utilizada em grandes empresas que trabalham com milhões de pessoas usuárias.

Seu principal benefício é a agilidade de atualização de informações para a pessoa usuária, sem a necessidade de submeter uma versão na loja a todo momento.

Para ilustrar um caso de uso, suponhamos que a equipe de produto e negócio precisa mudar a ordem de uma seção na home do aplicativo SwiftBank.

Tradicionalmente, teríamos que fazer os ajustes, submeter essa versão para a loja e esperar em média 3 a 5 dias para começar o rollout. Só assim as pessoas usuárias poderiam atualizar o app.

Com a técnica Server Driven UI, conseguimos fazer com que o back-end nos devolva as views que queremos exibir. Assim, conseguimos fazer essa atualização no aplicativo de forma rápida.

Como exemplo, temos plataforma Apiary, que utilizamos para simular a resposta de um servidor. Poderíamos rapidamente mudar a ordem de uma seção, como a de Empréstimos e salvar, no caso, na vida real, fazer um deploy. Assim, conseguimos fazer a alteração rapidamente.

Além disso, também é possível fazer outras alterações, como cor e tamanho, tudo via back-end. Portanto, nosso app ficará mais dinâmico, pois responderá ao JSON que o back-end nos retorna. Aprenderemos a fazer essas configurações nesse curso.

Pré-requisitos

Para começar esse curso, é interessante que você tenha familiaridade com a linguagem Swift, saiba fazer requisições HTTP e tenha noções de arquitetura.

Esse é o conteúdo que vamos aprender nesse curso. Te esperamos no vídeo seguinte!

Server Driven UI no iOS - Conhecendo o projeto e a técnica Server Driven UI

Você conhece as principais práticas utilizadas por grandes empresas para tratar as atualizações em seus aplicativos?

Como exemplo, temos o projeto SwiftBank, que começamos a trabalhá-lo no curso anterior dessa formação. Ele é um aplicativo que simula a carteira digital de uma pessoa usuária. Encontramos dados como, saldo, cartão de crédito, e algumas soluções bancárias.

Se a equipe de negócio e produto precisasse vender mais seguros, que está no fim do aplicativo, uma estratégia poderia ser movê-lo para o início da lista. Isso, pois, muitas vezes, a pessoa usuária abre o aplicativo e não visualiza todas as seções.

Qual seria o fluxo atual para fazermos esse ajuste? Teríamos que nos reunir com a equipe de desenvolvimento e fazer essa alteração no código. No arquivo HomeView.swift, na linha 35, temos a lista que exibe todas as seções. Nela, temos cada uma das views instanciadas de forma estática.

Para fazer esse ajuste, teríamos que recortar a view da linha 61 e colá-la antes de cartão de crédito ou empréstimo, dependeria da estratégia de negócio usada na empresa.

Depois disso, teríamos que gerar uma versão do módulo, integrar com o aplicativo principal, subir uma nova versão do app para a loja, ou seja, Apple Store. Esse processo demora entre três a cinco dias, dependendo do ajuste, para começar o rollout e as pessoas usuárias atualizem o aplicativo.

É uma simples alteração, mas que demoraria de três a cinco dias para acontecer. Geralmente, isso é um problema para as empresas, afinal, precisam de agilidade para resolver seus problemas. Muitas vezes, não temos três a cinco dias para começar a testar um produto.

Customizações simples, como o tamanho do texto ou cor, não precisamos, necessariamente, seguir esse fluxo habitual.

Nesse curso, ao invés de deixarmos as views estáticas, ou seja, instanciadas na mão, vamos configurar o aplicativo para receber do back-end todas as views que precisamos renderizar na tela.

O objetivo é tornar isso mais dinâmico, o que o back-end retornar, exibiremos na tela. Por exemplo, se em uma requisição, o back-end retornar primeiro a seção de cartão de crédito, seguido de balance (saldo), transações, empréstimos e poupança, ou seja, reordenar, o aplicativo já vai saber qual view tem que mostrar e a sua sequência.

Se precisarmos fazer uma alteração de texto, isso também virá do back-end, pegamos o valor e setamos nas variáveis. É muito mais dinâmico, pois para fazer uma atualização no back-end, conseguimos fazer um deploy a qualquer momento.

O tempo para fazer a alteração é de 10 minutos, em seguida, as pessoas usuárias já começam a atualizar os aplicativos via requisição HTTP, e não via loja.

Essa técnica se chama Server-Driven UI, esse é o tema principal do nosso curso. No vídeo seguinte, começaremos a entender como podemos deixar o nosso aplicativo mais dinâmico através dessa prática.

Server Driven UI no iOS - Configurando o Apiary

Para começar, configuraremos o aplicativo para ser possível fazer requisições HTTP. Até o momento, todas as informações estão estáticas no app. Então, o primeiro passo é estabelecer um ponto de conexão entre o aplicativo e alguma ferramenta que usaremos.

No nosso caso, não teremos um back-end específico. Portanto, usaremos uma ferramenta chamada Apiary. Vamos descobrir como utilizá-la.

Usando a Apiary

A ideia é que não vamos codificar o back-end. Por isso, precisamos simular a resposta de uma requisição para podermos utilizar o app. Então, usaremos o Apiary.

Ao acessá-lo usando o login do GitHub, vamos utilizar uma estrutura de resposta na qual conseguimos simular um JSON, ou seja, um payload de resposta para o aplicativo. Que é o seguinte código:

        {
            "header": {
                "title": "0lá, Pedro"
            },
            "items": [ 
                {
                    "id": "balance",
                    "amount": "88,67"
                },
                {
                    "id": "card",
                    "amount available": "9.047.08",
                    "invoice_due_date": "04/05"
                },
                {
                    "id": "latest_transactions",
                    "results": [
                        {
                            "id": "23847919"
                            "title": "Compra realizada no iFood"
                            "amount": 22,70",
                            "icon": "restaurante-icon"
                        },
                        {
                            "id": "34843928",
                            "title": "Pagamento mensal Academia",
                            "amount":"99,90",
                            "icon": "gym-icon"
                        },
                        {
                            "id": "42534928",
                            "title": "Compra supermercado popular",
                            "amount": 45,90",
                            "icon": "supermarket-icon"
                        }
                    ]
                }
            }

Para que o Apiary funcione corretamente para que você não tenha nenhum problema é seguir os espaçamentos padrão do código. Sempre que for começar a escrever no Apiary, você precisa deixar pelo menos dois tabs do teclado de espaçamento. Sabendo disso, basta seguir a indentação normalmente.

Ao colar esse trecho de código no Apiary, na lateral superior direita da tela, clicamos no botão "Save". Feito isso, na lateral direita da tela, é exibido uma seção conforme o que foi configurado no nome. Nesse caso, definimos como ### Get Home no código, então é isso que aparece.

Clicamos nessa opção, que é um botão. Feito isso, abre uma janela. Na seção Request, clicamos no campo e mudamos de "Production" para "Mock Server". Feito isso, logo acima, notamos que a URL muda. Copiamos, abrimos uma nova janela no navegador, colamos e pressionamos "Enter". Assim, temos como retorno a estrutura JSON.

Validando o JSON

Recomendamos que, ao mexer no Apiary e fazer alguma alteração no JSON, você valide para verificar se o documento está correto.

Para validar, copiamos todo o código de retorno. Depois, abrimos outra aba no navegador e buscamos por "JSON Validator". Clicamos no primeiro resultado de busca e somos encaminhados para uma nova janela com um campo de código.

Então colamos o código e clicamos em "Validate JSON". Assim, recebemos a mensagem abaixo:

JSON is valid!

Portanto, foi validado. Isso significa que foi validade. Se esquecermos uma vírgula no código, por exemplo, ele não será validado. Nesse caso, a mensagem exibida indica um erro e onde ele ocorre. Por isso, recomendamos essa prática.

Configurando a requisição

Sabendo disso, voltamos para o projeto. Na Apiary, copiamos novamente a URL com o "Mock Server" ativado. Depois, abrimos o Xcode para configurar essa requisição.

Lembrando que temos uma pasta de networking, que é a conexão que oo aplicativo fará nas requisições. O objetivo é colocar isso na classe HTTPClient.

Deixamos um trecho pronto. Então, próximo à linha 26, você notará que há uma constante chamada de apiaryURL. Nos parênteses de URL(), substituímos o link pelo que você configurou no seu API. No nosso caso, fica da seguinte forma:

//Código omitido

let apiaryURL = URL(string: "https://private-f1a3f-swiftbankserverdriveui.apiary-mock.com/home")

//Código omitido

Para testar se o aplicativo está fazendo a requisição, abrimos a view principal, HomeView.swift. No fim do código, próximo à linha 87, chamaremos o método onAppear {}. Com ele, quando a view aparece, conseguimos chamar o método que faz a requisição.

Nas chaves, faremos uma chamada assíncrona, pois temos a classe ViewModel, que já tem um método get, isso nos ajudará. Passamos, então, o do {}. Nas chaves, chamamos o Task {}, que ajudará a fazer uma chamada assíncrona.

O objetivo é utilizar o ViewModel, então nas chaves, passamos let response = try await viewModel.getHome(). Feito isso, conseguimos saber qual foi a resposta da requisição. Então, na linha abaixo, passamos print(response).

//Código omitido

.onAppear {
    do {
        Task {
            let response = try await viewModel.getHome() 
            print(response)
        }
    }
}

//Código omitido

Vamos testar para conferir se está funcionando. Para isso, clicamos na linha 92 para colocar um breakpoint, feito isso, aparece uma seta azul. Dessa forma, conseguimos parar exatamente nesse trecho de código e verificar a resposta do servidor.

No topo da tela, clicamos no ícone de "Play" para executar o projeto. Repare que aparece uma linha verde no breakpoint, isso significa que o aplicativo está parado nesse trecho.

Feito isso, na lateral inferior direita da ferramenta, clicamos para abrir a seção de debug, indicada pelo ícone quadrado com um retângulo na lateral direita.

Logo após, abre um campo. Nele, digitamos o comando po response, seguido de "Enter". O retorno que temos é de um objeto, algo bem interessante. Ao passar o mouse pela linha, temos o header com o título Olá Pedro.

Então, a requisição está funcionando. Clicamos novamente na linha 92 para remover o breakpoint. Em seguida, clicamos no botão de "Play" para continuar a execução do programa.

Essa configuração inicial nos permite fazer uma requisição. A seguir começaremos então a modelar o JSON para entender as diferenças de um response, ou seja, um JSON comum e um que vamos usaremos com a abordagem de server driven UI.

Te esperamos no próximo vídeo!

Sobre o curso iOS: utilizando Server Driven UI no aplicativo

O curso iOS: utilizando Server Driven UI no aplicativo possui 176 minutos de vídeos, em um total de 52 atividades. Gostou? Conheça nossos outros cursos de iOS em Mobile, ou leia nossos artigos de Mobile.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Server Driven UI no iOS
• Mapeando seção de saldo (balance)
• Terminando seção de Balance
• Configurando a seção de cartão
• Configurando seções genéricas