Today I’m taking a day off from Interactive Diary, to focus on fixing My Wallet app, which is way outdated from Flutter 3.3 recently released. The last update I did for My Wallet was around June last year, with Flutter 2.2 😅 I know, so much have changed since then, and that’s easy to understand why My Wallet was so outdated.
Here are some few lesson I learned while upgrading Flutter version for My Wallet.
Update regularly
This is the biggest mistake I made in my personal project, that causes me great time to update later when the app is totally broken. The longer the wait, the harder it is to update.
My suggestion (to my future self) is to update at most 4 weeks after new Flutter (and/or Dart) release version is out. This is to give time to research the changes in the release note, wait for minor bug fixes, and read feedbacks from other developers before dive in into code.
Choose dependencies wisely
With my first Flutter app, I did not care much when choosing what dependencies to use in my app. As result, in this big update, I have to remove 2 of my dependencies and search for alternative solution.
After a hard afternoon fixing the dependencies issues, here are my lesson learn to choose better dependencies
Flutter favourite program: If a package is part of Flutter favourite program, then it’s very unlikely to be outdated. It will be safe at least a year before it’s outdated. So I can assume it’s safe to pick a Flutter favourite package from Flutter favourite listing.
Frequent release: I learn to check the time in between the first release and the second release, and also the time of the last release of the package. This shows whether the maintainer is actively maintaining package, or there is no longer maintenance. This is helpful in case there’s any issue in the future, if the owner is still actively maintaining the package, the higher change that my issue can receive attention and discussion to fix.
More discussion: This is actually related to the point above, frequent release, but it’s more into how active the community is toward the package. Check the discussion in issue tab, if the maintainer or other community collaborators are actively discussing the issues, with solutions to any current problem, then it’s highly likely that the package will stay active for a long time. If there are PRs attached to the discussion, that’s the ‘pick-me’ signal.
More collaborator: Once again, this is related to the discussion and frequent release point. The more collaborator, the higher chance to get issues fixed and merge. Simply because when there are more collaborators, the maintainer will not be overloaded with issues in the package, hence there will be more manpower to get the issue fix and maintain the package.
Less dependencies on other package: I totally did not realised how important this point is until I faced the worst version conflict I have ever had. The reason is because the package I selected dependents on more than other 10 packages. That was a great nightmare for me.
Give more comments
I know some developers think comments in the code are for junior, but personally I think it’s a great way to refresh your mind a month later when you read your own code. At least that’s what happens with me, in My Wallet.
I used GitHub project, and GitHub issues to maintain my app. And I noted the meaning of my code whenever I think the code is complicated. Thanks to this practice, after a year since I last updated the app, it’s not too difficult now to retrace my steps, and I can complete upgrading the app in just 2 days (~20 hours)
That’s all for today. I’m exhausted. I need to sleep.
If you like my post, please follow me for more tips.
Comments