In this entry we’re going to focus on building Apple Watch apps that can communicate back and forth with the host application running on the iPhone. This is extremely important since the Apple Watch provides a second screen/peripheral complimentary experience to the main app running on the iOS device – be it a remote control, or quick view/glance into whats happening within the bigger picture.
In my last post I showed how to setup remote logging and instrumentation/analytics in an Apple Watch app using IBM MobileFirst Platform Foundation server. I used the methods described below for communicating between the WatchKit and host apps in the sample app from that previous post.
When we’re talking about bidirectional communication, we’re talking about sending data two ways:
- Sending data from the host app to the WatchKit app
- Sending data to the WatchKit app from the host app
At first thought, you might think “oh that’s easy, just use NSNotificationCenter to communicate between the separate classes of the application”, but things aren’t exactly that simple.
An Apple Watch app is really made of 3 parts: 1) the main iOS application binary, 2) the user interface on the Apple Watch, and 3) the WatchKit extension binary (on the iOS device).
Yep, you read that correctly, the WatchKit extension (which controls all of the logic inside the Apple Watch UI and resides on the iOS device) is a separate binary from the “main” iOS application binary. These are separate processes, so objects in memory in the main app are not the same objects in memory in the extension, and as a result, these processes do not communicate directly. NSNotificationCenter isn’t going to work.
However there are definitely ways you can make this type of a scenario work.
First, WatchKit has methods to invoke actions on the host application from the WatchKit extension. WatchKit’s openParentApplication or handleWatchKitExtensionRequest methods both provide the ability to invoke actions and pass data in the containing app, and provide a mechanism to invoke a “reply” code block back in the WatchKit extension after the code in the host application has been completed.
For example, in the WatchKit extension, this will invoke an action in the host application and handle the reply:
[objc][WKInterfaceController openParentApplication:@{@"action":@"toggleStatus"} reply:^(NSDictionary *replyInfo, NSError *error) {
[logger trace:@"toggleStatus reply"];
[self updateUIFromHost:replyInfo];
}];[/objc]
Inside the host application we have access to the userInfo NSDictionary that was passed, and we can respond to it accordingly. For example, in the code below I am setting a string value on the userInfo instance, and taking appropriate actions based upon the value of that string.
[objc]- (void)application:(UIApplication *)application
handleWatchKitExtensionRequest:(NSDictionary *)userInfo
reply:(void (^)(NSDictionary *replyInfo))reply {
//handle this as a background task
__block UIBackgroundTaskIdentifier watchKitHandler;
watchKitHandler = [[UIApplication sharedApplication] beginBackgroundTaskWithName:@"backgroundTask"
expirationHandler:^{
watchKitHandler = UIBackgroundTaskInvalid;
}];
NSString *action = (NSString*) [userInfo valueForKey:@"action"];
[logger trace:@"incoming request from WatchKit: ", action];
LocationManager * locationManager = [LocationManager sharedInstance];
NSMutableDictionary *result = [[NSMutableDictionary alloc] init];
if ([action isEqualToString:@"toggleStatus"]) {
//toggle whether or not we’re actually tracking the location
[locationManager toggleTracking];
} else if ([action isEqualToString:@"stopTracking"]) {
[locationManager stopTracking];
} else if ([action isEqualToString:@"currentStatus"]) {
//do nothing for now
}
NSString *trackingString = [NSString stringWithFormat:@"%s", locationManager.trackingActive ? "true" : "false"];
[result setValue:trackingString forKey:@"tracking"];
reply(result);
dispatch_after( dispatch_time( DISPATCH_TIME_NOW, (int64_t)NSEC_PER_SEC * 1 ), dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0 ), ^{
[[UIApplication sharedApplication] endBackgroundTask:watchKitHandler];
} );
}[/objc]
This covers the “pull” scenario, and is great if you want to invoke actions within your host app from your WatchKit extension, and then handle the responses back in the WatchKit extension to update your Apple Watch UI accordingly.
What about the “push” scenario? The previous scenario only covers requests that originate inside the WatchKit extension. What happens if you have a process running inside of your host app, and have updates that you want to push to the WatchKit extension without an originating request?
There is no shared memory, and it is not a shared process, so neither NSNotificationCenter or direct method invocation will work. However, you *can* use Darwin notifications (which work across seprate processes by using CFNotificationCenter). This enables near-realtime interactions across processes, and you can share data as attributes of a CFdictionary object based between processes. You can also share larger amounts of data using access groups, and notify the separate processes using the CFNotificationCenter implementation.
Note: CFNotificationCenter is C syntax, not Objective-C syntax.
First you’ll need to subscribe for the notifications in the WatchKitExtension. Pay attention to the static id instance “staticSelf”… you’ll need this later when invoking Objective-C methods from the C notification callback.
[objc]static id staticSelf;
– (void)awakeWithContext:(id)context {
[super awakeWithContext:context];
//add your initialization stuff here
CFNotificationCenterAddObserver(CFNotificationCenterGetDarwinNotifyCenter(), (__bridge const void *)(self), didReceiveTrackingStatusNotificaiton, CFSTR("TrackingStatusUpdate"), NULL, CFNotificationSuspensionBehaviorDrop);
staticSelf = self;
}[/objc]
From within your host app you can invoke CFNotificationCenterPostNotification to invoke the Darwin Notification.
[objc]-(void) postTrackingStatusNotificationToWatchKit {
NSString *trackingString = [NSString stringWithFormat:@"%s", self.trackingActive ? "true" : "false"];
NSDictionary *payload = @{@"tracking":trackingString};
CFDictionaryRef cfPayload = (__bridge CFDictionaryRef)payload;
CFNotificationCenterPostNotification(CFNotificationCenterGetDarwinNotifyCenter(), CFSTR("TrackingStatusUpdate"), (__bridge const void *)(self), cfPayload, TRUE);
}[/objc]
Then in the WatchKit extension, handle the notification, and update your WatchKit extension accordingly.
[objc]void didReceiveTrackingStatusNotificaiton() {
[staticSelf respondToPostFromHostApp];
}[/objc]
We’ve now covered scenarios where you you can request data or actions in the host application *from* the WatchKit extension, and also how you can push data from the host application to the WatchKit extension.
Now, what if there was a library that encapsulated some of this, and made it even easier for the developer? When I wrote the app in my previous post, I used the methods described above. However, I recently stumbled across the open source MMWormhole, which wraps the Darwin Notifications method (above) for ease of use. I’m pretty sure I’ll be using this in my next WatchKit app.
Helpful Links for inter-process communication between WatchKit and host apps:
- Big Nerd Ranch on Communication with the Parent Application
- WMWormhole for communication between Apps and Extensions
- StackOverflow thread on pushing data to the WatchKit Extension
Series on Apple WatchKit Apps powered by IBM MobileFirst:
- Part 1: Powering Apple Watch Apps with IBM MobileFirst
- Part 2: Bidirectional Communication Between An Apple Watch and the Host App (this post)
- Part 3: Serving Data to the Apple Watch with IBM MobileFirst