DEV Community: Surhid Amatya

Implementing Object-Oriented Programming (OOP) in Flutter and Dart

Surhid Amatya — Fri, 30 Jan 2026 07:34:14 +0000

If you are in Programming field and have done programming then in your travel you must have googled OOP and it's implemnetaiton in your respective language, right? Found one example in counter, other in login and similar other in other different ways. While exploring these examples did you ever felt disconnected and thought if only it answered a single query I had in my mind.

I had that thought if only it took a single thing and connected using different OOP principle. In this blog I am trying to solve same query of mine. While saying this to understand this blog you must have Basic understanding of OOP concepts (classes, inheritance, interfaces, and polymorphism) and familiarity with running Flutter apps.

When you build Flutter apps, you are already using OOP whether you realize it or not. Widgets are classes. State is an object. Your app is a forest of interacting objects quietly doing their jobs.

OOP is not about writing more classes. It is about modeling your app in a way that matches how the problem behaves in the real world. When done well, the code reads like a story instead of a puzzle.

Object Oriented Programming is built on four core pillars:

Inheritance
Encapsulation
Polymorphism
Abstraction

Today, we will break each one down and show how they show up naturally in Flutter and Dart code.

When people hear “OOP”, they think of service layers and interfaces. Flutter quietly teaches OOP every day through widgets and state.

Let's put on our "OOP Glasses" and look at the code you write every day.

Inheritance: Inheritance lets one class acquire the properties and methods of another class.

Every time you make an StatelessWidget:

class MyButton extends StatelessWidget {
  // ...
}

You are using Inheritance. What Happens When You Ctrl + Click StatelessWidget

If you Ctrl (or Cmd) + click on StatelessWidget, you don’t see magic. You see code.

Simplified, it looks like this:

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

  @protected
  Widget build(BuildContext context);

  @override
  StatelessElement createElement() => StatelessElement(this);
}

Already, several things are happening. What Your Widget Inherits Automatically. When you extend StatelessWidget, Flutter asks you for exactly one thing:

Widget build(BuildContext context);

That’s it. Now flutter handles:

layout
constraints
repainting
diffing
scheduling
performance

You will only describe what the UI should look like.

Encapsulation: The definition of encapsulation is "the action of enclosing something in or as if in a capsule". Removing access to parts of your code and making things private is exactly what Encapsulation is all about (often times, people refer to it as data hiding).

In a simple mean each object in your code should control its own state. State is the current "snapshot" of your object. The keys, the methods on your object, Boolean properties and so on. If you were to reset a Boolean or delete a key from the object, they're all changes to your state.

Limit what pieces of your code can access. Make more things inaccessible, if they aren't needed.

We’ve all written a basic counter:

class _CounterState extends State<CounterWidget> {
  // That little underscore (_) is doing heavy lifting
  int _count = 0; 

  void increment() {
    setState(() {
      _count++;
    });
  }
}

That underscore _ isn't just a naming convention; it’s a security guard. It locks _count inside this specific class. No other file in your project can reach in and mess with that number.

This is Encapsulation.

If you made _count public, some other random widget might accidentally reset it to zero. By hiding the data and only exposing a function (increment) to change it, you’ve made your code crash-proof.

Polymorphism: Polymorphism means "the condition of occurring in several different forms." That's exactly what the fourth and final pillar is concerned with – types in the same inheritance chains being able to do different things.

If you have used inheritance correctly you can now reliably use parents like their children. When two types share an inheritance chain, they can be used interchangeably with no errors or assertions in your code.

Have you noticed that Text, Container, Row, and Image all look completely different, but you can stick any of them into the child property of a Center widget?

That’s Polymorphism in action. Now, look at how this exact same logic runs your UI. You do this every time you use a Column.

// POLYMORPHISM IN FLUTTER:
// The Column expects a List<Widget>. 
// It doesn't care if they are texts, icons, or complex containers.
Column(
  children: [
    // Form 1: A Text Widget
    Text("Hello World"), 

    // Form 2: A Container Widget
    Container(height: 50, color: Colors.red),

    // Form 3: A Custom Button Widget
    MyCustomButton(), 
  ],
)

Why this matters: The Column widget's code loops through that list and calls build() on every item.

It calls build() on Text -> You get letters.

It calls build() on Container -> You get a red box.

That is Polymorphism. One list, many forms, zero crashes.

Abstraction: To abstract something away means to hide away the implementation details inside something – sometimes a prototype, sometimes a function. So when you call the function you don't have to understand exactly what it is doing.

If you had to understand every single function in a big codebase you would never code anything. It would take months to finish reading through it all.

You can create a reusable, simple-to-understand, and easily modifiable codebase by abstracting away certain details.

Imagine you write a widget that is composed of an icon. You force it to be a specific Icon class.

class RigidCard extends StatelessWidget {
  // RIGID: This card allows ONLY an Icon.
  // It is composed of a concrete class.
  final Icon icon; 
  final String title;

  const RigidCard({required this.icon, required this.title});

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Column(
        children: [
          icon, // We know exactly what this is.
          Text(title),
        ],
      ),
    );
  }
}

Why this fails: If tomorrow you want to put an Image or a Lottie Animation inside that card, you can't. The composition is too specific. You'd have to rewrite the class.

Composition In Terms of Abstraction (Flexible)
Now, let's use Abstraction (Widget) to define the "slot" for the composition.

