0Pricing
Flutter Mobile Development · Aula

Escrita de Plugins de Plataforma Personalizados para iOS e Android

Crie plugins federados que exponham APIs nativas de Kotlin e Swift ao Dart.

Escrita de Plugins de Plataforma Personalizados para iOS e Android é uma aula grátis de Flutter Mobile Development no CoddyKit. Esta é a aula 3 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Flutter Mobile Development, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Flutter Mobile Development inclui 4 aulas no total.

Partes desta aula ainda não foram traduzidas e aparecem em inglês.

Why Platform Plugins?

Dart cannot call native iOS or Android APIs directly. A platform plugin bridges that gap, exposing Swift/Objective-C and Kotlin/Java capabilities to your Dart code through a typed channel.

  • Package: pure Dart, no native code.
  • Plugin: Dart API plus platform-specific native implementations.

You write a plugin whenever you need hardware (sensors, BLE), OS services (notifications, keychain), or a native SDK that has no Dart equivalent. In this lesson we author a federated plugin that surfaces native Kotlin and Swift APIs to Dart.

Federated Plugin Architecture

A federated plugin splits responsibilities across several packages so different parties can own different platforms:

  • app-facing package (battery): the public Dart API developers import.
  • platform interface (battery_platform_interface): an abstract contract all implementations must satisfy.
  • platform packages (battery_android, battery_ios): concrete native implementations registered via pubspec.yaml.

This decoupling lets a third party add, say, a Windows implementation without touching the app-facing package. The interface package is the linchpin contract.

The Platform Interface Contract

The platform interface uses the plugin_platform_interface package. It declares an abstract base class with a MethodChannel-free contract, plus a default instance other packages override.

The PlatformInterface token-verification prevents implementers from extends-ing and breaking the contract; they must use implements guarded by verifyToken.

import 'package:plugin_platform_interface/plugin_platform_interface.dart';

abstract class BatteryPlatform extends PlatformInterface {
  BatteryPlatform() : super(token: _token);

  static final Object _token = Object();
  static BatteryPlatform _instance = MethodChannelBattery();

  static BatteryPlatform get instance => _instance;

  static set instance(BatteryPlatform value) {
    PlatformInterface.verifyToken(value, _token);
    _instance = value;
  }

  Future<int> getBatteryLevel() {
    throw UnimplementedError('getBatteryLevel() is not implemented.');
  }
}

MethodChannel: The Default Implementation

The default implementation talks to native code over a MethodChannel. Each channel has a unique name shared by Dart and native sides. invokeMethod serializes arguments using the standard message codec and awaits a native reply.

Keep channel names namespaced (reverse-DNS) to avoid collisions across plugins.

import 'package:flutter/services.dart';
import 'battery_platform_interface.dart';

class MethodChannelBattery extends BatteryPlatform {
  final MethodChannel _channel =
      const MethodChannel('com.example.battery/methods');

  @override
  Future<int> getBatteryLevel() async {
    final level = await _channel.invokeMethod<int>('getBatteryLevel');
    if (level == null) {
      throw PlatformException(code: 'NO_LEVEL', message: 'Level unavailable');
    }
    return level;
  }
}

Android: Kotlin Plugin Registration

On Android the native side implements FlutterPlugin and MethodChannel.MethodCallHandler. In onAttachedToEngine you wire a MethodChannel with the same name used in Dart, then route incoming calls in onMethodCall.

  • result.success(value) resolves the Dart Future.
  • result.error(code, msg, details) throws a PlatformException in Dart.
  • result.notImplemented() signals an unknown method.

This is Kotlin, not Dart, so it is illustrative only.

iOS: Swift Plugin Registration

On iOS you conform to FlutterPlugin and register in register(with:), creating a FlutterMethodChannel with the matching name. handle(_:result:) dispatches calls and replies via the FlutterResult callback.

For federated plugins the platform package declares its native entry point under flutter.plugin.platforms.ios in pubspec.yaml, pointing at the Swift class. The Dart registrant is wired automatically.

Declaring the Federated pubspec

The platform implementation packages announce themselves via flutter.plugin.platforms. The dartPluginClass is registered with the platform interface at startup, and pluginClass names the native class.

Crucially the app-facing package lists each platform package under default_package, so adding a platform is a pubspec change, not a code change.

Endorsing Platform Implementations

The app-facing package endorses implementations by depending on them in its pubspec.yaml. Endorsed packages are pulled in transitively, so app developers add one dependency and get every platform.

