Skip to main content

7 posts tagged with "flutter"

View All Tags

· 2 min read

Hey ūüĎč,

Hoje vou compartilhar com você um commit bem interessante do repositório do Flutter:

Implementing switch expressions in foundation/ and material/

Cont√©m a implementa√ß√£o do "novo" switch da linuagem Dart em 2 pacotes important√≠ssimos do framework: foundation e o material. √Č interessante ver na pr√°tica como um novo recurso da linguagem agora integra os aplicativos que iremos criar.

O Dart vem evoluindo e se aperfeiçoando, trazendo funcionalidades já existentes em outras linguagens, tornando-a assim mais robusta e atrativa, especialmente para dessenvolvedores de plataforma nativas que contam com alguns recurso que só existem no Kotlin/Swift.

Lendo o código antes e depois podemos avaliar o quanto a legibilidade melhora.

Aqui está o código antigo:

switch (parameters['value']) {
case 'Brightness.light':
debugBrightnessOverride = ui.Brightness.light;
case 'Brightness.dark':
debugBrightnessOverride = ui.Brightness.dark;
default:
debugBrightnessOverride = null;
}

Aqui está o código novo:

debugBrightnessOverride = switch (parameters['value']) {
'Brightness.light' => ui.Brightness.light,
'Brightness.dark' => ui.Brightness.dark,
_ => null,
};

Este novo switch foi introduzido na versão 3.1, liberada em agosto de 2023. Ou seja, não é uma atualização tão nova assim, mas só agora ela está fazendo parte do Flutter. Deixo aqui o link para você conferir em detalhes: https://dart.dev/language/branches#switch-expressions

Espero que voc√™ tenha gosta e esta dica tenha sido √ļtil. D√° uma conferida no link do commit, vale a pena!

· One min read

BLoC Banner

Gerenciamento de estado com Flutter é um tópico bem amplo e neste post vamos explorar (um pouco) sobre o tão conhecido BLoC!

BLoC e bloc_library n√£o s√£o a mesma coisa! √Č crucial entender que, apesar do nome, eles representam coisas diferentes.

O padrão BLoC é uma arquitetura que separa a lógica de negócios da interface do usuário.

O package bloc_library é uma implementação concreta desse padrão.

O pattern e o package s√£o distintos.

O pattern foi apresentado pelo Google na DartConf em 2018. Foi a arquitetura escolhidas para compartilhar a lógica de negócio entre um aplicativo Flutter e uma aplicação AngularDart, utilizando Streams.

O package implementa esta arquitetura, abstraindo e facilitando a implementação do pattern. E deu tão certo que é um dos packages mais populares para gerenciamento de estado.

E é essencial reconhecer que o pattern em si é independente e pode ser implementado sem este package.

· 2 min read
Resum√£o:

Flutter é um framework não-opinativo.

Responsabilidade e discernimento na escolha.

Mantenha o mais simples possível

O Flutter √© um framework n√£o opinativo, ou seja, ele n√£o imp√Ķe e n√£o obriga sobre como funcionalidades devem ser implementadas.

Permite que os desenvolvedores usem a¬†sua criatividade e experi√™ncia para encontrar solu√ß√Ķes personalizadas para seus problemas, em vez de serem for√ßados a seguir um conjunto r√≠gido de regras e conven√ß√Ķes impostas pelo framework.

Isso significa que √© poss√≠vel escolher diferentes op√ß√Ķes que resolvem o mesmo problema.

Consumir uma API REST, utilizando o package http, dio ou chopper ?.

Navegação utilizando APIs nativas ou packages como fluro, beamer ou go_router ?.

Armazenamento local, com sqflite, drift ou isar ?.

Cada uma das op√ß√Ķes possuem pr√≥s e contras.

No gerenciamento de estado, a mesma coisa.

Sobram alternativas nativas: setState(), ChangeNotifier, InheritedWidget, StreamBuilder, etc.

E packages, como riverpod, flutter_bloc, provider, mobx, etc.

Mas qual o motivo ent√£o de discuss√Ķes acaloradas sobre a "melhor" alternativa para gerenciamento de estado ?

O motivo é simples: não existe "bala de prata", ou seja, não existe a melhor opção. E sim, aquela opção que se encaixa melhor no seu projeto.

Cabe aos desenvolvedores a responsabilidade e o discernimento na escolha.

√Č natural que as pessoas discutam sobre como fazer isso da ‚Äúmelhor‚ÄĚ maneira poss√≠vel. E cada um vai defender a sua escolha em detrimento das outras.

Felizmente, o amadurecimento do Flutter e da comunidade contribu√≠ram para que estas discuss√Ķes tivessem cada vez menos import√Ęncia. Mas ainda assim continua sendo um t√≥pico ‚Äúquente‚ÄĚ.

O Flutter √© um framework que oferece flexibilidade e liberdade de escolha em suas implementa√ß√Ķes.

