Understanding Hot-Reload in Flutter

Maureen Josephine
May 22, 2019 · 6 min read

There’s nothing as exciting as doing a slight change to your code and seeing the change reflect instantly in the application you are building. Well Flutter has this amazing hot-reload feature that allows you to see the reflected change after bug fixes, building User interfaces and even adding certain features to the app without running your application afresh over and over again. However, there are instances when hot-reload doesn’t work. I will take you through the necessary steps in understanding how hot-reload feature works in Flutter and its Limitations.

If you are new to Flutter kindly follow this link for installation guides and setup:

How hot-reload works.

  • Any library with changed code.
  • The application’s main library.
  • The libraries from the main library leading to affected libraries.

The updated source codes are sent into a running Dart Virtual Machine. The Dart VM then reloads all the libraries with updated code, The hot-reload mechanism updates classes with the new versions of fields and functions, the Flutter framework automatically rebuild, repaint ,re-layout the widget tree, allowing one to quickly view the effects of the changes.

How to do a Hot-reload in Flutter.

If you are running the Flutter application from the terminal using flutter run, do a slight change in the code and use ‘r ‘ for hot-reload and R for hot-restart as illustrated below.

In the above illustrations you will notice that the application reflects the changes one makes. The code change is only visible when the Dart code is run again after the change. Hot-reload causes the existing widgets to rebuild and only code involved in re-building the widgets are automatically re-executed.

Occasions when modified code doesn’t run even after Hot-reload.

1. Compilation errors.

In this case, correct the errors in the specific lines of code and retry hot reloading.

2. Previous state combined with modified code changes.

If the modification affects the state of the application/ its dependencies, the data the app is working with might not be consistent with the data it might executed from scratch. The result might be different when hot-reload and hot-restart is performed.

For instance, if you modify a class definition from extending StatelessWidget to StatefulWidget (or the reverse), after hot reload the previous state of your app is preserved. However, the state might not be compatible with the new changes.

Consider the following code as a Stateless widget :

class MyApp extends StatelessWidget {
Widget build(BuildContext context) {
return MaterialApp();
}
}

Change it to a Stateful widget as:

class MyApp extends StatefulWidget {
createState() {
return MyAppState();
}
}
class MyAppState extends State<MyApp> {
Widget build(BuildContext context) {
return MaterialApp();
}

If you hot reload the code, in the terminal, You will get an error message similar to “ MyApp is not a subtype of a StatelessWidget”.

This can be solved by hot-restarting the application by pressing “R”

3. Recent UI change is excluded

If the modified code is downstream of the root widget’s build method, then hot reload behaves as expected. However, if the modified code won’t be re-executed as a result of rebuilding the widget tree, then you won’t see its effects after hot reload.

Consider this example :

import 'package:flutter/material.dart';void main() {
runApp(MyApp());
}
class MyApp extends StatelessWidget {
Widget build(BuildContext context) {
return Icon(
Icons.favorite),
}
}

In the code above, MyApp() is the root application.

After running the code, change it to appear as:

import 'package:flutter/widgets.dart';void main() {
runApp(Center(
child: Text('I love Flutter',textDirection: TextDirection.ltr)));
}
}

If you hot-reload after this change, you will find that the app’s main() is not re-executed, the widget tree is rebuilt but the app’s root widget MyApp() is not changed. It brings out no visible change after a hot-reload.

However if you hot-restart by pressing R in the terminal, the app starts from the beginning and executes the new version of main() and builds a widget tree that displays “I love flutter” text.

4. Recent code change is included but app state is excluded

A full restart is required to see the changes if one changes initializers of global variables and static fields, . For example, the following code:

final cars= [
Car("C1"),
Car("C2"),
Car("C3"),
Car("C4"),
];

After running the above code, changed it to:

final cars= [
Car("C1"),
Car("C2"),
Car("C3"),
Car("C6"),
];

You will realise that there is no visible change after hot-reload unless you restart the code afresh.

Limitations of Hot-Reload

  1. When Enumerated types are changed to regular Classes and when class are changed to enumerated types.

Enumerated types, often called enumerations or enums, are a special kind of class used to represent a fixed number of constant values.

For instance when this enumerated type:

enum Colors {
red,
green,
blue
}

Is modified to :

class Colors {
Colors(this.m, this.n);
final int m;
final int n;
}

When you hot reload this modification, you will realise that hot-reload fails without any changes to the UI.

2. When Generic types are modified.

Generic types also known as parameterized type is a type that has formal type parameters. By convention, most types have variables have single-letter names, such as E, T, S, K, and V. Read more about Generics at :

For instance consider this Generic type:

class A<T> {
T i;
}

If its Modified to:

class A<T, V> {
T i;
V v;
}

Hot reload fails to commit this changes.

To get collective Flutter resources kindly read this article:

Thank you! Happy Fluttering 😃

podiihq

We build custom software