At runtime, each platform package's registerWith() sets the interface's instance to its own implementation. The Dart API then calls through BatteryPlatform.instance without knowing which platform answered.

// battery_android registers itself at startup
import 'battery_platform_interface.dart';

class BatteryAndroid extends BatteryPlatform {
  /// Registered via dartPluginClass in pubspec.yaml.
  static void registerWith() {
    BatteryPlatform.instance = BatteryAndroid();
  }

  @override
  Future<int> getBatteryLevel() {
    // Delegates to the MethodChannel under the hood.
    return MethodChannelBattery().getBatteryLevel();
  }
}

The App-Facing Dart API

The public package wraps the interface in an ergonomic, well-documented API. App developers never touch channels or platform classes — they call clean Dart methods.

Keep this layer thin: validation, convenience overloads, and documentation. All real work lives behind BatteryPlatform.instance.

import 'battery_platform_interface.dart';

class Battery {
  /// Returns the current battery level as a percentage (0-100).
  Future<int> get batteryLevel => BatteryPlatform.instance.getBatteryLevel();

  /// Convenience: true when the device is critically low.
  Future<bool> get isCritical async => (await batteryLevel) <= 15;
}

Streaming Native Events with EventChannel

For continuous data (charging state, sensor streams) a single method call is not enough. Use an EventChannel: the native side pushes events through a StreamHandler/FlutterEventSink, and Dart exposes them as a Stream.

receiveBroadcastStream lazily starts the native listener on first subscription and tears it down on cancel.

import 'package:flutter/services.dart';

class BatteryStream {
  final EventChannel _events =
      const EventChannel('com.example.battery/charging');

  Stream<bool> get onChargingChanged => _events
      .receiveBroadcastStream()
      .map((event) => event == 'charging');
}

Type-Safe Channels with Pigeon

Hand-written channels are stringly-typed and error-prone. Pigeon generates type-safe Dart, Kotlin, and Swift bindings from a single Dart definition file, eliminating method-name typos and codec mismatches.

You annotate an abstract class with @HostApi() (Dart calls native) or @FlutterApi() (native calls Dart), run the Pigeon generator, and wire the generated classes — no manual invokeMethod strings.

import 'package:pigeon/pigeon.dart';

class BatteryInfo {
  int? level;
  bool? isCharging;
}

@HostApi()
abstract class BatteryHostApi {
  BatteryInfo getBatteryInfo();
}

@FlutterApi()
abstract class BatteryFlutterApi {
  void onLevelChanged(int level);
}

Quick Check

You are publishing a Flutter plugin and want third parties to add new platform implementations (e.g. Windows) without modifying or forking your app-facing package. Which architecture and mechanism makes that possible?

Recap

You learned to author a federated platform plugin exposing native Kotlin and Swift APIs to Dart:

  • Architecture: app-facing package, platform interface, and per-platform implementations.
  • Contract: an abstract PlatformInterface with token verification and a swappable instance.
  • Channels: MethodChannel for request/response, EventChannel for native event streams, with matching names on both sides.
  • Native sides: Kotlin onMethodCall and Swift handle(_:result:) resolving via success/error.
  • Endorsement: pubspec wires dartPluginClass and pluginClass so platforms register themselves.
  • Pigeon: generates type-safe bindings to replace fragile string-based channels.

With this you can wrap any native SDK behind a clean, testable Dart API.

Perguntas Frequentes

A aula “Escrita de Plugins de Plataforma Personalizados para iOS e Android” é grátis?

Sim — o texto completo de “Escrita de Plugins de Plataforma Personalizados para iOS e Android” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Flutter Mobile Development, atualize para CoddyKit PRO. O curso de Flutter Mobile Development inclui 4 aulas no total.

O que vou aprender em “Escrita de Plugins de Plataforma Personalizados para iOS e Android”?

Crie plugins federados que exponham APIs nativas de Kotlin e Swift ao Dart. Você pratica Flutter Mobile Development com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Flutter Mobile Development?

Nenhuma experiência prévia é necessária. Flutter Mobile Development no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 3 de 4.

Quanto tempo leva a aula “Escrita de Plugins de Plataforma Personalizados para iOS e Android”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Flutter Mobile Development?

Sim. Cada aula de Flutter Mobile Development inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Chamada de Bibliotecas C com dart:ffi
  2. Canais de Plataforma Seguros quanto aos Tipos com Pigeon
  3. Escrita de Plugins de Plataforma Personalizados para iOS e Android
  4. Isolados em Segundo Plano e Gerenciamento de Memória Nativa
← Voltar para Flutter Mobile Development