E como mencionado anteriormente, n√£o existe a ‚Äúmelhor‚ÄĚ maneira. A escolha da op√ß√£o de gerenciamento de estado ideal depende do projeto e do contexto em que est√° sendo usada.

E para finalizar e responder a pergunta deste post, aqui est√° a resposta:

  • Avalie se as alternativas nativas s√£o suficientes
  • Se optar por packages, considere a complexidade do estado no aplicativo. Avalie a documenta√ß√£o e reposit√≥rio. Avalie mais de um package.
  • Fa√ßa uma prova de conceito com a situa√ß√£o mais complexa poss√≠vel.

Regra de ouro: mantenha o mais simples possível.

· 3 min read

Youtube‚Äč

Para complementar este post, também há o vídeo no youtube.

Novidades‚Äč

A vers√£o 3 do Flutter foi apresentado no Google I/O de 2022.

O grande destaque desta nova versão é que o framework está com suporte estável para macOS e Linux, atingindo 6 plataformas diferentes à partir da mesma codebase.

Outras 3 funcionalidade que chamaram a atenção foram:

Material 3‚Äč

A nova geracao do Material Design est√° progressivamente sendo implementada, trazendo um novo esquema de cores, melhorias na tipografia novos componentes e uma capacidade muito maior na personalizac√£o dos aplicativos. Acompanhe a issue e fique por dentro das atualizac√Ķes.

https://github.com/flutter/flutter/issues/91605


Firebase Crashlytics‚Äč

Agora é possível acessar em tempo real os relatórios de "crash" (com stacktrace completo) do seu aplicativo, algo antes exclusivo aos apps nativos. Vale ressalver que este recurso do Firebase é gratuito.


Flutter Web‚Äč

Utilizando a API ImageDecoder (nos browsers que oferecem suporte) a decodificańá√£o de imagens ficou 2x mais r√°pida. E a nova API do Flutter que controla o ciclo de vida de um aplicativo agora fornece um controle maior da inicializańá√£o. Confira os detalhes no link

https://docs.flutter.dev/development/platform-integration/web/initialization


Performance‚Äč

Como de costume, toda atualizac√£o do traz consigo melhorias em performance e desta vez n√£o foi diferente. Basta atualizar a vers√£o e executar o seu aplicativo.


Casual Games Toolkit‚Äč

Um outra novidade que deixou muita gente empolgada é o . Um conjunto recursos para criar jogos casuais utilizando Flutter.

https://flutter.dev/games


Dart 2.17‚Äč

A nova vers√£o da linguagem Dart foi anunciada, trazendo como grandes novidades:

Enums‚Äč

Agora é possível adicionar propriedades/métodos à um Enum.

enum FlutterBootcamp {
kura('setState'),
libria('testes'),
civitas('firebase');

final String conteudo;

const FlutterBootcamp(this.conteudo);

String exibirConteudo() {
return 'O principal conte√ļdo deste app √©: $conteudo';
}
}

void main() => print(FlutterBootcamp.civitas.exibirConteudo());

Super initializers‚Äč

A passagem de parametro para "super-classe" (ou classe m√£e) ficou mais simples:

class Bootcamp {
String? linguagem;
Bootcamp({this.linguagem});
...
}

// Antes
class FlutterBootcamp extends Bootcamp {
FlutterBootcamp({String? linguagem}) : super(linguagem: linguagem);
}

// Depois
class FlutterBootcamp extends Bootcamp {
FlutterBootcamp({super.linguagem});
}

Named args‚Äč

Os named arguments podem ser informados em qualquer ordem. N√£o precisam ser declarados no final do construtor.

class FlutterBootcamp {
final String? conteudo;
final int? aplicativos;

const FlutterBootcamp(this.conteudo, {this.aplicativos});
}

// antes
FlutterBootcamp('Do básico ao avançado', aplicativos: 6);

// depois
FlutterBootcamp(aplicativos: 6, 'Do básico ao avançado');

· 2 min read

Neste post, vamos explorar um dos conceitos mais importantes para quem está começando com Flutter: o ciclo de vida dos widgets.

Voçe já deve saber que em Flutter, tudo é um widget e que temos 2 tipos: Stateless e o Stateful.

E a diferença entre eles é o objeto State, pois ele confere ao Stateful o poder da mutação enquanto o Stateless permanece imutável.

O construtor destes widgets tem a mesma estrutura:

class GreenFrog extends StatelessWidget {
const GreenFrog({ Key? key }) : super(key: key);


Widget build(BuildContext context) {
return Container(color: const Color(0xFF2DBD3A));
}
}
class YellowBird extends StatefulWidget {
const YellowBird({ Key? key }) : super(key: key);


State<YellowBird> createState() => _YellowBirdState();
}

Ambos aos serem implementados, fazem override diferentes: método build no Stateless e o Stateful faz do createState(), nos obrigando à implementar _YellowBirdState().

E nele nós temos o seguinte código:

class _YellowBirdState extends State<YellowBird> {

Widget build(BuildContext context) {
return Container(color: const Color(0xFFFFE306));
}
}