class FlexibleCard extends StatelessWidget {
  // ABSTRACT: This card allows ANY Widget.
  // It is composed of an abstraction.
  final Widget visual; 
  final String title;

  const FlexibleCard({required this.visual, required this.title});

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Column(
        children: [
          visual, // We don't know what this is! It's just "a Widget".
          Text(title),
        ],
      ),
    );
  }
}

Now, look at how the Composition changes based on the implementation:

// Usage 1: Composed with an Icon

FlexibleCard(
  visual: Icon(Icons.star), // Abstraction lets this fit
  title: "Favorites",
);

// Usage 2: Composed with an Image

FlexibleCard(
  visual: Image.asset('assets/logo.png'), // Abstraction lets this fit too
  title: "Brand",
);

// Usage 3: Composed with a Switch

FlexibleCard(
  visual: Switch(value: true, onChanged: (_) {}), // Even this fits!
  title: "Settings",
);

Now the detail:
Composition: The FlexibleCard HAS-A visual element inside it. That is the structure.

Abstraction: The type of that element is Widget. Widget is the contract (the Abstraction). It says "I don't care if you are an image, text, or button, as long as you can paint yourself on the screen."

Result: Because you used Composition in terms of Abstraction (holding a generic Widget instead of a specific Icon), your FlexibleCard is now infinite. You never have to touch its code again, no matter what new design requirements come in.

This is the heart of Flutter: Build slots (Abstraction) and fill them with blocks (Composition).

Conclusion
You don't need to read a dusty textbook to understand Object-Oriented Programming.

Inheritance is why you extend StatelessWidget.
Encapsulation is why you use _ in your State variables.
Polymorphism is why every widget has a build() method.
Abstraction is why you nest widgets inside widgets.

You aren't just "building screens." You are orchestrating a conversation between objects. And the best part? You were already doing it.

Flutter didn’t invent a new paradigm. It applied object-oriented principles with restraint and taste.

If you align your services, state, and business logic with the same rules that Flutter uses internally, your app starts to feel coherent rather than stitched together.

You don’t need to learn OOP for Flutter. You need to realize that Flutter has been teaching you all along.

From memory to machines: how notifications actually work

Surhid Amatya — Mon, 19 Jan 2026 07:09:09 +0000

Here we talked about the Notification.. Now let’s connect that human idea to the system behind it.

Marketing and engineering look at notifications very differently.

How marketing thinks

We want to send messages.
We want people to remember us.
We want them to come back.

How engineering thinks

We need reliability.
We need scale.
We need control.

Both are right. Both are incomplete alone.

A notification system exists to make them meet in the middle. The real flow, explained simply

Let’s use a food delivery example. You place an order.

What happens next?

`[ Order Placed ]
       |
       v
[ Notification Service ]`

The order service does not send a push directly. It only says:
“Something happened.”

The brain: Notification Service

The Notification Service is like a smart receptionist. Before sending anything, it asks questions.

[ Notification Service ]
        |
        |-- Is the user logged in?
        |-- Do they allow notifications?
        |-- Have we sent too many today?
        |-- What device are they using?
        |-- Push? Email? SMS?

This is where marketing intent meets engineering rules.

Marketing says: “Send an update.”

Engineering asks: “To whom, how, and safely?”

Giving the message a human voice. Once the system decides to send, it prepares the message.

[ Template ]
   |
   v
"Your order is on the way"

[ Personalization ]
   |
   v
"Hi Ram, your order is on the way"

Without this step, notifications feel robotic. With it, they feel personal.

Just like calling someone by name at the door.

Delivery workers (the invisible heroes). Now the message needs to reach the user.

[ Workers ]
   |
   |-- Push (APNS / FCM)
   |-- Email (SMTP)
   |-- SMS

Workers are like delivery people.

If one road is blocked, they retry.
If a service is slow, they wait.
If something fails, they queue again.

This is where trust is built. Closing the loop: learning from users. After delivery, the system watches.

[ User ]
   |
   |-- Opened?
   |-- Clicked?
   |-- Ignored?
   |-- Disabled notifications?

That data goes back.

Now:

Marketing learns what people care about
Engineering learns what breaks
Product learns what matters
Next notification becomes smarter.

Real-life version of this loop

A laptop shop gives you a branded bag.

[ Free Bag ]
     |
     v
[ Daily Use ]
     |
     v
[ Brand Recall ]
     |
     v
[ Return Customer ]

Same loop. Different medium.

Why does this matter?

Most teams build notifications like plumbing.

Pipes in.
Messages out.

The best teams build notifications like memory design. They ask:

What should users remember?
When should they remember it?
How gently can we remind them?
When does it become noise?

It’s not just architecture. It’s psychology turned into systems.

Notifications are not just saying: “Something happened.”

They are saying: “Remember us when it matters.”

And when marketing and engineering agree on that, you stop sending messages and start building relationships.

Notifications Are Not Just Messages. They Are Memory Triggers.

Surhid Amatya — Mon, 12 Jan 2026 09:02:21 +0000

When we hear the word “notification”, we think of phones.

A popup.
A vibration.
A sound.

But notifications existed long before smartphones. They just looked different.

Example 1: The doorbell

When someone rings your doorbell, what are they really doing?

They’re not just making noise. They’re saying:

“I’m here. I want to meet you.”

That bell is not information only. It’s a trigger.

It moves you from whatever you were doing to the door. That’s exactly what a digital notification does.

