503: Service Unavailable
503: Service Unavailable
访问太频繁了，服务器要炸。Apple Watch开发的一些细节和总结
这篇文章旨在总结一下最近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。然后点击视图左下角的刷新按钮，刷新证书，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 & Deies 就可以查看。
2、WatchKit app的特殊导航类型
按照导航形式和风格分为两种
1）分层风格（push/pop、Present和iphone上的导航风格一样）
2）分页风格（presentControllerWithNames、becomeCurrentPage）
具体的视图切换、页面的跳转API
- (void)pushControllerWithName:(NSString *)name context:(id)context
- (void)popC
- (void)popToRootC
- (void)presentControllerWithName:(NSString *)name context:(id)
- (void)presentControllerWithNames:(NSArray *)names contexts:(NSArray *)
- (void)dismissC
- (void)becomeCurrentP
需要注意的是使用以上这一组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&按钮，点击后当前的这组视图将Dismiss掉，返回上一层视图。但是如果我在当前这组分页视图中再present出一个模态视图，然后返回，会发现原先这组分页视图左上角上面的返回&cancel&按钮消失了，也就无法返回到上一层了。貌似在这些视图中调用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))
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 *))
需要注意的是主应用每次执行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);
这样就完成了一次 watchkit extension 与主应用之间的数据通信了。watchkit extension中的输出打印是：
say: Hello World!
即 watchkit extension 通过请求获得主应用传送过来的数据了。
另外一种通信方法就是我们熟知的应用中，主应用与extension通过App Group来进行数据共享通信。