DEV Community: Nikki Goel

How “Design Patterns Explained” Changed the Way I Design Software

Nikki Goel — Tue, 02 Jun 2026 18:45:22 +0000

I read Design Patterns Explained 2nd Edition a few months ago. I thought I'd finally write about it and some of the lessons I took away from it.

I was reading the final chapters while starting Offline Dashcam, a project at Wheelseye, a logistics company. Looking back, it was the perfect project to apply many of the ideas from the book.

This article is about how the principles in the book helped me design and code a complex feature.

A Shift in Thinking

There are books that give information or are used as references. But sometimes you read a book that changes the way you think.

Design Patterns Explained is one of those books for me. The book is for anyone who is looking to understand design patterns, not just catalog them, but actually understand why they exist, what problems they solve, how to recognise, implement, and refactor them.

It explained encapsulation through tons of examples, along with concepts like abstraction, polymorphism, and inheritance. More importantly, it showed how these ideas influence real design decisions: which classes should be abstracted and how classes should relate to and aggregate one another.

As engineers, we know features evolve. A “simple” requirement today can grow into something much bigger tomorrow.

I always tried to be ready for that. But I sometimes focused on the wrong kind of change. Things worked, they shipped — but updating them wasn’t always smooth. I knew I could improve how I approached design, but I couldn’t clearly explain what was missing.

I didn’t read Design Patterns Explained to solve this. I picked it up just to understand design patterns better.

But while reading, I started noticing the missing pieces in my own decisions.

And those realisations changed how I design software today.

This book didn’t teach me patterns. It changed how I think. And once that happened, patterns showed up naturally in my code.

Design Is Mostly About Change

One idea hit me early in the book:

Build for today. But keep the door open for tomorrow.

My usual flow was:

Understand the feature
Code it
Adjust later

It wasn’t wrong. It just wasn’t always ready for the right changes.

The Offline Dashcam is a device with a built-in wireless hotspot and an SD card slot. It is attached to a vehicle and records video to the SD card. We can connect to its Wi-Fi to view, download, and delete those recordings. I was working on adding support for this feature in our mobile application (built using Flutter 💙).

Each vendor has different firmware with different chipsets. This means:

Different API endpoints
Different request bodies & responses
Different capabilities

We need to keep our codebase open to adding new chipsets, while maintaining the capabilities of each one without disrupting user experience.

Principles Before Patterns

Encapsulate what varies.

Before reading the book, I would often think in terms of features. The book pushed me to think in terms of change. Instead of asking "What does this feature do?", I started asking "What part of this feature is likely to change independently?"

I created a list of things that were likely to vary:

The chipset initialisation process is different for each chipset.
The API endpoints and response protocols are different.
Capabilities of each chipset are different. (E.g. audio support)

What stayed the same was more interesting:

Start Recording
Stop Recording
Delete File
Get Device Info
Get Recordings
Take Snapshot

No matter which chipset the user connected to, the app still needed to perform the same operations.

That led me to a simple question:

What if the rest of the application only knew about these operations and never about the chipset itself?

I introduced a common repository contract:

abstract class OfflineDashcamRepository {
  Future<void> startRecording();
  Future<void> stopRecording();
  Future<DashcamMedia> getDeviceData();
  Future<DashcamDeviceInfo> getDeviceAttributes();
}

Each chipset implemented the same contract in its own way, allowing the rest of the application to remain unaware of vendor-specific details.

This confirmed that each chipset should have its own repository and API layer. The rest of the layers should not be aware of these differences. The initialisation process also varied by chipset. To keep that complexity from spreading through the application, I introduced a factory that selects the correct repository implementation during onboarding. From that point onward, the rest of the application works through a common abstraction.
I explored different approaches, applied the "encapsulate what varies" principle to each of them, and chose the design that best matched the kinds of change I expected.

Before, chipset differences leaked into business logic:

if (chipset == Chipset.gk7201) {
  final response = await gkApi.getDeviceAttributes();
  ...
} else if (chipset == Chipset.hisilicon) {
  final response = await hisiApi.getDeviceAttributes();
  ...
}

Every new chipset meant more conditionals scattered throughout the codebase.

Instead, the chipset is detected once during onboarding:

final chipset = await chipsetDetector.detectChipsetType();

final repository =
    dashcamRepositoryFactory.create(chipset);

From that point onward, the rest of the application talks only to the repository abstraction:

final deviceInfo =
    await repository.getDeviceAttributes();

The use cases, Blocs, and UI never need to know which chipset is connected.

How This Changed My Architecture Decisions

Chipset differences do not spread through the codebase.

They live in one place.

               OfflineDashcamRepository
                           ▲
                           │
        ┌──────────────────┴──────────────────┐
        │                                     │
Gk7201DashcamRepositoryImpl   HisiliconDashcamRepositoryImpl
        │                                     │
        ▼                                     ▼
 Gk7201 API Service               Hisilicon API Service


        OfflineDashcamRepository

                │
                ▼

             Use Case
                │
                ▼

               BLoC
                │
                ▼

                UI

The chipset-specific logic exists only in the API and repository layers.

Everything above the repository layer depends on abstractions. Adding a new chipset means creating a new implementation, not rewriting the UI, BLoCs, or use cases.

At runtime, the correct implementation is selected.

The rest of the system doesn’t need to know which chipset it is talking to.

A Practical Insight I Took Away

When I stopped thinking “which pattern should I use?”

and instead started asking:

What here is stable, and what is likely to change?

In this case, chipsets changed. The operations the app needed to perform did not.
Now I look for variability by asking questions. I interrogate new code: Does this depend on specific hardware? Will another vendor break this? Can the UI team change a colour without me refactoring the API layer? If the answer is yes, that piece gets its own box. Its own boundary. Its own file where it can change without asking permission.

Keeping Things Cohesive

Earlier, I sometimes built giant “god” BLoCs or Services that handled everything.

But now, I have use cases, which delegate to services, factories, repositories, etc., as needed.

Now:

UI layer handles UI stuff
Storage handles storage stuff
Hardware/API code stays near hardware/API code

No giant boss-component running the whole show.

If a new engineer joins later, they won’t have to decode one huge file to make a small change.

High cohesion → less stress.

A Real Change in Everyday Workflow

Earlier, if a new requirement came in — for example, “Also support taking snapshots while recording” — I would hesitate a bit.

Where should that logic go? Will it break recording flow? Will I end up refactoring too much?

Now, the path is clear:

A new feature → a new use case
Hardware behaviour → a new chipset implementation
API change → stays near the API service
UI behaviour → stays in its own layer

Refactoring and testing became more predictable because each piece has its own space.

When code has the right boundaries, future change stops feeling risky.

What Changed in Me (and What’s Next)

I didn’t expect this book to influence my day-to-day work.

But I caught myself designing with more clarity from the very next feature.

Now, I:

notice variability early
keep change local
choose simplicity by default
and think about the developer who joins after me

I’m still learning to balance all this, but my software is starting to feel more ready for whatever comes next.

If you’ve ever felt your code works but it doesn’t feel quite ready for the future, this book might help you spot the same gaps I did.

I picked up the book hoping to learn design patterns. I finished it thinking differently about change. The patterns were useful, but the mindset shift was what stayed with me.

I Don’t Know Machine Learning as Well as I Thought I Did

Nikki Goel — Sun, 24 May 2026 16:14:04 +0000

Human Learning ML — Devlog #1

Out of curiosity, I picked up ML and AI as the next tech stack I wanted to learn. After a month, I’m realising it’s probably going to take a year or more before I feel even minimally confident enough to put it on my resume.

A little background: I did Andrew Ng’s Machine Learning Specialisation in college around 5–6 years ago. I built a fraud detection project, an image classification project, and even wrote a research paper titled “YOLOv3 Remote Sensing SAR Ship Image Detection.” Then I got a job as a Mobile Engineer (with a bit of backend work too) and slowly got busy with life.

Back then, it mostly felt like choosing a good enough ML algorithm based on the dataset and desired outcome. I didn’t see much beyond that at the time. But with the rise of LLMs, I got curious again and started reading AI Engineering by Chip Huyen, along with random blogs, Andrej Karpathy videos, research papers, and other internet resources.

I realised I had a lot of misconceptions, knowledge gaps, and even more curiosity.

The rest of this blog is about those things.

One thing I started doing was drawing rough mental maps of how concepts connect together.

This was one of the first sketches I made while trying to understand what actually goes into a “foundation model.”

One of my early attempts at connecting together concepts like data, architectures, and foundation models.

Misconceptions:

Context: When someone says a foundation model needs context tokens to generate the next output token, I thought “context” only meant the input tokens we provide.

But that’s not true. That’s only the starting point. These input tokens are processed, additional context may be added via external tools like MCPs, and previously generated output tokens themselves also become context for the next token.
Stateless: When we send prompts to a foundation model like ChatGPT, the information is not stored inside the model itself, i.e., the model does not permanently learn from it. It processes the prompt, generates an output, and moves on. Basically, they are stateless.
Self-Supervision: The so-called pre-training process of a foundation model does not rely heavily on human labellers because the model learns through self-supervision using massive amounts of internet data.

Knowledge Gaps

Intuitions:
1. Derivatives: I forgot the intuition for derivatives. They represent the "rate of change at a particular point" in a function. The rate of change, i.e., the slope, can be steep or shallow. That represents the magnitude of the change. The sign tells whether the change is increasing or decreasing.
2. Dot Product: I have to look this up again.
3. Attention Mechanism: Why does the transformer use the dot product between query and key vectors to score attention between tokens?
4. Parameters and Model Size: I still struggle to intuitively understand why models with more parameters generally perform better. Since parameters are tied to the function the model learns, how does increasing parameter count improve learning capacity and reasoning ability?
  
  I even started drawing out tiny toy examples to rebuild intuition around parameters, functions, and what models are actually learning.
  
  Trying to rebuild intuition around parameters and functions.