Example 2: Pamphlets on the street

Someone gives you a pamphlet about a new coaching center.

Is that just paper?

No.

It’s a notification in physical form. It’s saying:
“There is a company called XYZ. They can help you with ABC.”

You may not need them today. But when the need comes, that name suddenly feels familiar.

That’s not just informing. That’s planting memory.

Example 3: Pen and notebook from an institute

A training institute gives you:

A pen with their logo
A notebook with their name

Every time you write something, you see that brand. They are not interrupting you. They are living quietly in your memory.

Later, when you think: “I need some technical training…”

Their name appears in your head. That pen was a notification that lasted months.

Example 4: Laptop shop giving you a bag
You buy a laptop. The shop gives you:

A laptop bag
A mouse pad With their branding.

Every day you use it. You’re not reading an ad. But your brain keeps seeing that name.

Next time you want accessories, repairs, or another laptop, you don’t search first.

You remember first.

That’s notification power without a screen.

So what is a notification, really?

A notification is not just: “Here is some information.”

A real notification is: “Remember me when you need this.”

In tech, we do it with:

Push notifications
Emails
SMS
In-app messages

In real life, we do it with:

Bells
Pamphlets
Branded pens
Free bags

Same idea. Different medium. Where marketing and engineering meet

Marketing teams think about:

Recall
Awareness
Engagement
Repetition

Engineering teams think about:

Delivery
Timing
Reliability
Scale

Notifications sit exactly in the middle.

Marketing decides what should be remembered. Engineering decides how it reaches the user.

When both work together, notifications stop being noise. They become memory hooks.

Why this matters in digital products.
In apps, users forget fast. They install today. They disappear tomorrow.

Notifications exist to gently say: “Hey, remember us.”

But the goal is not to shout. The goal is to stay familiar.

Just like that pen on your desk.

Just like that bag you carry every day.

The real job of a notification:

Not to interrupt.
Not to spam.
Not to beg for attention.

Its real job is simple. To stay in the user’s mind
so when the moment comes, they remember you.

That’s not just communication. That’s connection.

And that’s why notifications are not only a tech feature.

They are psychology.
They are marketing.
They are memory.

In next Blog we'll discuss about a Tech architecture how does a application cann plan for a notification service to make your brand pop out in their mind when they remeber something.

A New Year, an Open Source Tool

Surhid Amatya — Thu, 01 Jan 2026 05:19:26 +0000

A New Year, an Open Source Tool, and a Small Problem That Kept Bugging Me

There’s something about the start of a new year that makes you want to clean things up.

Not just desks and calendars, but ideas that have been sitting in your head for a while.

For me, one of those ideas was API documentation.

Over the past few weeks, I’ve been writing about APIs, how systems communicate, and why documentation matters more than we usually admit. All of that wasn’t theory. It came from a very real problem I kept running into.

We technically had API documentation. But it didn’t feel shareable.

It worked for engineers. It didn’t work for conversations.

And that gap kept showing up at the worst moments.

The small frustration that wouldn’t go away

Every time someone outside the backend team asked, “Can you share the API docs?”

I paused.

Not because the docs didn’t exist. But because I knew what they would see.

Swagger links. Postman collections. Accurate, but intimidating.

I didn’t want to explain how to read the documentation before they could even understand the API.

That pause was the signal.

I didn’t want to replace tools. I wanted to connect them.

This wasn’t about building yet another documentation generator.

Swagger already does a great job. Postman is powerful. OpenAPI exists for a reason.

The problem wasn’t missing data. The problem was missing context and presentation.

So I started building something very small for myself.

A simple web app that:

Connects to Swagger / OpenAPI URLs
Optionally reads Postman collections
Keeps documentation live and in sync

Presents APIs in a more human, browsable way

No uploads every time something changes.
No PDFs going stale.
No guessing which version is correct.

Just one place to point people to.

Why open source it?

At some point, it became obvious this wasn’t just my problem.

If you’re building APIs that are meant to be reused, shared, or trusted, you eventually hit the same wall:
“Technically documented” is not the same as “understandable”.

So instead of keeping this as an internal utility, I decided to open source it. Just a tool that grew out of a real need.

The project

It’s early.
It’s evolving.
And it’s intentionally simple.

If you’re curious, here’s the repository:
api-baucha

You’ll find:

The idea, structure room to improve it together

Why this feels like the right way to start the year

Open-sourcing this feels like closing a loop.

From:
“What is an API?”
To:
“How systems communicate”
To:
“Why documentation breaks”
To:
“Let’s try something different”

It’s not about perfection. It’s about clarity.

And if this tool saves even a few people from hesitating before sharing their API docs, it’s already done its job.

I’ll keep writing as this evolves. And I’ll keep it honest.

That feels like a good way to begin the year.

Happy New Year.

How APIs Actually Travel Between Systems

Surhid Amatya — Sat, 27 Dec 2025 12:37:52 +0000

So far, we’ve talked about APIs as a way for systems to communicate.

But here’s an important clarification.

An API defines what systems say to each other. Network protocols define how those messages travel.

Let's discuss about some of the most common ways messages move across the network.

Think of APIs as the language. Think of protocols as the roads, vehicles, and traffic rules.

Let’s walk through the important ones in simple terms.

HTTP – the basic conversation

HTTP is the most common way applications talk over the internet. When you open a website or an app loads data, it usually uses HTTP underneath.

