Skip to main content

Observer Pattern: The Hidden Magic Behind Flutter State Management

When I first started learning state management in Flutter, it honestly felt like magic. I'd change one variable, call setState , and the screen would just… update. Later I met ValueNotifier and ValueListenableBuilder , and it got even stranger — now only one widget would rebuild while everything around it stayed perfectly still. I hadn't written any code to watch for changes. I hadn't wired anything up. It just worked. And anything that "just works" without me understanding why makes me a little uncomfortable. So I did what any curious developer does: I went down the rabbit hole. I wanted to know how a value "knows" when to tell the UI to rebuild. Who is listening? How does the change travel from my variable to the pixels on screen? That question led me to something much bigger than Flutter — a classic software design pattern called the Observer pattern . Once I understood it, the magic didn't disappear. It just turned into some...

Impeller: Elevating Flutter Performance with Predictable Rendering

In the world of Flutter, Impeller is a buzzword that has caught the attention of developers and enthusiasts alike. But what exactly is Impeller, and why is it crucial for Flutter apps? Let’s dive into the details.

What is Impeller?

Impeller is a new rendering engine for flutter. Now, many of you can think. What is a rendering engine. Rendering engine is nothing but a piece of software responsible for converting input instructions or data into visual or audible output. Basically, it helps us to draw UI of an app according to the instruction you give it. Flutter engine is written is C/C++language. Which is the part of dart UI. Rendering engine in Flutter orchestrates the transformation from widget tree to pixels on the screen. Before Impeller flutter used skia as a default graphics engine. But, there was some issues on it.

Challenges with Skia:

Skia has been the graphic engine for Flutter since its inception. Skia is also a powerful render engine, which powers various platforms, including Chrome, Firefox, Android, and ChromeOS. However, Skia wasn’t custom-built specifically for Flutter. For this reason, there many issues with flutter app. Like,  

  • Performance: Early-onset jank (stuttering or frame drops) was a common issue.
  • Platform-Specific Limitations: Skia didn’t fully leverage modern hardware-accelerated graphics APIs like Metal on iOS and Vulkan on Android.
  • Lack of Instrumentation: Skia lacked comprehensive instrumentation for capturing and analyzing graphics resources. 

What's new in Impeller? 

Impeller solved many problem of Skia. Also, it is customly build for flutter, which can take advantage of modern graphics APIs like Metal or Vulkan. For this, developer can improve the performance of their flutter app. There are many advantage of Impeller. Like,

  • Predictable performance: Impeller compiles all shaders and reflection offline at build time. It builds all pipeline state objects upfront. The engine controls caching and caches explicitly.
  • Instrumentable: Impeller tags and labels all graphics resources, such as textures and buffers. It can capture and persist animations to disk without affecting per-frame rendering performance.
  • Portable: Flutter doesn't tie Impeller to a specific client-rendering API. You can author shaders once and convert them to backend-specific formats, as necessary.
  • Leverages concurrency: Impeller can distribute single-frame workloads across multiple threads, if necessary.

Flutter enables Impeller on android and ios by default. But for legacy devices that don't support Vulkan, Impeller will fallback to the the legacy OpenGL renderer. If you want to disable the Impeller you can do it. For this, checkout the Impeller documentation.

For Flutter developer across the world, the creation of Impeller is a significant update in Flutter framework. Which will help a developer to improve the Flutter apps, by enhancing app quality.

Comments

Popular posts from this blog

Keep Your Promises: The Liskov Substitution Principle Made Simple

If you're learning clean code, you'll keep running into the "SOLID" principles. The L stands for the Liskov Substitution Principle (LSP) — a scary name for a genuinely simple idea. This guide starts from zero, so no prior knowledge is needed. What it is The Liskov Substitution Principle says: If something is supposed to work like a certain type, then any "version" of that type must be able to take its place without causing problems. That's the whole thing. If you call something a Doctor , it has to actually behave like a doctor everywhere a doctor is expected. If you call something an ApiClient , it has to behave like one everywhere. Break that, and your program fails — usually later, in a confusing way. The principle is named after Barbara Liskov, a computer scientist who described it back in 1987. But you don't need the academic version to use it well. First, what does "substitute" mean? This is the word that makes the whole pr...

Understanding BuildContext in Flutter!

As a Flutter developer, you might have encountered the term BuildContext early in your journey. Despite its importance, many developers struggle to grasp its full significance. Today, we’re going to dive into what BuildContext is, what it does, and why it’s crucial for running your Flutter app. What is BuildContext In both stateless and stateful widgets, when you override the build method, it takes BuildContext context as a parameter. This context is provided by the Flutter framework. Here’s a simple example to illustrate: Widget build(BuildContext context) { return OutlinedButton( onPressed: () async { await Future< void >.delayed( const Duration(seconds: 1 )); if (context.mounted) { Navigator.of(context).pop(); } }, child: const Text( 'Delayed pop' ), ); } BuildContext do a simple task, track all of your widget location. In flutter, it all about widgets. Everything is build on a collection of widgets. Some widgets are parent w...

Observer Pattern: The Hidden Magic Behind Flutter State Management

When I first started learning state management in Flutter, it honestly felt like magic. I'd change one variable, call setState , and the screen would just… update. Later I met ValueNotifier and ValueListenableBuilder , and it got even stranger — now only one widget would rebuild while everything around it stayed perfectly still. I hadn't written any code to watch for changes. I hadn't wired anything up. It just worked. And anything that "just works" without me understanding why makes me a little uncomfortable. So I did what any curious developer does: I went down the rabbit hole. I wanted to know how a value "knows" when to tell the UI to rebuild. Who is listening? How does the change travel from my variable to the pixels on screen? That question led me to something much bigger than Flutter — a classic software design pattern called the Observer pattern . Once I understood it, the magic didn't disappear. It just turned into some...