Xamarin e Flutter: Analisando bits e bytes livre de hypes!
“Descobriram” o Flutter, a mais nova tecnologia criada pelo Google para desenvolvimento mobile que chega para “matar” todas as demais tecnologias existentes e dominar o mercado!!! Será???
Antes de iniciar nosso “Deep Dive” pelas entranhas do Flutter precisamos esclarecer algumas coisas muito importantes para que ninguém se faça de “desavisado”.
Quem me conhece sabe que curto usar um pouco de humor em meus conteúdos, então não leve tudo pelo lado pessoal.
EU PROMETO que, neste artigo, serei o MAIS IMPARCIAL POSSÍVEL E NÃO TENHO PRETENSÃO ALGUMA de convencer você que Xamarin é melhor que Flutter e vice-versa!
Meu objetivo aqui é apresentar aspectos técnicos mais aprofundados sobre cada uma das tecnologias… Fazer um artigo técnico e não uma “resenha fervorosa” avaliando uma tecnologia contra a outra dando pontinho pra somar no final e “descobrir” qual é a melhor… Este artigo esta mais para “onde houver fé que eu leve a dúvida” (Falcão, 1994, disco: O dinheiro não é tudo, mas é 100%) do que te dar uma “bala de prata” pra resolver todos os seus problemas…
Se você “é do Xamarin” e está pensando “Meu Deus, o Balivo estudando/falando sobre Flutter, o que isso quer dizer?”, eu respondo… Absolutamente nada, só quer dizer que estou antenado ao que acontece no mercado e acho que você deveria estar fazendo o mesmo, afinal, o objetivo é seguir “pagando os boleto” certo?
Agora se você é “devoto” de “Pai Google” e está pensando “o que este Xamaritano quer vir falar de Flutter”… Saiba que venho estudando e fazendo pequenos projetos para provas de conceito com Flutter muito antes do NuBank fazer uma palestrinha falando que Flutter é a bola da vez, “talkey”?
Me desculpem o prefácio, mas é importante estabelecermos alguns pontos antes de iniciar, ainda mais em tempos de hipersensibilidade das pessoas a #zuera…
Enfim, vou começar fazendo uma breve apresentação de cada uma das tecnologias e seguimos a partir daí!
Os competidores… Digo… Digo… Os Frameworks!
Flutter
Como o próprio site diz o Flutter é (em tradução interpretada):
Uma suíte de componentes (kit de ferramentas) para criação interfaces bonitas com compilação nativa para celulares, web e desktop a partir de um único código!
Como a própria definição diz, o Flutter, a proposta aqui é implementar um código único e poder, a partir desse código, compilar/publicar essa aplicação para celulares, web e desktop.
Até aqui nada de novo frente a outras ferramentas e frameworks já consolidados no mercado como Ionic, Cordova, React Native, etc…
Deve ter notado que, na lista acima, eu não citei o Xamarin.Forms e há um motivo técnico para isso… IMHO, eu não considero Flutter e Xamarin.Forms frameworks COMPARÁVEIS… E não é “mimimi” de um melhor que o outro, é um ARGUMENTO TÉCNICO que vou discorrer adiante.
Xamarin.Forms
O Xamarin.Forms é um “framework” que tem como objetivo abstrair a criação de interfaces a partir de um código único que é “traduzido” e “convertido” no ELEMENTO NATIVO correspondente em cada uma das plataformas atendidas pelo Xamarin.
Não pretendo me alongar falando a respeito do Xamarin.Forms pois tenho, tanto em meu canal no YouTube como aqui no blog, um vasto conteúdo a respeito então, caso deseje saber mais, recomendo que assista o meu CURSO COMPLETO de Xamarin.Forms É GRÁTIS e também dê uma olhada nos artigos da série Desenvolvendo aplicativos Cross-Platform com Xamarin (Partes 1, 2 e 3) que, apesar de serem antigos (pretendo fazer um review deles futuramente) tem bastante conteúdo técnico sobre as bases do Xamarin.Forms que vale a pena você entender.
Escovando bits…
Enfim, vamos analisar as tecnologias de acordo com alguns pontos de vista que considero relevantes. Vamos lá!
Iniciando os trabalhos: Configurando o ambiente…
Para começar a escrever seus aplicativos usando Xamarin ou Flutter você precisará preparar o seu ambiente, senão você não vai conseguir fazer nada!
O processo de SETUP do Xamarin já foi extremamente complexo e penoso… Inclusive eu mesmo já gerei uma série de “Tips and Tricks” para falar a respeito disso e já considerei a realização de um SETUP bem sucedido do Xamarin como uma execução exemplar de encantamento mágico ou coisa parecida… Atualmente o SETUP já vem todo mastigadinho embarcado no instalador do Visual Studio e você pode ter o seu ambiente configurado em 25 minutos com alguns poucos cliques e apenas assistindo o computador trabalhar… Não acredita, então assista meu vídeo [Tips and Tricks] Instalando o Visual Studio 2019 em 25 minutos VÍDEO SEM CORTES…
Para instalar o Flutter é bem simples também… Você faz o download do Flutter SDK (+/-700Mb), é um arquivo ZIP… Descompacta em uma pasta “qualquer”, acrescenta o caminho para esta pasta “qualquer” à variável de ambiente PATH do sistema operacional e PRONTO! O FLUTTER está instalado… Em poucos minutos você também está com tudo pronto… Só que não…
Para trabalhar com Flutter você precisará de algumas coisas mais, como a IDE para desenvolvimento, nesse caso você pode usar O Android Studio, o VSCode, e várias outras que oferecem suporte a tecnologia, PORTANTO você deve acrescentar essa parte também no SETUP… No site do Flutter tem vários modelos de setup a escolha… Só escolher o “sabor” que mais lhe agrada e pronto!
Para ambos você irá precisar instalar a Android SDK e isso “pesa” um pouco também… Mas é apenas fazer o download via SDK Manager que está disponível tanto no Visual Studio quanto no Android Studio, simples assim… Nesse ponto vai uma dica: Se você assim como eu, trabalha com várias tecnologias (Visual Studio, VSCode, Android Studio, etc) CERTIFIQUE-SE de estar utilizando a MESMA pasta da Android SDK para todas elas… Você pode descobrir que está com a Android SDK instalada várias vezes e isso vai te consumir alguns terabytes do seu HD!
Emuladores
Emuladores, simuladores, etc… São um caso a parte e não serão abordados neste artigo, até porque eu não utilizo nenhum, utilizo um dispositivo “véio” pra testar meus aplicativos, se ficar bom “nessamerda” com certeza vai ficar bom em um de última geração…
Mas se você usa ou pretende usar, eu já tive boas experiências com o Genymotion e, mais recentemente com os emuladores que vem configurados no Visual Studio, mas esses últimos não esquecendo de estar em Windows 10 Pro com Hyper-V ativado… Caso contrário fica um lixo…
Time to code… As linguagens de programação
No Flutter você irá utilizar basicamente o Dart como linguagem de programação… É uma linguagem simples de entender (pelo menos pra mim foi tranquilo), é muito parecida com JavaScript e Java e foi criada pelo Google em 2011, e é basicamente só o que podemos dizer sobre ela… É legal… Não sei… Eu diria que é “Ok”…
No Xamarin.Forms você pode usar SOMENTE O C# para implementar suas interfaces SE ASSIM VOCÊ desejar… Eu, particularmente prefiro utilizar o XAML para escrever minhas interfaces e deixar o C# para as demais “lógicas” das minhas aplicações… O C# tem bem mais tempo de estrada, a cada dia que passa vem ganhando mais adeptos e muitas features extremamente poderosas… Não que o Dart esteja parado no tempo, mas ainda tem um longo caminho pela frente…
Um aspecto interessante que você deve considerar é o seguinte… Se é um leitor atento, vai reparar que eu disse acima o seguinte “no Flutter você irá utilizar BASICAMENTE o Dart como linguagem”, a palavra CHAVE aqui é o “BASICAMENTE”… Se você precisar implementar uma funcionalidade específica de uma plataforma ou sistema operacional, do qual não tenha sido mapeada/disponibilizada pelo Google no Flutter, você vai precisar implementar partes em código “NATIVO” de cada plataforma, traduzindo em miúdos, isso quer dizer que, se você for fazer algo mais complexo do que as “telinhas” que alguns YouTubers e blogers “hypeiros” estão fazendo, tu vai precisar meter a mão em linguagens como Java ou Kotlin para partes específicas em Android… Vai precisar de Swift ou Objective-C (para iOS)… Ou ainda C e C++ (caso queira realmente extrair o máximo de performance em seus Games e afins)… NÃO QUE ISSO SEJA UM PROBLEMA, mas como eu disse, estamos falando de bits e bytes livre de hypes aqui, ok?
No caso do Xamarin você SEMPRE irá utilizar C# para isso (você também pode optar por F#), inclusive pode compartilhar partes de código com seu projeto Web, sua API, seu cliente desktop, etc… Isso pode acrescentar uma complexidade para gerir seus projetos, mas te economiza um tempo considerável fazendo CTRL-C, CTRL-V de suas “Models”, DTOs e afins…
Empilhando blocos… Arquitetura e componentes…
Bom… Se você é “do Flutter” ou “anti-Xamarin”, talvez esse tópico seja realista demais para você, pois aqui irei falar a respeito daquele argumento técnico que mencionei no início do artigo e isso pode ser tão polêmico quanto “mamilos”… Mas LEMBRE-SE que não quero defender uma tecnologia frente a outra… Só estou sendo REALISTA… Siga por sua conta e risco (rs)…
A proposta do Xamarin.Forms é disponibilizar uma suíte de componentes única que será transformada no elemento NATIVO de cada plataforma que o aplicativo estiver rodando, EXEMPLO: se eu escrevo que numa tela tem um elemento Entry (caixa de texto), o Xamarin.Forms irá “TRANSFORMAR” esse elemento Entry em um elemento EditText no Android e um elemento UITextField no iOS. Traduzindo em miúdos, o Xamarin.Forms me permite escrever um código único de interface onde cada elemento da tela será “renderizado” com o elemento NATIVO correspondente da plataforma que está rodando o aplicativo.
Isso nos traz algumas vantagens interessantes, como estamos renderizando elementos nativos, podemos desfrutar das guidelines de design de cada uma das plataformas sem muito esforço, no caso o Material Design para Android e o Cupertino para o iOS.
Outro aspecto interessante é que podemos estender e customizar partes de páginas, elementos e afins com interações específicas de cada uma das plataformas da forma que quisermos e, com isso, gerar uma experiência mais próxima de cada plataforma de forma tranquila e transparente, sem abrirmos mão do código único de interface ou customizando grandes “blocos” na tela.
A proposta do Flutter é muito similar a dos frameworks “web based” (Ionic, React Native [só que não], etc)… EXEMPLO: Quando você coloca em uma tela um elemento “caixa de texto” o Flutter irá DESENHAR esse elemento “caixa de texto”, aplicando um estilo comum (vamos falar dos guidelines adiante) dentro de um CANVAS SKIA, ele elemento NÃO VAI SER CONVERTIDO NO ELEMENTO NATIVO DA PLATAFORMA, portanto o aplicativo NÃO É NATIVO… OPA, perae SKIA, quem é SKIA?!
Skia é uma biblioteca para manipulação de gráficos 2D de altíssima performance que permite aos desenvolvedores criar e manipular elementos gráficos de forma simples e rápida, você pode saber mais sobre o Skia aqui.
Esse é um ponto muito forte do Flutter na verdade, frente aos frameworks “web based”, pois estes, por sua vez, estão sempre rodando “hospedados” dentro de um browser, sendo diretamente impactados pela performance deles, coisa que não acontece com o Flutter.
NESSE PONTO que digo que Flutter e Xamarin possuem propostas completamente diferentes e são “produtos” que, apesar de terem o mesmo objetivo e gerarem produtos finais parecidos (uma APK para publicar na Play Store e/ou um IPA para publicar na Apple Store), eles são COMPLETAMENTE diferentes… Ambos geram pacotes NATIVOS de cada uma das plataformas, mas só o Xamarin.Forms gera uma interface 100% NATIVA de fato!
Tanto que, no Flutter, para usufruir das guidelines nativas de cada uma das plataformas, cito Cupertino para iOS e Material Design para Android, você terá que escrever 2 arquivos de códigos de interface, um para cada plataforma…
MAIS UMA VEZ, isso pode não ser um problema para o seu projeto, sinceramente nunca foi um problema em 99% dos aplicativos que já escrevi com Xamarin pois, é mais comum do que deveria, cada designer achar que é melhor que um time inteiro de gente e bilhões investidos para projetar e definir usabilidade em cada um das plataformas, mas… Cada projeto é um projeto e tudo varia da proposta que deseja…
Tooling: Hot Reload saga…
Há um certo “frisson” entre os desenvolvedores a respeito do Hot Reload do Flutter, por ser rápido e funcionar muito bem… DE FATO, é uma excelente ferramenta… MAS PIPOCA quando o assunto é renderizar elementos escritos utilizando código específico (Java, Kotlin, Swift e Objective-C)…
No Xamarin finalmente temos um Hot Reload que funciona bem e o Hot Restart vem vindo aí… Vamos ver se vai funcionar… Tomara!
Sinceramente, eu não importo com esse tipo de ferramenta, sério… Não fico compilando projeto a cada 30 segundos para ver como está ficando… Geralmente eu implemento a interface INTEIRA e DEPOIS compilo e vejo como ficou… E só vou “aparando as arestas”… O Hot Reload vai ajudar no processo, sim… Mas não me importo se não funcionar como deveria… Mas agradeço ao Flutter por ter colocado o time Xamarin pra se mexer!
Performance e tamanho dos aplicativos
Em termos de tamanho do aplicativo, o Xamarin.Forms “perde” um pouco para o Flutter… Eu digo “perde” porque é comum muitos desenvolvedores reclamarem do tamanho de seus aplicativos desenvolvidos em Xamarin.Forms, isso varia muito de acordo com os “peduricalhos” (plugins, frameworks, etc) que cada um utiliza em seus projetos… Isso nunca foi um problema para mim, meus aplicativos Xamarin.Forms sempre ficaram na casa dos 17Mb e RARAMENTE ultrapassam os 20Mb, mas eu sou mais “purista”, não uso frameworks MvvM, não costumo usar muitos plugins, muitas vezes os aplicativos ficam com tamanhos tão aceitáveis que nem preciso configurar o Linker, mas confesso que fazer aplicativos pequenos dão um certo trabalho com Xamarin.Forms, mas dá pra aprender fácil, não é um bicho de sete cabeças.
O fato do Flutter sem um pouco “mais leve” talvez te permita ser mais “lambão” no projeto, é sempre bom ficar atento aos detalhes.
A performance, sinceramente eu não tenho uma opinião formada a respeito… E sinceramente acho que NINGUÉM TEM… Por favor, não seja como um vi em um certo artigo onde o autor simplesmente diz que Flutter é mais rápido, baseado num comentário de um outro blog onde um usuário pergunta para o autor qual é mais rápido, o autor diz “Flutter” daí o usuário pergunta se ele tem um benchmark de ambos e o autor diz: Infelizmente não, mas o Flutter é mais rápido baseado em minhas experiências… (Clique aqui para ver o artigo e aqui para ver o comentário usado como referência no artigo)
Por favor, não passe essa vergonha… Ainda não vi nada efetivamente produzido em Flutter para traçar um paralelo com algo similar em Xamarin.Forms… Não vale uma telinha com meia dúzia de campo como parâmetro… Por isso eu SEQUER vou perder mais meu tempo falando sobre isso… Vamos revisitar esse tema em artigos futuros…
DevOps: Testes automatizados e CI/CD
Ambas as plataformas possuem suporte a testes automatizados, cada um com sua característica distinta, de modo geral são fáceis de implementar.
O mesmo podemos dizer a respeito de CI/CD… A dificuldade no deployment é sempre a mesma para o ambiente Apple, mas aí não tem o que fazer… Não se trata de algo que cada uma das tecnologias podem resolver, elas tem apenas que “aceitar”…
Porém, nesse quesito, o Xamarin possui algumas ferramentas mais visuais, na minha opinião, que tornam o processo menos penoso…
Mas ainda é chato… Obrigado E F@%#$%#-SE Apple!
Comunidades
O Xamarin.Forms possui uma comunidade de desenvolvedores gigantesca! Além dos centenas de milhares de desenvolvedores que implementam funcionalidades e submetem para o time do Xamarin.Forms acrescentarem ao “core” do framework.
O mesmo ocorre com o Flutter, consideradas as devidas proporções dado o tempo de vida de um e de outro…
Mas é uma questão de tempo e principalmente da forma que será feita a condução do projeto pelo Google… A Microsoft, que faz uma espécie de “curadoria” no Xamarin.Forms tem conduzido o projeto de forma extraordinária e isso faz toda diferença para evolução da ferramenta…
Detalhes… Apenas detalhes…
Tanto Flutter quanto Xamarin.Forms são OPEN-SOURCE, portanto são totalmente gratuitos inclusive para uso comercial…
O fato do Flutter renderizar os elementos em tela sem seguir as guidelines das plataformas por padrão não afetam a usabilidade dos aplicativos, mas acrescentam uma demanda extra caso esse aspecto seja importante para o seu projeto.
Pelo fato dos aplicativos Xamarin.Forms serem implementados em C#, você tem um compartilhamento maior de código não só entre as plataformas Android e iOS, mas sim com outros ambientes, tais como Web, API, Desktop… Como já mencionei anteriormente… E isso pode acelerar o desenvolvimento do seu projeto como um todo, não só de aplicativos para celular…
O Flutter também possui suporte para Web, mas ainda está no começo (até o dia de lançamento desse artigo)…
Considerações finais…
Como já sabem, eu trabalho quase que exclusivamente com Xamarin 24h por dia, mas escrevi este artigo para tentar oferecer um conteúdo mais aprofundado sobre Flutter e Xamarin.Forms…
Um ponto que me incomoda bastante no Flutter é o Google… Sim, o Google! A Microsoft já teve sérios problemas com mudanças bruscas na forma de fazer as coisas em suas ferramentas de desenvolvimento… Me lembro até hoje de um problema que tive com Access anos atrás… Foi terrível!
Mais isso ficou no passado… No entanto, o Google é famoso por descontinuar tecnologias e simplesmente deixar as coisas pra lá… Um bom exemplo disso é o Google Glass, onde foram gastos TRILHÕES de dólares no negócio e hoje nem se ouve falar disso… E foi aquilo, um hype do caramba em cima do negócio e, no fim, virou merda nenhuma…
Outro ponto, mais especificamente em desenvolvimento de software, o Google é famoso por não ter “preguiça” de reinventar a roda entre versões da mesma ferramenta… Exemplo disso é o Angular… Já tá na versão 7 (eu acho) e se você aprendeu a trabalhar com a versão 4, vai ter que reaprender pra usar a 5, 6 e 7, porque é “tudo” praticamente diferente…
Enfim… Esses são pontos que coloco para que considerem a respeito… Dizer que Alibaba, Nubank e muitas outras potências estão usando Flutter e por isso é bom usar no projeto, pensem o seguinte… Se der uma merda, você vai ter a grana que esses caras tem para mudar o seu projeto inteiro de arquitetura? Se sua resposta for não, talvez seja melhor optar por uma tecnologia mais consolidada no mercado, e não estou dizendo que é Xamarin.Forms não… As vezes seu time entende mais de Java, Kotlin, Swift e Objetive-C e faça sentido pra você começar usando o padrão das plataformas… Simples assim!
E no caso do Nubank, acho que eles tem coisas mais importantes para se preocupar, mas eles gostam de fazer cortina de fumaça gerando hype… Mas isso é assunto para outra mídia… Um bate-papo num buteco (rs)….
Enfim…
Espero, de coração, ter atingido o propósito de ser imparcial neste artigo e, principalmente, ter contribuído para que você conheça mais a fundo as tecnologias antes de sair implementando suas aplicações com opiniões superficiais cheias de hypes dos oportunistas com objetivo te de empurrar um treinamentozinho pago depois de um tempo…
É de EXTREMA importância ser REALISTA analisando as ferramentas diversas, sejam elas quais forem!
Um forte abraço a todos e até a próxima conexão!!!