Nao sei por que esse canal nao tem dezenas de milhares de subscribers. O melhor canal de Flutter em portugues que tem. Parabens, Professor Diego. Obrigado pelo conteudo sempre super util.
Sucesso! Se tiver alguma dúvida avisa ai! É sempre importante após cada vídeo desses: testar em um projeto seu o conceito, depois pesquisar mais sobre e marcar o que precisa aprofundar no futuro.
Muito boa sua explicação. O que vejo em relação a essa discussão de qual gerenciamento de estado usar no Flutter é que se questiona qual gerenciador usar sem nem mesmo saber se vai precisar de um gerenciador. Nos meus projetos até hoje só usei o provider e atendeu o que eu precisava sem ter q apelar para outros pacotes que vão gerar muito condigo. As vezes menos é mais.
Obrigado Marcelo, tentamos melhorar a cada dia. Você está 100% correto, a maioria dos recursos necessários para um app o próprio Flutter fornece. Além disso, muitas vezes, as pessoas não tem curiosidade de explorar o código de um package, que as vezes cria apenas algumas abstrações sob recursos do core do Flutter 😀
O gerenciamento de estado é todo esse sistema. O provider para injeção e recuperação, o change notifier para notificação das mudanças e o estado que é a classe que armazena e trabalha com oa dados 👍
@@drantunes legal, professor eu estou pensando em usar so ChangeNotifier e AnimatedBuilder para o gerenciamento de estado e a lib get_it para injeção de dependencias? o que vc acha ? Fico em duvida se estou fazendo a coisa certa em nao optar o bloc,provider e nem mobx e investindo em uma coisa nativa
@@eduardomonegate2029 É uma boa escolha de sistema sim. Se você fizer bem desacoplado e as classes foram bem independentes, se precisar, você pode substituir no futuro tranquilamente.
Eu não entendi "nada"... Como venho de sistemas de verdade a única preocupação minha (lá nesses ambientes) era com a persistência dos dados. O que o "estado" (que não ficou claro o que é exatamente no Flutter) se encaixa nisso? Uma vez que 1 bilhão de acessos diferentes podem acessar o único local onde o dado (no singular mesmo para ficar simples) pode estar, todos verão a mesma coisa. Se em algum desses locais for necessário alterar o dado, só com um "confirma" (Update) isso acontecerá (não mudando o que os outros estão vendo). Com essa "lógica" de estado, o dado sendo visto nos outros acessos, seria alterado dinâmicamente (Por "mágica" ele seria substituído enquanto está se vendo???), mais ou menos como ocorre no Firebase (que se entrar um dado novo, ou houver uma alteração ela aparece sem ser necessário clicar ou fazer algo, como "refresh")??? É isso??? Por favor, explique "pegando pela mãozinha"... fica mais fácil entender como se fossemos idiotas. Eu agradeço.
Bom dia Euclides, Sistemas de verdade = manipulação direta do banco de dados? Se for isso, provavelmente você desenvolve para backend ou alguma linguagem sem "reatividade". De toda forma você entendeu sim a ideia... A questão do "gerenciamento de estado" surgiu nos últimos anos no frontend, principalmente na comunidade Javascript, e foi usado também no Flutter. Sim, o "estado" consiste na informação ou dado que será apresentado na tela para o cliente ou usado para construir uma tela. Pode-se entender como os diferentes "estados" que uma tela pode ter com base em um dado (exemplo: vazio, carregando, erro, sucesso, etc). Quando um estado é alterado (por exemplo, adiciono um novo item a um carrinho), interfaces modernas (como o Flutter) utilizam de reatividade para atualizar todos os componentes que fazem uso deste dado (no caso o carrinho de compras). Neste exemplo, ao clicar em um botão para adicionar um produto, o ícone de carrinho iria adicionar +1 na label (igual no ifood). Se nesta mesma tela, tiver um botão no final de tela mostrando o total parcial no carrinho, esse valor também será atualizado dinamicamente e "automaticamente". Essa é a "mágica". Esta mágica só é permitida por algum método para gerenciar como este estado é criado, modificado e consumido. São diferentes métodos que você pode usar, como Provider + ChangeNotifier, BLoC, MobX, entre outros. No geral, a maioria desses métodos se baseia em um padrão chamado Observer (ou Publish Subscribe), no qual componentes (widgets) se inscrevem para receber atualizações de uma classe (neste caso o estado). Qualquer alteração interna, o estado irá notificar todos os componentes que se inscreveram com o novo estado. Neste momento o componente fará o que quiser com o novo estado (pode apenas mostrar, ou usar de lógica para trabalhar com o estado). No exemplo que dei, o componente de ícone de carrinho irá incrementar o total de produtos... mas o componente de botão irá utilizar o estado para somar o subtotal da compra. São lógicas diferentes, mas usam o mesmo dado. Por fim, o gerenciamento de estado nada tem haver com persistência. O fato dos exemplos em Firebase mostrarem o dado em "tempo real", apenas significa que o SDK do Firebase fez uma abstração utilizando streams no Flutter para consumir os dados, mas para mostrar na tela você ainda precisa de uma forma de atualizar a tela "automaticamente" quando novos dados são enviados. No caso do Firebase você irá utilizar um StreamBuilder para consumir os dados "diretamente", embora não seja uma boa abordagem para um aplicativo de verdade. Espero ter ajudado um pouco.
@@flparaujo Se for um app pequeno e simples, você não precisa de packages, pode usar as soluções do próprio Flutter como o ChangeNotifier e ValueNotifier. Caso precise de algo como o Provider, mas não queira instalar o package pode usar o InheritedWidget. Apps intermediários hoje algumas recomendações são o próprio Provider, MobX, Riverpod e BLoC (depende do tamanho da sua equipe e experiência). Para aplicações bem grandes, geralmente a recomendação é usar o BLoC. Existem vários fatores ainda a considerar como nível de experiência, necessidade de usar um padrão para mutação dos dados, etc. O mais importante é entender o que cada solução faz e lembrar que não existe solução mágica (se parecer mágica, lembre das histórias: sempre há uma troca ou custo :)
Pode ser usado sim, mas eles não fazem a mesma coisa. No canal tem alguns vídeos que fiz usando Provider e MobX juntos por exemplo. GetX é mais usado pela reatividade, mas também faz a parte de injeção de dependências (similar ao que o Provider faz).
Muita gente foge do Flutter por conta do gerenciamento de estado,logo de cara quando esta começando a aprender,são opções demais e exemplos de menos,deveríamos ter algo como a Java Pet Store,ninguém vai escolher o Flutter só por conta de apps mobile,o Flutter ganharia muita atenção se tivéssemos mais exemplos de lojas on line,erps,kanbans etc implementados em flutter,quando se demora muito para se entender um conceito ou acha-se que vai ter que escrever muito,nego vai apra outra opção,é muita opinião diferente,alguns dizem que statefull widget é coisa do capeta,sem ver o negócio funfando a gente fica no acho,eu acho que vou usar sim statefull widget e signals,ams é achismo por enquanto,estou estudando.
Muito obrigado pelo conteúdo disponível de flutter aqui no youtube!! Assistindo em 2024 😂😂
Nao sei por que esse canal nao tem dezenas de milhares de subscribers. O melhor canal de Flutter em portugues que tem. Parabens, Professor Diego. Obrigado pelo conteudo sempre super util.
Muito obrigado 😁
cheguei no gerenciamento de estado. Estudando com o Diegao p entender finalmente...
Sucesso! Se tiver alguma dúvida avisa ai! É sempre importante após cada vídeo desses: testar em um projeto seu o conceito, depois pesquisar mais sobre e marcar o que precisa aprofundar no futuro.
Professor Diego você tem uma didática fantástica. Obrigado pelo conteúdo compartilhado.
Sua aula é fenomenal!!!
Muito obrigado Saulo!
Muito boa sua explicação. O que vejo em relação a essa discussão de qual gerenciamento de estado usar no Flutter é que se questiona qual gerenciador usar sem nem mesmo saber se vai precisar de um gerenciador. Nos meus projetos até hoje só usei o provider e atendeu o que eu precisava sem ter q apelar para outros pacotes que vão gerar muito condigo. As vezes menos é mais.
Obrigado Marcelo, tentamos melhorar a cada dia. Você está 100% correto, a maioria dos recursos necessários para um app o próprio Flutter fornece. Além disso, muitas vezes, as pessoas não tem curiosidade de explorar o código de um package, que as vezes cria apenas algumas abstrações sob recursos do core do Flutter 😀
Excelente!
o melhor vídeo !
deveriam ter 10mil alunos aqui kk
professor, provider é usado para injeçao de dependencias ne? e o changenotifiy faz a gerencia do estado?
O gerenciamento de estado é todo esse sistema. O provider para injeção e recuperação, o change notifier para notificação das mudanças e o estado que é a classe que armazena e trabalha com oa dados 👍
@@drantunes legal, professor eu estou pensando em usar so ChangeNotifier e AnimatedBuilder para o gerenciamento de estado e a lib get_it para injeção de dependencias? o que vc acha ? Fico em duvida se estou fazendo a coisa certa em nao optar o bloc,provider e nem mobx e investindo em uma coisa nativa
@@eduardomonegate2029 É uma boa escolha de sistema sim. Se você fizer bem desacoplado e as classes foram bem independentes, se precisar, você pode substituir no futuro tranquilamente.
@@drantunes Obrigado professor, vc tem me ajudo muito.
Eu não entendi "nada"... Como venho de sistemas de verdade a única preocupação minha (lá nesses ambientes) era com a persistência dos dados.
O que o "estado" (que não ficou claro o que é exatamente no Flutter) se encaixa nisso?
Uma vez que 1 bilhão de acessos diferentes podem acessar o único local onde o dado (no singular mesmo para ficar simples) pode estar, todos verão a mesma coisa. Se em algum desses locais for necessário alterar o dado, só com um "confirma" (Update) isso acontecerá (não mudando o que os outros estão vendo).
Com essa "lógica" de estado, o dado sendo visto nos outros acessos, seria alterado dinâmicamente (Por "mágica" ele seria substituído enquanto está se vendo???), mais ou menos como ocorre no Firebase (que se entrar um dado novo, ou houver uma alteração ela aparece sem ser necessário clicar ou fazer algo, como "refresh")???
É isso???
Por favor, explique "pegando pela mãozinha"... fica mais fácil entender como se fossemos idiotas.
Eu agradeço.
Bom dia Euclides,
Sistemas de verdade = manipulação direta do banco de dados?
Se for isso, provavelmente você desenvolve para backend ou alguma linguagem sem "reatividade".
De toda forma você entendeu sim a ideia...
A questão do "gerenciamento de estado" surgiu nos últimos anos no frontend, principalmente na comunidade Javascript, e foi usado também no Flutter.
Sim, o "estado" consiste na informação ou dado que será apresentado na tela para o cliente ou usado para construir uma tela.
Pode-se entender como os diferentes "estados" que uma tela pode ter com base em um dado (exemplo: vazio, carregando, erro, sucesso, etc).
Quando um estado é alterado (por exemplo, adiciono um novo item a um carrinho), interfaces modernas (como o Flutter) utilizam de reatividade para atualizar todos os componentes que fazem uso deste dado (no caso o carrinho de compras). Neste exemplo, ao clicar em um botão para adicionar um produto, o ícone de carrinho iria adicionar +1 na label (igual no ifood). Se nesta mesma tela, tiver um botão no final de tela mostrando o total parcial no carrinho, esse valor também será atualizado dinamicamente e "automaticamente". Essa é a "mágica". Esta mágica só é permitida por algum método para gerenciar como este estado é criado, modificado e consumido. São diferentes métodos que você pode usar, como Provider + ChangeNotifier, BLoC, MobX, entre outros.
No geral, a maioria desses métodos se baseia em um padrão chamado Observer (ou Publish Subscribe), no qual componentes (widgets) se inscrevem para receber atualizações de uma classe (neste caso o estado). Qualquer alteração interna, o estado irá notificar todos os componentes que se inscreveram com o novo estado. Neste momento o componente fará o que quiser com o novo estado (pode apenas mostrar, ou usar de lógica para trabalhar com o estado). No exemplo que dei, o componente de ícone de carrinho irá incrementar o total de produtos... mas o componente de botão irá utilizar o estado para somar o subtotal da compra. São lógicas diferentes, mas usam o mesmo dado.
Por fim, o gerenciamento de estado nada tem haver com persistência. O fato dos exemplos em Firebase mostrarem o dado em "tempo real", apenas significa que o SDK do Firebase fez uma abstração utilizando streams no Flutter para consumir os dados, mas para mostrar na tela você ainda precisa de uma forma de atualizar a tela "automaticamente" quando novos dados são enviados. No caso do Firebase você irá utilizar um StreamBuilder para consumir os dados "diretamente", embora não seja uma boa abordagem para um aplicativo de verdade.
Espero ter ajudado um pouco.
Entre provider, getx e mobx qual o mais recomendado?
Depende do tamanho da sua aplicação e do seu time. Pode me falar mais sobre os casos que pretende usar?
@@drantunes Aplicações desde das mais simples as mais complexas.
@@flparaujo Se for um app pequeno e simples, você não precisa de packages, pode usar as soluções do próprio Flutter como o ChangeNotifier e ValueNotifier. Caso precise de algo como o Provider, mas não queira instalar o package pode usar o InheritedWidget. Apps intermediários hoje algumas recomendações são o próprio Provider, MobX, Riverpod e BLoC (depende do tamanho da sua equipe e experiência). Para aplicações bem grandes, geralmente a recomendação é usar o BLoC. Existem vários fatores ainda a considerar como nível de experiência, necessidade de usar um padrão para mutação dos dados, etc. O mais importante é entender o que cada solução faz e lembrar que não existe solução mágica (se parecer mágica, lembre das histórias: sempre há uma troca ou custo :)
@@drantunes Valeu!!! Eh isso. Obrigado!!!
O provider nao seria o indicado para projeto maiores? e o getx mobx?
Pode ser usado sim, mas eles não fazem a mesma coisa. No canal tem alguns vídeos que fiz usando Provider e MobX juntos por exemplo. GetX é mais usado pela reatividade, mas também faz a parte de injeção de dependências (similar ao que o Provider faz).
@@drantunes Obrigado pela explicação prof!
Muita gente foge do Flutter por conta do gerenciamento de estado,logo de cara quando esta começando a aprender,são opções demais e exemplos de menos,deveríamos ter algo como a Java Pet Store,ninguém vai escolher o Flutter só por conta de apps mobile,o Flutter ganharia muita atenção se tivéssemos mais exemplos de lojas on line,erps,kanbans etc implementados em flutter,quando se demora muito para se entender um conceito ou acha-se que vai ter que escrever muito,nego vai apra outra opção,é muita opinião diferente,alguns dizem que statefull widget é coisa do capeta,sem ver o negócio funfando a gente fica no acho,eu acho que vou usar sim statefull widget e signals,ams é achismo por enquanto,estou estudando.