#Flutter: o que é bom e o que não é tão bom #dart

Tempo de leitura: 11 minutos

Como vimos AQUI, grandes empresas estão ativas na comunidade Flutter e AQUI construímos nosso primeiro APP. Bem, como toda linguagem, temos pontos fortes e fracos, e no post de hoje, você vai conferir cada um deles.

Pontos fortes

1) O fato de o Flutter fazer seu próprio desenho da interface do usuário em vez de ser um wrapper em torno dos componentes nativos específicos da plataforma tem vantagens e desvantagens. Se algo for renderizado de alguma forma no iPhone de teste com o iOS 12, por exemplo, ele deve ser processado exatamente da mesma maneira, não apenas em qualquer outra versão do iOS, mas também em qualquer telefone Android.

Com o React Native ou o Xamarin, os componentes de UI têm várias propriedades que são suportadas apenas em uma plataforma ou outra, ou talvez sejam suportadas, mas traduzidas de maneiras ligeiramente diferentes para suas contrapartes nativas nos bastidores. Isso significa que você precisa testar em vários dispositivos e versões do sistema operacional (e possivelmente escrever código específico da plataforma para corrigir algumas situações) ou apenas saber que pode parecer quebrado (ou pelo menos diferente) para alguns usuários. Seu aplicativo pode até falhar se você usar um atributo ou um recurso que não é compatível com uma versão específica do sistema operacional.

Com o Flutter você será muito mais seguro (pelo menos para a parte da interface do usuário do aplicativo). Você ainda deve verificar o aplicativo em vários dispositivos, especialmente se você usar plug-ins de terceiros que mapeiam para componentes nativos específicos da plataforma subjacente. Este será o caso se você usar coisas como áudio / vídeo, notificações push, faturamento no aplicativo, etc.).
O lado negativo dessa abordagem é abordado na próxima seção do artigo.

2) O reload quente é útil demais, é o sonho de um desenvolvedor que se tornou realidade: ⌘ + S no editor, e o aplicativo é recarregado em um segundo! Adeus ao interminável processo de construção / espera / execução / espera / teste / start-over. Na realidade, você ainda precisa reconstruir quando você alterar ativos e plug-ins, alterar algo na navegação, inicialização de estado ou lógica, mas a maioria das alterações da interface do usuário é aplicada imediatamente enquanto o aplicativo está em execução. Para aplicativos com muita interface do usuário, você dedica a maior parte do tempo.

3) Aplicativos reativos também podem ser desenvolvidos no desenvolvimento puro de iOS e Android, é claro, mas é mais fácil e natural com o Flutter (e o React Native). Isso ocorre porque ele está no centro da tecnologia, e não em algo fornecido por bibliotecas de terceiros e implementado de várias maneiras diferentes.

4) O Dart é simples, mas uma linguagem poderosa e completa, comparável ao Swift, Kotlin ou Java. A programação async/await/Future é fácil e também parece completa e consistente (não posso dizer o mesmo sobre JavaScript).

5) O Flutter e o Dart possuem suporte integrado para ambos os testes de unitários para lógica, e testes de widget para UI / interações. Por exemplo, você pode enviar gestos de toque e rolagem, localizar widgets filhos na árvore de widgets, ler texto e verificar se os valores das propriedades do widget estão corretos. Os documentos oficiais fazem um bom trabalho ao apresentar claramente o que está disponível.

6) Adoro o suporte integrado para descrever todos os aspectos da interface do usuário do aplicativo. A parte mais difícil na criação dos temas claros e escuros do meu aplicativo foi escolher a cor certa (criei apenas dois, mas poderia ter criado 10 com a mesma abordagem). Em termos de código, são apenas algumas linhas (basicamente, defina a propriedade theme do objeto raiz MaterialApp – veja isso para um exemplo completo).

7) Essa é uma vantagem de qualquer tecnologia multiplataforma na realidade, não apenas o Flutter: criar um aplicativo para as duas plataformas ao mesmo tempo facilita muito o alinhamento delas em todos os momentos. Com o processo de desenvolvimento tradicional, você pode lançar ambas as plataformas ao mesmo tempo e com paridade de recursos, mas depois de um tempo você percebe que uma plataforma está tendo um desempenho melhor do que a outra (em termos de downloads, vendas, receitas de anúncios …). Então você começa a cortar custos do outro, o que significa que um é parcialmente deixado para trás.

O que não é tão bom

Eu tenho que dizer que eu realmente não encontrei nada que merecesse ficar sob uma seção “ruim”, mas aqui está uma lista de coisas que não são tão boas, pelo menos de certos pontos de vista:

1) Como mencionado algumas vezes, o Flutter pinta a interface do usuário de maneira personalizada, mas não cria componentes nativos. Ele faz um ótimo trabalho ao replicar o Material Design do Android e também os componentes específicos do iOS com a biblioteca do Cupertino, mas ainda não é original. Isso tem algumas implicações, como:

  • (A) Se o iOS 13 mudasse a forma como um controle segmentado ou um UISwitch é processado, seu aplicativo Flutter que usa CupertinoSegmentedControl ou CupertinoSwitch manteria a aparência antiga até que o Flutter seja atualizado e você o reconstrua. Pode-se argumentar que muitos usuários não se importariam (a maioria dos meus amigos não-techy não se importaria e nem perceberia, por exemplo, eles só se preocupariam com o aplicativo que parecesse bonito o suficiente, em vez de saber se ele é 100% consistente com a aparência pura do sistema operacional), mas pode ser um problema se você for um purista.

  • (B) Se você planeja usar o Flutter para apenas uma seção de um aplicativo existente, você pode ver uma diferença entre a parte nativa e parte Flutter. Novamente, isso pode incomodar você (e seus usuários) ou não. Menos um problema para aplicativos que são 100% Flutter, é claro.

  • (C) Para tornar as coisas o mais fáceis possível para você como desenvolvedor, e supondo que seus usuários não se importam com a aparência nativa do aplicativo, você poderia simplesmente usar o MaterialApp (que usa componentes do Material Design) e compilá-lo para ambos Android e iOS. Ele funcionará bem, apesar da aparência não nativa. Se, em vez disso, você se importar com isso e decidir usar o MaterialApp para Android e um CupertinoApp para iOS, estará duplicando a maioria, senão todo o código da interface do usuário (que pode ser uma parte considerável do aplicativo) e você tornará a arquitetura mais complexa. Considere isso com cuidado e decida se valeria a pena.

