'Background processes' page issue - Contents maybe deprecated

[tc14077]

Page URL: https://flutter.dev/docs/development/packages-and-plugins/background-processes.html
Page source: https://github.com/flutter/website/tree/master/src/docs/development/packages-and-plugins/background-processes.md

Description of issue:
I am a flutter developer and I had followed Ben Kony's excellent guideline to create my application with background process under flutter SDK version 1.9. However, the example mentioned in this page does not adapted the changes on flutter SDK version 1.12. As I understanding, flutter had introduced a new way to register plugin in the release of SDK version 1.12. Flutter team also provided a clear guideline to demonstrate the necessary change on the pre 1.12 Android projects. The page mentions a very important motivation to ours which is the plugins will not work on older pre-1.12 Android projects if it developed exclusively on the new plugins API.

Unfortunately, the example that provided by the Ben, Executing Dart in the Background with Flutter Plugins and Geofencing, is using the pre 1.12 way to register the plugins for "background" Application. It makes the plugins all working in background limited under V1 embedding which are still using PluginRegistry way to register the plugin. And, some new plugins that developed exclusively on the new plugins API become not applicable in the end.

      // Create a FlutterNativeView with no drawing surface (i.e., a
      // background view).
      sBackgroundFlutterView = FlutterNativeView(context, true)
      
      // Register all plugins for the application with our new
      // FlutterNativeView's plugin registry. Other plugins will not
      // work when running in the background if this isn't done!
      val registry = sBackgroundFlutterView!!.pluginRegistry
      sPluginRegistrantCallback.registerWith(registry)
      
      val args = FlutterRunArguments()
      args.bundlePath = FlutterMain.findAppBundlePath(context)
      args.entrypoint = callbackInfo.callbackName
      args.libraryPath = callbackInfo.callbackLibraryPath
      
      // Start running callback dispatcher code in our background view.
      sBackgroundFlutterView!!.runFromBundle(args)

Since I am still new to flutter, I almost tried my best to browse the internet for finding a way to deal with this issue but I failed. Can flutter team suggest a better way to implement background process for the flutter project after SDK version 1.12?

[sfshaza2]

@bkonyi, can you weigh in?

[bkonyi]

Yeah, this article is out of date for the Android plugin portion. We should look into updating it or providing updated documentation. Let me know what you'd like to see done here @sfshaza2 and I'll put it on my list :-)

[sfshaza2]

@bkonyi, I'm ok if you want to update the article in-place and we can add a note saying it's been updating to the new Android plugin structure. But I'm also ok if you want to create new docs for the site. ;)

[bkonyi]

@bkonyi, I'm ok if you want to update the article in-place and we can add a note saying it's been updating to the new Android plugin structure. But I'm also ok if you want to create new docs for the site. ;)

We should really do both... :-) I was kind of hoping that we'd have a more unified background execution offering with all the work Matt C. was putting in before he left, but I think we should offer some better documentation than just referring to my article (although I don't mind the klout I've been getting from it!).

I'll go ahead and update the article sometime in the next couple of weeks (I'm running for the border tomorrow, so I'll be OOO until I reach Ontario mid next week). Should we set up a meeting to discuss what proper docs should look like?

[tc14077]

Thank you for having attention to my issue! I am very looking forward to see the updates on the flutter website!

[tc14077]

@bkonyi, I am also having difficulty with the message passing between the main isolate and "background" isolate(that created in the native side). I know it could be done by ReceivePort and SendPort Class when we are creating the isolate in the dart platform. However, the way that you had introduced in the previous article seems can not be benefited from these classes. Could you please also consider to cover this topic in the next article update?

Before I am submitting this issue, I did a workaround for adjusting this problem. When I would like to pass the content/message(says A) from "background" isolate to the main isolate in dart level:

1. I will first pass the A to native side through method channel;

2. Then, using service callback to pass the A back to the activity; (In this point, the callback function is being considered as a kind of "portal" that enabling the communications between main and background isolate)

