Não use drogas, use Flutter! (talk #1)

Julio Henrique Bitencourt
Flutter — Comunidade BR
9 min readJan 12, 2019

Esse post foi originalmente escrito em blog.juliobitencourt.com e para uma melhor leitura aconselho ir lá, uma vez que o medium é muito limitado.

Nesse post farei um resumo geral do talk apresentado com a introdução do mais novo (e fóda) framework de desenvolvimento mobile da Google. [O título é de total responsabilidade do leão do Proerd]

Já tem algum tempo, principalmente ao longo desse ano, que o Flutter vem ganhando uma notoriedade entre as tecnologias de desenvolvimento de aplicações mobile, muitos que experimentam estão falando muito bem, outros falam mal porque gostam de falar mal (ou porque foge da zona de conforto), mas o fato é que, a Google está investindo pesado e a comunidade está gostando. Então, vamos ver o que diabos esse Flutter tem de bom..

Cenário mobile:

Acho que não é nem necessário falar sobre o mercado de aplicações mobile, porque em pleno início de 2019 já é muito auto explicativo a utilização de smartphones no dia a dia, e é natural que o ecossistema de tecnologias para desenvolvimento dessas aplicações seja amplo (só não tem mais opções que frameworks js). Mas quando chega um app pra desenvolvimento na nossa mesa, impossível não vir a cabeça como primeira opção, o desenvolvimento nativo.

> Nativo

É indiscutível que considerando apenas performance e recursos, o desenvolvimento nativo será a melhor opção (a não ser que o código seja muito mal feito, aí não há tecnologia que salve), mas o ponto chave principal é que é muito caro manter 2 ou mais times de desenvolvimento especializados em cada plataforma, para dar manutenção em 2 codebases completamente distintas, tendo de um lado o Android com o queridinho Java e o muito bom Kotlin, e de outro o iOS com o Objective C e Swift. Olhando pelo lado de agilidade para ter um produto no mercado, raramente uma startup, sem muitos recursos, iria optar por desenvolver nativamente.

Se olharmos a arquitetura básica de um app nativo, o código nativo se comunica diretamente com a plataforma na renderização do visual no canvas e a utilização de recursos como GPS e sensores.

Arquitetura básica nativo

> Híbrido

Uma segunda opção, também famosa, seria a utilização de tecnologias como Ionic e Phonegap, que se originaram do core do Cordova e são conhecidas como híbridas. Isso porque utilizam um Stack Web no desenvolvimento (Html, Css e Js) e são renderizadas em um Webview (que é basicamente um navegador).

São populares pois o desenvolvimento dessas aplicações é fácil, sendo basicamente um website, e simples, principalmente para quem já vem do desenvolvimento web. Porém, sempre há um porém, e elas são conhecidas por terem problemas de performance, segundo a própria arquitetura básica:

Arquitetura básica híbrido

Podemos notar que o código JS é envelopado em um webview para rodar na plataforma, e para utilização dos recursos entra no cenário a famosa Bridge (mais sobre isso em breve).

> ‘Compilados’

Uma outra alternativa no desenvolvimento pode ser denominada como os ‘compilados’, isso porque eles não utilizam as linguagens oficiais e não são nativos das plataformas, porém também não rodam em um webView, assim, também não são híbridos.

Flutter e React Native se encaixam nessa categoria, e embora não sejam os únicos, vamos focar neles. Esses são considerados por muitos os salvadores, pois possuem o melhor dos dois mundos, uma performance boa e uma agilidade no desenvolvimento com uma única codebase para ambas plataformas.

React Native é um framework muito famoso e mantido pelo Facebook, o objetivo não é falar muito do react ou comparar as tecnologias — embora seja quase inevitável — e sim apresentar o flutter, mas existe um grande ponto de exclamação no react.

A famosa Bridge. O React Native utiliza sim recursos nativos das plataformas, mas o código JS não é convertido para código nativo, e para ter essa comunicação é necessário utilizar uma ponte.

Bridge/Ponte

O JS é muito bom e performático no seu mundo, a plataforma é muito boa no seu mundo, quando é necessário essa comunicação as coisas tendem a complicar, claro que por utilizar recursos nativos a performance ainda é muito boa, e depende muito do aplicativo, mas a — ponte — é uma realidade e uma hora o gargalo pode aparecer.

Arquitetura básica React Native

Na arquitetura básica do React Native percebemos justamente o JS utilizando a bridge para se comunicar com os recursos nativos de cada plataforma. Mas então, quando esse raio de artigo vai falar do sdk da Google!?

Qual a grande sacada do flutter?

Chegou a hora de destruir essas pontes, ou pelo menos, se aproximar ao máximo da performance que uma aplicação nativa pode obter ao se comunicar com os recursos da plataforma.

Calma que tem mais, qual a outra grande sacada do flutter?

Sim, Widgets! Em flutter tudo são widgets, a verdade é que qualquer artigo de apresentação do SDK, essa com certeza vai ser a informação principal, e você vai se cansar de ler que tudo são widgets, mas uma hora vai se dar conta que é verdade.

Textos, linhas, colunas, imagens, formulários, ícones, botões, enfim, tudo o que você vê em um app e até o que não vê, são renderizados como widgets. E é importante saber que para o Flutter, esses widgets devem obedecer 3 princípios:

Aparência

É importante que eles sejam agradáveis visualmente, bonitos, mantenham o Look and Fell de cada plataforma (quando necessário e desejado), afinal a UX do android em muitos casos é diferente do ios.

Rápidos

Quando há a iteração do usuário, é essencial que sejam o mais suave e rápidos possíveis, isso inclui transições e animações.

App ‘The History of Everything’ desenvolvido em Flutter. GooglePlay

Extensíveis e Customizáveis

Como desenvolvedor, facilita muito que tenha a possibilidade de se estender e customizar widgets existentes, principalmente para manterem a branding de sua própria empresa.

Arquitetura básica Flutter

E o ponto chave para tudo isso ser possível está na arquitetura do flutter, basta passar o olho ali que já notamos a falta da bridge, se analisar um pouco mais, notamos que os widgets saíram da plataforma e agora são renderizados no próprio aplicativo. Isso além de permitir que os widgets sejam rápidos, extensíveis e customizáveis, dá uma liberdade extrema aos desenvolvedores para renderizar qualquer coisa/formato no canvas das plataformas, acabando com as desculpas para negar os projetos malucos dos designers..

Agora imagina o seguinte, o android possui inúmeras versões, atualmente o Android Pie (API Level 28), assim como o iOS na versão 12, milhares de smartphones estão distribuídos no mercado entre essas diversas versões, formatos, fabricantes, se tornando literalmente o pesadelo dos desenvolvedores, afinal, cada versão nova traz recursos novos, que não necessariamente rodam na versão anterior (lembra dos widgets na parte da plataforma?), aí cabe ao coitado do dev testar o app em milhares de emuladores, inundar o codebase com libs de compatibilidade e torcer para que ao disponibilizar o app, tudo rode perfeitamente no smartphone de 2014 daquele seu tio que não gosta de mudanças. Mas com o flutter meu caro amigo, o que você desenvolver para um smartphone, VAI RODAR IGUAL EM TODOS SMARTPHONES (lembra dos widgets na parte do SDK?)!! Não é incrível!?

Presencie a magnificência de uma aplicação em flutter que utiliza widgets do Material Design, rodando em uma versão da plataforma lançada 2 anos antes da criação do Material Design, e que não contém suporte para esses widgets!

Android versão 4.1.2 rodando Material Design com Flutter

Quem nunca?

Colocou o código pra compilar, foi dar uma volta, pegar um café e quando voltou ainda nem havia acabado?

Com certeza isso é muito comum, mas não para o Flutter, e não é mágica, é o hot reload. Ao mudar o visual ou até mesmo o comportamento dos widgets, basta um ctrl+s e pronto, quase que instantaneamente o resultado está renderizado! Sem contar na praticidade e agilidade pra desenvolver e debugar as aplicações.

Hot Reload na prática

Bom, não sabemos a data exata que a Google começou a trabalhar no Flutter, mas em 2016 ele já deu as caras na Dart Developer Summit, ganhando maior notoriedade e adesão da comunidade a partir do release Alpha em 2017, já a partir de 2018 o boom ocorreu e o sdk evoluiu ainda mais, lançando suas versões Beta 1, Beta 2, Beta 3, Release preview 1, Release preview 2 e finalmente em 4 de dezembro de 2018 a versão 1.0 final!! o/

O anúncio foi feito em um grande evento da Google, transmitido mundialmente em live.

A versão final foi anunciada junto a várias novidades excitantes para quem vinha acompanhando, investindo tempo e apostando no Flutter, dentre elas sendo breve dá para destacar:

  • Codemagic, uma ferramenta de automatização de builds para os apps;
  • Flare, e a possibilidade de criar animações em vetor, facilmente exportando-as para rodar como um Widget no Flutter (assim como o app History of Everything mostrado acima)
  • A possibilidade de rodar Flutter em um Raspberry Pi, assim como a demonstração do que vem sendo feito para integração do Flutter rodando em desktop Windows/Mac, e inclusive durante a apresentação eles revelaram que a aplicação utilizada para mostrar os slides no Mac, havia sido desenvolvida em Flutter! (Vê aí a revelação)
  • E por fim, Hummingbird! Sim! Flutter na web, flutter em todos os lugares!

Prazer, Dart.

Wtf?! É, confesso que eu também não conhecia Dart antes do Flutter. Criada em 2011, digamos que há um ano não era uma linguagem tão popular, embora seja de propriedade da propria Google, era utilizada principalmente como backend/web. Mas agora com certeza sua popularidade vem aumentando.

É natural e todo mundo tem esse espanto inicial, ‘Por que não usa javascript? Por que não usa kotlin? Por que mimimi?’, segundo os engenheiros do Flutter o JS foi realmente cogitado inicialmente, assim como outras, mas acontece que Dart é uma linguagem realmente boa, possui recursos modernos, é rápida e se encaixa perfeitamente com o Flutter, principalmente porque permite compilar AOT(Ahead of Time) e JIT(Just in Time), entre outros benefícios descritos lindamente no artigo linkado ao fim deste.

“Ahhh mas eu vou ter que aprender mais uma linguagem, não quero..”

Bom, é aquela velha máxima, sabendo os conceitos… o stackoverflow está aí para ajudar na sintaxe. Dart é open source, e por ser orientada a objetos, quem vem do java, c# e afins vai perceber que a curva de aprendizado é bem pequena, além de muitos casos perceber o quão melhor de codificar é, com menos verbose principalmente. Vá em frente, teste você mesmo rodando dart online no dartpad. Atualmente dart está na versão 2.1, sendo que um dos focos dessa nova versão foi a performance.

É isso, o talk finaliza com um live coding que está explicado e detalhado no próximo artigo ‘Não use drogas, use Flutter! (talk #2)’

Principais referências, lê aí que vale a pena:

--

--