E é aqui que a mágica acontece. Graças ao objeto State, podemos mudar a cor do Container de amarelo para vermelha, usando o setState(). Algo impossível de se fazer em no GreenFrog, que possui a cor verde e por ser um Stateless widget, é imutável.

Até aqui deduzimos então que:

tip

Stateless e Stateful widgets possuem o mesmo ciclo de vida. Quando o construtor é invocado, eles executam o mesmo override.

E como vimos anteriormente, o Stateful possui o override ao método createState() e que o retorno é um objeto State.

E √© exatamente aqui que aprofundamos quando se trata do ‚Äúciclo de vida dos widgets‚ÄĚ.

Sendo bem rigorosos, podemos afirmar que o ‚Äúciclo de vida‚ÄĚ, portanto, trata-se do objeto State e n√£o do Stateless/Stateful.

Sendo menos rigorosos, podemos afirmar que o ‚Äúciclo de vida‚ÄĚ de um Stateful √© mais amplo, pois envolve tamb√©m o objeto State, afinal, n√£o √© poss√≠vel criar um Stateful sem ter um objeto State.

No próximo post, iremos abordar os métodos o initState e o dispose, pois são eles que acompanham a criação e destruição do objeto State (do Stateful widget).

· 3 min read
Resum√£o:

Imperativa: especificar como resolver um problema; controle detalhado.

Declarativa: concentra-se no que o código deve realizar; concentrar no resultado.

Essas duas abordagens são comumente usadas na programação e é importante entender suas diferenças para compreender melhor o uso declarativo pelo Flutter.

Compreender a diferença, facilita o entendimento em como o Flutter constroi interfaces.

Imperativa‚Äč

√Č um processo passo a passo que diz ao computador o que fazer e como faz√™-lo. Em outras palavras, √© um conjunto de instru√ß√Ķes que o computador segue para alcan√ßar o resultado desejado.

A programa√ß√£o imperativa envolve escrever c√≥digo que especifique exatamente como resolver um problema. Ela √© baseada no controle do fluxo de execu√ß√£o usando declara√ß√Ķes como loops, condicionais e vari√°veis. Lembre-se: passo-a-passo.

Adequada para situa√ß√Ķes em que voc√™ precisa ter mais controle sobre o fluxo do programa. Isso significa que se voc√™ precisa fazer algo muito espec√≠fico e precisa ter certeza de que √© feito de uma maneira determinada, ent√£o a abordagem imperativa pode ser a melhor.

Declarativa‚Äč

√Č baseada em descrever o resultado desejado sem especificar como alcan√ß√°-lo. Em vez de escrever c√≥digo que especifica como resolver um problema, a programa√ß√£o declarativa se concentra no que o c√≥digo deve realizar.

A programa√ß√£o declarativa envolve escrever c√≥digo que descreve o problema e o resultado desejado, sem especificar como chegar l√°. √Č baseado na defini√ß√£o de regras e relacionamentos entre elementos. Lembre-se: resultado-desejado.

Adequada para situa√ß√Ķes em que voc√™ deseja descrever o que deseja alcan√ßar, sem se preocupar em como chegar l√°. Isso significa que se voc√™ deseja se concentrar no resultado, e n√£o no processo.

Ao trabalhar com interfaces de usuário, usar a abordagem declarativa para garantir que a interface pareça e se comporte exatamente como você deseja, sem se preocupar com a forma como é implementada.

Na pr√°tica‚Äč

SQL: Declarativo. Declaramos o resultado ao banco de dados: inserir, atualizar, excluir, consultar... mas n√≥s n√£o o instruimos em como ele deve executar tais opera√ß√Ķes.

Algor√≠timo: Imperativo. Imposto a cada linha de c√≥digo como ele deve se comportar. Declarar vari√°vel, computar valores, avaliar express√Ķes. Estamos instruindo exatamente o comportamento que queremos que o programa tenha.

Flutter‚Äč

Como mecionado anteriormente, o Flutter utiliza a abordagem declarativa: resultado.

Ao construi interfaces com ele, declaramos algo como: 1 imagem, 2 campos de texto e um bot√£o.

E o framework se encarrega de todo o resto, sem se preocupar com a implementação de cada elemento.

Com isso, os desenvolvedores podem se concentrar no que desejam alcançar e deixar que o framework se encarregue de como implementá-lo.

At√© breve‚Äč

· One min read

Depois de 3 anos e quase 130 commits, esta √© a nova vers√£o do site. Muita coisa mudou no Flutterverse, mas o desejo em continuar compartilhando conte√ļdo de qualidade para a comunidade continuam iguais.

Assim como o Flutter evoluiu, o flutterparainiciantes.com.br também não poderia ficar para trás.

Conte√ļdo revisado && atualizado. O site est√° muito mais completo.

E agora tem um blog.

Tudo para deixar o seu aprendizado mais f√°cil.

At√© mais ‚úĆÔłŹ