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个ProvisioningProfiles3个 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 > 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”按钮,点击后当前的这组视图将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)) 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来进行数据共享通信。

 





郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。