ML Concepts: Understanding where they fit into the bigger picture of machine learning. I need to revisit them again.
1. Activation Functions
2. Feedforward
3. RAG (Retrieval-Augmented Generation)
4. Post-Training

Things That Started Making Sense

Things I was curious about and finally got answers to:

SSMs: A newer architecture focused on handling longer contexts more efficiently because transformer architectures (used in most modern LLMs) become expensive and memory-heavy with long contexts.
Hybrid Architectures: Models can mix layers and ideas from different architectures and mechanisms. For example, combining ideas from attention mechanisms and RNN-like architectures.
Dataset: Quality of training data matters more than just quantity.
Naming Convention: Model names often represent the number of parameters. In Llama3-70B, 70B refers to the number of parameters.

The more concepts started making sense, the more new questions started appearing.

Still Curious

What are companies actually using for chatbots, customer support, and AI assistants?

Are they building on top of existing foundation models through APIs, fine-tuning open-source models, or training things in-house?

And what does “in-house AI” actually mean inside startups or enterprises? What kind of work do those teams actually do day-to-day?
How does post-training work for base models?

Do companies train the model again on additional data, or is the process more nuanced than that?

I tried drawing the pipeline based on my current understanding, but I still feel like I’m missing a lot of details around what actually happens during post-training.

My current mental model of pre-training → supervised fine-tuning → reinforcement learning.
How does RAG actually work internally?

Since context windows are limited, how does the system retrieve only the relevant pieces of information from huge datasets?
When using tools like Claude or Cursor, is every chat prompt an API call happening in real time?

And how do they stream responses word-by-word? Is it done through WebSockets or something else?
Why are models like Claude so good at coding tasks?

Is it because of post-training on coding datasets, reinforcement learning, tool usage, or something else?

Are there papers or engineering blogs explaining this in detail?
What does running a model on lower precision like FP8 or BF16 actually mean?

How does reducing precision still preserve model quality while improving performance?

Conclusion

Starting ML again after 5–6 years has been humbling. Back then, I thought I had understood it — courses, projects, even a research paper. But coming back to it now made me realise how much I had forgotten, and how much deeper the field actually goes.

This time, I’m trying to understand what is actually happening underneath instead of just making the models work.

Tests are for Future Releases

Nikki Goel — Sun, 24 Aug 2025 08:00:12 +0000

I used to think of tests as just a final check to confirm whether a feature worked. That perspective shifted a few years ago when I had shipped a feature, and later a teammate made changes that unintentionally broke a small but important part of it. No one noticed during code reviews or QA, but a simple code comment I had left — reminding myself to manually test an edge case — caught the issue.

It made me realise that tests aren’t just about verifying today’s work; they’re about safeguarding tomorrow’s. Whether it’s me revisiting the code months later or someone else making changes, tests act as a safety net, ensuring the feature continues to work as intended.

So when I joined my current organisation, one of the first things I proposed to the mobile team, was introducing tests. We have four mobile applications: two internal and two consumer-facing apps. One consumer-facing app that I work on is hybrid (Flutter + native Android and iOS) and has a team of 7-10 people.
Being a startup, we’re always chasing the next release, sprint, or metric. This often means shifting people between features. Breaking your own code is one thing; breaking someone else’s is almost guaranteed in this environment.

Given our user base and the need for stability, tests made sense. Everyone agreed, so I started a POC.
I picked a small Flutter module with two screens and built an internal framework using flutter_test. For the POC, I wrote two unit tests and one integration test that covered 4–5 edge-case flows. This meant setting up mocks for APIs, local storage, and analytics, setting up flavors, dependency injection tweaks, and documentation.

Then I showed this to the mobile engineering team.

To set the company’s mindset (since tests are considered heavy resource investment), I wrote separate documentation on test coverage. I suggested starting with tests for highly bug-prone code. Later if time permitted, we could add tests for business-critical features. The goal wasn’t 100% coverage, it was achieving the stability and saving time on bug fixes in future iterations.

The team’s initial response was hesitant, but it highlighted the challenge of balancing resources and stability in a startup.

It was a little discouraging, but I continue to suggest tests whenever a production bug occurs.
I think in this fast-moving startup, tests should not be treated as a luxury, an afterthought. Even a handful of tests for critical use cases can save us when teammates switch, features evolve, or releases get rushed.

When AI Suddenly Took Center Stage

Nikki Goel — Tue, 12 Aug 2025 17:58:00 +0000

A sudden AI interest in my company has left me avoiding it as much as possible.

I’ve been using Copilot for 3 years now and have been very happy with it. When ChatGPT launched, I quickly created an account and it integrated smoothly into my workflow. I promoted both Copilot and ChatGPT for the engineering team at my workplace—at least the mobile team—but to no avail.

That’s when the AI push really began. Over the past 4 months, as AI trends have surged, all the employees were encouraged to try them.
It started with a trial subscription of Cursor, with a lot of noise about MCPs. The focus was on using Cursor for our development, trying out various prompts, reviewing the code, and if it looked good, moving it to production.
I won’t go into the company’s reason for pushing AI tools.

For context, I’m a mobile developer using Android Studio, emulator(s), Chrome/Arc, etc. Adding another IDE to this stack wasn’t something I was eager for, especially since Copilot was already doing the job.
Given the encouragement, we tried it for one sprint. The results were not good, at least for the mobile team. The pressure to get the Cursor to make the UI from Figma designs with code quality that was just about acceptable… that was a tough week.

First, we decided to test it on something fresh. We got the Figma Mac App, integrated it’s MCP server—it was way better than Figma web for some reason. After many trials, prompts expanded from 2–3 lines to a full page (about 100 lines), basically a small PRD + TRD (Product and Technical Requirements Document). This included the feature explanation, all the Classes or file names to be updated, API contract sample, localisation rules, event rules, code structure rules, and more.
The output we got was somewhat intern-level work. It worked fine but needed a thorough review and significant refactoring. It did well at making model classes, repository functions and, small UI components (for Flutter). It fell short on UI code structure and state management.

All this was done in 1.5 days. Actual estimates were 3 days. So, a big win for the company, as it claimed to increase productivity by 50%. However, reviewing, fixing bugs and, refactoring took longer—so the total time was the same.

Encouraged by this partial win, we tried Cursor for an enhancement task in a released feature. This did not work at all. Writing detailed prompts took time; testing the result and rewriting the prompts took even more time and left the engineer frustrated, taking extra coffee breaks.

Since then, everyone has a different tool and workflow. Some are using Claude on the web, copy—pasting the code snippets on IDE. Others have embraced switching the IDEs between Cursor, Android Studio and web browser. I have been using the Copilot’s IDE extension, ChatGPT + web browser for regular web searches.
Lately we’ve also been trying out Copilot PR review. It seems odd: AI reviewing the code written by AI. It did give some good suggestions though. Let’s see how this works out.

I like the code completion in small chunks of code—easy to review, refactor, and test. Copilot works for me as I don’t have to switch to another code editor. For all other mundane tasks, ChatGPT works fine. In fact, switching from IDE to web browser for ChatGPT works well—it helps me focus on exactly what I’m looking for. For web searches, I still check Stack Overflow from time to time and read articles/blogs for learning, research, and debugging—focusing on human-written content.

I do want to try a local LLM, LM Studio as well.
I’m curious to see how these tools evolve, but for now, I’ll stick with what fits my workflow and leave the hype to others.

Navigating the Waters of Technical Curiosity: A Confession

Nikki Goel — Tue, 08 Aug 2023 17:55:11 +0000

Introduction

Hey there! I'm trying out something new today. This is not a tutorial blog but more of a personal development blog.

It has no conclusion or takeaway if that's what you're looking for. This blog serves as a confession for me trying to rationalize my new area of interest.

Embracing a New Horizon

In the past few months, I have become interested in various subjects other than mobile app development, my primary field of expertise.

These subjects span not just across tech stacks like backend and frontend but delve into the concepts such as understanding compilers, virtual machines, computer networking, databases internal working, etc.

A Deep Dive into the Unknown

It has been and continues to be a thrilling adventure for me. I've been reading about how compilers work, how programming languages are created, exploring the nuanced variations between them, how technologies like Firebase Cloud Firestore work, the physical path of the TCP/IP model, etc.

This has been a fascinating switch from learning how to use tech, be it a programming language, a framework, or a third-party service, to how is that technology created, its purpose, and the voids they endeavor to fill.

A Distracted Pursuit

I have not been able to concentrate on app development as a whole. Rather than swiftly implementing features or eradicating bugs, I often find myself entangled in the hows and whys of technology.

For example, while implementing a push notification feature in a mobile app, I side-tracked and started researching how does push notifications work, how was this invented in the first place, which protocols it uses, and more.

The Allure of Exploration

As I continue to explore this captivating realm, my learning resources have undergone a transformation.

From youtube videos and courses, I'm now moving to podcasts, white papers, research papers, books, GitHub feature proposals, and beyond.

This shift has also influenced my blog ideas, which are now more inclined towards delving into the "what" and "how" aspects rather than solely focusing on straightforward tutorials.

This transition is ironic, considering my very first blog embarked on a similar path.

I want to point out that this does not discredit the importance of the instructional content. I've certainly authored such blogs and and I continue to benefit from the insights of others. These resources remain integral to my daily routine.

A Dilemma Unveiled

This transition challenges me to realign my focus at work, finding an equilibrium between work and research.

The more I dwell on this, the more I become disinterested in my current work.

I may have gone down a few rabbit holes when I should've been focusing on finishing that feature.

The Joy of Curiosity

It's hard to say whether this is just a passing phase or a lasting change.

Perhaps trying out a challenging project could help me realign my focus.

One thing's for sure: I'm finding a lot of joy in exploring the uncharted waters of my newfound curiosity.

Custom Serializer with built_value in Dart and Flutter

Nikki Goel — Tue, 21 Feb 2023 10:31:13 +0000

