Створення Flutter-плагіна з нативною функціональністю

Створення Flutter-плагіна для нативної функціональності

Ви інтегруєте пропрієтарний SDK партнера — C++ бібліотеку з нативними викликами. Готових плагінів на pub.dev немає, а обгортка через ffi не підходить через складний lifecycle — наприклад, необхідно правильно керувати пам'яттю та синхронізацією з Dart-ізолятом. Знайома ситуація? Тоді пишемо власний плагін через Platform Channels. Ми, команда мобільних розробників з 10+ річним стажем, беремо такі задачі під ключ: від проектування API до публікації на pub.dev та інтеграції у ваш проект. У нас за плечима реалізація понад 40 кастомних плагінів для замовників з фінтеху, медицини та IoT. Знижуємо бюджет на інтеграцію до 40% за рахунок використання Pigeon та оптимізації платформенних каналів.

Як вибрати тип Platform Channel?

Визначення правильного каналу — основа стабільної роботи плагіна. Порівняємо три варіанти:

Типовий приклад: плагін для роботи з BLE-пристроєм. Сканування пристроїв — EventChannel (безперервний потік знайдених пристроїв). Підключення/відключення — MethodChannel. Отримання сповіщень від характеристики — знову EventChannel.

Чому Pigeon кращий за ручну серіалізацію?

StandardMessageCodec (дефолтний) підтримує примітиви, List, Map. Для кастомних об'єктів — серіалізуємо в Map<String, dynamic> на Dart-стороні та отримуємо HashMap на Kotlin / [String: Any] на Swift. Але це загрожує описками в іменах ключів. Альтернатива — Pigeon: інструмент від Flutter team для генерації type-safe API по .dart-специфікації. Pigeon генерує Kotlin/Swift код з типізованими класами — виключає runtime-помилки від описок в іменах методів. Застосування Pigeon скорочує час розробки на 30–40% та спрощує підтримку. Згідно з офіційною документацією Flutter, використання Pigeon рекомендоване для плагінів зі складною серіалізацією. Детальніше див. Platform Channels.

Порівняйте дві стратегії:

Як ми розробляємо плагін: етапи

1. Аналіз вимог: які нативні функції потрібні, які дозволи, lifecycle. Оцінюємо обсяг: 1–2 методи під одну платформу або 10+ з EventChannel для обох.
2. Проектування Dart API: контракт через Pigeon або ручні MethodChannel/EventChannel. Визначаємо типи даних.
3. Реалізація на iOS (Swift) та Android (Kotlin): використовуємо FlutterPlugin, ActivityAware, MethodCallHandler. Обробка всіх edge cases та помилок.
4. Тестування: модульні тести на Dart, інтеграційні тести на обох платформах, тестування на реальних пристроях.
5. Інтеграція у ваш проект: підключаємо через git dependency або публікуємо на pub.dev.
6. Документація: README з API, прикладами, CHANGELOG.

Структура плагіна

Створюємо через flutter create --template=plugin my_plugin. Структура:

my_plugin/
  lib/my_plugin.dart — Dart API
  android/src/.../MyPlugin.kt — Android реалізація
  ios/Classes/MyPlugin.swift — iOS реалізація
  example/ — приклад додатку для тестування

Dart-сторона оголошує контракт:

class MyPlugin {
  static const MethodChannel _channel = MethodChannel('my_plugin');

  static Future<String?> getPlatformVersion() async {
    return await _channel.invokeMethod<String>('getPlatformVersion');
  }

  static Stream<ScanResult> get scanResults {
    return const EventChannel('my_plugin/scan_results')
        .receiveBroadcastStream()
        .map((data) => ScanResult.fromMap(Map<String, dynamic>.from(data)));
  }
}

Android-реалізація: FlutterPlugin + ActivityAware

На Android плагін реалізує FlutterPlugin для lifecycle, MethodCallHandler для обробки викликів. Якщо потрібен Activity (наприклад для permission request), додатково ActivityAware:

class MyPlugin : FlutterPlugin, MethodCallHandler, ActivityAware {
    private lateinit var channel: MethodChannel
    private var activity: Activity? = null

    override fun onAttachedToEngine(binding: FlutterPlugin.FlutterPluginBinding) {
        channel = MethodChannel(binding.binaryMessenger, "my_plugin")
        channel.setMethodCallHandler(this)
    }

    override fun onMethodCall(call: MethodCall, result: Result) {
        when (call.method) {
            "getPlatformVersion" -> result.success("Android ${android.os.Build.VERSION.RELEASE}")
            else -> result.notImplemented()
        }
    }

    override fun onAttachedToActivity(binding: ActivityPluginBinding) {
        activity = binding.activity
    }
}

Критична деталь: result.success(), result.error() та result.notImplemented() повинні викликатися рівно один раз. Виклик result.success() двічі — краш IllegalStateException: Reply already submitted. Ми гарантуємо відсутність таких помилок у нашому коді.

iOS-реалізація на Swift

public class MyPlugin: NSObject, FlutterPlugin {
    public static func register(with registrar: FlutterPluginRegistrar) {
        let channel = FlutterMethodChannel(
            name: "my_plugin",
            binaryMessenger: registrar.messenger()
        )
        let instance = MyPlugin()
        registrar.addMethodCallDelegate(instance, channel: channel)
    }

    public func handle(_ call: FlutterMethodCall, result: @escaping FlutterResult) {
        switch call.method {
        case "getPlatformVersion":
            result("iOS " + UIDevice.current.systemVersion)
        default:
            result(FlutterMethodNotImplemented)
        }
    }
}

EventChannel та memory leaks

При використанні EventChannel на Android нативний бік отримує EventSink. Типовий витік: тримаємо EventSink в полі класу, Activity перестворюється при повороті екрана, старий EventSink не валідується — і виклик sink.success() після знищення кидає виняток. Рішення: обнуляти sink в onCancel() та перевіряти перед кожним викликом.

Публікація та версіонування

Для внутрішнього використання плагін живе в git-репозиторії та підключається через path або git dependency в pubspec.yaml. Для публікації на pub.dev — flutter pub publish з обов'язковим pubspec.yaml з homepage, repository, повним CHANGELOG.md.

Що входить в роботу

• Розробка Dart API та нативної реалізації для iOS та Android
• Інтеграція з вашим проектом (приклад використання)
• Документація по API та збірці
• Публікація на pub.dev або надання доступу до git-репозиторію
• Гарантія стабільності платформенних каналів та обробка помилок

Розробка плагіна: простий (1–2 методи, одна платформа) — 2–4 дні. Повноцінний cross-platform плагін з EventChannel, permissions та edge-case handling — 2–4 тижні. Вартість розраховується індивідуально. Отримайте консультацію: зв'яжіться з нами для оцінки вашого проекту. Ми вже реалізували понад 40 кастомних плагінів для замовників з фінтеху, медицини та IoT — приєднуйтесь. Замовте розробку плагіна прямо зараз.