0

I've been reading through the documentation on the WatchKit connectivity framework to try and figure out if I can delegate all of the intensive processing needs over to my parent iOS app. All of the code already exists in the parent app for doing the required processing and it seems significantly more efficient for it to do so, rather than the Apple Watch app duplicating the code and attempting it itself.

My question is whether this is possible if the app on the iOS device isn't active at the time the watch kit app makes the request? Will it just queue up the request until it's next opened or can it be configured to process it immediately? I would want the watch to always get some form of response or have a timeout on the request.

UPDATE:

I found that my particular issue was related to calling the reply handler from a background thread after executing a separate request. When I was doing this I didn't get a response back from the iOS device to the apple watch. This initially made me think the iOS device was ignoring the requests until it was active.

The solution for me was to do the following so that the reply handler is always called from the main thread. This seems to be a critical piece of the communication that I must have missed out in the documentation (or maybe it was missing :o). Long story, short, after making the update shown below I successfully got responses back every time.

dispatch_async(dispatch_get_main_queue(), { () -> Void in
    replyHandler(myResponse) // Always call from main thread!
})
  • Yes, it's possible with `sendMessage`. *"Calling this method from your WatchKit extension while it is active and running wakes up the corresponding iOS app in the background and makes it reachable."* If you need specific help, you should post a [mcve] along with a description of the problem. –  Mar 23 '16 at 12:58

1 Answers1

1

WCSession's sendMessage APIs enable the WatchKit extension to wake the iOS app up in the background as long as reachable is true. Here is a nice step-by-step tutorial on using sendMessage.

ccjensen
  • 4,578
  • 2
  • 23
  • 25
  • Thanks for confirming. I realised the issue I was facing was related to the iOS device calling the reply handler on a background thread (after executing a separate request in the background). I updated the reply handler so that its always called on the main thread and this seems to have resolved the issue. –  Mar 25 '16 at 11:35