Breaking: Asynchronous message sending with `async`(iOS 13 required) #527

philips77 · 2023-06-22T09:27:46Z

This PR is the second attempt after #526 to implement async methods for sending messages to the mesh network.

This time message types were left alone, so the send(...) methods return generic MeshResponse or ConfigResponse types and user has to cast manually.

Apart from that:

Minimum iOS version was set to 13.0 to support async/await.
Minimum Swift version is 5.5.
Messages are sent using a Task instead of DispatchQueue. The queue param in the MeshNetworkManager.init is now deprecated and unused.
Callback-based send(..) methods use the async methods under the hood.
It is possible to cancel sending a method using Task.cancel(), but the callback-based methods still return MessageHandle as they used to.

I did not migrate NetworkManager to be an actor. That will have to wait.

…ng iOS 13 as minimum version

eanderlind · 2023-06-22T19:11:39Z

A few higher-level comments to complement forthcoming in-file ones:

Would be great to have async versions of MeshNetworkManager.send() etc. Only needed for the versions that have Sendable parameters (ie no class objects as parameters). Instead of passing Element, use Element.index or the element's address. Similarly for ApplicationKey can pass in AppKeyidx.
Consider providing async and existing APIs in parallel to permit developers to gradually transition an implementation (or at least convert one part at a time, building and testing as go along).
If use continuation under the hood for an async call, any errors reported by the callback should be converted to throws
When wrapping a call in a Task, consider following syntax from Swift guide:

let handle = Task {
    return await add(newPhoto, toGalleryNamed: "Spring Adventures")
}
if foo { handle.cancel }  //my add
let result = await handle.value

I don't think the current MeshHandle.cancel() method will do the job correctly for an async Task.
5. TBD whether run task on current actor (Task {}), detached (Task.detached {}) or with TaskGroup. Suggest start simple, do some tests to see performance and whether propagating task cancellation is needed ,and update in a future pull request.

eanderlind

See summary in immediately preceding comment.

Example/Source/View Controllers/Network/Configuration/ModelViewController.swift

eanderlind · 2023-06-22T19:43:52Z

nRFMeshProvision/Layers/NetworkManager.swift

@@ -182,25 +182,29 @@ internal class NetworkManager {
    ///   - initialTtl:     The initial TTL (Time To Live) value of the message.
    ///                     If `nil`, the default Node TTL will be used.
    ///   - applicationKey: The Application Key to sign the message.


Should document under what conditions the method throws

nRFMeshProvision/Layers/NetworkManager.swift

eanderlind · 2023-06-22T20:08:52Z

nRFMeshProvision/Layers/NetworkManager.swift

+
+private extension NetworkManager {
+
+    func setDeliveryCallback(for destination: Address,


These apis assume there is a single callback per destination. May need similar approach as in NetworkConnection where there is a stack of delegates.

The limit per single callback per destination comes from the mesh spec. A Node can send only one message to a single destination address at a time.

I wasn't clear in my comment. There can be >1 listener in App (UI plus e.g. the executeNow() function in ConfigurationViewController if permitted to continue executing after user navigates away, or some logging function) When add SwiftUI it is way easier if UIkit ViewControllers continue to pass delegate to each other and add a 2nd (model controller) listener for when a SwiftUI view is responsible for presenting errors to end-user.

eanderlind · 2023-06-22T20:17:44Z

nRFMeshProvision/Layers/NetworkManager.swift

+        }
+    }
+
+    func setResponseCallback(for request: AcknowledgedMeshMessage,


Difficult to predict/derive the response source address(es) when sending to a Group address. Only approach we have found to work is matching opcodes and all the msg parameters.

When an acknowledged message is sent to a Group address the callback will not await for responses (as 0+ of such is equally expected), but rather will be called upon delivery (that is when the request is sent).
The response callback is only send for acknowledged messages sent to a Unicast Address.

ok - I didn't realize that is what these functions were for. Thought it was some new capability for App to listen in to what is happening...

eanderlind · 2023-06-22T20:46:14Z