The package, built_value is used for creating immutable classes in Dart with JSON serialization. It's a great package and uses build_runner to create generated files to avoid boilerplate code.

But if you've ever tried to deserialize a model class with a collection generic type like BuiltList, it'll drive you mad!

So, here is our goal. We're going to customize build_value's serializer such that it can deserialize properties like BuiltList<T> get data.

Overview

Application
Setting up Models
What's the problem?
Finally, a solution!
- 1. Adding specifiedType
- 2. Adding addBuilderFactory
This solution works. Why?
Simplifying the solution
Going one step further
Conclusion
Final Note

Here's the GitHub repo with all the code.

Application

The inspiration for this is a straightforward use case:

Creating a generic pagination model with the BuiltList<T> get data property.

So all paginated APIs can use this one model with a different data type for the data field. Rest of the fields like current_page, next_page, etc. are common for all paginated APIs.

Setting up Models

Create a file called generic_model.dart. Using the snippets bvtgsf from the built_value_snippets package in VS Code (or any other IDE), we get the following class.

I've made some changes to it as required.

/// Add the import for the serializer
import 'serializers.dart';

part 'generic_model.g.dart';

abstract class GenericModel<T>
    implements Built<GenericModel<T>, GenericModelBuilder<T>> {
  GenericModel._();
  factory GenericModel([void Function(GenericModelBuilder<T>) updates]) =
      _$GenericModel<T>;

  Map<String, dynamic> toJson() {
    /// Add the typecast [Map<String, dynamic>] to fix the error
    return serializers.serializeWith(GenericModel.serializer, this)
        as Map<String, dynamic>;
  }

  /// Add [<T>] to deserialize generic type values
  static GenericModel<T> fromJson<T>(Map<String, dynamic> json) {
    /// Add the typecast [GenericModel<T>] to fix the error
    return serializers.deserializeWith(GenericModel.serializer, json)
        as GenericModel<T>;
  }

  static Serializer<GenericModel> get serializer => _$genericModelSerializer;

  BuiltList<T> get data;
}

Let's complete the serializer class setup.

part 'serializers.g.dart';

@SerializersFor([
  GenericModel,
])
final Serializers serializers =
    (_$serializers.toBuilder()..addPlugin(StandardJsonPlugin())).build();

And last, let's generate the code by using the following command.

dart run build_runner build or

flutter pub run build_runner build if you have a Flutter project.

If you get any errors with this command, try it with the following parameters:

dart run build_runner build --delete-conflicting-outputs

And we're done with the initial setup.

What's the problem?

Now we'll test the serialization and deserialization with the generic type String. We'll create the class with a list of strings and try to serialize it.

void main() {
  /// Testing serialization generic type [String]
  final testModel = GenericModel<String>(
    (b) => b
      ..data = ListBuilder<String>(
        ['string 1', 'string 2'],
      ),
  );

  print('model: $testModel');
  print('serialized json: ${testModel.toJson()}');
}

Output:

model: GenericModel {
  data=[string 1, string 2],
}
serialized json: {data: [{$: String, : string 1}, {$: String, : string 2}]}

So this looks good. It worked.

But wait, we have to test deserialization as well. This won't work but don't go on my word. I'll show you.

void main() {
  /// Testing serialization with generic type [String]
  final testModel = GenericModel<String>(
    (b) => b
      ..data = ListBuilder<String>(
        ['string 1', 'string 2'],
      ),
  );

  print('model: $testModel');
  print('serialized json: ${testModel.toJson()}');

  /// Testing deserialization with generic type [String]
  final dummyJson = {
    'data': ['string 1', 'string 2'],
  };
  try {
    final testString = GenericModel.fromJson<String>(dummyJson);

    print(testString);
    print(testString.toJson());
  } catch (e) {
    print("Looks like it didn't work 🙃");
    print(e);
  }
}

Output:

model: GenericModel {
  data=[string 1, string 2],
}
serialized json: {data: [{$: String, : string 1}, {$: String, : string 2}]}
Looks like it didn't work 🙃
Deserializing '[data, [string 1, string 2]]' to 'GenericModel' failed due to: Deserializing '[string 1, string 2]' to 'BuiltList<Object>' failed due to: Bad state: No serializer for 'Object'.

The deserialization doesn't work. It's because built_value cannot detect the data type of the object to be created.

Hence we have to tell it explicitly.

Finally, a solution!

There are two things we need to add to fix this.

First, the specifiedType and second, the addBuilderFactory.

1. Adding `specifiedType`

In GenericModel class, we will explicitly tell the serializer to deserialize the T type.

abstract class GenericModel<T>
    implements Built<GenericModel<T>, GenericModelBuilder<T>> {
  GenericModel._();
 ...

  static GenericModel<T> fromJson<T>(Map<String, dynamic> json) {
/// <-------- Added here
    return serializers.deserialize(
      json,
      specifiedType: FullType(GenericModel, [FullType(T)]),
    ) as GenericModel<T>;
/// <-------- Added here
  }

  static Serializer<GenericModel> get serializer => _$genericModelSerializer;

  BuiltList<T> get data;
}

Before moving to step 2, let's run the code.

model: GenericModel {
  data=[string 1, string 2],
}
serialized json: {data: [{$: String, : string 1}, {$: String, : string 2}]}

Looks like it didn't work 🙃
Deserializing '[data, [string 1, string 2]]' to 'GenericModel<String>' failed due to: Bad state: No builder factory for GenericModel<String>. Fix by adding one, see SerializersBuilder.addBuilderFactory.

Progress, we have a different error now.

The error mentions addBuilderFactory, the same thing that we need for step 2.

1. Adding `addBuilderFactory`

This will be added to the serializer.dart class.

@SerializersFor([
  GenericModel,
])
final Serializers serializers = (_$serializers.toBuilder()
      ..addPlugin(StandardJsonPlugin())
/// <-------- Added here
      ..addBuilderFactory(
        const FullType(GenericModel, [FullType(String)]),
        () => GenericModelBuilder<String>(),
      )
      ..addBuilderFactory(
        const FullType(BuiltList, [FullType(String)]),
        () => ListBuilder<String>(),
      ))
/// <-------- Added here
    .build();

Now, if we run the code everything works. Yay! 🎉

model: GenericModel {
  data=[string 1, string 2],
}
serialized json: {data: [{$: String, : string 1}, {$: String, : string 2}]}
GenericModel {
  data=[string 1, string 2],
}
{data: [{$: String, : string 1}, {$: String, : string 2}]}

This solution works. Why?

built_value doesn't add a builder and specifiedType for generic values.

It is up to the developers how they want to define it.

In the test file of the built_value package, they have defined such a case here.