3. After the callback function is being called, the function will use the method channel to pass A back to the dart side.

I know this method is too clumsy(but it works for me), and therefore I am looking for a better suggestion to tackle this issue.

[sfshaza2]

Thanks for specifying the exact information you want to see, @tc14077! I'm sure you aren't alone in this.

[tc14077]

@sfshaza2, are there any progress on this issue?

[sfshaza2]

No, @tc14077, and you are unlikely to see any update in the near term, as all of Google is eyeball deep in the perf season. Beyond that, I have no idea what other higher priority tasks are on @bkonyi's plate. Since this isn't a place to get support, but to report doc errors/deficiencies, maybe you can get help from one of the sources on our community page, such as Discord or Stack Overflow.

Sorry I couldn't be more help.

[tc14077]

ok,thanks for your concern. =]

[bkonyi]

Yes, as @Sfshaza alluded to, we're all quite busy for the next couple of weeks so I likely won't have a chance to take a look at this for another month or so. However, if you're looking for an up-to-date example to work off of, you can take a look at the android_alarm_manager code which has already been migrated to the new Android embedding.

[sfshaza2]

Thanks, @bkonyi! By the way, I use sfshaza2@, not Sfshaza@. (It's a long and boring story.). :D

[tc14077]

Yes, as @Sfshaza alluded to, we're all quite busy for the next couple of weeks so I likely won't have a chance to take a look at this for another month or so. However, if you're looking for an up-to-date example to work off of, you can take a look at the android_alarm_manager code which has already been migrated to the new Android embedding.

cool, thanks!!

[bkonyi]

I've updated the article with examples that use the v2 Android embedding and pushed the relevant changes for the example plugin. Let me know if you run into any issues or have feedback!

[tc14077]

I've updated the article with examples that use the v2 Android embedding and pushed the relevant changes for the example plugin. Let me know if you run into any issues or have feedback!

Hi, @bkonyi
Thanks for the excellent guideline again!

However, I am facing issues after I followed the steps that given in the guide. As plugin registration is done via reflection in the V2 embedding, I skipped the following codes.

sBackgroundFlutterView = new FlutterNativeView(context, true);
PluginRegistry registry = sBackgroundFlutterView.getPluginRegistry();
sPluginRegistrantCallback.registerWith(registry);
FlutterRunArguments args = new FlutterRunArguments();
args.bundlePath = FlutterMain.findAppBundlePath();
args.entrypoint = callbackInfo.callbackName;
args.libraryPath = callbackInfo.callbackLibraryPath;
sBackgroundFlutterView.runFromBundle(args);

and try to use following codes to create a new Flutter background isolate (FlutterEngine i guess):

sBackgroundFlutterEngine = new FlutterEngine(context);
DartExecutor.DartCallback args = new DartCallback(context.getAssets(), FlutterMain.findAppBundlePath(context), callbackInfo);
sBackgroundFlutterEngine.getDartExecutor().executeDartCallback(args);

The isolate creation seems work fine after changing these codes, but there are some plugins (e.g., path_provider) are failed to call in the created isolate (i.e., background isolate). The MissingPluginException is raised after using it in the background isolate. I believe it may caused by the plugin not be registered appropriately. Are there any missing steps that leading this exception happen? Or are there any workaround for me to use plugin in the background isolate?

If this issue can be solved, this guideline can help others to get a practical experience on running Dart code in background. Any suggestion is appreciated and welcome!

UPDATE
Tested those plugin in yours geoforcing example app, it works fine! I think I must be missing something important steps!

UPDATE2
Following error prompted when I followed the guide to change my codes.
MissingPluginException (MissingPluginException(No implementation found for method getApplicationDocumentsDirectory on channel plugins.flutter.io/path_provider))

UPDATE3
After I ran through the debugging process, my flutter app works fine now. It turns out that a single package, flutter_ble: 0.6.2, affected the flutter engine to register the plugins to the new isolate. After I remove the flutter_blue in pubspec.yaml, all plugins can run normally in background isolate again.