Desarrollar paquetes y plugins

Los paquetes permiten la creación de código modular que se puede compartir fácilmente. Un paquete mínimo consta de lo siguiente:

pubspec.yaml

Un archivo de metadatos que declara el nombre del paquete, versión, autor, etc.

lib

El directorio lib contiene el código público en el paquete, mínimamente un único archivo <package-name>.dart.

Los paquetes pueden contener más de un tipo de contenido:

Paquetes Dart

Paquetes generales escritos en Dart, por ejemplo el paquete path. Algunos de estos podrían contener funcionalidad específica de Flutter y, por lo tanto, depender del framework de Flutter, restringiendo su uso únicamente a Flutter, por ejemplo el paquete fluro.

Paquetes de plugins

Un paquete Dart especializado que contiene una API escrita en código Dart combinada con una o más implementaciones específicas de la plataforma.

Los paquetes de plugins se pueden escribir para Android (usando Kotlin o Java), iOS (usando Swift o Objective-C), web, macOS, Windows o Linux, o cualquier combinación de estos.

Un ejemplo concreto es el paquete de plugin url_launcher. Para ver cómo usar el paquete url_launcher y cómo se extendió para implementar soporte para web, consulta el artículo de Medium de Harry Terkelsen, How to Write a Flutter Web Plugin, Part 1.

Paquetes FFI

Un paquete Dart especializado que permite llamar a código nativo utilizando dart:ffi. Estos paquetes funcionan de forma independiente en Dart y no requieren archivos de compilación específicos del SO. Se crean con el comando flutter create --template=package_ffi (ver Crear un paquete FFI). Este es el enfoque recomendado para construir y empaquetar código nativo desde Flutter 3.38.

Las siguientes instrucciones explican cómo escribir un paquete de Flutter.

Para crear un paquete de Flutter inicial, usa la bandera --template=package con flutter create:

$ flutter create --template=package hello

Esto crea un proyecto de paquete en la carpeta hello con el siguiente contenido:

LICENSE

Un archivo de texto de licencia (casi) vacío.

test/hello_test.dart

Las pruebas unitarias para el paquete.

hello.iml

Un archivo de configuración usado por los IDEs de IntelliJ.

.gitignore

Un archivo oculto que le dice a Git qué archivos o carpetas ignorar en un proyecto.

.metadata

Un archivo oculto utilizado por los IDEs para rastrear las propiedades del proyecto Flutter.

pubspec.yaml

Un archivo yaml que contiene metadatos que especifican las dependencias del paquete. Utilizado por la herramienta pub.

README.md

Un archivo markdown inicial que describe brevemente el propósito del paquete.

lib/hello.dart

Una app inicial que contiene código Dart para el paquete.

.idea/modules.xml, .idea/workspace.xml

Una carpeta oculta que contiene archivos de configuración para los IDEs de IntelliJ.

CHANGELOG.md

Un archivo markdown (casi siempre) vacío para rastrear los cambios de versión del paquete.

Para paquetes Dart puros, simplemente agrega la funcionalidad dentro del archivo principal lib/<package name>.dart, o en varios archivos en el directorio lib.

Para probar el paquete, agrega pruebas unitarias en un directorio test.

Para obtener detalles adicionales sobre cómo organizar el contenido del paquete, consulta la documentación del paquete de biblioteca Dart.

Si deseas desarrollar un paquete que realice llamadas a APIs específicas de la plataforma, necesitas desarrollar un paquete de plugin.

La API se conecta a la(s) implementación(es) específica(s) de la plataforma mediante un platform channel (canal de plataforma).

Los plugins federados son una forma de dividir la API de un plugin en una interfaz de plataforma, implementaciones independientes de la plataforma de esa interfaz, y una interfaz orientada a la aplicación que utiliza la implementación registrada de la plataforma en ejecución.

Los plugins federados separados por paquetes son plugins federados donde la interfaz de plataforma, las implementaciones de plataforma y la interfaz orientada a la aplicación están todas separadas en sus propios paquetes Dart.

Por lo tanto, un plugin federado separado por paquetes puede usar un paquete para iOS, otro para Android, otro para web, y otro más para un automóvil (como ejemplo de un dispositivo IoT). Entre otros beneficios, este enfoque permite que un experto en el dominio extienda un plugin existente para que funcione en la plataforma que mejor conoce.

