[pigeon]: Support of modern asynchronous api for Swift and Kotlin #8341

feduke-nukem · 2024-12-23T10:37:56Z

Added support of generating modern asynchronous api for Swift (async) and Kotlin (suspend). New annotation @modernAsync
Added ModernAsync annotation with SwiftModernAsynchronousOptions to specify if method throws

Pre-launch Checklist

If you need help, consider asking for advice on the #hackers-new channel on Discord.

hellohuanlin · 2024-12-23T19:13:07Z

packages/pigeon/example/app/ios/Runner/AppDelegate.swift

@@ -25,6 +25,16 @@ private class PigeonApiImplementation: ExampleHostApi {
    }
    completion(.success(true))
  }
+
+  func sendMessageModernAsync(message: MessageData) async throws -> Bool {


you can just overload the function name func sendMessage(...)

I don't think that I understood.

It's generated Host API code. We could not overload functions in Dart even if we do in Swift

hellohuanlin · 2024-12-23T19:14:27Z

packages/pigeon/example/app/ios/Runner/AppDelegate.swift

@@ -25,6 +25,16 @@ private class PigeonApiImplementation: ExampleHostApi {
    }
    completion(.success(true))
  }
+
+  func sendMessageModernAsync(message: MessageData) async throws -> Bool {
+    try? await Task.sleep(nanoseconds: 2_000_000_000)


is this used for unit test? we shouldn't wait for so long as it slows down the tests

This is used in example app for demonstration purposes

I am not sure if it is used in any tests. I could remove this code if it is necessary

Removed Task.sleep

hellohuanlin · 2024-12-23T19:15:42Z

packages/pigeon/example/app/ios/Runner/Messages.g.swift

+        Task {
+          do {
+            let result = try await api.sendMessageModernAsync(message: messageArg)
+            DispatchQueue.main.async {


you can do Task { @MainActor } here.

you can do Task { @MainActor } here.

Do you mean:

sendMessageModernAsyncChannel.setMessageHandler { message, reply in let args = message as! [Any?] let messageArg = args[0] as! MessageData Task { do { @MainActor let result = try await api.sendMessageModernAsync(message: messageArg) reply(wrapResult(result)) } catch { reply(wrapError(error)) } } }

Will it lead to executing api.sendMessageModernAsync on main thread that could block it?

No, i meant you can replace DispatchQueue.main.async {} with Task { @MainActor}

No, i meant you can replace DispatchQueue.main.async {} with Task { @MainActor}

What's the point/profit?

The purpose of swift concurrency is to replace GCD. So since you are using swift concurrency here, there's no reason to use GCD at all.

GCD

Okay I get it.

I am not very familiar with swift concurrency actually. Is that what you meant?

sendMessageModernAsyncChannel.setMessageHandler { message, reply in let args = message as! [Any?] let messageArg = args[0] as! MessageData Task { do { let result = try await api.sendMessageModernAsync(message: messageArg) await Task { @MainActor in reply(wrapResult(result)) } } catch { await Task { @MainActor in reply(wrapError(error)) } } } }

Maybe we could use MainActor.run instead? I think it is more readable.

sendMessageModernAsyncChannel.setMessageHandler { message, reply in let args = message as! [Any?] let messageArg = args[0] as! MessageData Task { do { let result = try await api.sendMessageModernAsync(message: messageArg) await MainActor.run(){ reply(wrapResult(result)) } } catch { await MainActor.run(){ reply(wrapError(error)) } } } }

In your first chunk of code, don't put await in front of Task.

For this particular case, you can use MainActor.run { ... }, since reply doesn't require an async context.

@hellohuanlin done

hellohuanlin · 2024-12-23T19:18:37Z

packages/pigeon/example/app/ios/Runner/Messages.g.swift

@@ -222,6 +223,30 @@ class ExampleHostApiSetup {
    } else {
      sendMessageChannel.setMessageHandler(nil)
    }
+    let sendMessageModernAsyncChannel = FlutterBasicMessageChannel(


can we just reuse the channel?

can you point me to where this is used? im wondering if you can just use the original channel

What do you mean by "original channel"? Each method of Host API got its own generated FlutterBasicMessageChannel.

This is default Pigeon generated code flow.

Maybe I've misunderstood you.

Maybe i misunderstood how pigeon is used. Just a strawman - can we share the same channel for both old and new ways of doing things?

The way we use channels will not differ at all either "new way" or "old". We just can not use two handlers for one channel at the same time.

Can we have old api to be the wrapper of the new api?

Could you provide code sample of what you mean?

nvm, i misunderstood what this code is doing.

feduke-nukem · 2024-12-24T08:43:04Z

@hellohuanlin @LouiseHsu @tarrinneal CI check fails:

Changed packages: pigeon
[0:00] Running for packages/pigeon...
  No version change.
  Found NEXT; validating next version in the CHANGELOG.
No version change found, but the change to this package could not be verified to be exempt
from version changes according to repository policy.
If this is a false positive, please comment in the PR to explain why the PR
is exempt, and add (or ask your reviewer to add) the "override: no versioning needed" label.

Do I need to bump version in CHANGELOG.md? Currently I append related to pr changes below NEXT label.

hellohuanlin · 2024-12-26T18:55:55Z

packages/pigeon/example/app/ios/Runner/Messages.g.swift

+        let messageArg = args[0] as! MessageData
+        Task {
+          let result = await api.sendMessageModernAsync(message: messageArg)
+          await MainActor.run {


Why doesn't the old version switch thread? Is setMessageHandler's callback guaranteed to be called on main thread?

The old version uses the callback approach that doesn't introduce asynchronous things like task so there was no need to switch to main to reply via channel

Is setMessageHandler's callback guaranteed to be called on main thread?

I guess so as it is platform channel way of communication

Have found implementation where I see dispatch_async(dispatch_get_main_queue()

After marking the func definition as @MainActor discussed here, here we can just do:

Task { @MainActor in let result = await api.send... reply(wrapResult(result)) }

After marking the func definition as @MainActor discussed here, here we can just do:

Task { @MainActor in let result = await api.send... reply(wrapResult(result)) }

No problem it could be easily done.

But could you explain to me how it would work?

If we mark the whole function with @mainactor doesn't that mean that some expensive async/await function call could potentially be called at main?

If we mark the whole function with @mainactor doesn't that mean that some expensive async/await function call could potentially be called at main?

The API contract is that this function will be called on main. The old API is also called on main and this does not change that. Marking it as @MainActor will allow compiler to enforce the implementor of this API to only use API that's safe to be used on main thread. That's one of the benefit of swift concurrency.

An expensive aync/await call inside this function will be called on the thread specified by that call. For example,

@MainActor func sendMessageModernAsync() { let foo = await myActor.getExpensiveFoo() }

Here getExpensiveFoo will be called under the async context of myActor, rather than that of the main actor.

hellohuanlin · 2024-12-26T19:09:15Z

packages/pigeon/example/app/ios/Runner/AppDelegate.swift

@@ -25,6 +25,10 @@ private class PigeonApiImplementation: ExampleHostApi {
    }
    completion(.success(true))
  }
+
+  func sendMessageModernAsync(message: MessageData) async -> Bool {


I just looked at the code again - it looks like the contract of pigeon is that the API (e.g. sendMessage) should be called on main thread. If that's the contract we want to preserve, we should mark the async API as main actor.

@MainActor func sendMessageModernAsync(message: MessageData) async -> Bool {}

The only thing that should be called on the main thread is dispatching messages via channel

https://docs.flutter.dev/platform-integration/platform-channels#jumping-to-the-main-thread-in-ios

If we mark the whole function with @MainActor doesn't that mean that some expensive async/await function call could potentially be called at main?

iiuc both way of communication needs to be on main thread.

The link you add here is calling from platform to dart side. This is the opposite side communication, which needs to be on main as well.

Actually it is the same from the point of dispatching reply via channel, be it call from platform to dart or replying to call from dart

feduke-nukem requested review from hellohuanlin, LouiseHsu and tarrinneal as code owners December 23, 2024 10:37

github-actions bot added p: pigeon platform-android platform-ios platform-linux platform-macos platform-windows labels Dec 23, 2024

feduke-nukem changed the title ~~[pigeon]: added support of modern asynchronous api for Swift and Kotlin~~ [pigeon]: Support of modern asynchronous api for Swift and Kotlin Dec 23, 2024

hellohuanlin reviewed Dec 23, 2024

View reviewed changes

feduke-nukem requested a review from hellohuanlin December 23, 2024 21:22

feduke-nukem force-pushed the issue-123867-async-await branch from fdb7254 to a8df692 Compare December 23, 2024 21:58

added support of modern async api Swift/Kotlin

583d6d7

feduke-nukem force-pushed the issue-123867-async-await branch from a8df692 to 583d6d7 Compare December 23, 2024 22:00

feduke-nukem and others added 3 commits December 24, 2024 10:53

issue(123867): added ability to specify swift throws in modern async

934c5c7

Merge branch 'main' into issue-123867-async-await

8ec409d

issue(123867): fix ci checks

52de826

hellohuanlin reviewed Dec 26, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[pigeon]: Support of modern asynchronous api for Swift and Kotlin #8341

[pigeon]: Support of modern asynchronous api for Swift and Kotlin #8341

feduke-nukem commented Dec 23, 2024 •

edited

Loading

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024 •

edited

Loading

feduke-nukem Dec 24, 2024

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024 •

edited

Loading

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024 •

edited

Loading

hellohuanlin Dec 23, 2024

feduke-nukem Dec 23, 2024 •

edited

Loading

hellohuanlin Dec 23, 2024

feduke-nukem Dec 24, 2024 •

edited

Loading

hellohuanlin Dec 26, 2024

feduke-nukem commented Dec 24, 2024

hellohuanlin Dec 26, 2024

feduke-nukem Dec 26, 2024

feduke-nukem Dec 26, 2024 •

edited

Loading

hellohuanlin Dec 26, 2024

feduke-nukem Dec 26, 2024

hellohuanlin Dec 26, 2024 •

edited

Loading

hellohuanlin Dec 26, 2024

feduke-nukem Dec 26, 2024 •

edited

Loading

hellohuanlin Dec 26, 2024

feduke-nukem Dec 26, 2024

[pigeon]: Support of modern asynchronous api for Swift and Kotlin #8341

Are you sure you want to change the base?

[pigeon]: Support of modern asynchronous api for Swift and Kotlin #8341

Conversation

feduke-nukem commented Dec 23, 2024 • edited Loading

Pre-launch Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem Dec 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem Dec 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem Dec 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem Dec 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem Dec 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem commented Dec 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hellohuanlin Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feduke-nukem commented Dec 23, 2024 •

edited

Loading

feduke-nukem Dec 23, 2024 •

edited

Loading

feduke-nukem Dec 23, 2024 •

edited

Loading

feduke-nukem Dec 23, 2024 •

edited

Loading

feduke-nukem Dec 23, 2024 •

edited

Loading

feduke-nukem Dec 24, 2024 •

edited

Loading

feduke-nukem Dec 26, 2024 •

edited

Loading

hellohuanlin Dec 26, 2024 •

edited

Loading

feduke-nukem Dec 26, 2024 •

edited

Loading