When working with UI in Flutter, there are often cases where you need to measure the size of widgets that have variable sizes depending on their child widgets. Let’s take the example of an OTT streaming app.
In the movie detail page, the plot section shows both text and images. If this area exceeds a certain height, a ‘More’ button appears, partially hiding the content. Pressing ‘More’ reveals the rest of the content.
This plot section does not have a fixed size. Rather, its height varies dynamically based on the amount of text data, device width, and image height. Therefore, to implement such a UI structure, it’s necessary to measure the rendered height of the widget and conditionally set up UI elements like the ‘more’ button and the hidden content based on whether it exceeds a certain height.
So, how can we measure the dynamic size of widgets? In this post, we’ll explore step-by-step how to measure the variable size of widgets through a simple example. Additionally, we’ll delve into the following concepts, addressing Flutter’s rendering process.
- WidgetTree, ElementTree, RenderTree
- BuildContext
- RenderObject
- addPostFrameCallback
- NotificationListener
Implementation Goals
Let’s briefly examine the example we’ll cover in the post.
The above screenshot depicts a simple page displaying information about movie cast members. It consists of a Text widget for the title section and a ListView widget with ExpansionTile displaying information about the cast members, all wrapped inside a Column. The Text widget for the title section shows the current height of the Column.
class CastInfoPage extends StatelessWidget {
const CastInfoPage({super.key});@override
Widget build(BuildContext context) {
return Scaffold(
backgroundColor: const Color(0xFF000000),
appBar: AppBar(
leading: const Icon(
Icons.arrow_back_ios,
color: Colors.white,
),
titleSpacing: 0,
backgroundColor: Colors.black,
centerTitle: false,
title: Text(
'Dune: Part Two',
style: AppTextStyle.headline1,
),
),
body: SafeArea(
child: SingleChildScrollView(
padding: const EdgeInsets.symmetric(horizontal: 16) +
const EdgeInsets.only(top: 20),
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text(
'Height : ${0}',
style: PretendardTextStyle.bold(
size: 24,
height: 37,
letterSpacing: -0.2,
),
),
const SizedBox(height: 10),
ListView.separated(
physics: const NeverScrollableScrollPhysics(),
padding: EdgeInsets.zero,
shrinkWrap: true,
itemCount: CastModel.castList.length,
separatorBuilder: (_, __) => const SizedBox(height: 8),
itemBuilder: (context, index) {
final item = CastModel.castList[index];
return ExpansionTile(
tilePadding: EdgeInsets.zero,
title: Row(
children: [
ClipRRect(
borderRadius: BorderRadius.circular(56 / 2),
child: CachedNetworkImage(
height: 56,
width: 56,
imageUrl: item.imgUrl,
fit: BoxFit.cover,
),
),
const SizedBox(width: 10),
Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text(
item.name,
style: AppTextStyle.title1,
),
Text(
item.role,
style: AppTextStyle.body3.copyWith(
color: AppColor.gray02,
),
)
],
),
],
),
children: <Widget>[
Text(
item.description,
style: AppTextStyle.body3,
),
],
);
},
)
],
),
),
),
);
}
}When you click on the ExpansionTile, the widget expands to show detailed information about the cast members. Therefore, the size of the widget changes, requiring adjustment of the height value accordingly. We can summarize the following requirements.
- Must be able to obtain the precise size of the currently rendered widget.
- Should be able to access the value in the measuring widget to handle UI conditionally.
- Must detect changes in widget size dynamically and obtain the changed size (not expandable size).
- Should be easy and convenient to use.You can check out the implemented example through the following site.
How are Widgets Drawn?
First, let’s take a look at how widgets are drawn on the screen in Flutter.
You’ve probably heard about the concept that Flutter creates widgets based on a 3 Tree Architecture consisting of Widget, Element, and Render. You may not be very familiar with encountering objects of elements or render trees during Flutter development, as it's not very common. However, understanding the basic concepts of Flutter's widget tree structure can be very helpful when direct manipulation or access to element or render objects is required, as in this example. So, let's try to explain it in a way that's easier to understand.
Widget Tree — Blueprint of a Car
class Lamborghini extends StatelessWidget {
const Lamborigini({super.key});
@override
Widget build(BuildContext context) {
return Car(
paint: RedPaint(),
engine: 4LV8Engine(),
wheel: RimsAltaneroShinyBlack(),
carbon : UpperExteriorCarbon(),
...
);
}
}To help understand the three tree structures of widgets, let’s use the analogy of building a Lamborghini. To build a car, various components such as color, engine, etc., need to be determined. In the above code, we’re passing necessary options to the Car class within the build method.
This process is similar to creating a blueprint for the car, defining how the car’s components are structured and shaped. StatelessWidget or StatefulWidget always override the build method and return a widget inside. These codes are returned as a widget tree and internally create the necessary 'element' through createElement().
Key Point!
The code inside thebuildmethod is returned as a 'widget tree' and creates an 'element tree'.
Element Tree — Car Parts and Engineers
The element tree generated from the widget tree is comprised of elements that are part of widgets and are responsible for managing widget lifecycle and state changes. While the widget tree contains structural information about the code written by developers, the element tree consists of pieces of widgets created based on the widget tree.
If the widget tree is likened to a blueprint of a car, the element in the element tree can be compared to both the car parts and the engineer managing those parts. Just as a car engineer arranges and manages necessary parts according to the blueprint, the element tree creates elements that are parts of the UI needed for the final rendering of widgets and communicates any changes to the render tree as necessary. Now, let's take a closer look at the characteristics of elements.
Widgets are Immutable, Elements are Mutable
All Flutter widgets are immutable, meaning their content cannot be modified during runtime. This is similar to a car not being able to suddenly transform into a motorcycle. However, elements are mutable, allowing widgets to be changed as needed. In other words, elements can be removed and replaced with new elements.
Role of BuildContext
The BuildContext, which we always pass as an argument when executing the build method in StatelessWidget or StatefulWidget, is used when direct manipulation or access to the Element object is required. It also indicates where the Element created from the widget tree is positioned in the tree. It's like an engineer (BuildContext) examining the blueprint (Widget Tree) to determine where the necessary parts (Element) are and arranging them accordingly.
showDialog<void>(
context: context,
builder: (BuildContext context) {
return AlertDialog(...);
},
);Similarly, when displaying a popup using methods like showDialog, we always need to pass the BuildContext because we need to know which widget (screen) in the composed tree the dialog should appear on.
Key Point!
- The element tree manages the widget’s lifecycle and communicates changes to the render tree as needed.
- BuildContext is used to determine the position of widgets currently displayed on the screen and plays an important role in manipulating or accessing elements.
-BuildContext is also considered as an Element.
Rendering Tree — Car Manufacturing, Manufactured Car
Once the necessary elements are created, the widget finally creates a Render Tree. It's used to handle the actual rendering via the widget's createRenderObject method, which creates a RenderObject, an object that manages the widget's size and layout information. During this process, the RenderObjectElement, created from the Element Tree, becomes directly involved.
The rendering tree can be likened to the manufacturing of a car using car parts. It completes the car using the components manufactured from the Element Tree.
In the rendering tree, two main methods, layout and paint, are used to actually render the widgets we see. During the layout phase, parent nodes pass constraints to child nodes, and at the lowest level, the final size information is passed back up to determine where and how widgets should be drawn. Then, the paint operation is performed, passing the work to the GPU thread to finally complete the widgets.
Key Point!
What If it Wasn’t Composed of Three Widget Trees?
Now that you have some understanding of the architecture of the widget tree, you can clearly understand the reason why widgets are composed of three widget trees. If you were to replace a wheel on a car, you wouldn’t need to rebuild the entire car from scratch. You’d simply replace the existing wheel with a new one. Flutter operates on a similar principle. When parts of a rendered widget need to change based on state, the corresponding element detects this and communicates the changes to the render tree, allowing only the necessary parts to be re-rendered.
However, if Flutter’s widget tree were composed of only one tree, even widgets that didn’t need to change based on state would be redrawn, leading to inefficiencies. It would be like building a new car every time you change a wheel.
In summary, the fundamental reason Flutter’s widgets are composed of three tree structures is to efficiently re-render only the necessary parts of the screen when changes are needed based on state.
1. Separating Widget Trees and Accessing Render Objects via BuildContext
Now, let’s go through step by step how to derive the size of widgets with variable sizes depending on their child widgets.
As mentioned earlier, the rendered size of a widget exists in the render tree within a RenderObject, and to access this object, we need a BuildContext. Therefore, the formula is established that with just a BuildContext, we can access the rendered size of a widget.
Size size = context.size!;With this code, we can check the rendered size of a widget accessible via the BuildContext.
However, there is one problem in the current example code’s widget tree.
We want to obtain the rendered size of the Column widget through its associated RenderObject. However, the BuildContext that can access the RenderObject is located higher up at the CaseInfoScreen level. This means that if we proceed like this, we’ll end up measuring not only the size of the Column but also the size of the AppBar, which is a child widget of the Scaffold.
To solve this issue, there are various methods, but the simplest approach is to separate the widget whose size you want to measure, like a StatelessWidget or StatefulWidget. By doing this, a new sub-widget tree is created where the BuildContext is directly accessible through the build(BuildContext context) method of the separated widget. This is commonly referred to as "separating the BuildContext."
class ContentView extends StatefulWidget {
const ContentView({Key? key});
@override
State<ContentView> createState() => _ContentViewState();
}
class _ContentViewState extends State<ContentView> {
double renderedHeight; // <-- Rendered height of the [ContentView] widget
@override
void initState() {
super.initState();
/// Accessing the rendered size of the widget via [BuildContext]
/// and assigning it to the renderedHeight variable
renderedHeight = context.size?.height ?? 0;
}
@override
Widget build(BuildContext context) {
return Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text(
'Height : ${renderedHeight}', // <- Displaying the rendered height in a Text widget
),
...
],
);
}
}Now, as shown in the above code, by separating the widget we want to measure into a separate StatefulWidget, we can obtain the rendered height of the desired widget by accessing the size value through the BuildContext within the new build method.
NOTE
If you don’t separate it into a separate widget, using GlobalKey to find the RenderObject can also be a good approach.
2. Obtaining Size When Widget Rendering is Complete
However, running the above code will result in the following runtime error:
======== Exception caught by widgets library =======================================================
The following assertion was thrown building Builder(dirty):
Cannot get size during build.Why does this error occur?
As explained earlier, in the render tree, the layout method is responsible for passing constraints from parent nodes to child nodes and determining the final size information from the bottom node to the top node to decide where and how the widget should be drawn. The problem arises because an attempt is made to access the size value before the layout method is executed.
To address this issue, Flutter provides the addPostFrameCallback method. This method is used to register a callback that is invoked after the widget has been painted on the screen. In other words, it's a callback method that is executed after the rendering tree operations are completed.
WidgetsBinding.instance!.addPostFrameCallback((_) {
setState(() {
renderedHeight = context.size!.height;
});
});Inside the addPostFrameCallback callback method, as shown in the code above, you can assign the rendering height of the widget accessed through the BuildContext to the renderedHeight variable. This way, by accessing the rendering size value through the context only after the widget has been rendered, you can assign a value to the renderedHeight variable without encountering any errors.
3. Detecting and Obtaining Size When Widget Size Dynamically Changes
While most of the requirements have been met, there’s one remaining functionality: detecting when the widget’s size changes due to user interaction and displaying the updated size on the screen.
When the ExpansionListTile widget on the screen is clicked, the widget expands, changing its size. However, the current code does not detect the size change and update the value.
To address this, we can use a widget called NotificationListener, which is useful for detecting and handling notifications (such as size changes, scrolling, gestures, etc.) that occur within the widget tree.
NotificationListener(
onNotification: (_) {
if(renderedHeight != context.size!.height) {
setState(() {
renderedHeight = context.size!.height;
log('height : $renderedHeight');
});
}
return true;
},
child: Column(...)
)Wrap the existing Column widget with a NotificationListener widget. Inside the onNotification callback, add logic to detect the size change of the widget and update its size accordingly. In the provided code, the setState method is used to update the changed size.
NOTE
SinceNotificationListenercan receive events like scrolling or touch gestures, which could lead to unnecessary updates if the size remains the same, the update logic is placed within the conditionif(renderedHeight != context.size!.height).
By adding this code, the widget’s height changes are detected, and the size is updated accordingly. However, a new issue arises: continuous execution of the onNotification callback whenever the widget's size changes.
[log] height : 367.0
[log] height : 367.0
[log] height : 369.3854225873947
[log] height : 375.8518112897873
[log] height : 385.81551444530487
[log] height : 435.25
[log] height : 413.13516367971897
[log] height : 430.28125
[log] height : 448.9247215986252
[log] height : 469.3435592651367
[log] height : 491.38857555389404
[log] height : 551.9744523763657
[log] height : 540.0271100997925
[log] height : 567.0The onNotification callback is repeatedly executed whenever the widget's size changes, leading to multiple unnecessary calls to the setState method. This could potentially impact performance and needs to be addressed.
To solve this issue, we can implement a debouncer logic. A debouncer delays consecutive calls for a certain period and executes the action only after the last call.
/// Deboucner Module
class Debouncer {
final Duration delay;
Timer? _timer;
Debouncer(this.delay);
void run(VoidCallback action) {
_timer?.cancel();
_timer = Timer(delay, action);
}
}/// ContentView Widget
double? renderedHeight;
final Debouncer debouncer = Debouncer(const Duration(milliseconds: 50));
Widget build(BuildContext context) {
return NotificationListener(
onNotification: (_) {
debouncer.run(() { // <-- Apply Debouncer Callback
if(renderedHeight != context.size!.height) {
setState(() {
renderedHeight = context.size!.height;
log('height : $renderedHeight');
});
}
});
return true;
},
child: Column(...)
...
}In the provided code, a Debouncer class is declared, and within the onNotification callback, the debouncer is used to delay consecutive calls to the setState method. This ensures that the setState method is only called after the widget's size has stopped changing, optimizing performance.
4. Modularizing for Ease of Use
Since the functionality of obtaining the rendering size of a variable widget can be applied to different screens or multiple projects, modularizing it for easy use is a good idea.
Therefore, I created a custom widget called MeasureSizeBuilder. This widget encompasses all the logic discussed earlier, and it is designed to allow access to the rendering size of the specified widget through the builder property, which returns the widget whose size needs to be measured. The size can be accessed through the size property within the builder.
Now, let’s take a look at the completed example code.
import 'package:cached_network_image/cached_network_image.dart';
import 'package:flutter/material.dart';
import 'package:measure_size_builder/measure_size_builder.dart';
import 'package:measure_size_implementation/src/cast_model.dart';
import 'package:measure_size_implementation/src/style/app_color.dart';
import 'package:measure_size_implementation/src/style/app_text_style.dart';
class CastInfoPage extends StatelessWidget {
const CastInfoPage({Key? key});
@override
Widget build(BuildContext context) {
return Scaffold(
backgroundColor: const Color(0xFF000000),
appBar: AppBar(
leading: const Icon(
Icons.arrow_back_ios,
color: Colors.white,
),
titleSpacing: 0,
backgroundColor: Colors.black,
centerTitle: false,
title: Text(
'Dune: Part Two',
style: AppTextStyle.headline1,
),
),
body: SafeArea(
child: SingleChildScrollView(
padding: const EdgeInsets.symmetric(horizontal: 16) +
const EdgeInsets.only(top: 20),
child: MeasureSizeBuilder(
builder: (context, size) {
return Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text(
'Height : ${size.height}',
style: PretendardTextStyle.bold(
size: 24,
height: 37,
letterSpacing: -0.2,
),
),
const SizedBox(height: 10),
ListView.separated(
physics: const NeverScrollableScrollPhysics(),
padding: EdgeInsets.zero,
shrinkWrap: true,
itemCount: CastModel.castList.length,
separatorBuilder: (_, __) => const SizedBox(height: 8),
itemBuilder: (context, index) {
final item = CastModel.castList[index];
return ExpansionTile(
tilePadding: EdgeInsets.zero,
title: Row(
children: [
ClipRRect(
borderRadius: BorderRadius.circular(56 / 2),
child: CachedNetworkImage(
height: 56,
width: 56,
imageUrl: item.imgUrl,
fit: BoxFit.cover,
),
),
const SizedBox(width: 10),
Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text(
item.name,
style: AppTextStyle.title1,
),
Text(
item.role,
style: AppTextStyle.body3.copyWith(
color: AppColor.gray02,
),
)
],
),
],
),
children: <Widget>[
Text(
item.description,
style: AppTextStyle.body3,
),
],
);
},
)
],
);
},
),
),
),
);
}
}
Finally, we have fulfilled all the requirements we set out to achieve 🎉
I have published the measure_size_builder package used in the example. For those interested in this feature or modularized code, please refer to the following link.
Conclusion
In this post, we explored how to determine the rendering size of widgets with variable sizes, along with the principles of widget rendering in Flutter. As delving deeply into the rendering principles of Flutter can become quite challenging and complex, we only covered simple concepts in this post. If you’re interested in learning more about the detailed rendering principles of Flutter, I recommend checking out the following post. It’s really well organized.
Also, if you’re curious about the complete code of the example covered in the post, please refer to my GitHub repository.
I’ll be back with more informative topics next time. Thank you for reading :)
