WE ARE
YOUR PARTNER
FOR
SOFTWARE
DEVELOPMENT

During application development, we often encounter situations where we need to add new functionalities to an existing one. However, doing so can lead to unpredictable errors. This is because when modifying the code of an old function to accommodate a new one, we need to minimize the possibility of the added functionality affecting shared variables.

In this case, you should use the Decorator design pattern to implement the modifications. Simply put, the Decorator pattern allows you to add new behavior to an object without affecting the behavior of other objects within the same class.

1. Problem

Imagine that you have a Customer with a property called Cart and behaviors like AddToCart and CheckOut. In a typical workflow, the user will add products to their Cart and then perform CheckOut. Once the CheckOut information is successful, the order details will be sent to your warehouse for shipping.

However, according to new customer demands, a faster shipping carrier is added. Now, customers can choose between the traditional shipping carrier and the faster one. At this point, you might think of modifying the CheckOut process to add a condition: if the customer selects a different shipping carrier, you will execute a different CheckOut behavior.

But if more shipping carriers are added in the future, managing the code will become increasingly difficult due to the numerous conditions and behaviors being added. Therefore, it's best if these new behaviors are added using a Decorator.

By creating a base decorator class that wraps the Customer object, we can rewrite the CheckOut behavior with the newly added processing while still preserving the original behavior of the Customer object.

2. Usage examples (Decorator Pattern)

I will write a code snippet to illustrate how to use the decorator in the above scenario as follows:

Cart.cs

namespace Decorator
{
    public class Cart
    {
        public List Products { get; private set; } = [];

        public void AddProduct(string product)
        {
            Products.Add(product);
        }

        public string Details()
        {
            return string.Join(", ", Products);
        }
    }
}

Customer.cs

namespace Decorator
{
    public abstract class Customer
    {
        public Cart Cart { get; set; } = new();

        public virtual void AddToCart(string product)
        {
            Cart.AddProduct(product);
        }

        public abstract void CheckOut();
    }
}

DecoratorCustomer.cs

namespace Decorator
{
    public abstract class DecoratorCustomer : Customer
    {
        protected Customer? _customerComponent;

        public DecoratorCustomer(Customer customerComponent)
        {
            _customerComponent = customerComponent;
        }

        public override void CheckOut()
        {
            if (_customerComponent != null)
            {
                _customerComponent.CheckOut();
            }
        }
    }
}

DecoratedCustomer.cs

namespace Decorator
{
    public class DecoratedCustomer : DecoratorCustomer
    {
        private string _deliveryProvider { get; set; } = "Default delivery";

        public DecoratedCustomer(Customer customerComponent) : base(customerComponent)
        {
        }

        public void AddDeliveryInfo(string deliveryProvider)
        {
            _deliveryProvider = deliveryProvider;
        }

        public override void CheckOut()
        {
            Console.WriteLine("Delivery information");
            // Get delivery time based on the delivery provider
            GetDeliveryInfo();
            base.CheckOut();
        }

        private void GetDeliveryInfo()
        {
            Console.WriteLine($"Delivery provider: {_deliveryProvider}");
            if (_deliveryProvider.Contains("Express"))
                Console.WriteLine("Delivery time: 1 day");
            else
                Console.WriteLine("Delivery time: 2-3 days");
        }
    }
}

ConcreteCustomer.cs

namespace Decorator
{
    public class ConcreteCustomer : Customer
    {
        public override void CheckOut()
        {
            Console.WriteLine($"Checkout information: {Cart.Details()}");
        }
    }
}

Program.cs

using Decorator;

// Default customer checkout information
ConcreteCustomer customer = new();
customer.AddToCart("Fridge");
customer.AddToCart("Washing machine");
customer.AddToCart("Oven");
customer.AddToCart("Microwave");
customer.CheckOut();
Console.WriteLine("======#==#======");

// Decorated customer checkout information
DecoratedCustomer decoratedCustomer = new(customer);
decoratedCustomer.AddDeliveryInfo("Express delivery");
decoratedCustomer.CheckOut();
Console.WriteLine("======#==#======");

The result after executing the program is as follows:

As you can see, initially the information checked out only included the Cart details. After being decorated, the checkout process can now output the shipping carrier information as well.

By implementing the above, you can customize the behaviors of an object to suit various use cases while maintaining the stability and integrity of the object. However, I also recognize that a certain level of knowledge is required to apply this architecture effectively because the overall structure can spread the functionality across multiple files, making it more challenging to read and understand. Developers need to carefully consider suitable architectures to apply to their projects to minimize potential errors.

Whether you need scalable software solutions, expert IT outsourcing, or a long-term development partner, ISB Vietnam is here to deliver. Let’s build something great together—reach out to us today. Or click here to explore more ISB Vietnam's case studies.

Reference:

1. Decorator design parttern.
2. Decorator example in C#   

Introduction

Flutter excels at rendering a declarative UI at 60fps, but it remains a guest on the host operating system. When an application requires access to platform-specific APIs—such as low-energy Bluetooth, obscure biometric sensors, or background process management—we must bridge the gap between the Dart runtime and the native host.

While the MethodChannel API is the foundational transport layer, building a scalable, maintainable plugin requires more than just passing strings back and forth. This post details the architecture and engineering standards for building production-grade Flutter plugins, focusing on the Federated Architecture, Type Safety, and Concurrency.

How to implement

The Federated Plugin Architecture

For production systems, monolithic plugins (where Android, iOS, and Dart code reside in one package) are discouraged. The industry standard is the Federated Plugin Architecture. This pattern decouples the API definition from the platform implementations, enabling independent scalability and testing.

The Structure

A federated plugin is split into multiple packages, typically organized in a monorepo:

• plugin_name (App-Facing): The entry point for consumers. It forwards calls to the default platform instance.
• plugin_name_platform_interface: Contains abstract base classes and data models. This ensures all platform implementations adhere to the same contract.
• plugin_name_android / plugin_name_ios: The concrete implementations for specific platforms.
  
  

Benefits:

• Isolating Dependencies: Android-specific Gradle dependencies do not leak into the Web or iOS implementations.
• Testability: The platform_interface allows you to inject mock implementations during Dart unit tests without needing a simulator.
  
  

Enforcing Type Safety with Pigeon

The raw MethodChannel relies on Map<String, dynamic> and untyped standard message codecs. This is brittle; a typo in a map key or a mismatched data type causes runtime crashes (ClassCastException) rather than compile-time errors.

The Solution: Pigeon.

Pigeon is a code generation tool that creates type-safe bridges between Dart and Native code. It generates the serialization logic, ensuring that data contracts are respected across boundaries.

Step A: Define the Schema (Dart)

Create a standalone Dart file (e.g., pigeons/messages.dart) to define the API.

Dart:

import 'package:pigeon/pigeon.dart';

@ConfigurePigeon(PigeonOptions(
     dartOut: 'lib/src/messages.g.dart',
     kotlinOut: 'android/src/main/kotlin/com/example/plugin/Messages.g.kt',
     swiftOut: 'ios/Classes/Messages.g.swift',
     kotlinOptions: KotlinOptions(package: 'com.example.plugin'),
))

class CompressionConfig {
     int? quality;
     String? format; // 'jpeg' or 'png'
}

class CompressionResult {
     Uint8List? data;
     String? error;
}

@HostApi()
abstract class ImageCompressorApi {
     @async
     CompressionResult compress(Uint8List rawData, CompressionConfig config);
}

Step B: Generate the Protocol

Running the Pigeon generator produces:

• Dart: An abstract class used by your plugin logic.
• Kotlin: An interface (ImageCompressorApi) to implement.
• Swift: A protocol (ImageCompressorApi) to conform to.

Android Implementation (Kotlin)

Modern Android plugins should be written in Kotlin and must handle lifecycle awareness and threading correctly.

The generated Pigeon interface simplifies the setup. Note the use of Coroutines to move work off the main thread.

Kotlin:

import io.flutter.embedding.engine.plugins.FlutterPlugin
import kotlinx.coroutines.*

class ImageCompressorPlugin : FlutterPlugin, ImageCompressorApi {
     private val scope = CoroutineScope(Dispatchers.Main)

