Flutter — Eu escolho você!

Perdão pelo título nerd desse post, mas como nerd que sou, preciso fazer essa associação da escolha de uma tecnologia à escolha de um Pokémon na hora de uma batalha.

Não existe a melhor linguagem, o melhor framework, a melhor IDE, etc. Essas coisas são sempre condicionadas ao contexto apresentado no momento da tomada dessa decisão. Entretanto, é sempre de bom tom, ou prudente em algumas ocasiões, que essa decisão seja tomada levando em conta vários fatores, e é sobre isso que quero falar.

Primeiro, o contexto: quando entrei na Alice, isso aqui era tudo mato! Fui o primeiro desenvolvedor a ser “Mad” o suficiente a encarar esse desafio chamado Alice. Tínhamos a missão óbvia que era tirar o aplicativo do papel, e lançar para iOS e Android (dunmmmm), massss… eu não tenho experiência com iOS (meu foco sempre foi Android) - digamos que sou 99% Android e aquele 1% iOS que só serve pra fazer uns hotfixes marotos.

Um adendo rápido: sempre torci o nariz para frameworks híbridos para mobile, Phonegap, Ionic, React Native - tudo bullshit pra mim, enfim já desabafei e agora é hora de morder a língua.

Na mesma época que disse sim pra Alice, estavam começando a falar desse tal Flutter. O Nubank estava usando e estavam super empolgados. Comecei a estudar sobre esse carinha e dividi com o time as coisas que eu estava achando interessante. No fim chegamos a conclusão que fazia muito sentido dar uma chance à esse framework.

Zoeira! Seria o artigo mais superficial possível se terminasse assim, não que iremos super nos aprofundar neste artigo, mas lembra lá no começo que eu disse que precisamos levar em conta alguns fatores na hora de escolher um framework?… então, vamos a eles.

Melhor, menor time do mundo

Lembra que não tínhamos outros devs mobile no comecinho? E que meu background é Android? …usar um framework híbrido pareceu muito importante e conseguiria magicamente com uma só base de código gerar dois apps para plataformas distintas… logo, Flutter!

Hoje esse ponto não faz mais sentido, pois já temos pessoas muito competentes com background iOS… entretanto Flutter tem se mostrado muito eficiente e produtivo, pois sua curva de aprendizagem é bem suave e até nosso designer — O Sanches — já mandou uns códigos da hora no projeto, e ele se sentiu assim:

Tá, mas “porque Flutter e não React ou outro framework?”.

Diga-me como que renderizas e te direi quem és.

Uma preocupação neste ponto é dar ao usuário uma experiência fluída, como um app desenvolvido de forma nativa e nada de experiência “weblike” ou componentes que funcionam bem no Android e travam no iOS (ou vice-e-versa). Aqui acredito que o Flutter tem um ponto muito positivo, pois ele utiliza estratégia bem similar ao Unity… saca aquela engine de games? Provavelmente você joga ou já jogou algo no seu celular que use Unity. E como é isso? Bom, basicamente, o que o Flutter mostra para o user é uma view openGL utilizando as libs gráficas em C/C++ das plataformas (Android NDK e LLVM), e toda a UI é constituída de elementos visuais que por padrão são baseados no Material do Google, então nada de componentes em HTML5, ou coisas compiladas em Dalvik (Android) ou componentes altamente acoplados com Objective-C, que gerem inconsistências de usabilidade ou coisas que os designers perdem os cabelos.

Comunidade não, community.

“Quais empresas encararam esse framework?” Ok, essa é uma pergunta válida, pois ninguém vai querer usar algo que só o “Mercadinho Pague & Leve” tá usando pra fazer o controle de estoque dele. Aqui tivemos uma resposta que foi positiva também que é o próprio fato de ser um framework do Google - que não sei vocês - mas pra mim já dá um selinho de qualidade (tudo bem que o Google dá umas vaciladas nos produtos pra end-user (uma lista de flops do Google)).

Voltando (e desculpe a divagação), o próprio Google tem usado no Assistant e Google Ads; outro gigante que já usa Flutter é a chinesa Tecent, mesmo que nós aqui no ocidente não sejamos impactados em nada por essa empresa (ela é muito relevante no mercado chinês e isso quer dizer centenas de milhões de users). E no Brasil? Quem usa? Nubank e iFood pra citar duas empresas gigantes. Tem outras claro, algumas menores e outras que não estão divulgando, mas aqui tem uma relação de empresas brasileiras flutterando.

Por falar em Flutterando (esse é o nome de uma das comunidade que surgiu no Brasil sobre o assunto), é aqui onde quero chegar… saber quem usa, e mais do que apenas mostrar como exemplo, saber se tem mais pessoas dispostas a trocar ideias, tirar dúvidas, fazer novas libs, documentar, contribuir em projetos open source e contratar para a Alice.

