Update 'Background processes' page

[zoechi]

@mit-mit commented on Thu Sep 20 2018

This was added recently by @bkonyi and he posted on medium, however there was feedback we should also cover it on flutter.io

---

@ram231 commented on Fri Sep 21 2018

can you also add Inherited Model, i can't seem to find any tutorials or documentation about Inherited Model.

---

@Sfshaza commented on Mon Oct 15 2018

@mit-mit, I've added placeholder a page to the new website that points to the Medium article. It's a partial solution for now.

---

@Sfshaza commented on Mon Oct 15 2018

@ram231, could you file another issue for InheritedWidget docs on the flutter/website repo?

[mit-mit]

@Sfshaza I'd love to see some updates to our background docs.

We currently have these two: https://docs.flutter.dev/cookbook/networking/background-parsing https://docs.flutter.dev/packages-and-plugins/background-processes

But they are not cross-linked, and it's not clear when to just use isolates, and when to use the lower-level mechanisms from Ben's post.

[atsansone]

Bumping to P1 because this issue has been raised multiple times over four years without resolution.

[stuartmorgan]

@Sfshaza I'd love to see some updates to our background docs.

We currently have these two: https://docs.flutter.dev/cookbook/networking/background-parsing https://docs.flutter.dev/packages-and-plugins/background-processes

But they are not cross-linked, and it's not clear when to just use isolates, and when to use the lower-level mechanisms from Ben's post.

I think there's some confusion here because the word "background" is being used to mean two completely different things on those pages. The first is about doing work that's not on the main thread. The second is referring to the mobile app state of being in the background, meaning your app isn't active and usually not running.

Maybe the two pages just need to do a better job clarifying terms?

(I see that https://github.com/flutter/website/issues/3104 asks for basically making the latter easy to understand and use for someone who doesn't know iOS, which unfortunately is probably impossible because Apple very deliberately makes it impossible to do any kind of generic "just run things while backgrounded", and instead requires using narrow, special-purpose APIs for specific use cases, because they don't want unfettered access to running in the background.)

[mit-mit]

+1 (explaining "work not on the main thread" vs "mobile app being in the background" is what I meant by clarifying "when to use what")

[navaronbracke]

Regarding the background processes documentation that is currently on that page: I recently looked up information for said "background processes", which led me to this exact page.

Since the page itself does not go very in depth on it, I had a look at the Medium article and the sample code for the plugin there.

After quite some reading, I came to the conclusion that the original documentation should perhaps explain the steps needed to setup a background Flutter Engine that runs a vm:entry-point with user code.

This roughly translates to

1) Create a callback handle in Dart (top-level or static method)

• important is the @vm:entry-point 2) Save the callback handle (i.e. using shared preferences), for using it later
• this involves calling a regular MethodChannel method, which just saves the handle on the native side (i.e the initialize method in the example)
• usually this is done in void main() {} 3) On the native side, retrieve the callback handle when needed (i.e. in a background service) 4) Use the callback handle to start a new FlutterEngine, that executes the Dart entrypoint that was created in step 1
• Do not forget to clean up the FlutterEngine

It would be nice to see these steps in a codelab of sorts?