How it behaves:

One side sends a message
The other side replies
Conversation ends

It’s like sending a letter and waiting for a reply. This works well for:

Loading pages
Fetching data
Simple request–response communication

HTTPS – HTTP with a lock

HTTPS is the same as HTTP, but secured. Think of it like sending the same letter, but inside a locked envelope. Only the sender and receiver can read it.

That’s why HTTPS is used for:

Login systems
Payments
Any sensitive data

From an API point of view, nothing changes in behavior. Only privacy and safety improve.

WebSocket – keeping the call open

WebSocket is different. Instead of sending a message and closing the connection, it keeps the line open.

It’s like a phone call:

Both sides stay connected
Both can speak anytime

This is used when:

Messages need to flow both ways where Updates must be instant

Examples:

Live chat
Real-time notifications
Live dashboards

APIs using WebSockets don’t “ask again and again”.They listen continuously.

TCP – slow but reliable delivery

TCP is about reliability. Imagine sending fragile items through a courier service that:

Confirms delivery
Resends if something is lost
Keeps things in order

That’s TCP. Most APIs rely on TCP underneath because:

Messages arrive correctly
Nothing is lost silently

It’s slower than some options, but trustworthy.

UDP – fast but no guarantees

UDP is the opposite approach. It sends messages quickly, without checking if they arrived.

Imagine shouting information across a room: Some people may miss it
But it’s fast

UDP is used where speed matters more than perfection:

Video calls
Live streaming
Online games

APIs rarely use UDP directly, but systems built on real-time data often do.

HTTP/3 (QUIC) – modern and faster roads

HTTP/3 is a newer version of HTTP that runs on top of UDP.

The idea is simple:

Reduce delays
Recover faster from network issues

It’s useful for:

Mobile apps
IoT devices
Real-time experiences

From the API point of view, this mostly happens behind the scenes.

SMTP and FTP – special-purpose messengers

Some protocols exist for very specific jobs.

SMTP is designed for emails.
FTP is designed for file transfers.

They are not general API communication tools, but they still represent structured system-to-system communication.

They follow strict rules, just like APIs do.

Conclusion

APIs don’t float magically between systems. They travel using protocols like:

HTTP / HTTPS
WebSocket
TCP / UDP

Documentation tells you:

Which protocol is used
What behavior to expect
Whether communication is instant or delayed
Whether it’s one-time or continuous

Without this clarity, teams guess. And guessing leads to fragile systems.

Why this matters for documentation?

When API documentation is good, it answers questions like:

Do I request or do I listen?
Is this real-time or delayed?
Is this secure?
Will I get a response immediately?

Without documentation, developers press buttons randomly, like using a TV remote without knowing what each button does.

And that brings us back to the same point again.

Good documentation doesn’t just explain APIs. It explains how to communicate safely and correctly.

Why Good API Documentation Feels Invisible (Until It’s Missing)

Surhid Amatya — Thu, 25 Dec 2025 07:19:35 +0000

Imagine buying a standing fan. All the parts are inside the box.
The motor works. The blades are fine.

But there’s

No manual.
No guide.
No steps.
No diagram.

You stare at the parts, try to assemble them, remove them again, tighten something that shouldn’t be tightened, and after a while you start wondering if the fan is broken or if you are or some aabra ka daabra will do the magic.

Now imagine buying a smart TV without instructions.

The screen turns on, but:

The remote has too many buttons
Settings feel hidden
You don’t know what features exist

The product technically works, but you never reach its full potential.

That frustration is exactly what bad API documentation feels like. APIs without documentation feel the same. Have you ever tried using:

A new API, new library or even a new internal service

Everything is “there”, but nothing feels clear.

You try one value. It fails. You try another. It half-works.
Error messages appear, but don’t really help.

You start Googling.
You read random examples.
You question whether you’re even using it correctly.

Then suddenly, you find a well-written guide.

Things click.
You move faster with confidence.

That’s the power of good documentation.

Documentation is how systems introduce themselves. An API is a way for systems to talk to each other.

Documentation is how the API explains itself. It answers basic questions like:

What can I do with you?
How should I talk to you?
What do you expect from me?
What will you give me back?

Without documentation, systems are forced into guessing. And guessing does not scale.

Good code does not remove the need for documentation

There’s a common belief: “Well-written code doesn’t need documentation.”

That sounds reasonable, but it breaks down in real systems.

Code explains how something works. Documentation explains how to use it.

A few realities we all know:

Features rarely live in one file
Logic is often spread across services
Dependencies are not always obvious

Reading code alone doesn’t tell you:

What assumptions were made
What must not be changed
What other systems depend on this behavior

Documentation connects those invisible lines. APIs are contracts, not just code

Every service you build exposes an API.

That API is a promise: “If you talk to me like this, I will respond like that.”

You don’t want to explain this promise inside your classes or functions.
That would clutter the code and still not help non-developers.

This is why API documentation exists outside the code.

It’s a shared agreement that anyone can read. Not everyone reading your docs writes code and this part is often ignored.

API documentation is not just for developers. It’s also read by:

QA teams
Product managers
Frontend developers
Partners
Sometimes investors

They don’t want to understand your implementation. They want to understand capabilities and boundaries.

Documentation makes your system understandable beyond engineering.

Writing documentation improves your own thinking. Something interesting happens when you write documentation.

You start asking yourself:

