stuartmorgan-g

We'd lose testing that it works with the oldest version we support though. If we want testing of the latest, I would much rather we do it via having two...

For triagers: the current state here is that PR is blocked on https://github.com/flutter/packages/pull/3257#discussion_r1128552963

Triage update: still blocked on someone having time to investigate https://github.com/flutter/packages/pull/3257#discussion_r1128552963 I haven't had time yet, but it's still on the list to dig into how to resolve this (either...

See https://github.com/flutter/packages/pull/3257#discussion_r1528851122 for a suggestion on how to unblock this.

> @stuartmorgan I see that [this PR](https://github.com/flutter/packages/pull/4319) has been split into it's separate platform pieces and is just blocked on merging the iOS changes. Should we go ahead and do...

> this PR needs a large migration. Pigeon is the big one What Pigeon migration does it still need? It looks like you've updated the calls to use Pigeon, and...

> Once this is fully reviewed and approved, we can start landing components, yes. It looks like once the last round of comments from @reidbaker and I are addressed, this...

> If you want to land this without those changes then that's fine with me. Yes, I'm very much in favor of landing as-is; I don't want to saddle this...

> I've created a pr for that at [flutter/engine#39817](https://github.com/flutter/engine/pull/39817) but if that fails, we could possibly create our own `FlutterException` replacement similar to how it's done in the `cpp_generator` What's...

> Is there a reason why the try-catch statement is explicitly ommited for asynchronous methods? Seems to be the case for kotlin as well, compared to the java & cpp...