death of a design (decision)

One big challenge for us developers is accepting that we can make mistakes in our designs. It’s easy to point out problems in other people’s code, but true growth happens when we look at our own code and find areas to improve. This self-reflection is where we become better at coding.

Being Open to Change

The book teaches us that being open to changing our designs is crucial. Making a better-designed program might mean going back to our code and making improvements. It reminds us that designing things is an ongoing process.

Designing is a Do-Over

Designing, as the book explains, is a step-by-step process. It’s about creating, checking, and fixing things over and over again. This process applies not only to the code we create but also to the designs we get from other programmers. Being flexible and ready for change is key.

Watch Out for Pride:

The book warns us about feeling too proud to admit our designs might have issues. If we’re not willing to look at and improve our designs, we might miss opportunities to make them better. Being humble and committed to getting better is important.

Conclusion:

In the world of software design, learning from our mistakes and improving our designs is a sign of a good developer. The book is like a guide, helping us navigate the complexities of coding and reminding us that we get better by always being ready to learn. So, let’s take on the challenges, learn from our mistakes, and create designs that last.

References

Head First OOA&D book

And that’s it, I would love to hear your feedback about this article or discuss any related topics, so feel free to drop a comment or reach out to me on Twitter or LinkedIn.

Thanks for your time.

However, sometimes we forget what MediaQuery really is.

but before that, I want to display an experiment by Christian Findlay which he shared on a Twitter thread.

He was trying to calculate how many Page intense created and how many time build() method calls while resizing the screen widget, so he added aText widget to display that.

So we can see here that the widget rebuilds many times because the build() method is calling every time the screen width changes.

Then he removes MediaQuery from Text widget and tried the same thing,

But what we find here is the widget is not rebuilding, the build() method only called once in the beginning.

So why this happens?

MediaQuery and rebuilds

So, Let’s go back to when we were talking about what we forget about MediaQuery.

MediaQuery is a InheretedWidget.

Sometimes we forget about that. So they may use MediaQuerycarelessly which can negatively impact the performance of your application.

MediaQuery is an InheretedWidgetmeans that it rebuilds all its child widgets whenever the device screen characteristics change. This is important to keep in mind because if you use MediaQuery frequently, you risk causing unnecessary rebuilds that can slow down your app.

And that makes sense why the widget is rebuilding many times when we add MediaQuery, isn’t it?

but why not when we don’t use MediaQuery while the screen size is changing? Is it any change on the screen triggers the build() method?
No.

Resizing and no rebuilds

The reason why there’s no call for the build() method while resizing the screen is, we’re getting confused between the layout phase and the build phase.

The build phase is when the Flutter framework calls the build method of a widget. In this phase, the widget is responsible for returning a tree of elements that represent the user interface. This tree can include other widgets, containers, text, images, or anything else that is part of the UI.

On the other hand, the layout phase is when the framework determines the size and position of each element in the tree. The framework takes the tree of elements created during the build phase and traverses it to calculate the position and size of each element, which is then used to render the UI on the screen.

In Summary

MediaQuery is a powerful widget that can help create responsive and adaptable user interfaces in Flutter. However, it is important to note that it requires some computing power to calculate the device screen characteristics. If you use MediaQuery too frequently, you risk causing unnecessary computational overhead that can slow down your app.

Besides that, it’s important to understand the difference between the build phase and the layout phase in Flutter. By understanding the widget lifecycle and following best practices, we can write efficient and performant Flutter apps.

References

• Inside Flutter
• Christian Twitter thread
• MediaQuery (Flutter Widget of the Week)

Thanks to Christian Findlay for bringing this great discussion to us and thanks to Gordon Hayes for sharing this info. with us.

And that’s it, I would love to hear your feedback about this article or discuss any related topics, so feel free to drop a comment or reach out to me on Twitter or LinkedIn.

Thanks for your time.

According to dart doc,

Dart is a single-threaded language.

