Practical technology learning
Flutter Hot Reload: Separate a Code Update from Fresh State Initialization
A changed screen and a fresh app start are different observations. This Flutter debug-lab plan compares a rebuilt label with a retained counter, then restarts the app to inspect initialization. The values are fictional and the procedure is a prediction to verify in an actual local Flutter environment.
Make initialization observable
Create a small State object with a counter initialized to 1 in initState, starting the override with super.initState(). Add a short initialization log. Run the debug app and use a button to reach 4, recording both the display and the lifecycle observation before editing the source.
Change code that runs in different places
Change the initialization assignment from 1 to 9 and change a simple label produced by build. These edits ask different questions: does the rebuilt UI use the new label, and has the counter's startup assignment run again? Keep those questions separate in the result sheet.
Predict the hot-reload observation
Hot reload preserves existing app state and rebuilds the widget tree. It does not rerun main or initState for the retained State object. In this controlled fixture, a changed build label can therefore appear while the current count remains 4. Check the tool result and the actual log rather than relying only on the label.
Compare a hot restart
Hot restart restarts the Flutter app and discards its current in-memory state. A newly initialized counter can then use 9 in this fixture. Record the new initialization log alongside the displayed value. This observation is different from testing saved preferences or another persistence mechanism.
Record the development context
- Flutter SDK, target and debug mode used.
- Initial count and interaction sequence before the edit.
- Exact reload or restart action and its tool result.
- Changed label, displayed count and initialization log.
Choose the restart that matches the edit
Some code changes cannot be applied through hot reload, and changes to native code need a full restart. Follow the relevant tool guidance before diagnosing an initialization bug. A successful development reload is not evidence that a release build, startup path or persistence feature has been tested.