Hi lads!

As the year wraps up, I wanted to wish you all a fantastic New Year filled with vibrant colors, smooth gradients, and zero bugs. 🚀

See you on the other side, and may your build always succeed on the first try!

Upcoming Happy New Year, everyone!

In the spirit of celebration, here’s a sneak peek at my Color Orb Demo – a widget that’s honestly quite useless… but hey, it looks absolutely stunning.

Coding traditions must be honored… So, in classic developer style, I’ll post the full thing next year. 😎

#widget #animation

Understanding pub get, pub upgrade, and pubspec.lock in Flutter

One of the common confusions among Flutter developers i face is how pub's dependency management works, especially the difference between pub get and pub upgrade, and the role of pubspec.lock. Let’s break it down.

We all know how to specify a version for a dependency in pubspec.yaml, pub provides us Semantic Versioning Specification to do that.

To avoid dependency conflict errors, we must understand these three things perfectly - pub get, pub upgrade and the role of pubspec.lock

❗️ pub get
• Fetches dependencies specified in pubspec.yaml, but prioritizes versions already locked in pubspec.lock and cached in .pub-cache.
• If nothing changes in pubspec.yaml, it won’t fetch newer versions from remote sources.

❗️ pub upgrade
• Forces an update to the latest versions of dependencies allowed by pubspec.yaml.
• Semantic cases when it can upgrade dependencies: '>=x.y.z <a.b.c' or ^x.y.z
• It can cause API changes and compilation issues.

❗️ The role of pubspec.lock
• This file ensures that all developers on a team use the same dependency versions.
• It locks specific versions after pub get. Once you've got a lockfile for your app, pub won't touch it until you tell it to. Once your app is locked, it stays locked until you manually tell it to update the lockfile.
• If pubspec.lock is not committed, different developers might get different versions, leading to inconsistency and potential errors.

⚠ Recommendations

✔ Avoid using pub upgrade carelessly. If you’re working in a team, always track pubspec.lock to prevent version conflicts. It’s better to lock dependency versions when stability is more important than new features.

✔ Commit pubspec.lock, but do it only for application packages to ensure that all developers on a team use the same dependency versions. When checking the Dart official documentation under “What not to commit”, we find that it is not recommended to commit the pubspec.lock file for libraries in source code repositories. The reason is that libraries should support a range of dependency versions, allowing flexibility while ensuring compatibility with tested versions.

✔ When multiple dependencies are involved, try to use the ^ symbol or range of versions. Depending on single concrete versions lacks flexibility. Coupled with shared dependencies, it leads to version lock. To cope with version lock, your package should depend on a range of versions. Once your app has a solid set of versions for its dependencies, that set gets pinned down in a lockfile. That ensures that every machine running your app uses the same versions of all of its dependencies.

Did you know that early Android versions didn’t have official Vsync support? This meant there was no proper synchronization between the GPU and display, leading to inconsistent frame rates and screen tearing.

❗️Before Vsync

Back then, Android relied on double buffering, where the GPU rendered frames in a back buffer. Once ready, it swapped buffers without any fixed timing. If the swap happened while the screen was reading data, you’d get screen tearing (split images). The frame rate was unstable, making animations feel choppy.

❗️After Vsync & More!

Starting with Android 4.1, things changed for the better:
✔️ Vsync was introduced to sync the GPU’s frame generation with the display’s refresh rate (e.g., 60Hz), preventing tearing.
✔️ Triple Buffering helped reduce lag and ensure smoother transitions between frames.
✔️ Choreographer standardized when rendering happens, leading to more consistent animations.

I bet almost every Flutter developer worried at least once that calling setState too frequently might slow down your Flutter app. Let’s see what really happens when we call setState ONE MILLION TIMES back-to-back!

Here’s the madness in code form for simple Counter app 🤡:

// Extreme Increment!
void _setState1000000() {
  for (int i = 0; i < 1000000; i++) {
    setState(() => _counter++);
  }
}

If we check Flutter’s profiler after calling _setState1000000(), we’ll discover that everything remains smooth! Even after one million setState calls, Flutter does NOT rebuild the UI one million times. Instead, it triggers only one rebuild per frame!

When you call setState, Flutter marks the widget as “dirty” (needs rebuild). If you call it again before the next frame, Flutter sees it’s already dirty and does nothing extra.

Check out Flutter’s internal logic 🤔:

