0Pricing
Flutter Mobile Development · Lekcja

Pisanie niestandardowych pluginów platformowych dla iOS i Androida

Twórz federacyjne pluginy udostępniające natywne API Kotlin i Swift w języku Dart

Pisanie niestandardowych pluginów platformowych dla iOS i Androida to bezpłatna lekcja Flutter Mobile Development na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Flutter Mobile Development, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Flutter Mobile Development zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

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.

Często zadawane pytania

Czy lekcja „Pisanie niestandardowych pluginów platformowych dla iOS i Androida” jest bezpłatna?

Tak — pełny tekst „Pisanie niestandardowych pluginów platformowych dla iOS i Androida” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Flutter Mobile Development, przejdź na CoddyKit PRO. Kurs Flutter Mobile Development zawiera 4 lekcji w sumie.

Co nauczysz się w „Pisanie niestandardowych pluginów platformowych dla iOS i Androida”?

Twórz federacyjne pluginy udostępniające natywne API Kotlin i Swift w języku Dart Ćwiczysz Flutter Mobile Development z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Flutter Mobile Development?

Nie wymagamy żadnego doświadczenia. Flutter Mobile Development w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Pisanie niestandardowych pluginów platformowych dla iOS i Androida”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Flutter Mobile Development?

Tak. Każda lekcja Flutter Mobile Development zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Wywoływanie bibliotek C za pomocą dart:ffi
  2. Bezpieczne typowo kanały platformy z Pigeon
  3. Pisanie niestandardowych pluginów platformowych dla iOS i Androida
  4. Izolaty działające w tle i zarządzanie pamięcią natywną
← Powrót do Flutter Mobile Development