2) Há uma lista decente de ótimos componentes de UI e outros plugins no GitHub, mas não é tão rico quanto os plugins que você pode encontrar para o React Native e até o Xamarin. Provavelmente é só porque o Flutter é muito mais novo e com uma comunidade menor, mas é assim que as coisas estão no momento. As opções são limitadas e muitos plug-ins são antigos, não são mantidos e talvez nem funcionem mais com as versões atuais de Dart / Flutter. Alguns componentes (especialmente aqueles que não são da interface do usuário, que mapeiam recursos específicos da plataforma) estão disponíveis apenas para iOS ou Android, mas não para ambos (geralmente suportam o Android, porque os desenvolvedores do Android são mais dedicados ao Flutter que ao iOS no momento, afinal o Flutter vem do Google). No entanto, é verdade que preencher as lacunas e escrever o código específico da plataforma apenas para a plataforma ausente ainda é melhor do que começar do zero e as coisas melhorarão com certeza se o Flutter continuar obtendo cada vez mais popularidade.

3) A tela de erro ou os logs que você obtém quando há um erro de layout (ou algo mais em um nível inferior) pode ser muito confuso e obscuro, já que aponta para alguma linha de código do framework que é talvez muitos níveis de abstrações abaixo do que você interagir diretamente. No iOS nativo e no Android, os erros geralmente são mais fáceis de entender e, em geral, é possível simplesmente copiar e colar o erro completo no Google e ter certeza de que você obterá uma lista útil de links que informam mais. Com Flutter, já que a comunidade ainda é relativamente pequena, não tanto.

4) Criar a IU (nos mesmos arquivos .dart onde seu código para a tela é) é fácil e direto. Isso também significa que não há muita separação. Eu preferiria criar a interface do usuário com código de marcação (semelhante ao que você faz em aplicativos Android nativos) em arquivos separados.

5) No Android, a grande maioria dos desenvolvedores usa o Clean Architecture e o MVP (model-view-presenter). No iOS, pode ser MVC, MVVM (model-view-viewmodel) ou Viper. Em ambos os casos (mas ainda mais para o Android), há padrões de arquitetura claros e conhecidos que provaram funcionar bem para aplicativos grandes. Para Flutter (e React Native também), parece que tudo ainda está sendo definido, não existe uma abordagem arquitetônica “padrão” ou “quase universalmente aceita”. Todos os artigos mostram amostras simples, o que é normal, porque eles ainda precisam levar as pessoas a bordo antes de falar sobre aspectos mais avançados. No entanto, se você planeja usar o Flutter para um projeto bastante grande, seria preferível ter uma ideia clara de como estruturá-lo, de modo que ele seja escalonável e facilmente mantido à medida que o aplicativo cresce em tamanho e complexidade.
Eu definitivamente não estou dizendo que o Flutter não permite que você crie aplicativos com uma arquitetura limpa e sustentável, mas apenas que haverá alguma tentativa / erro / experimentação / estudo envolvido, já que não é algo tão maduro e amplamente usado como estamos acostumados em aplicativos iOS / Android nativos.

Conclusões

Há muito potencial, é muito fácil começar e realmente criar algo real, e há muitos bons princípios e ideias. No entanto, a comunidade ainda é pequena e faltam plug-ins de plataforma cruzada. Além disso, você deve estar bem com o fato de que não terá uma interface de usuário 100% nativa e que, se quiser pelo menos estar o mais próximo possível do iOS e do Android, seu código e estrutura receberão mais complexo.
Pessoalmente, acho que esta é uma tecnologia muito útil (que você já pode usar) para as situações em que:

Você deve ser o mais rápido possível para alcançar a maior base de usuários – por exemplo, uma startup que está começando do zero e quer liberar para ambas as plataformas. Veja se há tração em um ou em ambos, e depois invista mais, aperfeiçoe as coisas, etc. Você pode ver isso como um protótipo muito avançado, que pode ser aperfeiçoado posteriormente ainda no Flutter ou substituído por uma versão nativa e uma equipe dedicada.

A interface do usuário não é a maior preocupação – por exemplo, aplicativos empresariais / B2B, onde você deseja ter um aplicativo que os funcionários / clientes podem usar com qualquer tipo de dispositivo, mas não estão muito preocupados com isso com tudo mais no ecossistema do sistema operacional. Isso é o que o Groupon fez por seu aplicativo para comerciantes (mas não para usuários finais), por exemplo.
O que posso dizer ao encerrar é que a criação do meu primeiro aplicativo simples foi muito agradável em sua maior parte, e embora eu tenha desenvolvido alguns aplicativos nativos para iOS e Android no passado, tenho certeza de que levei menos tempo para criar em Flutter (embora eu tenha começado sem ter conhecimento disso) do que teria levado para criar dois aplicativos nativos separados. Nada mal, eu diria!

Gostou do conteúdo? não deixe de seguir a uebile nas redes sociais, pois toda semana tem post novo aqui no blog com mais dicas para o seu impulso digital.