Does this actually make sense?
Why does this work this way?
Is this more complicated than it should be?

Explaining a system forces clarity. Many design issues are discovered not while coding, but while documenting.

Documentation is not extra work. It’s a design review you do with yourself.

So what does good API documentation actually include?

Good API documentation answers practical questions. Not everything. Just the right things.

It usually explains:

What the API is meant to do
How others should interact with it
What inputs are expected
What outputs look like
What errors mean
What is allowed and what is not

Think of it like a TV remote manual:

Button names
What each button does
What happens if you press the wrong one
Without that, users keep pressing random buttons and blaming the TV.

Why this matters more than ever?
Modern systems are built from many moving parts.

Different teams.
Different services.
Different communication styles.

The only thing holding them together is clear agreement. Documentation is that agreement written down.

Good APIs can fail because of poor documentation. Average APIs can succeed because their documentation is clear.

Because at the end of the day:

Systems run on code. Teams run on understanding.

How does API work? WHere's the manual?

Surhid Amatya — Wed, 24 Dec 2025 02:50:14 +0000

So far, we’ve talked about many things.

One system shares information.
Another system consumes it.
Both agree on how that exchange works.

That agreement is the foundation of all system communication.

But here’s the real question.

If two systems have never met before, how does one system know:

that the other system exists?
how to talk to it?
which channel to use?
what kind of information is allowed?
what happens if something goes wrong?

Systems don’t guess. They don’t experiment blindly. They rely on instructions to communicate and that instruction is Documentation.

How does one system know how to communicate?

Let’s go back to a simple example.

The TV remote again

Imagine buying a new TV, but there is no manual. You pick up the remote and start pressing random buttons. One button increases volume. Another suddenly changes language. Another switches input

Another turns the TV off completely

You could eventually figure it out, but only through trial and error.

That’s exactly what happens when systems try to integrate without documentation.

They keep guessing:

Does this value work?
What happens if I send this?
Why did it fail?
What does this response even mean?

It’s slow, frustrating, and risky.

Documentation is the remote’s manual.

It clearly says:

This button does this
This input is expected
This behavior is guaranteed

Channels matter, not just messages

Earlier, we talked about different ways systems communicate:

Asking for data
Being notified by events
Streaming updates
Sending files
Waiting for callbacks

But how does a system know which channel to use?

Think of communication in daily life.

You don’t send a wedding invitation via a fire alarm.
You don’t call someone on the phone to send them a photo album.
You don’t shout breaking news through a letter.

The channel matters.

Documentation tells systems:

Where to send requests
Where to listen for events
When to wait and when to react
What kind of communication is expected
Without that clarity, systems talk past each other.

The fishing hook example, but with instructions

Earlier, we used the fishing hook example for webhooks.

Now imagine someone gives you a fishing rod but tells you nothing else.

Where do you throw the hook?
What kind of fish are you catching?
How do you know when something is caught?
What do you do after the hook moves?

You could try randomly, but success would depend on luck.

Documentation is what tells you:

Where to place the hook
What kind of fish to expect
What movement means “something happened”
What to do next

Systems need the same clarity. This is where API documentation comes in

API documentation exists to answer very practical questions like:

Where do I send information?
What information is allowed?
What information is required?
What will I get back?
What events can I listen to?
What does success or failure look like?

To help teams answer these questions consistently, developers use tools like:

And similar documentation platforms

These tools don’t just list APIs. They describe the rules of communication.

They act like:

A remote control manual
A translator’s guide
A communication contract between systems

What happens without documentation?

Without documentation, integration becomes guesswork.

Teams are forced into trial-and-error:

Sending random values to see what works
Reading error messages like puzzles
Learning behavior only after something breaks

This wastes time and creates fragile systems.

Two systems might appear to work today, but the moment something changes, everything falls apart.

Documentation prevents this by:

Defining standards
Setting expectations
Making communication predictable

The quiet truth

Well-designed APIs can still fail if their documentation is poor. And average APIs can succeed if their documentation is clear.

Because systems don’t just need a way to talk. They need a shared understanding of how to talk.

In the next part, let's talk about why many API documentation tools focus more on technical completeness than human understanding, and how that gap shows up the moment non-engineers, partners, or investors look at them.

That’s where things usually break.

Platform-Agnosticism in Flutter: A Deep Dive

Surhid Amatya — Tue, 23 Dec 2025 04:41:11 +0000

In today’s world, users expect a seamless experience across their devices, whether they’re using a smartphone, tablet, desktop, or even a web application. As developers, ensuring this consistency can be challenging due to the variations in operating systems. However, Flutter makes this easier by being platform-agnostic.

But what does platform-agnosticism mean, and how does Flutter achieve it? This blog explores the concept, compares Flutter with other cross-platform tools, and breaks down the unique architecture that makes Flutter truly platform-independent.

What is Platform-Agnosticism?
Platform-agnosticism refers to how an application delivers a consistent user experience regardless of the underlying operating system. A platform-agnostic app works the same way across devices, hiding the complexities of different platforms from the user.

Users don’t care about the technical hurdles behind app development; they just want a smooth and consistent experience. That’s why being platform-agnostic is crucial.

Flutter embraces this philosophy by ensuring that apps look, feel, and function the same way across multiple platforms. Unlike other frameworks that rely on platform-specific UI components, Flutter has its own rendering engine that ensures uniformity.