Un plugin federado requiere lo siguiente:

interfaz orientada a la aplicación

La interfaz con la que interactúan los usuarios del plugin al utilizarlo. Esta interfaz especifica la API utilizada por la aplicación de Flutter. En un plugin federado separado por paquetes, este es el paquete del que dependen los usuarios del plugin para usarlo.

implementación(es) de plataforma

Una o más implementaciones que contienen el código de implementación específico de la plataforma. La interfaz orientada a la aplicación llama a estas implementaciones; no se usan directamente, ni se depende de ellas cuando están separadas por paquetes, en una aplicación, a menos que contengan funcionalidad específica de la plataforma accesible para el usuario final.

interfaz de plataforma

La interfaz que une la interfaz orientada a la aplicación con la(s) implementación(es) de plataforma. Esto declara una interfaz que cualquier implementación de plataforma debe implementar para soportar la interfaz orientada a la aplicación. Tener un paquete separado que defina esta interfaz asegura que todos los paquetes de plataforma implementen la misma funcionalidad de manera uniforme.

Idealmente, al agregar una implementación de plataforma a un plugin federado separado por paquetes, coordinarás con el autor del paquete para incluir tu implementación. De esta manera, el autor original respalda tu implementación.

Por ejemplo, supón que escribes una implementación foobar_windows para el plugin (imaginario) foobar. En un plugin respaldado, el autor original de foobar agrega tu implementación de Windows como una dependencia en el pubspec para el paquete orientado a la aplicación. Luego, cuando un desarrollador incluye el plugin foobar en su aplicación de Flutter, la implementación de Windows, así como las otras implementaciones respaldadas, están disponibles automáticamente para la aplicación.

Si por alguna razón no puedes hacer que el autor original del plugin agregue tu implementación, entonces tu plugin no está respaldado. Un desarrollador aún puede usar tu implementación, pero debe agregar manualmente el plugin al archivo pubspec.yaml de la aplicación:

dependencies:
  foobar: ^1.0.0
  foobar_windows: ^1.0.0 # Non-endorsed plugin implementation

Este enfoque también funciona para anular una implementación de plugin ya respaldada de foobar.

Para obtener más información sobre los plugins federados, por qué son útiles y cómo se implementan, consulta el artículo de Medium de Harry Terkelsen, How To Write a Flutter Web Plugin, Part 2.

Los plugins pueden especificar las plataformas que soportan agregando claves al mapa de platforms en el pubspec.yaml. Por ejemplo, el siguiente archivo pubspec muestra el mapa flutter: para el plugin hello, que soporta solo iOS y Android:

flutter:
  plugin:
    platforms:
      android:
        package: com.example.hello
        pluginClass: HelloPlugin
      ios:
        pluginClass: HelloPlugin

Al agregar implementaciones de plugin para más plataformas, el mapa de platforms debe actualizarse en consecuencia. For example, aquí está el mapa en el archivo pubspec para el plugin hello, cuando se actualiza para agregar soporte para macOS y web:

flutter:
  plugin:
    platforms:
      android:
        package: com.example.hello
        pluginClass: HelloPlugin
      ios:
        pluginClass: HelloPlugin
      macos:
        pluginClass: HelloPlugin
      web:
        pluginClass: HelloPlugin
        fileName: hello_web.dart

Un paquete de plataforma utiliza el mismo formato, pero incluye una entrada implements que indica qué paquete orientado a la aplicación implementa. Por ejemplo, un plugin hello_windows que contenga la implementación de Windows para hello tendría el siguiente mapa flutter::

flutter:
  plugin:
    implements: hello
    platforms:
      windows:
        pluginClass: HelloPlugin

Un paquete orientado a la aplicación puede respaldar un paquete de plataforma agregando una dependencia de él e incluyéndolo como un default_package en el mapa platforms:. Si el plugin hello anterior respaldara a hello_windows, se vería de la siguiente manera:

flutter:
  plugin:
    platforms:
      android:
        package: com.example.hello
        pluginClass: HelloPlugin
      ios:
        pluginClass: HelloPlugin
      windows:
        default_package: hello_windows
