My app communicates with its companion app (iOS or watchOS) using sendMessage(message:replyHandler:errorHandler:).
My understanding is that after calling this function, one has to wait until it is finished, i.e. until either replyHandler or errorHandler is called, before sendMessage can be called again.
In my case, sendMessage can be called by multiple asynchronous events. Thus, the calls have to be queued while an ongoing sendMessage has not been finished yet, and the oldest call each has to be dequeued when a sendMessage finishes.
I can imagine to set up a class storing the function parameters (message, replyHandler and errorHandler) as properties, and to define a fifo queue with such objects as elements, so that every time replyHandler or errorHandler is called, an object is dequeued and executed as sendMessage.
However, this seems a bit awkward to me. Is there an easier way to handle the problem?
EDIT:
Maybe such queueing is done automatically by WatchKit? I cannot find anything in the docs.
I run several test that called sendMessage(message:replyHandler:errorHandler:) before replyHandler was called, and everything worked correctly, i.e. when I stopped sending messages, the remaining replyHandlers were called.
So obviously sendMessage calls are queued internally, and one does not have to care about it.