Skip to content

Releasing resources acquired in a plugin #19206

Closed

Description

@mehmetf

Plugins in standalone flutter apps typically live as long as the application is alive. However, in add2app use case, we would want to be able to free the resources and destroy the plugin if the isolate backing the plugin is no longer active (e.g. if FlutterView is destroyed). In some cases, this can be done by subscribing to the activity lifecycle (e.g. if the Flutter is added as a separate activity) but most often the plugin is attached to a single view.

We need a way to detect that the isolate (i.e. FlutterNativeView) is being destroyed.

Activity

  1. nichtverstehen commented on Aug 24, 2018

    @nichtverstehen
    Contributor

    My understanding was that plugins can subscribe to view destroy events via Registrar.addViewDestroyListener.

    Incidentally, there is also #19358 tracking calling dispose() on the widget tree when containing FlutterView gets destroyed. This would allow plugins to release resources acquired per widget instantiation (for plugins implementing widgets) in a fashion symmetrical with resources acquisition.

  2. added
    engineflutter/engine related. See also e: labels.
    on Dec 6, 2018
  3. matthew-carroll commented on Mar 20, 2019

    @matthew-carroll
    Contributor

    @mehmetf does this need to apply to the old embedding, or just the new one?

    In either case, can you describe what the definition of done should look like? For example, should all 1P plugins actually free up their resources to consider this ticket done? Or is there a more narrow interpretation of this ticket that could be handled just by the embedding?

  4. mehmetf commented on Mar 20, 2019

    @mehmetf
    ContributorAuthor

    We need a way to detect that the isolate (i.e. FlutterNativeView) is being destroyed.

    If this is already there, this ticket can be closed.

    Should all 1P plugins actually free up their resources to consider this ticket done?

    No. The title is poorly worded. This is about embedder capability. Embedder needs to be able to signal to the plugin to clean up its resources.

  5. matthew-carroll commented on Mar 20, 2019

    @matthew-carroll
    Contributor

    Ok. Moving forward, plugins will be capable of being unregistered. They will be notified of this. Also, if the FlutterEngine that they are attached to is disposed of, all plugins will automatically be unregistered from that FlutterEngine first. Is that sufficient?

  6. mehmetf commented on Mar 20, 2019

    @mehmetf
    ContributorAuthor

    Yes.

  7. matthew-carroll commented on May 23, 2019

    @matthew-carroll
    Contributor

    I'm going to close this ticket now that enough of the plugin API has been merged to facilitate plugin resource cleanup when the FlutterEngine is destroyed.

  8. github-actions commented on Aug 30, 2021

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  9. locked as resolved and limited conversation to collaborators on Aug 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    a: existing-appsIntegration with existing apps via the add-to-app flowcustomer: mulligan (g3)engineflutter/engine related. See also e: labels.platform-androidAndroid applications specificallyplatform-iosiOS applications specifically

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions