Professor, acho que seria melhor se você utilizasse um projeto novo ao ensinar sobre estes conteúdos, o meu projeto por exemplo é bem diferente do seu, e isso me confunde um pouco.
Estou curtindo muito as aulas, o que me confunde um pouco é o provider: as vezes penso em colocar as chamadas de função fora do build. Tipo testei aqui o readNumberFormat() no iniState() e não funcionou. Não sei se colocar tudo no build o código fica ruim ou tem que ser assim mesmo com o provider.
Pense no provider como um sistema que irá te permitir declarar, instanciar e compartilhar um dado para múltiplas classes. Ao usar o context.watch ou context.read ou Provider.of você consegue recuperar esses dados compartilhados. Se você deseja chamar funções de um provider, você usa o read (no botão, initState, etc. mas não no build). Se você tem um ChangeNotifierProvider você precisa usar o .watch ou Provider.of dentro do build (assim a widget irá rebuildar quando algo for atualizado no dado que está compartilhando via Provider)
Professor, tem alguma aula especifica falando sobre async? você lançando assim eu fiquei com dificuldade de entender. senti falta de uma explicação mais detalhada. se tivesse forma de praticar mais isso pra entender seria bom.
Infelizmente não tem aula específica :\ No geral, o Dart funciona de forma síncrona (as operações são executadas no mesmo instante) e assíncronas (as operações são realizadas "em background" e retornam os dados no futuro). Por isso um código a = a + 1 é síncrono, enquanto uma chamada à uma API ou Database geralmente é assíncrona, pois pode demorar para processar e você não deseja que a interface fique travada para o usuário esperando a resposta de processamento. Por isso usamos o async - await, uma forma de tratar operações que tem natureza assíncrona... Se você não acha a leitura fácil, pode usar ao invés do async - await uma opção .then no final do código assíncrono, algo como future.then((result) { ... })
Há algum problema em disponibilizar providers para a aplicação inteira, ou eu devo restringir os mais específicos apenas para as telas as quais eu realmente preciso utilizar? Ótima explicação a propósito!
As duas coisas. Providers que serão usados pela aplicação toda (e.g. algum serviço de usuário, pode ser global). Mas se você possui algum provider que é usado em apenas um local, o ideal é que ele fique mais próximo do seu uso mesmo. Isso porque o Provider utiliza a árvore de widgets para busca das instâncias 👍
qual o vídeo onde vc adiciona a lista de favoritas a alguma forma de permanência de dados? tentei fazer sozinho com shared preferences mas to apanhando D:
Que massa professor! Sua didatica realmente eh otima!
Professor, acho que seria melhor se você utilizasse um projeto novo ao ensinar sobre estes conteúdos, o meu projeto por exemplo é bem diferente do seu, e isso me confunde um pouco.
uma sugestão é usar o sqlite. Vi que na aula 24, vc vai usa-lo. Vamos seguir o curso para ver.
Ótima dica!
Muito boa aula. Obrigado
Valeu Tiago!!!
Estou curtindo muito as aulas, o que me confunde um pouco é o provider: as vezes penso em colocar as chamadas de função fora do build. Tipo testei aqui o readNumberFormat() no iniState() e não funcionou. Não sei se colocar tudo no build o código fica ruim ou tem que ser assim mesmo com o provider.
Pense no provider como um sistema que irá te permitir declarar, instanciar e compartilhar um dado para múltiplas classes. Ao usar o context.watch ou context.read ou Provider.of você consegue recuperar esses dados compartilhados. Se você deseja chamar funções de um provider, você usa o read (no botão, initState, etc. mas não no build). Se você tem um ChangeNotifierProvider você precisa usar o .watch ou Provider.of dentro do build (assim a widget irá rebuildar quando algo for atualizado no dado que está compartilhando via Provider)
@@drantunes entendi, agradeço muito 🙏🏼
Professor, tem alguma aula especifica falando sobre async? você lançando assim eu fiquei com dificuldade de entender. senti falta de uma explicação mais detalhada. se tivesse forma de praticar mais isso pra entender seria bom.
Infelizmente não tem aula específica :\ No geral, o Dart funciona de forma síncrona (as operações são executadas no mesmo instante) e assíncronas (as operações são realizadas "em background" e retornam os dados no futuro). Por isso um código a = a + 1 é síncrono, enquanto uma chamada à uma API ou Database geralmente é assíncrona, pois pode demorar para processar e você não deseja que a interface fique travada para o usuário esperando a resposta de processamento. Por isso usamos o async - await, uma forma de tratar operações que tem natureza assíncrona... Se você não acha a leitura fácil, pode usar ao invés do async - await uma opção .then no final do código assíncrono, algo como future.then((result) { ... })
Há algum problema em disponibilizar providers para a aplicação inteira, ou eu devo restringir os mais específicos apenas para as telas as quais eu realmente preciso utilizar?
Ótima explicação a propósito!
As duas coisas. Providers que serão usados pela aplicação toda (e.g. algum serviço de usuário, pode ser global). Mas se você possui algum provider que é usado em apenas um local, o ideal é que ele fique mais próximo do seu uso mesmo. Isso porque o Provider utiliza a árvore de widgets para busca das instâncias 👍
qual o vídeo onde vc adiciona a lista de favoritas a alguma forma de permanência de dados? tentei fazer sozinho com shared preferences mas to apanhando D:
Recomendo ver toda a playlist. Esse app de cripto parto do zero até recursos nativos ;)
pq vc parou com os videos???????????
Não entendi... ainda continuo