Hot reload or hot restart — Flutter
Hot reload is one of the more useful features of Flutter that allows us to develop and see changes almost immediately. Even though it is quick and useful, it not always friendly to all the code changes. Here, we’re going to learn how and when hot reload works.
After the code has been modified, any libraries with the changed code, application’s main library, affected libraries leading from the main library are recompiled. The compiled source code files are injected into the running Dart VM, whether it is a physical device or emulator. After VM updates the classes with the new fields and functions, the Flutter framework automatically rebuilds the widget tree, allowing you to view the changes.
Hot reload doesn’t restart the app, it only tries to build the widgets to reflect the changes by preserving the state of the application. It executes the build method and all the other codes involved in the rebuilding of all the widgets are re-executed to rebuild the widgets. So if the code changes are downstream of the widget’s build method, hot reload will work as expected.
Hot reload can be performed from terminals or supported Flutter editors. And it only works when you’re running the app in debug mode.
When do we need hot restart or full restart?
Performing hot restart takes a little more time than the hot reload but faster than the full restart. Hot restart restarts the application after the new changes are loaded into the VM while full restart also compiles the native code such as Java / Kotlin / ObjC for the specific platforms where the flutter app is going to be running.
· Hot reload doesn’t run main() or initState() of any widgets. So, if the code changes are present in these parts of the code, hot restart will be needed to see the changes.
· Hot reload builds from the root widget, if you changed the root to a new root, hot reload won’t have any idea about the change and will build the old root.
· If the app has been in the background for too long and the process has been killed.
· If the new changes introduce any compile error.
· If enumerated types are changed to regular classes or regular classes are changed to enumerated types.
· Changes are in the CupertinoTabView’s build method. (Issue 43574)
· If generic class declarations are modified.
· Changing fonts. Changing assets are supported though.
· If you change the native codes such as Java / Kotlin / Swift. Full restart will be required.
· Changes that affect the state of the app or its dependencies.
· Changes in global and static variables.
Thanks for reading… Hope you find this article useful…
