The two background delivery methods (transferFile, transferUserInfo) usually stop working on watchOS 2.2 and only a watch restart helps to get them work again. After restarting, they work for a while the way they always should, then stop working again... Other methods (sendMessage, sendMessageData) are ok.
There was not any problems like this on watchOS 2.1.
Has anyone experienced this? Any workoaround?
Thank you for the radar. I've routed it to the right engineers to take a look.
Thanks @viking. Unfortunatelly my bug report was closed because it is a duplicate of another one, which I cannot see. It says:
Can you help me figure out the resolution? Im still experiencing the same issue in watchOS 2.2.2
Thanks!
WatchOS3 beta 3 session connectivity works for first wkinterfacecontroller/session. Establish another session for next wkinterfacecontroller (worked in watchOS2, is this correct?) that also contains
- (void)session:(WCSession *)session activationDidCompleteWithState:(WCSessionActivationState)activationState error:(nullable NSError *)error
but this session is never active.
having your WKInterfaceController's be the WCSession delegate is a bit of an anti-pattern, but if you do choose to persist with that approach you should only expect to have to activate the session once, and therefore only one of the WCSession delegate's should expect the session:activationDidCompleteWithState:error: callback
Hi viking, our design is to have each WKInterfaceController execute a sendMessage to retrieve data 'just in time' as it is needed for each UI. We can remove session activations, after the first one. Will session.delegate = self in each WKInterfaceController suffice to obtain the callback? We do our heavy lifting in session:didReceiveApplicationContext and not session:activationDidCompleteWithState:error:.
yes, that is correct though is not a great pattern as that means every interface controller is doing "model" and "networking" work. These tasks would be handled better by isolated compontents such as a persistance manager and communication manager". This way your app can take easily advantage of background runtime to improve the responsiveness of your application.
Also, if you are doing some sort of "request -- response" kind of pattern, it seems "sendMessage with a replyHandler" would be more suitable than "sendMessage and reply using applicationContext", as you then wouldn't even have to change the WCSession delegate.
OMG I feel so frustrated. I have wasted whole day trying to figure out this crap. Having implemented today extension for the app, my first reaction was, why is this different?! It is the same app group, why can't it just share files.
OK FINE, I'll do it with your fancy WatchConnectivity. Well, not so fast. Seems to work perfectly fine on simulator, try it on devices(the watch debugger is pathetic), nothing works! Send over a userInfo; simulator fine, device sending empty dictionary. Same code, no changes. Just magic.
Did you ever build any of your app using this, or did you just slap a framework together and rolled with it? I see countless posts people having trouble with this stuff and WatchOS isn't even that popular.
Unfortunately iOS extensions aren't able to use WatchConnectivity, only the iOS app and the WatchKit extension can. So in this case you'll have to have your today extension communicate with the iOS app via the regular paths (shared container, etc) and then have the iOS app "forward" that information on to the WatchKit extension using WatchConnectivity.
Awesome! At least I have a clue now.
So since I have been sending notifications to update my data and because it's been coming through NotificationServiceExtension, that can't talk to WatchConnectivity either, I suppose. Well that doesn't complicate things at all :/. I see why you would design it this way, but when my own (1) app can't talk to it's own parts, it becomes a bit of a hassle, don't you think?
Also it would be magnificent if we could debug all these extensions in one run. I mean they're all connected anyway when you run the app, why can't the console logs and breakpoints be connected across the codebase?
The best way to make sure the right teams at Apple know of your suggestions and the problems they would solve for you is to file an enhancement request!
