Migrated to Hive #16
Migrated to Hive #16
Conversation
The current widget 'App' uses two nested `FutureBuilder`s in a wrong way: The provided future should not be constructed inside the build method. As the [documentation](https://api.flutter.dev/flutter/widgets/FutureBuilder-class.html#managing-the-future) puts it: > The future must have been obtained earlier, e.g. during State.initState, State.didUpdateWidget, or State.didChangeDependencies. It must not be created during the State.build or StatelessWidget.build method call when constructing the FutureBuilder. If the future is created at the same time as the FutureBuilder, then every time the FutureBuilder's parent is rebuilt, the asynchronous task will be restarted. This behavior has been observed during development as flickering and crashing due to duplicate network activation. With this change the two `FutureBuilder`s now live in their own separate stateful widgets where the futures are constructed by their respective `initState` methods. This change has the furtunate side effect of making the original widget much simpler and easier to understand.
Co-authored-by: Søren Schwartz <[email protected]>
ghost
requested review from
|
@schwartz-concordium I think it's unfortunate that this was merged without squashing. Please take a look at https://github.com/Concordium/concordium-wallet/commits/main and try to make sense of it. What commits belong to which PRs? It may be obvious in this case by looking at the author, but imagine that all PRs were like this. Then you'd have a commit history that's very far from being as clear as it could be, without any gains. But also, many of the commits tell very little about why the changes were made. And many contain issues that were known and fixed before merging. This makes tools like git blame much less effective. My strong personal view is that the commit history is the most useful when every commit is a progressive improvement (complete unit of work if you will) and gives a clear explanation of why it's done. This can certainly be done properly without squashing but it's much more work (i.e. rebasing) and is in my opinion done better just as multiple PRs. I'm sorry for ranting but this matters a lot to me. I'll be very happy to do this discussion with you and the team offline. |
Purpose
Migrating from Shared Preferences to Hive.
https://concordium.atlassian.net/browse/CBW-1474
Changes
<Prefix>Serviceto<Prefix>ProviderforStorageProviderto follow the naming conventions of the Bloc architecture.https://bloclibrary.dev/#/architecture?id=data-provider
ci.ymlsince test step has been added.Checklist
hard-to-understand areas.