void markNeedsBuild() {
  if (dirty) return;  // Already marked dirty? Do nothing.
  _dirty = true;
  owner!.scheduleBuildFor(this);
}

Inside owner.scheduleBuildFor(this), Flutter gathers widgets that need rebuilding and schedules the next frame update. Since the widget is marked dirty only once, even if setState is called 1,000,000 times, it is added to the rebuild queue only once, resulting in just one frame update.

This tiny check is what allows Flutter to effortlessly handle massive amounts of state updates! It automatically batches UI updates, preventing unnecessary rebuilds. Calling setState multiple times won’t overload your UI.

Can You Spot the Async Issue?

I frequently see Flutter developers making this subtle yet critical mistake 👀:

final List<String> list = ["1"];

void main() async {
  // simulating near real case problem
  Timer.periodic(const Duration(seconds: 1), asyncWork);
}

Future<void> asyncWork(_) async {
  if (list.isNotEmpty) { // dangerous check
    await Future.delayed(const Duration(seconds: 2)); // some async work

    list.removeAt(0);

    print('completed');
  }
}

Even though we performed a check (list.isNotEmpty) at the beginning of asyncWork, running this code will lead to an RangeError(index). These types of async checks in Flutter can be dangerous. Try to verify conditions again or right after the Future completes.

Why we discuss this issue? Because in the example above, it’s easy to identify the problem due to the fixed 2-second delay. But in more complex scenarios, with multiple logical branches and varying processing speeds across different devices, debugging asynchronous issues like this can quickly become very confusing.

Think your map lookups are O(1)? Well) Let’s break down how HashMaps actually work, why bad hashing is a crime against performance, and how to avoid turning your code into a slow, memory-hungry mess.

Read the full post here:
🔍 Understanding Dart’s HashMap: Internals, Collisions, and Performance

Just read this good article by DCM.dev on 10 lesser-known Dart & Flutter functionalities - highly recommend it! You’ll probably walk away with a few new tools for your toolbox. 🙂

One of my favorites was the Future.any example - super handy when you need the first completed future, whether it’s a success or failure. Perfect for fallback strategies.

Important note when using Future.any:
Future.any() gives you the first responder, but the rest of your futures are still out there, doing their thing - sipping API calls, hogging memory, living their life. So if you’re triggering expensive tasks, be careful - they can still consume resources even after Future.any() resolves🤷‍♂

Use with care - and maybe a touch of respect. 🫡

So recently I tried to create that "beautiful") Liquid Glass effect from iOS 26 in Flutter. Turns out… It is quite hard to implement this exact effect 😅. But the good news? There are already plenty of open-source demos and clever packages out there, and by digging into them, I somehow understood what really goes into making this effect feel so magical.

If you're like me and didn't initially grasp the logic behind this effect, this post will give you an abstract overview of essential parts and what to search for to get the explanation behind it.

1. Transparent and Adaptive Colors
iOS 26 doesn’t just blur the background, it blends with it. UI elements are semi-transparent and react to what’s behind them in real-time. If your wallpaper is dark or colorful, buttons subtly shift to reflect that tone. The system dynamically samples colors and adjusts the tint to stay visually coherent.

How it works? - Real-time background texture sampling, color blending

2. Refraction Like Real Glass
Elements behave like actual thick glass. The content behind is bent, warped, and distorted, just like how light refracts through a lens.

How it works? - Screen-space coordinate distortion via Normal Map

3. Reflections and Environmental Highlights
These aren’t static shapes with transparency. They reflect. If your wallpaper has texture or bright areas, you’ll notice faint highlights mirrored on buttons or cards. And when you tilt your phone, those reflections shift ever so slightly.

How it works? - Simulated lighting model + environment map + real-time reflections

4. Fluid Motion and Morphing UI
Buttons compress when scrolling, chips stretch and float, and everything has this elastic, responsive behavior. Nothing feels flat or static.

How it works? - Physics-based animation, Metaballs/SDF Shape Blending

Final thoughts:
And while Flutter doesn’t (and probably won’t) support this style natively, packages like liquid_glass_renderer can get you pretty close. Although the final result might still fall slightly short of native-level realism, the visual fidelity is impressive overall. Hats off to the devs-pulling off this level of complexity takes real skill, and performance in tests looks solid too ❤️‍🔥

It’s definitely a non-trivial shader, and without AI-assisted explanations, I probably wouldn't have understood what each part does 🫠