/// code snippet from the generics_serializer_test.dart file at line 38
group('GenericValue with known specifiedType and correct builder', () {
    var data = GenericValue<int>((b) => b..value = 1);
    var specifiedType = const FullType(GenericValue, [FullType(int)]);

   /// defining a different serializer
    var serializersWithBuilder = (serializers.toBuilder()
          ..addBuilderFactory(specifiedType, () => GenericValueBuilder<int>()))
        .build();
    var serialized = json.decode(json.encode([
      'value',
      1,
    ])) as Object;

    test('can be serialized', () {
      expect(
          serializersWithBuilder.serialize(data, specifiedType: specifiedType),
          serialized);
    });

    test('can be deserialized', () {   /// <--- using different serializer
      expect(
          serializersWithBuilder.deserialize(serialized,
              specifiedType: specifiedType),
          data);
    });

The deserialization is done using a custom serializer object which contains a new builder and a specified type.

If we were to use generic value with collections (like BuiltList) we need another builder. This is mentioned in this test.

/// code snippet from the generics_serializer_test.dart file at line 197
group('CollectionGenericValue with known specifiedType and correct builder',
      () {
    var data = CollectionGenericValue<int>((b) => b..values.add(1));
    var specifiedType = const FullType(CollectionGenericValue, [FullType(int)]);
    var serializersWithBuilder = (serializers.toBuilder()
          ..addBuilderFactory(
              specifiedType, () => CollectionGenericValueBuilder<int>())

          /// adding second builder for collection
          ..addBuilderFactory(const FullType(BuiltList, [FullType(int)]),
              () => ListBuilder<int>()))
        .build();
...

In addition to a custom serializer, we add another builderFactory for the BuiltList collection.

We can of course create as many customizations now as needed by adding specifiedType and builderFactory methods.

Refer the test file here for more examples.

Simplifying the solution

Is this the end?

It depends.

We have found the solution but imagine you have to use the GenericModel class with not just one but multiple object types. We could copy-paste the builder factory to the serializer.dart class, but that's a bad idea.

Let me show you why.

final Serializers serializers = (_$serializers.toBuilder()
      ..addPlugin(StandardJsonPlugin())

      /// for [String]
      ..addBuilderFactory(
        const FullType(GenericModel, [FullType(String)]),
        () => GenericModelBuilder<String>(),
      )
      ..addBuilderFactory(
        const FullType(BuiltList, [FullType(String)]),
        () => ListBuilder<String>(),
      )

      /// for [int]
      ..addBuilderFactory(
        const FullType(GenericModel, [FullType(int)]),
        () => GenericModelBuilder<int>(),
      )
      ..addBuilderFactory(
        const FullType(BuiltList, [FullType(int)]),
        () => ListBuilder<int>(),
      )

    /// and so on...

Manually adding and removing them can introduce various bugs. Plus we're lazy and don't want to remember updating this.

Hence, we do what we do best -> automate it.

Automate is just a buzz keyword here, we're just going to abstract adding builderfactory for GenericModel.

We'll add a new class to the serializers.dart file which adds the builder factories to serializer object.

@SerializersFor([
  GenericModel,
])

/// Making this private and mutable
Serializers _serializers =
    (_$_serializers.toBuilder()..addPlugin(StandardJsonPlugin())).build();

final serializers = _serializers;

/// Class to add new factories according to the type
class GenericBuilderFactory<T> {
  /// Keeping track of the builder factories added to the serializers for type T
  static final Map<Type, GenericBuilderFactory> _factories = {};

  /// returning serializer if the builder factory is already added
  static Serializers getSerializer<T>() {
    if (_factories.containsKey(T)) {
      return _serializers;
    }
    return GenericBuilderFactory<T>()._addFactory();
  }

  /// Adding the builder factory
  Serializers _addFactory() {
    _factories[T] = this;

    _serializers = (_serializers.toBuilder()
          ..addBuilderFactory(
            FullType(GenericModel, [FullType(T)]),
            () => GenericModelBuilder<T>(),
          )
          ..addBuilderFactory(
            FullType(BuiltList, [FullType(T)]),
            () => ListBuilder<T>(),
          ))
        .build();

    return _serializers;
  }
}

Next, we call this static method to access serializer object in our GenericModel class.

...
  static GenericModel<T> fromJson<T>(Map<String, dynamic> json) {
    return GenericBuilderFactory.getSerializer<T>().deserialize(
      json,
      specifiedType: FullType(GenericModel, [FullType(T)]),
    ) as GenericModel<T>;
  }
...

We made a lot of changes, let's make sure our old tests are still passing.

Run the same builder_runner command and run the project with the dart run command.

Output:

GenericModel {
  data=[string 1, string 2],
}
{data: [{$: String, : string 1}, {$: String, : string 2}]}

Phew! The old code is working.

Let's try adding a test case for int type to make sure it's working.

...
/// Testing deserialization with generic type [String]
  final dummyJson = {
    'data': ['string 1', 'string 2'],
  };
  try {
    final testString = GenericModel.fromJson<String>(dummyJson);

    print(testString);
    print(testString.toJson());
  } catch (e) {
    print("\nLooks like it didn't work 🙃");
    print(e);
  }

  /// Testing deserialization with generic type [int]
  final dummyJsonInt = {
    'data': [1, 2],
  };
  try {
    final testInt = GenericModel.fromJson<int>(dummyJsonInt);

    print(testInt);
    print(testInt.toJson());
  } catch (e) {
    print("\nLooks like it didn't work 🙃");
    print(e);
  }
...

Output:

model: GenericModel {
  data=[string 1, string 2],
}
serialized json: {data: [{$: String, : string 1}, {$: String, : string 2}]}
GenericModel {
  data=[string 1, string 2],
}
{data: [{$: String, : string 1}, {$: String, : string 2}]}
GenericModel {
  data=[1, 2],
}
{data: [{$: int, : 1}, {$: int, : 2}]}

It worked!

So now we don't need to add the builder factory manually in the serializer object. This one-time setup is all we need.

Going one step further

We've tested our GenericModel with int and String data types. Now let's try it with a user-defined type, a new model called MyModel.

We'll create a new model with two properties: name and id.

part 'my_model.g.dart';

abstract class MyModel<T> implements Built<MyModel<T>, MyModelBuilder<T>> {
  MyModel._();
  factory MyModel([void Function(MyModelBuilder<T>) updates]) = _$MyModel<T>;

  Map<String, dynamic> toJson() {
    return serializers.serializeWith(MyModel.serializer, this)
        as Map<String, dynamic>;
  }

  static MyModel fromJson(Map<String, dynamic> json) {
    return serializers.deserializeWith(MyModel.serializer, json) as MyModel;
  }

  static Serializer<MyModel> get serializer => _$myModelSerializer;

  String get name;

  String get id;
}

Adding this model in the serializer.dart file.

...
part 'serializers.g.dart';

@SerializersFor([
  GenericModel,
  MyModel, // <--- Adding new model here
])
...

Now, run the dart run build_runner build command. Now that the code is generated and the errors are gone, let's test our new model.

...
  /// Testing deserialization with generic type [MyModel]
  final dummyJsonMyModel = {
    'data': [
      {'name': 'name 1', 'id': 'id 1'},
      {'name': 'name 2', 'id': 'id 2'},
    ],
  };

  final testMyModel = GenericModel.fromJson<MyModel>(dummyJsonMyModel);

  print('deserialized model: $testMyModel');

  /// Testing serialization with generic type [MyModel]
  print('serialized json: ${testMyModel.toJson()}');
...

Output:

deserialized model: GenericModel {
  data=[MyModel {
    name=name 1,
    id=id 1,
  }, MyModel {
    name=name 2,
    id=id 2,
  }],
}
serialized json: {data: [{$: MyModel, name: name 1, id: id 1}, {$: MyModel, name: name 2, id: id 2}]}

It works. We've successfully created a custom deserializer for a collection generic type model in build_value.

We also abstracted the addition of the builder factory for each generic type.

Conclusion

We have to create a custom serializer to deserialize the collection of generic data-type objects.
specifiedType and buildFactory methods have to be added for all the generic types.
The solution can be simplified by adding the above dependencies in the code instead of doing it manually.

Final Note

Thank you for reading this article. If you enjoyed it, consider sharing it with other people.

If you find any mistakes, please let me know.

Feel free to share your opinions below.

State Persistence Techniques for the Flutter Bottom Navigation Bar

Nikki Goel — Tue, 05 Apr 2022 07:35:35 +0000

Building a bottom navigation bar is simple in Flutter given the BottomNavigationBar Widget. However, we want to add features to the standard Widget.

Overview

Setup
- What do we want to achieve?
- Implementation
- Demo
- Result
1. Stack and OffStage
- Implementation
- Demo
- Result
- Alternative - Indexed Stack
2. AutomaticKeepAliveClientMixin
- Implementation
- Demo
- Result
Conclusion
Final Note

We'll set up a basic flutter app with bottom navigation and look at the problems we face. Like not initializing the bottom navigation bar pages every time we switch tabs or preserving the state of bottom tab pages.

Then we'll try a couple of approaches for resolving them. We'll compare the results and we can decide which one to go forward with.

Here's the GitHub repo with all the code.

Setup

We're going to start with the basic app containing bottom navigation with two tabs.

Tab 1: Scrollable list of items.
Tab 2: Displaying the escaped seconds of a Timer.

What do we want to achieve?

Create the navigation bar page only when we open the page.
Preserve scroll position of navigation bar page in Tab 1.
Preserve the escaped time of Timer in Tab 2.

Implementation

Let's start with a new Flutter project.

Parent Widget: Bottom navigation bar

We have a simple Scaffold with BottomNavigationBar containing two Tabs.

class BasicBottomNavigation extends StatefulWidget {
  const BasicBottomNavigation({Key? key}) : super(key: key);

  @override
  State<BasicBottomNavigation> createState() => _BasicBottomNavigationState();
}

class _BasicBottomNavigationState extends State<BasicBottomNavigation> {
  int currentIndex = 0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: [         /// List of tab page widgets
        const _Tabbar1(),     
        const _Tabbar2(),
      ][currentIndex],
      bottomNavigationBar: BottomNavigationBar(
        currentIndex: currentIndex,
        onTap: (index) {
          setState(() {
            currentIndex = index;     /// Switching tabs
          });
        },
        items: const [
          BottomNavigationBarItem(icon: Text("1"), label: "Tab"),
          BottomNavigationBarItem(icon: Text("2"), label: "Tab"),
        ],
      ),
    );
  }
}

Tab 1: A scrollable list of items

We have a ListView displaying the index inside a ListTile.

class _Tabbar1 extends StatelessWidget {
  const _Tabbar1({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    print("Tabbar 1 build");

    return Scaffold(
      appBar: AppBar(title: const Text("Tab bar 1")),
      body: ListView.builder(
        itemBuilder: (context, index) {
          return ListTile(
            title: Text("${index + 1}"),
          );
        },
        itemCount: 50,
      ),
    );
  }
}

Tab 2: Displaying escaped seconds of a Timer

We are using a Ticker to run the Timer and update our escaped duration every second.

Fun Fact: Ticker is used in Flutter for callbacks during Animation frames.


class _Tabbar2 extends StatefulWidget {
  const _Tabbar2({Key? key}) : super(key: key);

  @override
  State<_Tabbar2> createState() => _Tabbar2State();
}

class _Tabbar2State extends State<_Tabbar2>
    with SingleTickerProviderStateMixin {
  late final Ticker _ticker;
  Duration _escapedDuration = Duration.zero;

  get escapedSeconds => _escapedDuration.inSeconds.toString();

  @override
  void initState() {
    super.initState();
    print("Tabbar 2 initState");

    _ticker = createTicker((elapsed) {
      if (elapsed.inSeconds - _escapedDuration.inSeconds == 1) {
        setState(() {
          _escapedDuration = elapsed;
        });
      }
    });

    _ticker.start();
  }

  @override
  void dispose() {
    _ticker.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text("Tab bar 2")),
      body: Center(
        child: Text(escapedSeconds),
      ),
    );
  }
}

Demo

Result

Tabs are initialized only when we click on them.
The scroll position is not preserved.
Escaped time of the Timer is not preserved.

Nothing was preserved. We create new tab pages every time we click on them. The scroll position is lost we switch back to Tab 1. The Timer starts from 0 whenever we open Tab 2.

There is no problem with this approach as long as we don't need to preserve any state.

But since we do, let's look at how we can achieve it.

1. Stack and OffStage

One way to persist the bottom navigation bar page is to use Stack Widget.
We'll add all the pages as children of Stack with the order of the bottom tabs and display one child at a time with respect to the currently selected bottom tab.

Implementation

We'll wrap the Tabbar widgets with OffStage and the children list with Stack.
The offstage parameter takes a boolean value. If it's true, then the child is hidden or offstage, otherwise, the child is visible.

There is no change in the Tabbar classes.

Parent Widget: Bottom navigation bar

 return Scaffold(
      body: Stack(       ///  Added Stack Widget
        children: [
          Offstage(          /// Wrap Tab with OffStage 
            offstage: currentIndex != 0,
            child: const _Tabbar1(),
          ),
          Offstage(
            offstage: currentIndex != 1,
            child: const _Tabbar2(),
          ),
        ],
      ),

Demo

Result

Tabs are not initialized only when we click on them.
The scroll position is preserved.
Escaped time of the Timer is preserved.

All the tabs are initialized with the parent Widget. Hence the timer in Tabbar 2 started before we even opened that Tab. The good thing is that it preserves the scroll position and escaped time.

If creating all the tabs at once does not affect the performance and is what we want, then we use this technique.

1. Alternative - Indexed Stack

Turns out there's a Widget (as always with Flutter 😇) called IndexedStack that we can use. It's less code with the same result.

Parent Widget: Bottom navigation bar

return Scaffold(
      body: IndexedStack(      /// Replaced with IndexedStack
        index: currentIndex,
        children: const [
          _Tabbar1(),
          _Tabbar2(),
        ],
      ),

2. AutomaticKeepAliveClientMixin

As the name suggests, this mixin makes the client (Tabbar child widgets) keep themselves alive (not disposed of) after we switch the tabs. It also creates the Tab only when it is first clicked and not with the Parent Widget like the above methods.

Implementation

AutomaticKeepAliveClientMixin needs a PageView in the parent widget. So we'll wrap the body with PageView and pass the list of tabs as its children.

Further Reading: Other than PageView, there's a TabBarView (for top app bar tabs), which also makes AutomaticKeepAliveClientMixin work for tabs (child widgets) because it uses PageView internally.

Parent Widget: Bottom navigation bar

class AliveMixinDemo extends StatefulWidget {
  const AliveMixinDemo({Key? key}) : super(key: key);

  @override
  State<AliveMixinDemo> createState() => _AliveMixinDemoState();
}

class _AliveMixinDemoState extends State<AliveMixinDemo> {
  final PageController controller = PageController();  /// initializing controller for PageView

  int currentIndex = 0;
  final tabPages = [
    const _Tabbar1(),
    const _Tabbar2(),
  ];

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: PageView(        /// Wrapping the tabs with PageView
        controller: controller,
        children: tabPages,
        onPageChanged: (index) {
          setState(() {
            currentIndex = index;     /// Switching bottom tabs
          });
        },
      ),
      bottomNavigationBar: BottomNavigationBar(
        currentIndex: currentIndex,
        onTap: (index) {
          controller.jumpToPage(index);    /// Switching the PageView tabs
          setState(() {
            currentIndex = index;
          });
        },
        items: const [
          BottomNavigationBarItem(icon: Text("1"), label: "Tab"),
          BottomNavigationBarItem(icon: Text("2"), label: "Tab"),
        ],
      ),
    );
  }
}

Tab 1: A scrollable list of items

We replacing to StatefulWidget here because AutomaticKeepAliveClientMixin only works with the State Class as defined in its implementation.

"A mixin with convenience methods for clients of AutomaticKeepAlive. Used with State subclasses."

We need only two additions after this.

First, call the super.build() inside the build method. Second, override the wantKeepAlive and return true.

class _Tabbar1 extends StatefulWidget {
  const _Tabbar1({Key? key}) : super(key: key);

  @override
  State<_Tabbar1> createState() => _Tabbar1State();
}

class _Tabbar1State extends State<_Tabbar1> 
    with AutomaticKeepAliveClientMixin {     /// Using the mixin
  @override
  Widget build(BuildContext context) {
    super.build(context);    /// Calling build method of mixin
    print("Tabbar 1 build");
    return Scaffold(
      appBar: AppBar(title: const Text("Tab bar 1")),
      body: ListView.builder(
        itemBuilder: (context, index) {
          return ListTile(
            title: Text("${index + 1}"),
          );
        },
        itemCount: 50,
      ),
    );
  }

  @override
  bool get wantKeepAlive => true;    /// Overriding the value to preserve the state
}

Tab 2: Displaying escaped seconds of a Timer

The changes are the same as with the Tabbar 1 class above.

class _Tabbar2State extends State<_Tabbar2>
    with SingleTickerProviderStateMixin, 
    AutomaticKeepAliveClientMixin {    /// Using the mixin
  late final Ticker _ticker;

  @override
  Widget build(BuildContext context) {
    super.build(context);     /// Calling build method of mixin
    return Scaffold(
      appBar: AppBar(title: const Text("Tab bar 2")),
      body: Center(
        child: Text(escapedSeconds),
      ),
    );
  }

  @override
  bool get wantKeepAlive => true;   /// Overriding the value to preserve the state
}

Demo

Result

Tabs are initialized only when we click on them.
The scroll position is preserved.
Escaped time of the Timer is preserved.

The Tabbar 2 is initialized only the first time when we click on it. The Timer preserves its state and so does the scrolling position in Tabbar 1.

If we want to programmatically change the keepAlive condition, then we can use the updateKeepAlive() method of AutomaticKeepAliveClientMixin. For further reading, refer to this StackOverflow answer.

Conclusion

We can choose any one approach from the above options according to our requirements.

Don't want to preserve any state -> standard BottomBarNavigation.
Want to preserve state but fine with creating all the tabs at once -> IndexedStack or Stack and OffStage.
Want to preserve state and build tabs only once when clicked on them -> AutomaticKeepAliveClientMixin.

IndexedStack is the simplest approach while AutomaticKeepAliveClientMixin covers our need. Since we usually have API calls in tabs and don't want to call them every time we switch to that tab.

Final Note

Thank you for reading this article. If you enjoyed it, consider sharing it with other people.

If you find any mistakes, please let me know.

Feel free to share your opinions below.

Improve Flutter Skills by Studying Production-Level Applications

Nikki Goel — Fri, 22 Oct 2021 07:11:23 +0000

There are many concepts to understand in mobile development. Among these are pagination in API requests, local storage, error reporting, debugging, testing, linting, and CI/CD.

Following is a list of some open-source Flutter projects that can be used to study and improve our skills. All of these projects offer some useful concepts we can learn from.

Goal

We can learn from other people's code to understand and implement better code ourselves. This is where open-source projects come in. Using open-source projects is one of the best ways to improve our skills.

I look up to them personally. The list could have been much longer, but here I listed a few to get you started.

Let's take a look.

1. Photobooth

This is a web app. Flutter Web was made available on the stable channel this year. So Photo Booth is a great example of flutter web apps.

Another thing to learn from this is the use of native plugins like cameras. There're also firebase packages like firebase authentication, firebase storage, etc.

The app shows how we can internationalize a flutter app, how to structure folders, and the use of bloc as state management.

To go one step ahead, there's also CI/CD to look at when working with the deployment part. This app has GitHub workflows for testing, analyzing lint rules, deploying the new app version, etc.

The main focus for me though is the tests folder. From mocking a library to test gestures, there are many test cases that we can learn from.

2. Debugging Testing Publishing Flutter App

This app is a part of a course. There are different branches for each topic.

As the name suggests, we can learn about error reporting, testing (unit, widget, and integration tests), and debugging.

3. Marvel

This is specifically for riverpod package.

This app shows how we can paginate API requests while scrolling, how to cancel a request, and cache the result.

4. Movie App State Management Flutter

This project is wonderful. It shows how we can structure our code with various state management packages.

In addition to pagination, there's local data persistence as well.

5. Riverpod Tutorials

This project is specifically for riverpod package.

This is a ToDo application. The project starts simple with basic functionality and then progresses with new features. There is a different folder for each concept.

This project first introduces various providers. Then it shows how we can use them to pass data in our UI. Next comes how to deal with asynchronous data with Riverpod. There's error handling and cache management as well.

6. Flutter Templates

These are the templates/examples from the Flutter team. From "hello world" to "flutter layer architecture" and "platform channel", there is a lot to cover.

This is great for getting started.

Additionally, there's another project with templates, new_flutter_template. This one is still in work in progress I believe. But there are a few samples to look at.

7. Gallery

This app shows a number of examples of different widgets.
Besides that, the source code itself is a great example of how to deal with different themes, including font size and locale.

In addition to learning how to build the UI, there are also tests, Github workflows, and linting to look at.

8. Starter Architecture Flutter Firebase

This project focuses on the architecture and folder structure of the source code.

There is a lot of thought given to building a big-scale app codebase.

For state management and backend it's using Riverpod and firebase respectively. The common functionalities signing up, using firebase storage, dealing with APIs and streams, etc are converted with tests.

The other thing I appreciate about this project is the use of linting. Although now with the latest Flutter version, linting comes by default when we create a new app.

Nonetheless, linting is always a good thing to implement in a project.

There are some features/widgets that we might use in more than one app like a fancy animating container. We can make this code reusable if we make a separate package for it and import it into the projects that require it.

The author of this project does this for many UI components (widgets) and certain services like firebase auth. Now whenever the author has to use Firebase authentication, he can simply import the package and save time.

From studying this project can learn how to create a customizable and independent feature or services into a package.

9. SpaceX Go

This project seems to have it all. It handles API requests, caching images, managing notifications, localization, navigation, slivers, etc.

The beauty of this codebase is the code reusability. The project has a well-defined structure and uses generic classes.

This project can also be used to learn how to create model classes. Other things to look out for are tests, linting, and Github workflows.

Overall, the code is beautifully written and the project is well structured.

10. Chicago

Ever wanted to make your own widgets from scratch? By scratch here, I mean the RenderObject itself.

There is rarely a need for someone to create your own render objects, but when the need arrives we can refer to this project to understand how to create them.

There're also tests written for these widgets.

11. Finished Flutter Firebase DDD Course

With application architecture patterns in mind, the Domain-Driven Design pattern is one of the patterns we should be familiar with. This project follows the DDD architecture pattern and has tutorial series with both articles and videos by the author.

Along with DDD, the author has another application and tutorial series for Clean Architecture + Test-Driven Development (TDD).

12. Sqlite

To learn how to interact and write with the native interface (C APIs) in the dart, also known as ffi, this project is a great example.

As a bonus, there are tests as well.

13. Flutter Tips and Tricks

This is not a flutter application but a repository with a collection of various flutter/dart code snippets.

Nonetheless, the collection is amazing and a great learning tool. There are various small tricks for optimization and such as well.

Final Note

Thank you for reading this article. If you enjoyed it, consider sharing it with other people.
If you find any mistakes, please let me know.
Feel free to share your opinions below.

Reasons to learn Computer Networking as a Software Engineer

Nikki Goel — Tue, 07 Sep 2021 12:09:58 +0000

Listed below are the reasons why you might consider studying Computer Networking. It doesn't matter what your specialization is.

These are my personal opinions and reasons why I find this subject fascinating even though I don't directly work on it.

Note: You don't have to be an expert in Computer Networks, just knowing the basics gives an edge.

There are in no particular order.

1. Clear up misconceptions

Since we don't work in the networking field directly, we make some assumptions about how things might work. In fact, even the most basic terms that we ourselves daily use can be wrong.

For a long time, I thought that the source port is the same as the destination port in a network packet header. All the concepts that depended on this misconception were also erroneously assumed.

Our misconceptions might even be unknown to us until someone challenges them. So challenge yourself and question everything. Be curious.

2. Unravel technical terms we encounter every day

There are certain terms that we often hear like routers, web servers, proxy, etc. If we invest time to understand these, it will help us gain a better understanding of the overall perspective.
We don't have to deep dive into them, but the concept behind them should be clear.

We're not just improving our vocabulary, but we're also understanding the meaning of the words as we use them in our conversations.

3. Visualize the "Big Picture": Information traveling around the world

An API request like the below one seems simple at first look.

fetch('http://example.com')

But if we start unfolding it, it might take hours to understand the whole path.

An oversimplification would be like this:

Tracking the layers of TCP/IP model -> routers -> remote server somewhere in the world -> back to us

Just connecting all these dots reveals the "Big Picture".

![how-internet-works-1.png](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2py04ni08kzd6ct0okre.png) Source: [Standford](https://web.stanford.edu/class/msande91si/www-spr04/readings/week1/InternetWhitepaper.htm)

Now every time we work on a problem, subconsciously we'll think about it from a Computer Networking perspective as well.

4. History as viewed through the lens of Networking

The more I research computer networking, the more interested I become in its history.

I started with "How the internet works" and now I'm mapping together how HTTP came into the picture, its evolution from HTTP/1 to HTTP/3.

The questions like "Why does this tech exist?" and "What problems did it solve?" unravel the dilemma of which tech to use in what situations.
And this knowledge comes with practice as well as from knowing its history.

I'm amazed how Computer Networking is evolving and yet it's using the same principles.

If any of these reasons convinced you to dive into computer networks, what were they? I'd love to hear any additional reasons that you might add to this list.

Final Note

Thank you for reading this article. If you enjoyed it, consider sharing it with other people.
If you find any mistakes, please let me know.
Feel free to share your opinions below.

Future in dart: When to use async, await, and then

Nikki Goel — Sat, 07 Aug 2021 05:45:35 +0000

There are multiple ways to implement asynchronous logic in dart. Dart provides three keywords for this: async, await, and then.

In this blog, we'll learn how and when to use them according to our needs.

Overview

What is asynchronous programming?
Asynchronous in dart
Using then
Using async-await
Code Samples
- Sample 1
- Sample 2
Conclusion
Final Note

What is asynchronous programming?

Asynchronous programming refers to a block of code that runs in parallel with other blocks of code. As a result, we can do several things at the same time.

Source: GIPHY

For example, say we have an API request that fetches a list of recipes. This network call might take some time. During this fetching, we have a text field where a user can type into.

Our application is interacting with the user as well as fetching recipes simultaneously.

Another way to think about this is, doing some background tasks separately without disrupting the main task flow.

Asynchronous in dart

Dart gives us two ways to implement asynchronous logic:

In this blog, we'll discuss Future.

Future class has various constructors that we can use. There are certain keywords that we need to implement when using them. The keywords are: async, await, and then.

Using `then`

then works on the concept of callbacks. The callback is exactly what it says it is. Calling back (executing) a block of code sometime later.

Let's say we are fetching a list of recipes. This returns a Future.

After the Future is completed (we've fetched the recipes), we want to display a message to the user.
During this fetching, we don't want to stick there but continue to execute our next block of code.

Let's look at the following code. For simplicity, we'll use print statements.

You can run the code sample below in dartpad. Just copy-paste the code in dartpad and run it.

Output:

start fetching recipes
a random computation
recipes fetched
after fetching recipes

Let's understand the code.

In line 4, we are fetching our recipes.

Here, we've used the Future.delayed constructor for demo purposes. Using this, we can specify the time we want to wait for (here we are waiting for 1 second).
Refer here, if you want to know more about this function.

In lines 6-8, we are giving a callback (a block of code) that is supposed to run when the recipes are fetched (or Future is completed).

The code after line 8 should not wait for the recipes to be fetched but continue to execute.

Analyzing the output:

The first console print statement is start fetching recipes as expected.
The second console print statement is a random computation. This is the desired result. The Future takes time to complete and the rest of the code (below line 8) does not wait for it to complete but executes.
After a while, recipes fetched and after fetching recipes executes which were the callbacks for the Future.

So, then fits here perfectly.

Now let's see another use case.

After the Future is completed (we've fetched the recipes), we want to display a message to the user.
We want to wait for the recipes to be fetched and not execute the lines below 8.

The easiest way would be to put all the code inside the then block.

Output:

start fetching recipes
recipes fetched
after fetching recipes
a random computation

We've just added everything under the then block. Now, the a random computation is executed after the recipes are fetched.

There's a better way to implement this use case.

Since we want to wait for the recipes to be fetched and not execute the code below, we could use simpler syntax.

And that's what async and await are. An alternative syntax to implement asynchronous logic.

Using `async-await`

Let's implement our second use case again.

Output:

start fetching recipes
recipes fetched
after fetching recipes
a random computation

This time, we've not used any callbacks explicitly like the then block. Instead, we've added async in line 1 and await in line 4.

async keyword tells dart that this function might use asynchronous logic. So void main has the async keyword.
await keyword tells dart that the following statement will return a Future. The Future should be completed and then the code below will be executed.

Let's look at some more examples.

Code Samples

As seen above, we can have multiple implementations for the same logic. Let's look at some code samples and try to simplify them.

Sample 1

void main() async {
  await Future.delayed(Duration(seconds: 1), () {
    print('inside delayed');
  }).then((_) {
    print('inside then');
  });

  print('after delayed');
}

The then block is redundant here. Since we're awaiting the Future, the then callback can be implemented like a normal code of block.

Simplified:

void main() async {
  await Future.delayed(Duration(seconds: 1), () {
    print('inside delayed');
  });

  print('inside then');

  print('after delayed');
}

Sample 2

void main() {
  Future.delayed(Duration(seconds: 1), () {
    print('inside delayed 1');
  }).then((_) {
    print('inside then 1');

    Future.delayed(Duration(seconds: 1), () {
      print('inside delayed 2');
    }).then((_) {
      print('inside then 2');
    });
  });

  print('after delayed');
}

There is a nesting of then blocks here. We can use async, await syntax inside a then block also.

Simplified:

void main() {
  Future.delayed(Duration(seconds: 1), () {
    print('inside delayed 1');
  }).then((_) async {
    print('inside then 1');

    await Future.delayed(Duration(seconds: 1), () {
      print('inside delayed 2');
    });

    print('inside then 2');
  });

  print('after delayed');
}

I hope the examples helped in understanding the various syntaxes.

And that's it for asynchronous programming in dart using Future.

Conclusion

We can use then syntax or async-await syntax or both to implement asynchronous logic.
Any syntax can be used to achieve our desired result. But we should also focus on code-readability.

For further reading, you can refer to dart official docs.

Final Note

Thank you for reading this article. If you enjoyed it, consider sharing it with other people.

If you find any mistakes, please let me know.

Feel free to share your opinions below.

8 Computer Networking Resources for All Levels

Nikki Goel — Tue, 06 Jul 2021 09:16:48 +0000

Where to study Computer Networking from?

Below is the list of Computer Networking resources that I use. These can be useful to everyone. No matter if you are a beginner, intermediate, or expert in the subject.

All of these are free except the last one.

These are in no particular order.

1. Hussein Nasser - YouTube

This YouTube channel covers a wide range of topics. Some of them are:

Databases
Computer Networking
General Software Engineering
Career Advice

There are playlists such as beginners, intermediate and advanced. This gives an idea of where to start. There are other playlists as well for specific topics. The author also has many videos where he discusses the architecture and outages of tech companies.

There are practical examples along with the theory part. For example, a video explaining Nginx has a section of "making our own proxy using Nginx". This is my favorite thing about the channel.

The coding part is very helpful. I really like the energy of this guy and the content is understandable. This channel is what got me interested in Computer Networking in the first place.

2. Eli the Computer Guy - YouTube

This channel has a variety of content, from web development to Computer Networking. Here we'll only focus on the Networking part.

In many videos, alongside theory, the author also tells about the hardware component used with it. For example, when explaining a router, the author shows various physical router devices.

This helps us to fill a lot of gaps in our knowledge. Like identifying all the network-related physical devices.

The videos might be a little old but are still valid as concepts never change.

This channel is for all levels as well. There is a playlist for Networking. It starts with basics and then progresses to advanced stuff.

3. PacketLife - Blogs

This blog covers various Networking topics. We can browse by category if we want to learn about a particular niche.

The writing style is such that the blogs are very easy to understand.
The blogs usually start with an introduction and then proceed with an example. The examples are very detailed. There are step-by-step explanations and it feels like we are performing the example with him.

This is one of my favorite blogs in PacketLife. As a beginner, this helped me to get a hold of the concepts.

4. Network - WikiUniversity

Wikipedia is one of the best resources out there. The Network WikiUniversity is a curated list of Computer Networking topics. It's structured like an online course.

Wikipedia gives everything there is to know about a topic.

There are definitions, examples, diagrams, advantages, disadvantages, timelines, and much more. This gives an overview of the subject and we can deep dive into any specific area that we like.

There are also references in the form of videos, RFCs, published technical papers, etc.

One of my favorite thing about Wikipedia is, it gives unopinionated information. For a specific topic, it not only gives the advantages but also disadvantages as well. This helps in understanding when and when not to use that specific technology.

5. Sunny Classroom - YouTube

This channel has amazing videos. Again there is a wide range of topics covered.

There are animated diagrams in the videos. This helps to visualize how data flows from one device to another. The roles of every entity like a router, ISP, switch, DNS, etc becomes crystal clear.

The videos are also clubbed together under various playlists so it's easy to navigate.

6. A Top-Down Approach Featuring the Internet - Book

This is one of the classic books out there for Computer Networking. The concepts are very well explained.

The fact that it's available as web pages on the internet for free is a bonus.

I have not read the whole book yet. I usually jump to the chapter that I want to read about, instead of the chronological order.

7. CertBros - YouTube

Another amazing YouTube channel.

This is structured more like a video course. This channel also covers various topics.

The videos have high production value. The sequence of videos in the playlist is ordered. That's a plus for beginners.

8. Grokking Computer Networking - Educative.io

This course is not free. Students with Student Github Pack can enroll in it for free.

This is a text-based course as opposed to a video-based. That being said, this is one of the best courses I have ever studied. The amount of knowledge it provides is seamless. Everything is connected and well put together.

It takes time to finish it and that's a good thing. It means we are getting the information we hoped for. This makes the course worth it. This introduced me to various aspects of Computer Networking.

It also has quizzes, a final assessment, and a forum for doubts.

I am yet to complete the whole course. At the time of writing this blog, I've gone through the first half.

Honorable Mentions

Below are the websites that often open up in the search engine results, whenever I search my Computer Networking doubts. They are mostly the lecture notes in the form of pdfs, slides, web pages, etc. These lecture notes are part of some university courses.

I often refer to them.

RFCs

Last but not least, there are the RFCs (Request for Comments) documents. They are like technical documents but specific to the internet. Some of them are really detailed and it takes time to read them, but the information it provides is amazing. The community is also very active.

This concludes all the resources. 🎉🎉

Advice

Computer Networking is a vast subject. One can feel overwhelmed during learning it. I definitely was overwhelmed when I first started it and I still do sometimes.

My advice would be to not dwell on the fact that there is too much to learn. We don't have to learn everything out there. Focusing only on one thing at a time helps.

I maintain a casual journal for tracking my weekly progress. If you feel too stressed out or overwhelmed, you can try this method. It may help you also.

Final Note

Thank you for reading this article. If you enjoyed it, consider sharing it with other people.

If you find any mistakes, please let me know.

Feel free to share your opinions below.

What is setState() in flutter and when to use it?

Nikki Goel — Sun, 20 Jun 2021 12:05:14 +0000

When working on frontend applications, a common use case is "Updating the screen's UI dynamically". setState is one of the ways to accomplish this in flutter.

Overview

Tech Terms
What is a State Object in flutter
- Fun Fact
Example code
When to use setState
Going one step ahead
Summary
Final Note

Tech Terms

These are some common terms used in flutter. The concepts apply to other frameworks also, although each framework has its own technical term for them.

Widget: Any UI component on the screen is called a Widget in flutter. A Widget can have its own Widgets, like a tree structure.
StatefulWidget: A Widget that can change dynamically. Generally used when we want to modify something on the screen's UI.

What is a State Object in flutter?

setState is called inside a State class. Let's understand this in detail.

State is simply the information of a StatefulWidget. Every StatefulWidget has a State Object. This State Object keeps a track of the variables and functions that we define inside a StatefulWidget.

State Object is actually managed by corresponding Element Object of the Widget, but for this blog, we will only focus on the Widget part. If you don't know what Element Object is, I'll encourage you to read about it. It's not required to know for this blog though.

class MyWidget extends StatefulWidget { // immutable Widget
  @override
  _MyWidgetState createState() => _MyWidgetState();
  // creating State Object of MyWidget
}

class _MyWidgetState extends State<MyWidget> { // State Object
  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

Since StatefulWidget itself is immutable (cannot be modified), we use State Object to modify the UI.

We tell this State Object to update our screen's UI using a function called setState().

Function Definition

void setState(VoidCallback fn) {
  ...
}

This setState() takes a function as it's parameter.

VoidCallback is just a fancy way of saying: void Function()

typedef VoidCallback = void Function();

Example

We'll create a simple counter app (I know it's very common but bear with me).

This will have a variable counter initialized with 0.
We will display this counter on the screen inside the Text Widget.
Next, we'll have a button that increases this counter's value by 1.
The UI should be updated with the new value of counter.

Let's see the steps written above one by one.

When the Widget is created, the value of the counter is 0

int counter = 0;

Displaying value of counter on screen

Widget build(BuildContext context){
  return 
       ...
       Text(`counter value: $counter`)
       ...
}

When we click on a button, we increment the value of the counter

onTap: () {

  // passing an anonymous function to setState
  // that increments counter's value by 1
  counter++;
},

Update the UI

onTap: () {

  // passing an anonymous function to setState
  // that increments counter's value by 1
  // and update the UI
  setState(() {
    counter++;
  });
},

#Fun Fact :

We can update our variables first and then call the setState() function, since setState just informs the underlying framework that

"update this Widget's UI in next frame" (marks it dirty).

The underlying framework will use the last value that is defined before calling the setState function.

This is the same as above

onTap: () {
  counter++;
  setState(() {});
},

Example Code

import 'package:flutter/material.dart';

class MyWidget extends StatefulWidget {   // widget class

  const MyWidget({Key? key}) : super(key: key);

  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {  // state class
  int counter = 0; // initializing counter

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        crossAxisAlignment: CrossAxisAlignment.stretch,
        children: [

          // displaing the counter
          Text(
            'counter value: $counter',
            textAlign: TextAlign.center,
          ),
          TextButton(
            onPressed: () {

              //incrementing counter
              setState(() {
                counter++;
              });
            },
            child: const Text('Tap here to increment counter'),
          )
        ],
      ),
    );
  }
}

When to use setState() ?

When we want to change the UI of the screen.

We don't need to call setState every time we change a variable. We call setState only when we want the change in a variable to reflect on the UI of the screen.

For instance, say you have a form containing a text field and a button to submit it.

import 'package:flutter/material.dart';

class MyForm extends StatefulWidget {
  const MyForm({Key? key}) : super(key: key);

  @override
  _MyFormState createState() => _MyFormState();
}

class _MyFormState extends State<MyForm> {
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [

        // text field
        Form(
          child: TextFormField(),
        ),

        // submit button
        OutlinedButton(
          onPressed: () {},
          child: const Text('Submit'),
        ),
      ],
    );
  }
}

User types in the text field and clicks on submit button. Then we display that text field's text below the submit button.

import 'package:flutter/material.dart';

class MyForm extends StatefulWidget {
  const MyForm({Key? key}) : super(key: key);

  @override
  _MyFormState createState() => _MyFormState();
}

class _MyFormState extends State<MyForm> {
  // we'll use this to save the text user types
  String userText = "";

  // this will keep track of submit button's tapped action/event
  // and display the userText below submit button
  bool hasSubmitted = false;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Form(
          child: TextFormField(

            // triggered when we save the form
            onSaved: (value) {
              // store the text-field's value into
              // the userText variable
            },
          ),
        ),
        OutlinedButton(

          // this is triggered whenever we click on button  
          onPressed: () {
            // validate and save the form
            // display the text below the button
          },
          child: const Text('Submit'),
        ),

        // this will display the userText only
        // if user has clicked on submit button
        if (hasSubmitted) Text(userText)
      ],
    );
  }
}

