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。然后点击视图左下角的刷新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);
        }
    }
    
    
}

这样就完毕了一次 watchkit extension 与主应用之间的数据通信了。watchkit extension中的输出打印是：

say: Hello World!

即 watchkit extension 通过请求获得主应用传送过来的数据了。

 

第二种通信方法就是我们熟知的IOS应用中，主应用与extension通过App Group来进行数据共享通信。

 

版权声明：本文博主原创文章。博客，未经同意不得转载。