Saídas de emergência

Certo! Agora digamos que precisemos usar libs de third-parties que ainda não possuem versão para Flutter, como isso funciona? Ou se precisarmos fazer uma tela nativa? Ou qualquer coisa que o Flutter não consiga fazer? Neste ponto, temos como salvaguarda os MethodChannels, basicamente com esses carinhas você consegue acessar quaisquer métodos que estejam implementados do lado nativo do seu app. Então, sabe aquela lib third party da empresa que começa com Z e “oferece uma plataforma para o serviço de atendimento ao cliente hospedada na nuvem” e que ainda não tem versão Flutter? É aqui que você vai que procurar a saída.

Além disso, caso queira mostrar um componente visual muito treta de fazer na mão e quer reutilizar o que já existe no nativo, então o PlatformView está aqui para te salvar, esse cara tem o poder de renderizar o componente de UI dentro da própria View openGL que o Flutter renderiza. Louco, né?

Lifecycle vs State

Quem tem experiência com desenvolvimento mobile com certeza já se deparou com seguinte situação de hierarquia de componentização:

tela-> componente -> filho do componente -> mais outro componente

Super da hora, funciona, mas basta botar o app em background, receber um push pra ser interceptada para mostrar algo em um desses componentes, e nada mais funciona. Até você descobrir que o problema estava no Fragment de um desses componentes que ainda não entrou no onAttach esperando alguma outra bendita dependência ser criada. Tá, sei que temos várias estratégias para resolver um problema assim, mas gerenciar ciclo de vida de telas e fragments é sempre uma dor de cabeça. No Flutter, os widgets, como são chamados os componentes que ficam na arvore de render do Flutter, podem ser de dois tipos, Statefull e Stateless. Fácil, né? Sem pegadinhas, o framework se preocupa em gerenciar essa árvore para você. Os dados trafegam sem trocentos estados para se preocupar, se você precisa mostrar algo que é imutável usa Stateless, se algo vai mudar usa Statefull. É uma explicação bem grosseira, mas lembra que eu não vou me aprofundar? (Prometo um outro post sobre isso).

O que quero expor é que mesmo na arquitetura do projeto temos uma ganho interessante em relação a life/code quality e controle sobre os componentes em memória. Ainda nesse tópico, se você chegou até aqui dá uma olhada sobre BloC, vale a pena pra entender melhor sobre arquitetura de apps com Flutter.

CI ou não CI, tem como usar CI? Eis a questão.

Não tem como você trabalhar em um projeto de software sem se preocupar com CD (Continuous Delivery) e CI (Continuous Integration), buildar executáveis mobile e subir na mão em suas respectivas lojas é impensável hoje. Então veio essa questão “Que serviços conseguiríamos utilizar para fazer esse trabalho manual com Flutter?”. A documentação oficial do Flutter mostra de forma bem clara como utilizar o Fastlane para subir os executáveis dos apps em nas lojas, então foi meio que brainless escolher a ferramenta de CD (Continuous Delivery). Faltava responder a pergunta que nomeia este tópico. Optamos então pelo Circle CI, visto que é outra ferramenta bastante documentada e muito utilizada pela comunidade Flutter. Existem outras combinações de serviços, inclusive a documentação do Flutter indica outros CI como o Codemagic , Bitrise e Appcircle, mas a combinação CircleCI e Fastlane tem funcionado bem para nosso time, todo o processo de aceite de PRs, build de apps, deploy em tracks de beta e internal tests e subir para produção estão configuradas com essa dupla.

Conclusão

Então temos um framework híbrido, que tem tido cada vez mais adopters no Brasil e mundo a fora, que tem o Google como criador e supporter, que apresenta melhorias em relação a usabilidade e performance gráfica em relação a outras opções, permitindo finalmente termos uma base de código única entre iOS e Android, aumentando nossa produtividade e que possui uma curva de aprendizagem suave, e mesmo com tudo isso ainda conseguimos manter a sanidade com o uso de ferramentas para CI e CD e se algo der errado e o Flutter falhar na missão contamos com saídas de emergência para fugir e tentar abordagens nativas. E como você que chegou até aqui poderia esperar, o time de tech da Alice aprovou o Flutter "and we're good to go!".

Acho que consegui mostrar nosso entusiasmo pelo Flutter. Os pontos levantados nesse post foram os mesmos pontos que levantei para mostrar pro nosso time o quão da hora seria usar este framework, inclusive o Gustavo Amigo escreveu um post sobre como tomamos decisão em tech na Alice, onde ele explica mais sobre esse aspecto da nossa cultura.

E é isso amigos, espero que tenham gostado, dê-em o joinha, apertem o sininho e assinem o canal.

P.S.: a imagem do topo é desse projeto aqui https://github.com/TheAlphamerc/flutter_pokedex

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!