- Watch and iPhone display reachability on the fly
- Watch initiates a sensor record operation
- Now, when a dequeue operation is enabled:
- Watch sends the dequeue switch command to iPhone
- iPhone starts a timer
- iPhone replies to the Watch that it completed this operation (as part of a diagnostic)
- When timer fires on iPhone:
- iPhone sends message to Watch asking for next batch of sensor data
- Watch fetches up to one 'batch' of data and returns it to iPhone
- iPhone displays some basic data about the return packet
- Watch keeps track of how many timer commands it receives
- iPhone keeps track of how many timer attempts it tries
This exercise is primarily using the sendMessage() method which only works when the application is live on both sides. But with a bit of careful execution, data flow is illustrated. Features and problems with this approach:
- Reachability is (regardless of the reachable state):
- whether the two devices can communicate
- whether the iPhone application is in focus (for Watch)
- whether the Watch application is in focus (for iPhone)
- The watch can not launch the iPhone application with this approach. Similarly, fetch requests from the phone will not be delivered if the Watch isn't actively running the application
- Also, there is a sequence where system state is incorrect:
- start Watch app (do not start iPhone app)
- note that the state is reachable (this is the problem)
- enable the dequeue (notice that delivery is stuck in sending...)
- In general, the reachability support works ok, it is possible for the Watch to go in and out of range, either device to go into airplane mode, be rebooted, application killed and restarted, etc. and all continues to work as designed.
Next up will be to work with some of the queued message types and then more importantly to figure out how to launch an iPhone background method.
No comments:
Post a Comment