But before we dive into how Flutter achieves this, let’s explore how native apps and other cross-platform frameworks work.

How Native and Cross-Platform Apps Work
Every operating system—be it Android, iOS, Windows, macOS, or Linux—has its own set of Software Development Kits (SDKs) and Application Programming Interfaces (APIs) for building apps. These native apps interact with the operating system to access UI elements, hardware, and system services.

How Native Apps Work
Traditionally, if you wanted to build an app for both Android and iOS, you would need to:

Use Kotlin/Java and the Android SDK for Android development.
Use Swift/Objective-C and the iOS SDK for iOS development.

This approach requires separate codebases, meaning more development time, higher maintenance efforts, and developers with expertise in different programming languages.

How Cross-Platform Apps Work
To overcome the challenge of managing multiple codebases, cross-platform frameworks were introduced. They allow developers to write a single codebase that runs on multiple platforms.

Popular cross-platform tools include:

React Native (uses JavaScript)
Xamarin (uses C#)
Flutter (uses Dart)

However, most cross-platform frameworks rely on bridges to communicate with the native OS. These bridges translate cross-platform code into native components, causing slight delays in performance. Some frameworks even use web views to render UI elements, making them dependent on the underlying platform.

How Flutter is Different
Flutter takes a unique approach to cross-platform development by ensuring that the app itself is independent of the host platform.

Instead of using platform-specific UI components, Flutter renders everything from scratch using its own Flutter engine.

Here’s how it works:

When you build a Flutter app for a platform (e.g., Android):

The output is an APK (Android Package).
Inside this APK, there’s a Flutter engine along with the Flutter app.

When the user runs the app, the Flutter engine takes control and executes the Flutter app, ensuring the same behavior across all devices.
This self-contained nature of Flutter apps makes them truly platform-agnostic, as they do not rely on platform-specific UI elements.

How Flutter Renders User Interfaces (UIs)
Flutter achieves platform-agnostic UI rendering through a multi-layered architecture, which includes:

Embedder
Flutter Engine
Flutter Framework (Dart code)

1. Embedder
The embedder is the interface between the Flutter engine and the host platform. It allows Flutter apps to run on different operating systems by providing an Application Binary Interface (ABI).

Each platform has a separate embedder, written in the platform’s native language (e.g., Swift for iOS, Kotlin for Android, C++ for Windows).

2. Flutter Engine
The Flutter engine is responsible for:

Running Dart code
Managing assets
Handling events
Rendering UI

For rendering, Flutter uses Skia or Impeller:
Skia: An open-source graphics library that ensures smooth UIs.
Impeller: A new rendering engine that improves performance and is already the default for iOS.

Flutter doesn’t rely on native UI components but instead draws UI elements directly onto a blank “canvas” provided by the host platform.

3. Flutter Framework
At the highest level, the Flutter framework contains:

Widgets (UI components)
Dart code (business logic)
Animations and interactions

Because Flutter controls its own rendering, it ensures that apps look and behave the same way, no matter where they run.

Platform Channels: How Flutter Interacts with Native Services
Although Flutter apps are independent of the host OS, they sometimes need to access platform-specific features (e.g., camera, GPS, Bluetooth).

This is achieved through Platform Channels, which act as bridges between Flutter and the native platform.

There are two main types of platform channels:

1. Method Channels
Method channels allow bidirectional communication between Flutter (Dart) and the native platform.

For example, if your Flutter app needs to access the device’s GPS, it can send a request through a method channel, and the native side will return the GPS coordinates.

2. Event Channels
Event channels are used for continuous data streams from the native platform to Flutter.

They are useful for:

Listening to sensor data (e.g., accelerometer, gyroscope)
Receiving push notifications
Monitoring real-time system events

By using platform channels, Flutter apps can maintain a unified codebase while still leveraging platform-specific functionalities when needed.

Packages and Plugins in Flutter
Flutter has an extensive package ecosystem on pub.dev, with over 25,000+ packages available.

Packages extend Flutter's capabilities, while plugins provide access to platform-specific features through platform channels.

Examples of commonly used plugins:

camera → Accesses the device camera
geolocator → Fetches GPS location
permission_handler → Manages app permissions

If an existing plugin doesn’t cover a required feature, you can create your own using method and event channels.

Summary: Why Flutter’s Platform-Agnosticism Matters
Flutter’s ability to run the same app across different platforms is what makes it a game-changer.

Consistent UI across all devices → Flutter doesn’t rely on platform-specific UI components but renders everything using its own engine.
No dependency on native UI frameworks → Unlike React Native or Xamarin, Flutter doesn’t need bridges to translate UI components.
Optimized performance → Flutter uses Skia/Impeller for smooth rendering without relying on web views.
Seamless access to native features → Platform channels allow Flutter apps to interact with device-specific functionalities.
Future-proof architecture → If a new OS emerges, Flutter apps can easily adapt by adding a new embedder.

Flutter’s platform-agnostic nature allows developers to build high-performance, cross-platform apps while ensuring a consistent user experience.

Just other ways of communication

Surhid Amatya — Tue, 23 Dec 2025 04:33:26 +0000

So far, we’ve talked about What is an API, types of API.
These cover most everyday use cases, but they’re not the only ways systems talk to each other.

Here are a few more you’ll often hear about and you can explore on your free time.

File-based communication

Sometimes, systems don’t talk live at all. Instead, one system creates a file and another system reads it later.

Examples:

A system exports a CSV file at midnight. Another system picks it up and processes it in the morning. Reports are shared as files between systems.

This approach is common when:

Real-time communication is not required
Different organizations own systems.
Legacy systems are involved

It’s simple, but slow. Think of it as leaving a letter instead of having a conversation.

Webhooks (systems calling you back)

A webhook is like saying:
“Don’t ask me again and again. I’ll call you when something happens.”

Let's see an example of fishing hook. You don’t keep checking the hook every second to see if a fish is there. You wait.

When a fish bites the hook, the hook moves. That movement tells you something happened.

In the same way, with a webhook:

One system waits quietly When something important happens, a signal is sent. The other system reacts immediately.

Nothing is sent unless there is something to report.

So instead of asking again and again, the system is notified only when there’s actually an event, just like a fishing hook only moves when a fish is caught.

Examples:

Payment completed
User signed up
Order shipped

Webhooks are widely used in:

Payments
Notifications
Integrations between products

They reduce unnecessary communication and feel more real-time. Instead of one system constantly checking for updates, the other system sends a message automatically when an event occurs.

Messaging queues

In some systems, messages are placed into a queue and processed one by one. This is useful when:

Systems need to handle high traffic
Tasks should not block user actions
Reliability via async communication matters

Examples:

Sending emails
Processing background jobs
Updating analytics

Queues help systems stay stable even during traffic spikes.

Streaming communication

Streaming is used when data flows continuously instead of being requested.

Examples:

Live chat (eg: whatsapp chat)
Live comments (eg: youtube comments during live streaming of a game or event)
Stock price updates
Activity feeds ( eg: watch your fb feed it updates automatically for new data)

Instead of asking for updates, systems stay connected and receive data as it happens.

This approach is common in:

Social media
Financial platforms
Real-time dashboards

Direct database access (rare and risky)

Sometimes, one system directly reads another system’s database.

This is generally avoided because:

It tightly couples systems
A small change can break everything
Security risks are high

But in tightly controlled internal systems, it still exists.

Think of this as walking into someone’s house instead of knocking on the door (Would you allow this :) ).