Within an app, all Dart code runs in an isolate.

You might be wondering that if Dart is a single-threaded language how can we handle heavy tasks or long-running operations that could block the main thread and due to this the app is not responding? How could I deal with that?

That’s what we will discuss further.

What will we discuss?

1- What isolates are.

2- The differences between Thread and Isolates.

3- What the thread inside the isolate is and how it works.

4- How isolates communicate with each other.

5- Benefits of locking access between isolates.

6- Multi-threading in Dart and examples.

What are Isolates

An isolate is what all Dart code runs in. It’s like a little space on the machine with its own, private chunk of memory and a single thread running an event loop.

If you’re working with other languages like C++ for example, It might be confusing about the difference between isolates and threads. So before we jump into any details about isolates, let’s first discuss the difference between Threads and Isolates.

Threads vs. Isolates

They are both mechanisms that allow you to run code in parallel on separate execution contexts with some key differences:

Threads: are low-level mechanisms that run on the same operating system as the main thread. and they are managed by the operating system. Threads share the same memory and can communicate with each other through shared variables, etc.

Isolates: are high-level mechanisms that run independently from the main thread and they are managed by the Dart runtime. Isolates have their own memory and communicate with the main thread or each other only through message passing.

Okay, we mention above that every isolate has a thread that runs an event loop, and isolates communicate with each other with only message passing. So what are this event loop and message passing how do they work?

Event loop in isolate

Just like Kathy said,

It’s what makes really asyncronous code possible.

While the application is running on that single isolate, the Event loop inside that isolate keeps running the whole time the app is running.

The event loop just waits for any events to process just as tapping, downloading, or any other event.

And of course, we can have more than one isolate if we need it but how they can communicate with each other? by Message Passing…

Message Passing

Every isolate has its own isolated memory, and can only communicate by message passing back and forth.

Every isolate sends a message to the other isolate and the other one receives and processes it using the event loop we talked about above.

If you are common with threads, you might be confused about separating memory and lack of info. between isolates, so what are the benefits of that?

Benefits of locking access between isolates

First, let’s talk about the benefits of locking access between isolates and only passing messages between them:

1. Isolation: Isolates run in their own memory space means that they can’t directly access each other’s memory, which helps to prevent bugs and data corruption caused by the shared state.
2. Concurrency: Because isolates don’t share a memory, they can work on different tasks concurrently without interfering with each other. This allows you to take full advantage of multicore processors to improve the performance of your application.
3. Scalability: Isolates are lightweight and can run concurrently, so it’s easy to add more of them to your application as needed. This makes it easy to scale your application up to handle more traffic or data.
4. Fault Tolerance: Because isolates are independent and don’t share a memory, it’s easier to build fault-tolerant systems. If an isolate crashes, it doesn’t affect the other isolates.
5. Security: Because isolates are separate and can’t directly access each other’s memory, it’s more difficult for an attacker to exploit a vulnerability in one isolate to gain access to sensitive data in another isolate.
6. Simplicity: By passing messages between isolates instead of sharing memory, you can keep your code simple and avoid many of the complexities of shared-memory concurrency.

Multi-threading in Dart

We can accomplish Multi-threading in Dart by using isolates. Okay, enough talk we need examples...

To use isolates in Dart, you can use the Isolate class, which provides methods for creating and controlling isolates. Here is an example of how you can use an isolate to perform a task in parallel with the main thread:

import 'dart:isolate';

void main() {
  // Create the isolate
  Isolate.spawn(calculateSum, [1, 2, 3, 4, 5]);

  // Perform other tasks on the main thread
  print("Main thread is doing something else...");
}

void calculateSum(List<int> numbers) {
  var sum = numbers.reduce((a, b) => a + b);
  print("Sum: $sum");
}

In this example, the Isolate.spawn method is used to create a new isolate and run the calculateSum function on it. The main thread continues to run and perform other tasks while the isolate is running. You can also pass data to the isolate using the second parameter of the Isolate.spawn method, as shown in the example.