Steps:

User types in the text-field
User clicks submit button
onPressed function of submit button is triggered
Inside onPressed function:
1. Validate and save the form
2. This will trigger the onSaved function in the TextFormField
3. Inside onSaved function:
  1. Store the text field's value in the userText variable
4. Update hasSubmitted variable with true

Implementation:

import 'package:flutter/material.dart';

class MyForm extends StatefulWidget {
  const MyForm({Key? key}) : super(key: key);

  @override
  _MyFormState createState() => _MyFormState();
}

class _MyFormState extends State<MyForm> {
  String userText = "";

  bool hasSubmitted = false;

  // for getting access to form
  final _formKey = GlobalKey<FormState>();

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Form(
          // attaching key to form
          key: _formKey,
          child: TextFormField(
            onSaved: (value) {
              /// updating userText variable
              if (value != null) userText = value;
            },
          ),
        ),
        OutlinedButton(
          onPressed: () {
            // validating form
            if (!_formKey.currentState!.validate()) {
              return;
            }

            // saving form
            _formKey.currentState!.save();

            // updating hasSubmitted
            hasSubmitted = true;
          },
          child: const Text('Submit'),
        ),
        if (hasSubmitted) Text(userText)
      ],
    );
  }
}

There's one small step left.
When you run this program, you'll notice that nothing happens when we click on submit button.