One idea connects all of them. Whether systems communicate through:

APIs
Events
Files
Queues
Streams

The goal is always the same:

One system shares information. Another system consumes it. Both agree on how that exchange works.

The better this agreement is defined and documented, the easier systems is to build, integrate, and scale systems.

API - Agreement to communicate

Surhid Amatya — Mon, 22 Dec 2025 04:19:26 +0000

In the previous post, we understood what an API is using simple examples like translators, keyboards, and TV remotes.

Being a human being we always look out for a connection or a way to connect with another being. From 2020 human being have been heavily relying on Social Media Apps to communicate ( example: posting foods on instagram and making it foodagram, posting workout videos or any other videos to ocnnect globally.

Let's explore how these app communicates via Server to enterntain us, to enlighten us or to train us.

When you open Instagram, Facebook, X, or LinkedIn, a lot is happening quietly in the background.

Posts are loading
Likes are being counted
Comments are appearing
Notifications are updating

Our beloved device (phone, tablet, computer etc) is not doing all of this by itself.

Different systems are constantly talking to each other via API - the contract agreed upon to communicate.

But how exactly do they talk?

There are multiple ways communication through APIs. Let’s explore most common ones.

1. REST APIs (the most common one)

REST is the most widely used way for applications to communicate today.

Think of REST like ordering food from a menu.

You ask for something specific.
You get exactly that.
Clear request, clear response.

In social media apps, REST-style APIs are often used for things like:

Loading a list of posts
Fetching user profiles
Showing comments under a post
Getting notification counts

Why REST is popular

Easy to read for humans
Easy to understand for developers
Works well over the internet
Simple structure

Because of this, REST APIs are often the first choice when:

Apps need to fetch data
Mobile and web apps talk to servers
Readability and simplicity matter

2. XML-based APIs (older but still around)

Before modern APIs became popular, many systems talked using XML.

XML is more verbose and structured. It looks heavier, but it is very strict and well-defined.

You’ll still find XML-based APIs in:

Older enterprise systems
Banking and financial integrations
Government systems
Telecom platforms

Why XML is still used

Very strict structure
Strong validation rules
Works well for complex, formal data contracts

Readability

XML is harder for humans to read compared to REST-style responses.
But machines love its strictness.

That’s why XML APIs are often used where:

Precision matters more than simplicity
Systems are large and slow to change
Stability is more important than developer comfort

3. GraphQL (asking exactly what you need)

GraphQL is a newer way of communicating through APIs. Instead of the server deciding what data you get, the client asks exactly what it wants.

Imagine going to a restaurant and saying:
“I want rice, one piece of chicken, no curry, and extra salad.”

That’s GraphQL.

In social media apps, GraphQL is useful when:

Screens need different shapes of data
Mobile apps want to reduce data usage
Multiple data sources are involved

Why teams use GraphQL

Avoids over-fetching data
Flexible for frontend teams
Reduces the number of API calls

Trade-off

GraphQL is powerful, but more complex to design and maintain.
It’s often used by teams that already have mature systems.

4. Event-based communication (not asking, just informing)

So far, all examples were about asking for data.

But sometimes systems don’t ask. They just inform.
This is called event-based communication.

Example:

You like a post
The system emits an event: “Post liked”
Notifications update
Analytics systems record it
Recommendation engines react

All without you waiting. Where this is used

Notifications
Activity feeds
Analytics
Real-time updates

Event-based APIs are common in:

Social media
E-commerce
Financial systems
Real-time platforms

They help systems scale without constantly calling each other.

Conclusion

Social media apps don’t use just one type of API. They usually combine multiple approaches which differ in:

Readability
Structure
Flexibility
Use cases

But the core idea remains the same.

One system talks.
Another system listens.
Both agree on how the conversation works.

What Is an API? A Simple Way to Understand It

Surhid Amatya — Sun, 21 Dec 2025 11:56:17 +0000

API stands for Application Programming Interface. An API is not a screen, nor a website.
It is not something humans usually click and has been using regularly behind scene even more after introduction to social media

At its simplest, an API is a way for one system to communicate with another.

A middle layer that helps two different things understand each other without needing to know how the other one works internally.

Example 1: A language translator
Imagine you speak Nepali and your friend speaks Japanese.

You want to say, “How are you?”

You don’t suddenly learn Japanese.
Your friend doesn’t learn Nepali.

Instead, you can use a translator (personal or google :P ).

You speak in Nepali.
The translator listens.
The translator speaks Japanese to your friend.

You don’t care how the translator works inside.
You only care that:

You say something
The other person understands it

That translator is acting like an API.

You provide input in a format you understand.
The translator converts it and passes it forward.

Example 2: TV remote and television

A TV remote is a perfect real-world example of an API.

You press a button.
The TV reacts.

You don’t know:

How the signal travels

How the TV processes it

How the volume actually increases

You only know the agreement:

This button means volume up

This button means power off

As long as both sides respect that agreement, things work smoothly.

That agreement is the key idea behind APIs.

Example 3: The hot burning cake (Social media apps)

Now let’s bring this idea into the digital world. When you open a social media app:

You see posts

You see likes

You see comments

Your phone is not storing all of this information locally.

Behind the scenes, your app is talking to another system that holds the data. It asks for posts, sends likes, and fetches comments.

This conversation happens through APIs.

The app does not directly touch the database. The database does not care about your screen. They communicate through a defined interface.

That interface is the API.

The important idea

An API is not about technology first. It’s about communication and boundaries.

One system says:
“This is how you can talk to me.”

The other system says:
“Fine, I’ll talk to you in that way.”

When APIs are clear and well-designed, systems can grow, change, and scale without breaking each other.

When APIs are confusing or hard to understand, everything slows down.

In the next part, let's talk about types of APIs and when it's used and how the social media talks using it.

Can we ByPass Apple & Google Fees for Subscriptions (Legally!)

Surhid Amatya — Tue, 18 Mar 2025 05:33:07 +0000

Apple and Google take a 30% commission on in-app purchases, which can significantly impact businesses that rely on subscriptions. Major apps like Spotify, Netflix, Kindle, etc. have already found legal ways to bypass these fees while staying compliant with store policies.

Let's deep dive into how to get a user's subscription legally and maximize revenue, this guide will show you how to structure your subscription flow the right way.

The Key Strategy: Move Payments Outside the App
The safest way to bypass in-app purchase fees is to redirect users to your website for payments while ensuring you don’t explicitly mention external payments within the app.

What’s Allowed?

You can let users sign up for free in the app.
You can send an email directing users to a payment page.
You can show subscription benefits but without a "Buy" button.
You can include a “Manage Subscription” button that opens a browser.

What’s Not Allowed?

You cannot say “Subscribe on our website for lower fees” in the app.
You cannot add an external payment link directly inside the app.
You cannot use WebView to open a payment page (Apple blocks this).

The Subscription Flow
Here's how you can set up your subscription system to stay compliant and avoid in-app purchase fees:

User registers an account in-app (Email & Full Name).
User completes KYC (if needed).
User accesses basic/free features.
Subscription benefits are shown (e.g., "Upgrade to Premium for these and that features!") but without a direct purchase button.
A "Manage Subscription" button redirects to an external browser, where users can pay.
After payment, users log back into the app and get premium access.

Example UI (Safe for Apple & Google)
Here’s how your UI should look:

Example of a Payment Update Prompt (Without Mentioning Subscription)
Instead of mentioning subscriptions directly, apps use generic messages for payment issues:

"Please update your payment information" – Notice that this message does not reference subscriptions but instead directs users to an external website.

Example of a Manage Subscription Page (Redirecting Users Outside the App)

Another example is a "Manage Subscription" button that directs users to the website:

This UI follows the rules: It does not contain an in-app payment button but provides an option to manage the subscription externally.

Moving the Subscription Payment?
To stay compliant:

Add a "Manage Subscription" button inside your app.

When tapped, open an external browser (not WebView!).
Process the payment on your website.
After payment, allow users to log in and access premium features.

By implementing these strategies, you can retain your revenue while staying fully compliant with Apple & Google policies.

If you're building a subscription-based app, DO NOT attempt to bypass fees by adding external links inside the app. Instead, use a "Manage Subscription" button that opens a browser and handles payments externally.

By following this approach, you can avoid app store rejections, maximize revenue, and provide a smooth experience for your users.

Happy Coding! Safe Coding Always.

Note: May be this will work for somebody and may not work with somebody. May be in future Apple and Google will have strict action on this as well.

Reference:
https://dev.to/surhidamatya/understanding-app-store-fees-2l9d