This week in Flutter #74: The best state management solution, again
Oh, the never-ending discussion about state management in Flutter. Which approach should you use? Is one better than the other?
There is a link in today’s issue about it. Which state management do you use? And why?
- Michele Volpato
Development 🧑💻
Dr. Riverpod: How I learned to stop worrying and love state management
Which state management solution should you use for your Flutter app? Should you use an external package or stick with what the framework already provides? Whenever a developer asks me how to approach state management, I always share Flutter state management for purists by Inclu Cat, where no external package is used. Not because they should follow that approach, but because it is essential to understand it before looking into other solutions. This article by Alessio Salvadorini makes a step forward by allowing external packages but keeping the solution as minimal as possible.
One point I disagree with is that you need to pick only one state management technique. You should choose the one that fits best the specific area you are working on. If you implement features in sub-packages, you can use a different state management solution for each of them.
Adapt your Flutter app to Android 13
What problems could you face when using your Flutter app on Android 13? Different permissions, sudden popups, what a nightmare. But despair not, because David Serrano Canales will show you how to fix those.
How to add audio wave forms to your Flutter app
It is common to have waveforms in your app when playing some music or a podcast. Debjyoti Banerjee shows you the simplest way to add them to a Flutter app.
How to Auto-Generate your Providers with Flutter Riverpod Generator
Did you know you can generate your Riverpod providers with riverpod_generator? I didn’t. How can you do that? And most importantly, how does it work? Read more in this article by Andrea Bizzotto.
Tools 🛠
Shortening Flutter test feedback cycle in VS Code
Do you run flutter test
every time you change some code? Not before git commit
,
not before opening a pull/merge request. After each code change. You don’t.
Should you? Probably not, but if you want to, read this article by
Oleksandr Leushchenko.
That’s it for this week.
If you want to comment on any of this week’s entries, you can do it in the comment section below.
Have a bug-free week,
- Michele Volpato
Leave a comment