​
dependencies:
  hello_windows: ^1.0.0

Ten en cuenta que, como se muestra aquí, un paquete orientado a la aplicación puede tener algunas plataformas implementadas dentro del paquete y otras en implementaciones federadas respaldadas.

Muchos frameworks soportan tanto iOS como macOS con APIs idénticas o casi idénticas, lo que hace posible implementar algunos plugins para iOS y macOS con la misma base de código. Normalmente, la implementación de cada plataforma está en su propia carpeta, pero la opción sharedDarwinSource permite que iOS y macOS utilicen la misma carpeta en su lugar:

flutter:
  plugin:
    platforms:
      ios:
        pluginClass: HelloPlugin
        sharedDarwinSource: true
      macos:
        pluginClass: HelloPlugin
        sharedDarwinSource: true
​
environment:
  sdk: ^3.0.0
  # Flutter versions prior to 3.7 did not support the
  # sharedDarwinSource option.
  flutter: ">=3.7.0"

Cuando sharedDarwinSource está habilitado, en lugar de un directorio ios para iOS y un directorio macos para macOS, ambas plataformas utilizan un directorio compartido darwin para todo el código y recursos. Al habilitar esta opción, debes mover todos los archivos existentes de ios y macos al directorio compartido. También necesitas actualizar el archivo podspec para establecer las dependencias y los objetivos de despliegue (deployment targets) para ambas plataformas, por ejemplo:

  s.ios.dependency 'Flutter'
  s.osx.dependency 'FlutterMacOS'
  s.ios.deployment_target = '13.0'
  s.osx.deployment_target = '10.15'

Para crear un paquete de plugin, usa la bandera --template=plugin con flutter create.

Usa la opción --platforms= seguida de una lista separada por comas para especificar las plataformas que soporta el plugin. Las plataformas disponibles son: android, ios, web, linux, macos, y windows. Si no se especifican plataformas, el proyecto resultante no soportará ninguna plataforma.

Usa la opción --org para especificar tu organización, utilizando la notación de nombre de dominio inverso. Este valor se utiliza en varios identificadores de paquete y de bundle en el código del plugin generado.

Por defecto, el proyecto de plugin utiliza Swift para el código de iOS y Kotlin para el código de Android. Si prefieres Objective-C o Java, puedes especificar el lenguaje de iOS usando -i y el lenguaje de Android usando -a. Por favor elige uno de los siguientes:

$ flutter create --org com.example --template=plugin --platforms=android,ios,linux,macos,windows -a kotlin hello

$ flutter create --org com.example --template=plugin --platforms=android,ios,linux,macos,windows -a java hello

$ flutter create --org com.example --template=plugin --platforms=android,ios,linux,macos,windows -i objc hello

$ flutter create --org com.example --template=plugin --platforms=android,ios,linux,macos,windows -i swift hello

Esto crea un proyecto de plugin en la carpeta hello con el siguiente contenido especializado:

lib/hello.dart

La API de Dart para el plugin.

android/src/main/java/com/example/hello/HelloPlugin.kt

La implementación específica de la plataforma Android del plugin API en Kotlin.

ios/Classes/HelloPlugin.m

La implementación específica de la plataforma iOS del plugin API en Objective-C.

example/

Una aplicación de Flutter que depende del plugin y muestra cómo usarlo.

Dado que un paquete de plugin contiene código para varias plataformas escrito en varios lenguajes de programación, se necesitan algunos pasos específicos para garantizar una experiencia fluida.

La API del paquete de plugin se define en código Dart. Abre la carpeta principal hello/ en tu editor de Flutter favorito. Localiza el archivo lib/hello.dart.

Recomendamos que edites el código de Android usando Android Studio.