Here setState comes to the rescue!

Now the question is where should we call it?

There are two places in the program where we are updating variables.

inside onSaved function
insided onPressed function

So either one of these or both places should be the answer.

Let's ask one question to ourselves.

"On which variable update, do I want to update the UI of the screen?"

Is it userText inside onSaved function

or

hasSubmitted inside onPressed function?

You got it right!

It's inside the onPressed function after the hasSubmitted variable has been updated.

...
onPressed: () {
  // validating form
  if (!_formKey.currentState!.validate()) {
    return;
  }

  // saving form
  _formKey.currentState!.save();

  // updating hasSubmitted
  hasSubmitted = true;

  setState(() {});
},
...

Again, this is same as below:

onPressed: () {
  // validating form
  if (!_formKey.currentState!.validate()) {
    return;
  }

  // saving form
  _formKey.currentState!.save();

  setState(() {
    // updating hasSubmitted
    hasSubmitted = true;
  });
},

Why use setState here?

In our logic, we used hasSubmitted variable as a condition to show the userText. So only after updating hasSubmitted value, does the UI show our desired result.

Going one step ahead :

What happens when you use the setState inside the onSaved function only?

...
onSaved: (value) {
      /// updating userText variable
      if (value != null) userText = value;
      setState(() {});
    },
  ),
),
OutlinedButton(
  onPressed: () {
// validating form
    if (!_formKey.currentState!.validate()) {
      return;
    }

// saving form
    _formKey.currentState!.save();

// updating hasSubmitted
    hasSubmitted = true;
  },
...

It works here also. Surprise!!

But why? This goes against everything we've read so far in this blog.

So here's what happens.

When we call setState, the Widget inside we called it is marked as dirty.

Now whenever the framework actually rebuilds the UI of the screen, it will take into account all the latest values of the respective variables and paint the pixels on the screen.

This happens 60 times per second usually, which is the frame per second (fps) rate of flutter. That means approximately every 16ms (1000/60 ms).

If there is any other change until the next frame renders, those changes will also be reflected on the screen's UI.

The change in hasSubmitted variable falls under such case.

How do we verify it?

Let's add print statements and see exactly when does the UI actually rebuild.

import 'package:flutter/material.dart';

class MyForm extends StatefulWidget {
  const MyForm({Key? key}) : super(key: key);

  @override
  _MyFormState createState() => _MyFormState();
}

class _MyFormState extends State<MyForm> {
  String userText = "";

  bool hasSubmitted = false;

  // for getting access to form
  final _formKey = GlobalKey<FormState>();

  @override
  Widget build(BuildContext context) {
    print('Widget build called');

    return Column(
      children: [
        Form(
          // attaching key to form
          key: _formKey,
          child: TextFormField(
            onSaved: (value) {
              print('inside save');

              if (value != null) userText = value;

              print('hasSubmitted value before setState: $hasSubmitted');

              setState(() {});

              print('hasSubmitted value after setState: $hasSubmitted');
            },
          ),
        ),
        OutlinedButton(
          onPressed: () async {
            print('button clicked: ->');

            // validating form
            if (!_formKey.currentState!.validate()) {
              return;
            }

            print('before calling save');

            // saving form
            _formKey.currentState!.save();

            print('after calling save');

            print('hasSubmitted value after calling save: $hasSubmitted');

            // updating hasSubmitted
            hasSubmitted = true;

            print(
                'hasSubmitted value after updating hasSubmitted: $hasSubmitted');
          },
          child: const Text('Submit'),
        ),
        if (hasSubmitted) Text(userText)
      ],
    );
  }
}

With these print statements, we can see the order in which the flutter framework updates the UI.

Let's write something in the text field and click on submit button.

Inside console:

Widget build called
button clicked: ->
before calling save
inside save
hasSubmitted value before setState: false
hasSubmitted value after setState: false
after calling save
hasSubmitted value after calling save: false
hasSubmitted value after updating hasSubmitted: true
Widget build called

Clearly, the Widget is built after the hasSubmitted is set to true.

So the major question is: "Why can't we use setState inside onSaved function instead of inside onPressed function, it seems to work fine."

Because this method doesn't work for all the use cases. And it is also logically wrong.
When you'll come back to refactor the code (like for adding a new feature), things might not work as expected. Debugging the code will also be difficult since the problem is in the old code.

Let's see an example of such a use case.

Okay, we're almost done. This is the most important part. We've been building up to this point since the starting of this blog.

Let's go back to the steps of this example and add one more thing to it.

After saving the form, say we want to make an API call to send the data that the user typed to a server. For simplicity, let's say we're going to do some computation with the userText data which will take a minimum of 20ms (this can be any duration of your choice).

This is a practical example. Usually, we do communicate with our application's backend server.

Does our desired result still happen?

onPressed: () async {
  print('button clicked: ->');

  // validating form
  if (!_formKey.currentState!.validate()) {
    return;
  }

  print('before calling save');

  // saving form
  _formKey.currentState!.save();

  print('after calling save');

  print('hasSubmitted value after calling save: $hasSubmitted');

  /// some computation that takes 20ms
  await Future.delayed(const Duration(milliseconds: 20), () {});

  // updating hasSubmitted after 20ms
  hasSubmitted = true;

  print(
      'hasSubmitted value after updating hasSubmitted: $hasSubmitted');
},

See inside onPressed function. We're awating a Future and then updating the hasSubmitted value.

If you don't know what await, async and Future means, then just think that we're basically saying to program, "Hey flutter framework, we're gonna do some task that'll probably take some time. Please do it in the next iteration."
I'll encourage you to read about asynchronous programming. This concept is not exclusive to dart.

#Note: We can also use a Timer to get the same effect, but here we'll use Future.

Inside console:

Widget build called
button clicked: ->
before calling save
inside save
hasSubmitted value before setState: false
hasSubmitted value after setState: false
after calling save
hasSubmitted value after calling save: false
Widget build called
hasSubmitted value after updating hasSubmitted: true

Now, we don't see the UI updates on the screen. And according to our print statements order, hasSubmitted variable is updated after the Widget has been rebuilt.

Reason?

Warning: This includes some advanced topics. I'll try to explain it as simply as possible.

There is a queue of microtasks. One by one all the tasks are performed by dart. When we use await, we tell dart to first complete the current task (waiting for 20 ms), then move on to the next one in the queue.

So although some tasks (like rendering of the screen and waiting for 20 ms) are being performed concurrently, the tasks below the await keyword (updating hasSubmitted variable) will not be performed till the current task is completed.

So, when the framework actually rendered the dirty Widget(MyForm), hasSubmitted variable's value was not updated. Hence we don't see our typed text below the submit button.

Something to search about:

There is also an event queue. When we don't wait for the Future to complete but want to continue on to the next microtask, the task in Future is added to event queue.

Want to experiment more?

Try changing the duration to 0 seconds.

The UI still doesn't update as desired.

If you wanna dig deep into why after encountering the await keyword, does the code below it doesn't run synchronously even if the duration is 0 seconds, then read about the event loop in dart. There are other resources also that you can easily find on the internet. This concept is not exclusive to dart.

With this new use case (using a Future), our desired output is not achieved. Below is the short summary.

   /// Approach 1: this is good (recommended)
   setState((){
     hasSubmitted = true;
   });

   ...

   /// Approach 2: this is also good
   hasSubmitted = true;
   setState((){});

   ...

   /// Approach 3: this is not good
   setState((){});
   hasSubmitted = true;

What happens when we use setState inside both the functions?

This case is dangerous.

Since our desired result is achieved, we overlook the one extra call to setState inside the onSaved function.

I hope now you got an idea of when and when not to use setState.

Since this was a very simple example with only two variables to think of, it's easy to implement our logic into code.

When the program becomes bigger and complicated, keeping track of updating the variables and UI becomes cumbersome.

Then we use a mix of StatefulWidget's setState and/or some other state management solution.

I'll encourage you to read flutter official docs and build apps to get a grip on this.

Summary

setState is a way to dynamically change the UI.
We call it inside the State Object class of the StatefulWidget.
Calling setState marks the corresponding Widget dirty. When flutter builds the next frame (approx. every 16ms), it renders the Widget according to the latest values of the State Object.
Where we call setState matters a lot.
There are other state management solutions also.

Final Note

Thank you for reading this article. If you enjoyed it, consider sharing it with other people.

If you find any mistakes, please let me know.

Feel free to share your opinions below.

DEV Community: Nikki Goel

How “Design Patterns Explained” Changed the Way I Design Software

A Shift in Thinking

Design Is Mostly About Change

Principles Before Patterns

How This Changed My Architecture Decisions

A Practical Insight I Took Away

Keeping Things Cohesive

A Real Change in Everyday Workflow

What Changed in Me (and What’s Next)

I Don’t Know Machine Learning as Well as I Thought I Did

Misconceptions:

Knowledge Gaps

Things That Started Making Sense

Still Curious

Conclusion

Tests are for Future Releases

When AI Suddenly Took Center Stage

Navigating the Waters of Technical Curiosity: A Confession

Introduction

Embracing a New Horizon

A Deep Dive into the Unknown

A Distracted Pursuit

The Allure of Exploration

A Dilemma Unveiled

The Joy of Curiosity

Custom Serializer with built_value in Dart and Flutter

Overview

Application

Setting up Models

What's the problem?

Finally, a solution!

1. Adding specifiedType

1. Adding addBuilderFactory

This solution works. Why?

Simplifying the solution

Going one step further

Conclusion

Final Note

State Persistence Techniques for the Flutter Bottom Navigation Bar

Overview

Setup

What do we want to achieve?

Implementation

Parent Widget: Bottom navigation bar

Tab 1: A scrollable list of items

Tab 2: Displaying escaped seconds of a Timer

Demo

Result

1. Stack and OffStage

Implementation

Parent Widget: Bottom navigation bar

Demo

Result

1. Alternative - Indexed Stack

Parent Widget: Bottom navigation bar

2. AutomaticKeepAliveClientMixin

Implementation

Parent Widget: Bottom navigation bar

Tab 1: A scrollable list of items

Tab 2: Displaying escaped seconds of a Timer

Demo

Result

Conclusion

Final Note

Improve Flutter Skills by Studying Production-Level Applications

Goal

1. Photobooth

2. Debugging Testing Publishing Flutter App

3. Marvel

4. Movie App State Management Flutter

5. Riverpod Tutorials

6. Flutter Templates

7. Gallery

8. Starter Architecture Flutter Firebase

9. SpaceX Go

10. Chicago

11. Finished Flutter Firebase DDD Course

12. Sqlite

13. Flutter Tips and Tricks

1. Adding `specifiedType`

1. Adding `addBuilderFactory`

Using `then`

Using `async-await`