本文旨在总结最近Watch在发展中遇到的问题和细节
1、左右Watch真机调试问题
一般的情况下，你为IOS主应用创建了一个extention，比方说Today Extension 。Xcode都会自己主动帮你生成该extention的appid，然后生成相应的Provisioning Profile。然后在Targets-->Build Settings-->Code Signing 里选择相应的Provisioning Profile。勾选相应的keychain就能够run了。
假设你为你的项目创建了AppleWatch。那么就会在原项目中新增了 watchkit extension 和 watchkit app 两个target。那么你须要在苹果开发人员中心为watchkit extension 和 watchkit app 分别创建正确的bundle identifier。
而为watchkit这两个扩展新建的bundle identifier都是从主应用的bundle identifier进行扩展的，这种命名规则必须遵守。
假如你的主应用bundle identifier是com.jaybin.myapp。那么watchkit extension的bundle identifier就必须为com.jaybin.myapp.watchkitextension。
watchkitapp的bundle identifier就必须为com.jaybin.myapp.watchkitapp。由于在 iOS 系统上。app 本体是核心。全部的执行实体都是依托在本体上的。
到这里你就能够为watchkit这两个target相应的appid创建相应的Provisioning Profile。加上主应用的话，一共须要6个ProvisioningProfiles。3个 development Profiles,3 个 archiving/store Profiles。
最后一步就是将证书部署到Xcode项目中执行或者打包。首先依照以下操作 Xcode >Preferences > Accounts > YOUR_ACCOUNT > View Details 。
能够看到该账号下的全部证书，随便选中当中的一个Profiles，选择在Finder打开。然后将该目录下的全部证书删除。这样能够清空原先的无效Profiles。然后点击视图左下角的刷新button，刷新证书，Xcode会将最新的证书download下来，包含刚才创建的新Profiles。
最后确保项目中的target。主target和watchkit target都选择关联上了正确的team。然后选择相应正确的Provisioning Profiles（普通情况下Provisioning Profiles选择automaic就能够run了）。只是奇怪的是。我仅仅对watchkit extention创建了相应的appid和profile 就能够run了。预计是Xcode 自己主动帮我们把Watchkit app 的Provisioning Profile设置好了。
别忘了在执行之前先clean项目。由于Xcode有时候会缓存旧的profile和设置。
最后提醒一下，AppleWatch的开发/真机调试和iphone是一样。也须要在开发人员中心中的账号下加入开发測试设备。
否则就会 “提示错误：应用验证失败”
查看AppleWatch的UDID和查看iphone设备的一样，假设watch和iphone已经配对成功的话，在查看iphone的UDID页面下方就能查看到watch的UDID。在Xcode下的 Window > Deivces 就能够查看。
2、WatchKit app的特殊导航类型
依照导航形式和风格分为两种
1）分层风格（push/pop、Present和iphone上的导航风格一样）
2）分页风格（presentControllerWithNames、becomeCurrentPage）
详细的视图切换、页面的跳转API
- (void)pushControllerWithName:(NSString *)name context:(id)context
- (void)popController;
- (void)popToRootController;
- (void)presentControllerWithName:(NSString *)name context:(id)context;
- (void)presentControllerWithNames:(NSArray *)names contexts:(NSArray *)contexts;
- (void)dismissController;
- (void)becomeCurrentPage;
须要注意的是使用以上这一组API进行视图切换与跳转时，Push和Present方法第一个參数是相应的在Storyboard中为WKInterfaceController设置的identifier字符串。
当然对于WatchKitApp，是能够在Storyboard里建立多个InterfaceController并像在iOS应用一样直观的画出视图转换连接的，能够通过视图控制器代码实现对应视图切换与跳转。直接在Storyboard中设置Triggered Segues。
使用Segues时。Selection相同支持Push和Model两种跳转方式。
关于分页导航。我们也能够在Storyboard里按住control从视图A拖到视图B选择next page能够建立此关系。
关于WatchKitapp的导航最值得关注的就是分页导航（Page-based）与分层导航（Stack）模式的混用。由于在视图的切换与跳转中，为了方便与用户的交互我们经常须要多种导航方式混用。
可是分页导航与分层导航是相互排斥的，因此必须使用模态方式（Present）进行切换。
比方主控制器为分页视图时（页面导航用Page-based）。要正确弹出一个分级视图栈能够用presentControllerWithName:conext:方法，而主控制器为分级视图时。要正确弹出单页视图，也用presentControllerWithName:conext:。
假设想弹出多个页面组成的分页视图，我们能够present一组Controller, 这一组Controller将以page control的形式展示。这时须要改为用presentControllerWithNames:contexts:。只是这样有一个问题，假设我在一个分级视图中present一组Controller，即当前展现的视图以page control的形式展示。
对于这组分页视图而言，全部视图的左上角都会默认自带一个返回的“cancel”button，点击后当前的这组视图将Dismiss掉。返回上一层视图。
可是假设我在当前这组分页视图中再present出一个模态视图，然后返回。会发现原先这组分页视图左上角上面的返回“cancel”button消失了，也就无法返回到上一层了。
貌似在这些视图中调用dismissController也不起作用。
所以，对于presentControllerWithNames:contexts:，假设present出一组Controller后，在这组Controller视图中就不要再present出模态视图。否则这组分页视图将无法返回到上一级页面。
只是关于分页视图，另一个非常好用的方法。reloadRootControllersWithNames:contexts: 当app启动时，假设想以分页界面的形式展现视图控制器，即用户能够左右滑动切换视图。那么我们就能够在初始界面控制器的init方法中调用reloadRootControllersWithNames:contexts:方法。这样的情况，我们一般会在storyboard文件里配置一组初始的页面集合。
当app启动时，WatchKit会实例化和初始化第一个展示的页面，即初始界面控制器（MainInterfaceController）。然后是分页界面中的其它界面控制器。也就是说当系统载入WatchKit app界面时。它将一下子实例化和初始化组成界面的全部界面控制器。
当用户从一个界面控制器切换至下一个时，它将调用当前界面控制器的didDeactivate方法。以及即将展示的界面控制器的willActivate方法。willActivate方法可确保界面中的信息是最新的。当然我们也能够在app执行时在willActivate方法中调用该方法。
3、关于Watch与Iphone主应用的数据通信
假设在watchkit extension中进行数据的申请。比方网络调用。这样就会造成无法复用项目中已有的代码，会写出非常多反复的代码。性能上优化的空间不大。 所以假设Apple Watch应用须要执行长时间执行在后台的任务，比方网络调用。这时应该让iPhone端的主应用来做这个工作。
1）使用WKInterfaceController中的openParentApplication:reply:方法在后台唤醒iPhone端主应用，由主应用去进行网络数据的处理，处理完毕后再返回WatchKit扩展所需的数据。
watchkit extension发送请求唤醒主应用：
+(BOOL)openParentApplication:(NSDictionary *)userInfo reply:
(void(^)(NSDictionary*replyInfo, NSError *error)) reply;
watchkit extension中，详细Demo例如以下：
//watchkit extension 向主应用发送请求，唤醒主应用
NSMutableDictionary *userInfo = [NSMutableDictionary dictionary];
[userInfo setObject:@"say something" forKey:@"openType"];
[WKInterfaceController openParentApplication:userInfo reply:^(NSDictionary *replyInfo, NSError *error){
//主应用处理完后的回调，返回extension所需的数据
NSString *words = [replyInfo objectForKey:@"words"];
NSLog(@"say: %@",words);
}];
2）主应用处理WatchKit请求的方法，UIApplicationDelegate方法：
-(void)application:(UIApplication*)application
handleWatchKitExtensionRequest:(NSDictionary*)userInfo reply:(void (^)(NSDictionary *))reply;
须要注意的是主应用每次运行UIApplicationDelegate方法，处理完毕WatchKit的请求后都要回调reply(replyInfo);否则这种方法会响应失败。
主应用中，详细Demo例如以下：
//主应用处理来自watchkit extension的请求
- (void)application:(UIApplication *)application handleWatchKitExtensionRequest:(NSDictionary *)userInfo reply:(void(^)(NSDictionary *replyInfo))reply{
if(userInfo){
NSString *openValue = [userInfo objectForKey:@"openType"];
if(openValue && [@"say something" isEqualToString:openValue]){
NSMutableDictionary *replyInfo = [NSMutableDictionary dictionary];
[replyInfo setObject:@"Hello World!" forKey:@"words"];
//主应用处理完毕后。回调来自watchkit extension的 reply(replyInfo)，否则方法响应失败
reply(replyInfo);
}
}
}
say: Hello World!
即 watchkit extension 通过请求获得主应用传送过来的数据了。
第二种通信方法就是我们熟知的IOS应用中，主应用与extension通过App Group来进行数据共享通信。
版权声明：本文博主原创文章。博客，未经同意不得转载。