Antes de editar el código de la plataforma Android en Android Studio, primero asegúrate de que el código se haya compilado al menos una vez (en otras palabras, ejecuta la aplicación de ejemplo desde tu IDE/editor, o ejecuta en una terminal:

cd hello/example; flutter build apk --config-only

Luego usa los siguientes pasos:

1. Inicia Android Studio.
2. Selecciona Open an existing Android Studio Project en el diálogo Welcome to Android Studio, o selecciona File > Open en el menú, y selecciona el archivo hello/example/android/build.gradle o el archivo hello/example/android/build.gradle.kts.
3. En el diálogo Gradle Sync, selecciona OK.
4. En el diálogo Android Gradle Plugin Update, selecciona Don't remind me again for this project.

El código de la plataforma Android de tu plugin se encuentra en hello/java/com.example.hello/HelloPlugin.

Puedes ejecutar la aplicación de ejemplo desde Android Studio presionando el botón de ejecución (▶).

Recomendamos que edites el código de iOS usando Xcode.

Antes de editar el código de la plataforma iOS en Xcode, primero asegúrate de que el código se haya compilado al menos una vez (en otras palabras, ejecuta la aplicación de ejemplo desde tu IDE/editor, o ejecuta en una terminal cd hello/example; flutter build ios --no-codesign --config-only).

Luego usa los siguientes pasos:

1. Inicia Xcode.
2. Selecciona File > Open, y selecciona el hello/example/ios/Runner.xcworkspace.

El código de la plataforma iOS para tu plugin se encuentra en Pods/Development Pods/hello/../../example/ios/.symlinks/plugins/hello/ios/Classes en el Project Navigator. (Si estás utilizando sharedDarwinSource, la ruta terminará con Flutter/hello/Sources/hello en su lugar).

Puedes ejecutar la app de ejemplo presionando el botón de ejecutar (▶).

Flutter utiliza Swift Package Manager como estrategia principal para gestionar las dependencias nativas de iOS y macOS.

Para agregar una dependencia a tu plugin usando Swift Package Manager:

1. Crea un archivo Package.swift en el directorio ios/my_plugin_name o macos/my_plugin_name de tu plugin.
2. Declara tu dependencia nativa dentro del arreglo dependencies del archivo descriptor Package.swift:

dependencies: [
    .package(url: "https://github.com/path/to/HelloLibrary.git", from: "1.0.0")
]

Para obtener detalles completos e instrucciones sobre cómo estructurar carpetas nativas, empaquetar recursos o manejar configuraciones híbridas, visita la guía Swift Package Manager for plugin authors.

Flutter continúa soportando CocoaPods para compatibilidad hacia atrás. Si tu plugin necesita dar soporte a desarrolladores que aún no se han migrado a Swift Package Manager, especifica tu dependencia de CocoaPods al final de ios/hello.podspec:

s.dependency 'HelloPod', '0.0.1'

Para pods privados, consulta la sección Private CocoaPods para garantizar el acceso al repositorio:

s.source = {
    # For pods hosted on GitHub
    :git => "https://github.com/path/to/HelloPod.git",
    # Alternatively, for pods hosted locally
    # :path => "file:///path/to/private/repo",
    :tag => s.version.to_s
  }

Para obtener y vincular las dependencias del plugin, agrega el plugin a las dependencias de pubspec.yaml de tu proyecto de aplicación y ejecuta flutter pub get. Flutter automáticamente resuelve y conecta los descriptores de Swift Package Manager o los archivos pod de CocoaPods durante el paso de compilación de la aplicación nativa.

Si tu plugin requiere un manifiesto de privacidad, por ejemplo, si utiliza alguna required reason API, actualiza el archivo PrivacyInfo.xcprivacy para describir el impacto de privacidad de tu plugin, y agrega lo siguiente al final de tu archivo podspec:

s.resource_bundles = {'your_plugin_privacy' => ['your_plugin/Sources/your_plugin/Resources/PrivacyInfo.xcprivacy']}

Para obtener más información, consulta Privacy manifest files en el sitio de desarrolladores de Apple.

Te recomendamos editar el código de Linux utilizando un IDE con integración de C++. Las instrucciones a continuación son para Visual Studio Code con las extensiones "C/C++" y "CMake" instaladas, pero se pueden ajustar para otros IDEs.

Antes de editar el código de la plataforma Linux en un IDE, primero asegúrate de que el código se haya compilado al menos una vez (en otras palabras, ejecuta la aplicación de ejemplo desde tu IDE/editor de Flutter, o ejecuta en una terminal cd hello/example; flutter build linux).

Luego usa los siguientes pasos:

1. Inicia Visual Studio Code.
2. Abre el directorio hello/example/linux/.
3. Elige Yes en el aviso que pregunta: ¿Te gustaría configurar el proyecto "linux"?. Esto permitirá que funcione el autocompletado de C++.

El código de la plataforma Linux para tu plugin se encuentra en flutter/ephemeral/.plugin_symlinks/hello/linux/.

Puedes ejecutar la aplicación de ejemplo usando flutter run. Nota: Crear una aplicación de Flutter ejecutable en Linux requiere pasos que son parte de la herramienta flutter, por lo que incluso si tu editor proporciona integración con CMake, compilar y ejecutar de esa manera no funcionará correctamente.

Recomendamos que edites el código de macOS usando Xcode.

Antes de editar el código de la plataforma macOS en Xcode, primero asegúrate de que el código se haya compilado al menos una vez (en otras palabras, ejecuta la aplicación de ejemplo desde tu IDE/editor, o ejecuta en una terminal cd hello/example; flutter build macos --config-only).

Luego usa los siguientes pasos:

1. Inicia Xcode.
2. Selecciona File > Open, y selecciona el hello/example/macos/Runner.xcworkspace.

El código de la plataforma macOS para tu plugin se encuentra en Pods/Development Pods/hello/../../example/macos/Flutter/ephemeral/.symlinks/plugins/hello/macos/Classes en el Project Navigator. (Si estás utilizando sharedDarwinSource, la ruta terminará con hello/darwin/Classes en su lugar).

Puedes ejecutar la app de ejemplo presionando el botón de ejecutar (▶).

Recomendamos que edites el código de Windows usando Visual Studio.

Antes de editar el código de la plataforma Windows en Visual Studio, primero asegúrate de que el código se haya compilado al menos una vez (en otras palabras, ejecuta la aplicación de ejemplo desde tu IDE/editor, o ejecuta en una terminal cd hello/example; flutter build windows).

Luego usa los siguientes pasos:

1. Inicia Visual Studio.
2. Selecciona Open a project or solution, y selecciona el hello/example/build/windows/hello_example.sln.

El código de la plataforma Windows para tu plugin se encuentra en hello_plugin/Source Files y hello_plugin/Header Files en el Solution Explorer.

Puedes ejecutar la aplicación de ejemplo haciendo clic derecho en hello_example en el Solution Explorer y seleccionando Set as Startup Project, luego presionando el botón de ejecución (▶). Importante: Después de realizar cambios en el código del plugin, debes seleccionar Build > Build Solution antes de volver a ejecutar, de lo contrario, se ejecutará una copia obsoleta del plugin compilado en lugar de la última versión con tus cambios.

Finalmente, necesitas conectar la API escrita en código Dart con las implementaciones específicas de la plataforma. Esto se hace usando un platform channel (canal de plataforma), o a través de las interfaces definidas en un paquete de interfaz de plataforma (platform interface).

Para agregar soporte para plataformas específicas a un proyecto de plugin existente, ejecuta flutter create con la bandera --template=plugin nuevamente en el directorio del proyecto. Por ejemplo, para agregar soporte web en un plugin existente, ejecuta:

$ flutter create --template=plugin --platforms=web .

Si este comando muestra un mensaje sobre la actualización del archivo pubspec.yaml, sigue las instrucciones proporcionadas.

En muchos casos, las implementaciones de plataforma que no son web solo utilizan el lenguaje de implementación específico de la plataforma, como se muestra arriba. Sin embargo, las implementaciones de plataforma también pueden utilizar Dart específico de la plataforma.

En algunos casos, algunas plataformas se pueden implementar completamente en Dart (por ejemplo, usando FFI). Para una implementación de plataforma solo en Dart en una plataforma diferente de web, reemplaza pluginClass en pubspec.yaml con dartPluginClass. Aquí está el ejemplo hello_windows anterior modificado para una implementación solo en Dart:

flutter:
  plugin:
    implements: hello
    platforms:
      windows:
        dartPluginClass: HelloPluginWindows

En esta versión no tendrías código C++ para Windows y, en su lugar, heredarías la clase de interfaz de plataforma Dart del plugin hello con una clase HelloPluginWindows que incluye un método estático registerWith(). Este método se llama durante el inicio y se puede usar para registrar la implementación de Dart:

class HelloPluginWindows extends HelloPluginPlatform {
  /// Registers this class as the default instance of [HelloPluginPlatform].
  static void registerWith() {
    HelloPluginPlatform.instance = HelloPluginWindows();
  }

Las implementaciones de plataforma también pueden usar tanto Dart como un lenguaje específico de la plataforma. Por ejemplo, un plugin podría usar un canal de plataforma diferente para cada plataforma, de modo que los canales se puedan personalizar por plataforma.

Una implementación híbrida utiliza ambos sistemas de registro descritos anteriormente. Aquí está el ejemplo hello_windows anterior modificado para una implementación híbrida:

flutter:
  plugin:
    implements: hello
    platforms:
      windows:
        dartPluginClass: HelloPluginWindows
        pluginClass: HelloPlugin

La clase Dart HelloPluginWindows usaría el método registerWith() mostrado anteriormente para implementaciones solo de Dart, mientras que la clase C++ HelloPlugin sería la misma que en una implementación solo de C++.

Te animamos a probar tu plugin con pruebas automatizadas para asegurar que la funcionalidad no tenga regresiones a medida que realizas cambios en tu código.

Para obtener más información sobre cómo probar tus plugins, consulta la sección Testing plugins. Si estás escribiendo pruebas para tu aplicación de Flutter y los plugins están causando fallos, consulta Flutter in plugin tests.

Si deseas desarrollar un paquete que realice llamadas a APIs nativas utilizando el FFI de Dart, necesitas desarrollar un paquete FFI.

Para crear un paquete FFI inicial, usa la bandera --template=package_ffi con flutter create:

$ flutter create --template=package_ffi hello

Esto crea un proyecto de paquete FFI en la carpeta hello con el siguiente contenido especializado:

lib: El código Dart que define la API del paquete, y que realiza llamadas al código nativo usando dart:ffi.

src: El código fuente nativo.

hook/build.dart: El script de gancho de compilación (build hook) que compila el código nativo.

Para usar el código nativo, se necesitan vinculaciones (bindings) en Dart.

Para evitar escribir esto a mano, se genera desde el archivo de cabecera (src/hello.h) mediante package:ffigen. Consulta la documentación de ffigen para obtener información sobre cómo instalar este paquete.

Para regenerar los bindings, ejecuta el siguiente comando:

$ dart run tool/ffigen.dart

Las funciones nativas de ejecución muy corta se pueden invocar directamente desde cualquier isolate. Para ver un ejemplo, consulta sum en lib/hello.dart.

Las funciones de mayor duración deben invocarse en un helper isolate (isolate auxiliar) para evitar la pérdida de fotogramas en las aplicaciones de Flutter. Para ver un ejemplo, consulta sumAsync en lib/hello.dart.

Es una práctica recomendada agregar la siguiente documentación a todos los paquetes:

1. Un archivo README.md que presente el paquete
2. Un archivo CHANGELOG.md que documente los cambios en cada versión
3. Un archivo LICENSE que contenga los términos bajo los cuales se licencia el paquete
4. Documentación de la API para todas las APIs públicas (consulta a continuación para más detalles)

Cuando publicas un paquete, la documentación de la API se genera automáticamente y se publica en pub.dev/documentation. Por ejemplo, consulta los documentos de device_info_plus.

Si deseas generar la documentación de la API localmente en tu máquina de desarrollo, utiliza los siguientes comandos:

1. Cambia de directorio a la ubicación de tu paquete:

   cd ~/dev/mypackage
   

   content_copy

2. Dile a la herramienta de documentación dónde se encuentra el SDK de Flutter (cambia los siguientes comandos para reflejar donde lo colocaste):

      export FLUTTER_ROOT=~/dev/flutter  # on macOS or Linux
   
      set FLUTTER_ROOT=~/dev/flutter     # on Windows
   

   content_copy
3. Run the `dart doc` tool (included as part of the Flutter SDK), as follows:

      $FLUTTER_ROOT/bin/cache/dart-sdk/bin/dart doc   # on macOS or Linux
   
      %FLUTTER_ROOT%\bin\cache\dart-sdk\bin\dart doc  # on Windows
   

   content_copy

Para obtener consejos sobre cómo escribir documentación de la API, consulta Effective Dart Documentation.

Las licencias individuales dentro de cada archivo LICENSE deben estar separadas por 80 guiones en una línea propia.

Si un archivo LICENSE contiene más de una licencia de componente, entonces cada licencia de componente debe comenzar con los nombres de los paquetes a los que se aplica la licencia de componente, con cada nombre de paquete en su propia línea, y la lista de nombres de paquetes separada del texto real de la licencia por una línea en blanco. (No es necesario que los paquetes coincidan con los nombres del paquete pub. Por ejemplo, un paquete podría contener código de múltiples fuentes de terceros y podría necesitar incluir una licencia para cada una de ellas).

El siguiente ejemplo muestra un archivo de licencia bien organizado:

package_1

<some license text>

--------------------------------------------------------------------------------
package_2

<some license text>

Aquí hay otro ejemplo de un archivo de licencia bien organizado:

package_1

<some license text>

--------------------------------------------------------------------------------
package_1
package_2

<some license text>

Aquí hay un ejemplo de un archivo de licencia mal organizado:

<some license text>

--------------------------------------------------------------------------------
<some license text>

Otro ejemplo de un archivo de licencia mal organizado:

package_1

<some license text>
--------------------------------------------------------------------------------
<some license text>

Una vez que hayas implementado un paquete, puedes publicarlo en pub.dev, para que otros desarrolladores puedan usarlo fácilmente.

Antes de publicar, asegúrate de revisar los archivos pubspec.yaml, README.md, y CHANGELOG.md para asegurarte de que su contenido esté completo y sea correcto. También, para mejorar la calidad y facilidad de uso de tu paquete (y hacer que sea más probable que obtenga el estado de Flutter Favorite), considera incluir los siguientes elementos:

• Diversos ejemplos de uso de código
• Capturas de pantalla, gifs animados o videos
• Un enlace al repositorio de código correspondiente

A continuación, ejecuta el comando de publicación en modo dry-run para ver si todo pasa el análisis:

$ flutter pub publish --dry-run

El siguiente paso es publicar en pub.dev, pero asegúrate de estar listo porque la publicación es para siempre:

$ flutter pub publish

Para obtener más detalles sobre la publicación, consulta los documentos de publicación en dart.dev.

Si estás desarrollando un paquete hello que depende de la API de Dart expuesta por otro paquete, debes agregar ese paquete a la sección dependencies de tu archivo pubspec.yaml. El código de abajo hace que la API de Dart del plugin url_launcher esté disponible para hello:

dependencies:
  url_launcher: ^6.3.2

Ahora puedes hacer import 'package:url_launcher/url_launcher.dart' y launch(someUrl) en el código Dart de hello.

Esto no es diferente de cómo incluyes paquetes en aplicaciones de Flutter o cualquier otro proyecto de Dart.

Pero si hello resulta ser un paquete de plugin cuyo código específico de la plataforma necesita acceso a las APIs específicas de la plataforma expuestas por url_launcher, también debes agregar las declaraciones de dependencia adecuadas a tus archivos de compilación específicos de la plataforma, como se muestra a continuación.

El siguiente ejemplo establece una dependencia para url_launcher en hello/android/build.gradle:

android {
    // lines skipped
    dependencies {
        compileOnly rootProject.findProject(":url_launcher")
    }
}

Ahora puedes hacer import io.flutter.plugins.urllauncher.UrlLauncherPlugin y acceder a la clase UrlLauncherPlugin en el código fuente en hello/android/src.

Para obtener más información sobre los archivos build.gradle, consulta la documentación de Gradle sobre scripts de compilación.

El siguiente ejemplo establece una dependencia para url_launcher en hello/ios/hello.podspec:

Pod::Spec.new do |s|
  # lines skipped
  s.dependency 'url_launcher'

Ahora puedes hacer #import "UrlLauncherPlugin.h" y acceder a la clase UrlLauncherPlugin en el código fuente en hello/ios/Classes.

Para obtener detalles adicionales sobre los archivos .podspec, consulta la documentación de CocoaPods.

Todas las dependencias web son manejadas por el archivo pubspec.yaml, como cualquier otro paquete de Dart.