You can also use compute functions from dart:ui library to run a function in an isolate, it's an easy way to run a function in an isolate and get the result back.

import 'dart:ui';

void main() {
    compute(longRunningTask, 1000000).then((result){
        print(result);
    });
}

int longRunningTask(int x) {
    int sum = 0;
    for (int i = 0; i < x; i++) {
        sum += i;
    }
    return sum;
}

All in all, isolates provide an effective way to handle concurrency and parallelism in your code and it’s one of the core features of Dart and Flutter, it makes it easy to build high-performance, concurrent, and scalable systems with minimal complexity.

I have to mention that, I really recommend watching this “Flutter in Focus” video or reading this article about isolates and event loops and of course taking a look at Concurrency in Dart doc.

After the #Flutter 3.7 release, I have to mention that developers can use Plugins and Platform Channels from any isolate. read this for more info.

And that’s it, I would love to hear your feedback about this article or discuss any related topics, so feel free to drop a comment or reach out to me on Twitter or LinkedIn.

Thanks for your time.

Therefore, we do our work inside the WidgetsBinding.instance.addPostFrameCallbackcallback or WidgetsBinding.instance.endOfFrame.then so we use BuildContext safely.

So what’s the difference?

And how does this relate to the rendering process?

WidgetsBinding

the WidgetsBinding class provides us access to the current state of the widgets system or as the flutter docs say,

The glue between the widgets layer and the Flutter engine.

through the WidgetsBinding instance, we can access “addPostFramCallback” and “endOfFrame.then”.

“addPostFramCallback” and “endOfFrame.then” both can be used to schedule a callback to be executed after the rendering phase to the current frame ends.

But before showing the difference between them, we need first to define the “rendering phase”.

Rendering Phases

in #Flutter, rendering goes through four phases and each one has a specific purpose:

1. Layout phase: During the layout phase, the dimensions and positions of the widgets are calculated. it ensures that the widgets are properly positioned and sized on the screen.
2. Painting phase: During the painting phase, the widgets are painted on the screen using the dimensions and positions calculated during the layout phase. The painting phase involves traversing the widgets tree and calling the paint method of each widget.
3. Compositing phase: The compositing phase takes the painted widgets and combines them into a single image that can be displayed on the screen.
4. Rasterizing phase: in this final phase, the engine receives the updated layer tree containing the drawing instructions and converts them into pixels. in other words, the scene is displayed on the screen as a matrix of pixels.

For more deep info about rendering in Flutter, check this talk by Adam Barth.

Now, let’s jump back to our main topic…

‘addPostFrameCallback’ vs. ‘endOfFrame.then’

As we said before,

“both can be used to schedule a callback to be executed after the rendering phase to the current frame ends”

However, they differ in terms of when the callback is executed in relation to the rendering phases.

• “addPostFramCallback”: adds a callback that is executed immediately after the “rendering phase” ends but before the engine starts the “layout phase”. This method is useful for tasks that need to be performed after the widgets have been painted, but before the layout is calculated.
• “endOfFrame.then”: returns a future that completes after the “rendering phase” ends, but after the “layout phase” of the first frame has started. This method is useful for tasks that need to be performed after the widgets have been painted and the layout has been calculated.

Each method has its own purpose to fulfill your needs.

And that’s it, I would love to hear your feedback about this article or discuss any related topics, so feel free to drop a comment or reach out to me on Twitter or LinkedIn.

References:

• https://api.flutter.dev/flutter/widgets/WidgetsBinding-mixin.html
• https://api.flutter.dev/flutter/scheduler/SchedulerBinding/addPostFrameCallback.html
• https://api.flutter.dev/flutter/scheduler/SchedulerBinding/endOfFrame.html
• https://www.youtube.com/watch?v=54yoCqkew6g&ab_channel=Flutter