     override fun onAttachedToEngine(binding: FlutterPlugin.FlutterPluginBinding) {
          // Wire up the generated Pigeon API
          ImageCompressorApi.setUp(binding.binaryMessenger, this)
     }

     override fun compress(
          rawData: ByteArray,
          config: CompressionConfig,
          result: Result<CompressionResult>
     ) {
          // MOVE TO BACKGROUND THREAD
          scope.launch(Dispatchers.Default) {
               try {
                    val compressedData = NativeCompressor.process(rawData, config.quality)
                    val output = CompressionResult(data = compressedData)

                    // Return to Main Thread to send result back to Flutter
                   withContext(Dispatchers.Main) {
                        result.success(output)
                   }

               } catch (e: Exception) {
                    withContext(Dispatchers.Main) {
                    result.error(e)
              }}
          }

     }

     override fun onDetachedFromEngine(binding: FlutterPlugin.FlutterPluginBinding) {
          ImageCompressorApi.setUp(binding.binaryMessenger, null)
          scope.cancel() // Prevent memory leaks
     }
}

Key Engineering Consideration: If your plugin requires Activity references (e.g., for startActivityForResult or Permissions), your plugin class must implement ActivityAware. Do not rely on the deprecated Registrar.

iOS Implementation (Swift)

iOS implementation follows a similar pattern using Swift protocols and Grand Central Dispatch (GCD).

Swift:

import Flutter
import UIKit

public class SwiftCompressorPlugin: NSObject, FlutterPlugin, ImageCompressorApi {

     public static func register(with registrar: FlutterPluginRegistrar) {
          let messenger = registrar.messenger()
          let api = SwiftCompressorPlugin()
           // Wire up the generated Pigeon API
          ImageCompressorApiSetup.setUp(binaryMessenger: messenger, api: api)
     }

     func compress(
          rawData: FlutterStandardTypedData,
          config: CompressionConfig,
          completion: @escaping (Result<CompressionResult, Error>) -> Void
     ) {
          // MOVE TO BACKGROUND QUEUE
          DispatchQueue.global(qos: .userInitiated).async {
          do {
                let data = try NativeCompressor.process(rawData.data, quality: config.quality)
                let result = CompressionResult(data: data, error: nil)

                // Callback is thread-safe in Pigeon generated code,
               // but explicit main queue dispatch is good practice for UI work
               DispatchQueue.main.async {
                      completion(.success(result))
                }
               } catch {
                     completion(.failure(error))
               }
          }
     }
}

Performance and Concurrency

A common bottleneck in plugin development is blocking the Platform Thread.

• The Issue: Flutter's Platform Channels invoke native methods on the host's Main Thread (UI Thread).
• The Consequence: If you perform JSON parsing, Bitmap decoding, or File I/O directly in the handler, the entire device UI (not just the Flutter app) will freeze (Jank).
• The Fix: Always offload operations exceeding 16ms to a background thread (using Dispatchers.IO in Kotlin or DispatchQueue.global in Swift) immediately upon receiving the call.

Testing Strategy

Robust plugins require a layered testing approach.

Unit Tests (Dart)

Mock the platform interface. Because we decoupled the logic, we can test the Dart transformation layers without an emulator.

Dart:

class MockApi implements ImageCompressorApi {
     @override
     Future<CompressionResult> compress(Uint8List rawData, CompressionConfig config) async {
          return CompressionResult(data: rawData); // Echo back for testing
     }
    }

     void main() {
           test('Controller transforms data correctly', () async {
          final api = MockApi();
          // Inject API into controller and assert logic
      });
}

Integration Tests (On-Device)

Use the integration_test package to verify the full round-trip. This ensures the native compilation and linking are correct.

Summary

Building a plugin is not just about making it work; it is about making it safe and scalable.

• Federate: Split your logic from your platform implementations.
• Strict Typing: Use Pigeon to eliminate runtime serialization errors.
• Thread Management: Never block the Main Thread; offload heavy lifting immediately.
• Lifecycle: Manage Activity attachment and detachment cleanly to avoid leaks.