Breaking changes compromises this plugin with flutter 3.29+

[srmncnk]

Flutter introduced flutter/flutter#150525 with version 3.29.

This means that Dart code is executed in the same thread as the platform channel (Java/Kotlin/Swift/ObjC code).

But implicitly this is true for all instances of FlutterEngine. For this plugin, which utilizes another FlutterEngine to spawn long living backgroud task in a foreground service, this means that the core functionality is compromised - running a new ForegroundTask will make it run in the same thread as the main Isolate, causing potential delays and stutters to ui, if anyone is doing any heavy lifting in the background (which is likely the main purpose of this plugin).

More details of this are being discussed flutter/flutter#169339 and in the upper issue. Currently the workaround is to opt-in to two flags - DisableMergedPlatformUIThread (and possibly EnablePlatformIsolates?). This will restore the previous state and FlutterEngine will continue to work as before - but these flags are bound to be deprecated at some point, at which this plugin will be potentially compromised and not have a workaround anymore.

[thorito]

Any progress on this issue?

[srmncnk]

@Dev-hwang @thorito If anybody is at FlutterCon Berlin ATM, feel free to ping me for a chat.

[bcliang]

@srmncnk @thorito with DisableMergedPlatformUIThread now removed, what did your teams decide to do? Our use case is real-time sensor data processing (data received over BLE), where the BLE comm is all handled within the foreground task. For now, we've pinned our flutter sdk to version 3.35.7

[srmncnk]

@bcliang We did not update yet. Waiting for the dart team as they promised to implement isolate thread pinning: dart-lang/sdk#46943
What would semi-solve our problems, but we'd still need to refactor a lot of code, unfortunatelly.

FWIW - are you using BLE via FFI / JNIgen? If not (if you're still using platform channels), then you still tap into the platform thread, regardless from where the Dart call comes from.

[bcliang]

Thanks. Having that dedicatedThread parameter seems like it would solve our issue.

Also, thank you for highlighting the bit about BLE in the platform thread. We started with low level calls but in recent updates had migrated to using flutter_blue_plus, which does use a platform channels implementation. Still, I think we need to stick with a a separate isolate to handle the more expensive signal processing tasks

[ppamorim]

@srmncnk @bcliang I wrote this document alongside a initial implementation in my fork. Would be this a way to solve that issue in the original repository too?

You can check the whole change proposal too if you find it interesting here.

[srmncnk]

I only read the TL;DR (one my way to a trail run right now), but my immediate feedback would be this:

• you can still spawn a new flutter engine and immediately spawn a pure dart isolate
• that will guarantee continouius execution
• it will guarantee a different thread that the one from ui
• it will not be always the same thread (still waiting for the drt team pr to land)
• callbacks wont work but can be achieved via hacking the ffi api
• IMO separate flutterenginegroup does not help

[ppamorim]

I only read the TL;DR (one my way to a trail run right now), but my immediate feedback would be this:

• you can still spawn a new flutter engine and immediately spawn a pure dart isolate
• that will guarantee continouius execution
• it will guarantee a different thread that the one from ui
• it will not be always the same thread (still waiting for the drt team pr to land)
• callbacks wont work but can be achieved via hacking the ffi api
• IMO separate flutterenginegroup does not help

Thank you for the feedback, I will review that soon.

I implemented a solution that hacks the ffi for the callbacks, it's in the list of issues reported.

[srmncnk]

@ppamorim Did you use NativeCallable? https://api.dart.dev/dart-ffi/NativeCallable/NativeCallable.listener.html

[ppamorim]

@srmncnk Updated the implementation with NativeCallable. Please note this implementation is just me testing waters for a final solution, I am totally open to change if you have a better suggestion that would solve this with less code.

Thank you for the feedback.

[srmncnk]

@ppamorim If it works, it's a viable alternative - that is, if you're conformable not having a dedicated thread. Personally I am still waiting for dart thread pinning to be done.

[ppamorim]

@ppamorim If it works, it's a viable alternative - that is, if you're conformable not having a dedicated thread. Personally I am still waiting for dart thread pinning to be done.

I am pretty much waiting for that too, we might need to keep the suggested implementation for those apps that aren't on the minimum version that will add support to dart thread pinning. Would reporting my analysis and suggestion to the dart team so they can use as context for their implementation?

[srmncnk]

@ppamorim I'd say that making noise on all the relevant issues would help. Probably not a lot, but worth a try.