对于大多数手机摄影爱好者，面对移动设备中上千张照片，ReKoMe这款软件可谓救星。
ReKoMe来自于此前PingWest报道过的Orbeus团队。他们此前专注于对企业、开发者开放的B2B/B2D服务。ReKoMe运用该团队此前研发的图像内容识别、人脸识别等核心技术，为用户管理手机内相片提供了捷径。
在这款软件中，所有移动设备中的图片不仅以设备自带的时间和地点方式进行了分类，还可以根据图片内容进行定向搜索。比如说，可以在搜索框中查找&车（car）&，所有图片中包含了车的照片都会被整理出来，呈现在搜索框下方。人人都碰上过想给朋友展示自己家花花草草、猫猫狗狗或是某个旅行中拍摄到的好玩的东西，在手机上拼命往回翻却找不到的场景。ReKoMe就是这样的场景的解决方案。
这款手机软件目前已经支持2,000多类事物的识别。初次打开软件时，需要在Wifi环境下，该软件会利用网络，通过云端计算给手机上的本地图片都打上一些标签，并将图片归类到这些标签的文件夹下。每张图片都可以有三至五个标签，所以同一张图片中有多个内容也会被同时存放在不同的关键词文件夹下。Orbeus团队提供的数据指出，目前软件的识别精准度可达到97%。下图以Text（文字）为关键词进行搜索后，就连图片中非刻意拍到的纸张上的文字也能被指认出来。
此前，我们在报道中提到过，针对图像及人类识别类软件，用户比较担心的一个问题是个人隐私的暴露。Orbeus的产品经理玉山向PingWest解释：&在分类过程中，我们不会读取用户的图片内容。我们只需要指甲盖那么点大小的缩略图，就可以识别出图片中事物的轮廓，加以分类。而且，我们会尽可能缩小所需缩略图的尺寸，才能节省带宽，保证计算和传输的速度。在分类完成后，云端的这个数据也会自动删除，绝不会存储用户信息的。&
该团队此前推出的开放给第三方开发者的api，及针对Google Glass开发的api，都表明这是一家针对企业端提供服务的初创公司。团队联合创始人刘天强说，现在该团队已经有近3000个企业级客户，其中包括线上相亲约会网站、安保类公司及汽车厂商等。
视觉识别技术已经有很多公司和团队在进行开发研究&&甚至PayPal和阿里巴巴作为支付类公司，也在研究视觉识别以辅助支付交易的安全性。但刘天强表示市场竞争并不是他们所需要担心的问题：&在视觉识别领域，竞争一直都是有的，不过这个市场并没有饱和。因为这个技术在还没有到完全成熟的情况下，对于很多企业客户而言，是有最好但并非是绝对需要的（good to have but not national needs)。&这是他们作为初创团队在该领域的机会。
通过此前在Api领域的尝试，该团队对于图像的分析数据也积累到一定程度，可以更好地训练和加强处理图像的算法。ReKoMe是他们开发的第一款针对消费端的软件。玉山说：&一来我们在跟用户的沟通中发现，大家都很有这样管理及快速搜索照片的需求。二来是可以通过做一款软件来更容易地demo我们技术的。&
ReKoMe已经于今日上线App Store，该团队表示Android版本的程序也将很快上线，未来还将考虑将移动设备中的视频也纳入管理范畴。
猜你喜欢：
最新图文资讯
站长之家专栏推荐
增值电信业务经营许可证: 闽B2-号 - 北京公安局网监中心备案号: 95号 -
(C)CopyRight 2002- Inc All Rights Reserved. 站长之家 版权所有1177人阅读
app和后端的交互，一般都是通过后端提供的api实现。api的设计，估计很多刚进入app后端的小伙伴会一无头绪，不知道怎么入门。下面根据自己3年的app后端经验，总结出下几个api设计原则，给小伙伴参考。
1. 什么是api？
　　这个问题在以前发表的文章“7.app和app后端的通讯”中其实已经回答了，这里再重复一次。
　　相信大家都用过银行的柜员机(ATM)的查询余额，转帐，取款等操作。
　　当在柜员机取款的时候，我们输入要取款的金额，隔一会钱就出来了，如果因为有什么问题不能取款（例如超过取款金额的限制），屏幕上也会显示出错误的信息。
　　在整个过程中，我们只要输入金额，获得结果（取款成功或不成功），就行了，至于柜员机内部是怎么处理，我们不需要理会。
　　柜员机这种把内部的处理遮蔽的做法极大方便了我们的使用。
　　同样的，在后端，也只提供了一系列的功能给app使用，这系列的功能以api的形式提供。
　　api的定义：API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
　　当app调用api的时候，只需要明确下面３点:
　　1.这个api是干啥的（柜员机例子中，是取款功能，还是查询余额,还是转账）
　　2.知道要输入什么（柜员机例子中，取款要输入金钱）
　　3.知道结果是什么（柜员机例子中，取款是成功还是失败）
　　至于api内部是怎么处理的，app根本无需理会。
　　从这里可看出，api能在最大程度遮蔽了app后端复杂性，极大提高了app前端的开发效率。
2. api设计的8点
　　(1)Restful设计原则
　　Restful风格：RESTfu设计原则,它被Roy Felding提出（在他的”基于网络的软件架构“论文中第五章）。而REST的核心原则是将你的API拆分为逻辑上的资源。这些资源通过http被操作（GET ,POST,PUT,DELETE）。
　　在实际的开发过程中发现，程序员由于在web端养成的习惯，api操作中通常就只有两种方式&POST&&GET&。大家可看一下微博的api例子&statuses/destroy&，这个很明显是delete操作的api却是用post方式提交。不是完全遵守Restful风格的风格。
　　这个设计原则最简单的应用就是根据object而不是页面来设计api。最开始的时候，app的一个页面需要什么数据，api就返回什么数据。结果随着app的UI不断改版，需要的数据不断变化，不停地修改api，最后当api的改动会影响以前的版本的时候，只能写一个新的api版本，最后弄得api中有很多V2,V3这样的标志，恶梦!
　　后来在网站的重构过程中，就根据object来设计api，但根据object来设计，又有一个问题，一个大object可能包含很多小object，是一个api返回全部小object，还是分为多个api返回？根据业务和技术，带宽等仔细考虑吧。
　　(2) api的命名
　　一看api名字就知道这个api是干啥。在创业团队中，一般就只有一两个人负责后台，当你要负责几十甚至上百个api，你就知道不能“望名知api”是个什么样的痛苦。
　　api的命名，我是挺喜欢微博的命名风格，例如删除微博的api &statuses/destroy&，第一个是对象，第二个是对象的操作删除
　　(3)api的安全性
　　这点会在以后的“怎么保证app通讯的安全性”一文中详细论述。
　　(4) api返回数据
　　app客户端的语言 java 和object-c都是强类型语言，所以怎么处理空值显得特别重要，不合理的设计很容易造成app的闪退。
　　从后台的角度来说，api中返回的数据中，正确值和空值的类型必须一样，举例，用户名的字段是“realname&: &xxx”,如果用户名为空，则应该返回“realname&: &&。如果返回值是一个array，空数据则返回一个空array，绝对禁止null值。
　　对于客户端，必须用个全局的函数来处理所有api的返回数据，需要有一个机制：对于某个客户端需要数据，如果api中缺失，客户端自动补上并给予默认值。这个机制在我们的实践中大大减少了app的闪退。
　　同时，在数据库设计的时候，一个合理的设计必须是所有字段都有默认值，不应该允许null值。null在大量的语言和数据库中，会带来无穷的问题。对于这个数据库设计原则，我以前不太明白，现在经历了一年的api设计后，终于懂得。
　　如果客户端是php，还有一个问题，php中数组和字典都是array，但在java 和object-c中是不一样，这个问题一定要注意。
　　(5)图片的处理
　　在不同版本的app中，各种不同尺寸的手机中，同一张图片显示的尺寸可能是不一样，如果每次都需要用返回原图，然后在客户端处理，则极大浪费网络资源。而如果是后台处理好图片才返回，则又是一个挑战，怎么有效保存和裁剪多种图片尺寸呢
　　例如，一开始头像只需要返回60*60的尺寸，后来在新的版本需要返回70*70, 又出了一个新版本，需要返回80*80, 每次增加一个新的尺寸，怎么在数据库上记录下来。这个问题在一开始做api的时候没考虑，后来不得不用了一个极端的方法，没增加新的图片尺寸，就在数据库中增加一个新的字段，保存并生成新的图片尺寸，结果最后数据库的头像字段有&avatar&,&avatar_60_60&,&avatar_70_70&,&avatar_80_80&，这种极度恶虐的设计。
　　最后，针对图片，我们才用了这样的策略：
　　（1）客户端本地缓存图片，只有没有合适的图片，才去服务器取。
　　（2）当客户端需要某种尺寸的图片，由客户端告诉服务端图片的尺寸，服务端动态生成并缓存起来。
　　例如，客户端需要图片（/img/bdlogo.gif）的80*80的尺寸，则在图片的路径加上宽和高的参数（类似于CDN的机制） /img/bdlogo.gif？w=80&h=80， 则服务器就生成80*80的尺寸并返回。
　　采用了这样的图片处理机制，数据库中只要有一个字段保存原图就行了，其它尺寸就由客户端告诉服务端动态生成。以后无论什么尺寸的图片，数据库中都不需要记录，数据库只有原图就行了。
　　注意，现在的文件云存储服务（例如七牛，又拍云）等都提供了这个文件的缩放功能，而且能加速文件的上传下载速度，极大提升了app的用户体验，强烈推荐使用。
　　(6)返回的提示信息
　　最科学的情况，服务端只返回信息代码，具体的文字提示由客户端决定。
　　如果文字信息是由服务端返回，则最起码要区分2种信息：提示用户的信息，提示客户端程序员的信息。这两者的区别：
　　1.提示用户的信息是要在让客户知道的，提示客户端程序员的信息不需要让客户知道的。
　　2. 提示用户的信息文字很友好，客户不需要专业基础一看就知道是什么，提示客户端程序员的信息则很专业，例如告诉客户端少传了哪个参数？哪个参数有问题等等。
　　(7)在线api测试文档
　　我们网站的api在线测试文档，是使用既是一份在线api文档，也是一个在线测试工具，极大方便沟通和测试。每次客户端程序员觉得某个api有什么问题，我们就是这个在线工具上讨论沟通的。客户端程序员最喜欢这个玩意了^-^。
　　这个api在线测试文档，是使用了Swagger-UI搭建的。Swagger-UI简单而一目了然。它能够纯碎的基于html+javascript实现，只要稍微整合一下便能成为方便的API在线测试工具。项目的设计架构中一直提倡使用TDD（测试驱动）原则来开发，swagger-ui在这方面更是能提供很大帮助。
　　下面是用Swagger-UI搭建的api文档中的一个api的例子，可看到，整个api的提交方式，作用，参数都非常清晰明了。
　　当按了“测试”，就以post方式调用这个api，返回的结果如下：
　　所有的返回结果，一目了然，cool！！！
　　api返回的数据，是以json格式返回的。用json格式，最省流量，而且几乎每种计算机语言都支持json格式。用xml的话，太耗费流量了，而且冗余数据多，不适合移动端。
　　在&app后端&的qq群，有个app创始人使用了这个api在线测试文档后赞不决口，称赞虽然前期的搭建需要花一段时间，但极大提高了app前后端工作的效率。以后有小伙伴问相关的问题，他都强烈推荐这个Swagger-UI。
　　(8)在app启动时，调用一个初始化api获取必要的信息
　　通过这个初始化api，获取一下必要的信息，例如，最新的app版本。当发现本地app的版本已经低于最新的app版本，可提示用户更新。当然了，这个提示版本更新的功能很多第三方sdk都提供。
3.如何处理api的版本升级
　　当app做了大改版后，可能会出现一个问题，发现现在的api已经不适了，就考虑到api的升级，同时为了兼容已经发布的app，原来的api必须要保留。为了避免同一个app中调用不同版本的api，一般就会全部升级api的版本，例如:原来的是“/v1/statuses/destroy”，升级为“/v2/statuses/destroy”。
　　在api的版本升级时，需要注意以下2点：
　　1. v2版本的api的controller必须要继承v1版的controller，v2版本的api只重写需要改动的api。
　　2. 在线api测试文档中详细标明返回内容，已作对比，方便客户端人员的调试。
---------------------------------------------------------------------------------------------------------------------------
打开链接 &&总目录 ，能查看本人发表过的所有原创“app后端”文章。
【作者】曾健生
【app后端qq群】&
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi&
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：606791次
积分：8943
积分：8943
排名：第748名
原创：220篇
转载：304篇
评论：248条
本人曾健生，家乡是佛山，现在广州工作，先后开发过社交app&ekeo&&米信&的后端，目前就职于app云后端平台bmob（想了解bmob点击）
“app后端技术” qq群：
如果您觉得这系列的文章对你有所帮助，欢迎打赏。支付宝账号： 收款人：曾健生
文章：39篇
阅读：101590
(3)(10)(12)(4)(6)(1)(15)(6)(2)(3)(3)(1)(15)(6)(7)(12)(7)(12)(4)(5)(6)(4)(2)(3)(9)(9)(19)(3)(6)(10)(20)(7)(4)(43)(50)(15)(26)(36)(38)(21)(11)(7)(14)(1)(1)(2)(2)(7)(5)(1)(1)(8)(11)(8)(7)App适配iPhone 6/ Plus和iOS 8：10条小秘诀
招聘信息：
（原文： 作者：Jack Wu 译者：）过节啦！为庆祝佳节，看看我给这篇文章写的这段极客小诗吧：“Keynote前夜，无人知晓，新API能否登场对Siri的期待，Touch ID的希望而此刻iOS 8应声而出，震惊全场扩展，Swift，Metal，整整一箩筐通用Storyboard，又有谁曾料想一片欢呼声中，有人开始迷惘现有的这些App，适配问题实在惆怅不过不必担心，因为这篇教程会与您讲讲新的API和屏幕尺寸，助你的App焕发容光遵循十条小贴士，豁然开朗iOS 8萌萌哒！嗯……老鸭粉丝汤？”先不管诗写的怎样，言归正传——让你的App适配iOS 8和新设备的十条小贴士——正好赶上节假日！:]准备开始你可能会想&“我在iPhone 6 Plus上把我的App遛了一遍，看起来没啥问题”&。没错，你的App跑起来应该和原来一样，但这并不意味着你可以就此收手！让现有的App在&放大显示模式（Scale Mode）&下运行，这一点Apple已经做得不错了，App单纯地被放大，以此适应更大的屏幕。随便扫一眼，似乎还可以，但你会发现上面的状态栏也变大了。现在你一定想让自己的App在全屏显示模式下运行吧，有图有真相：全屏显示模式让你的App能在相同的屏幕空间内显示更多的信息。注意，状态栏的大小也不一样。在这张图片中，文字可能看起来特别小，但在Retina HD屏幕上看起来刚好合适。现在开始准备适配全屏显示模式，那么问题来了：&要放弃支持iOS 7吗？你总要做出最终抉择，然而这里还有几点值得考虑：iOS 7用户依然能在App Store上获取当前版本。大屏设备（iPhone 6和iPhone 6 Plus）运行系统的最低版本是iOS 8。虽然iOS 8的采用率低于一年前同期的iOS 7，但也已经超过60%。酷炫的新API。:]好，现在你心意已决，接下来我们分三个小节来讲 让你的App适配iPhone 6，iPhone 6 Plus和iOS 8的十条小贴士。注：如果你选择iOS 7为更新的目标系统，你依然可以使用新API。欲知如何在同一个App中支持不同的iOS版本和设备，请参阅。第一小节 – 支持新的屏幕尺寸第1条：选用自适应布局和通用Storyboard如果你的App已经在用Storyboard和Auto Layout，那就省事了，适配工作轻而易举。如果没有，&更待何时？&Size Class&依赖于&Auto Layout 和 通用Storyboard（Universal Storyboard），显然Apple已经清楚表明Storyboard会是将来iOS App的一大中心。而且，没有这个的话最新的SDK WatchKit根本跑不起来。好消息是，如果你还没选用，上有几篇关于Storyboard和Auto Layout的优秀教程。我很中意这几篇：要开始实现自适应布局，第一步就是把现有的Storyboard转换成&通用Storyboard&——一个可以处理任何屏幕大小界面的Storyboard。你要做的只是点击一下！打开你的Storyboard，在Info Panel（command＋option＋1）信息面板中选定&Use Size Classes&：你会注意到你的视图都变成了正方形。先别太激动，这并不意味着你的App现在可以支持黑莓Passport手机，这只是一个适配&Any（任意）&屏幕尺寸的代表性尺寸。所有的约束应该是原样保留了下来，目前还没有任何实质变化。你可以使用&Assistant Editor（辅助编辑器）&中新加的&Preview（预览）&模式来确认这一点。你现在&可以&做的是为不同的尺寸类别单独设置约束。要深入学习自适应布局，尺寸归类和通用Storyboard，请参阅。注：如果你的App是Universal App，你可能为iPhone和iPad界面单独准备了不同的Storyboard。这里有两种选择：继续使用分开的Storyboard。只把iPhone的Storyboard，或把所有的Storyboard转换成通用Storyboard，然后依然分别为iPhone和iPad进行适配。砍掉重练！改成一个通用Storyboard！这样以后就只需维护一个Storyboard，不过这个方案的工作量可不小。目前Xcode中还没有帮助你重构的工具，转换只能靠自己。第2条：开启全屏显示模式与启动画面文件回想一下，全屏显示模式比放大显示模式爽多了，而你刚刚完成的工作只是采用自适应布局，如果你的App不能在全屏显示模式下运行的话，这又有何益呢？幸运的是，开启全屏显示模式相当容易，还有一点额外的好处！Apple如是说：在运行时，系统会查找Storyboard launch screen file（Storyboard启动画面文件），如果想让系统知道你的App支持iPhone 6的不同屏幕尺寸，请在你的App Bundle里包含一个Storyboard启动画面文件。 如果存在这样的文件，系统会认定你的App明确适配iPhone 6和iPhone 6 Plus并在全屏显示模式下运行。打住！&启动画面Storyboard&？也许你会问：“顾名思义的话……我再也不用准备20个启动画面图片了？”对对对！确定一定以及肯定！这就开工吧，由&New File&向你的App中添加一个新文件。在iOS > User Interface当中有一个新的文件类型&Launch Screen&，名副其实，向你的App添加一个新的启动画面！话说Xcode创建的默认启动画面真是有点寒碜。有意思，前面我们聊的都是Storyboard，这下Xcode为你创建了一个&xib&文件。赶紧打开这个xib，删掉那几个丑到爆的label，把它装扮成你喜欢的样子吧。如果想让它和以前一样的话，只要添加一个包含启动图片的UIImageView就可以了。最后，到项目综合设置（General Settings）里像这样选择你的新xib文件为&Launch Screen File&：构建你的App并在iPhone 6 Plus模拟器上运行，新启动画面和超赞的全屏显示模式，尽情享受吧。注：如果要支持iOS 7和／或更老的系统版本，你依然要提供4英寸启动图片。否则你的App会以3.5英寸模式显示。第3条：新一代Retina显示屏和@3x图片iPhone 6 Plus配备了401 PPI的新一代&Retina HD 显示屏&。要适配这么高的分辨率，你需要提供&3倍&分辨率的图片。就像@2x图片一样，你要做的就是提供@3x图片，iOS会帮你加载正确的图片。注：iPhone 6同样配备了Retina HD 显示屏，但其像素密度与前代Retina iPhone相同，依然加载@2x的图片资源。你的App可以在全屏显示模式下运行了！喜大普奔！不过还有很多问题要处理，请先不要离开！第二小节 – 用户许可的变动用户一定会喜欢iOS 8在隐私设置方面的改进。不幸的是，如果使用不当，你的App可能会崩溃。在这一小节中，你将修复这些问题，让用户放心、开心。往下看，这小节的三条小贴士：第4条：修复位置许可iOS 8引入请求用户位置的两个新权限：一个仅当App运行时接收更新，另一个可以在App未运行的时候接收更新。以前，开始监视位置的时候，iOS会自动向用户寻求App权限。这一点在iOS 8中有所改变，你需要在开始更新位置之前明确地显式请求用户许可。为此，如果当前许可状态不明，你需要调用&CLLocationManager&的requestWhenInUseAuthorization或requestAlwaysAuthorization方法。在CLLocationManager调用startUpdatingLocation方法之前加上这个调用就行了。就这么简单：&&self.locationManager&=&[[CLLocationManager&alloc]&init];
&&self.locationManager.delegate&=&
&&if&([CLLocationManager&authorizationStatus]&==&kCLAuthorizationStatusNotDetermined)&{
&&&&[self.locationManager&requestWhenInUseAuthorization];
&&[self.locationManager&startUpdatingLocation];最后一步：在App的&info.plist&中添加&NSLocationWhenInUseUsageDescription&或&NSLocationAlwaysUsageDescription&为新键，然后输入告知用户请求许可的字符串。例如：“显示附近的物品项需要获取您的位置。”第5条：修复通知注册在iOS 8中，用户通知许可有变动，主要是为了支持&可操作通知&。老版本的相关API在iOS 8中无效，不宜使用。现在，通知许可共分为两&层&，你的App必须先请求许可&显示&特定类型的通知，而成功得到用户许可后，你需要请求许可接收&远程&通知。之前的做法是在-application:didFinishLaunchingWithOptions:内调用-registerForRemoteNotificationTypes:来接收delegate回调检查状态。如果在iOS 8中这么写，你会发现根本没有调用delegate方法。这是由于你需要先请求第一层用户通知许可。以下是&appDelegate&中的一个简单示例：-&(BOOL)application:(UIApplication&*)application&didFinishLaunchingWithOptions:(NSDictionary&*)launchOptions&{
&&UIUserNotificationSettings&*settings&=&[UIUserNotificationSettings&settingsForTypes:UIUserNotificationTypeAlert&|&UIUserNotificationTypeBadge&|&UIUserNotificationTypeSound&categories:nil];
&&[application&registerUserNotificationSettings:settings];
&&return&YES
-&(void)application:(UIApplication&*)application&didRegisterUserNotificationSettings:(UIUserNotificationSettings&*)notificationSettings&{
&&if&(notificationSettings.types&!=&UIUserNotificationTypeNone)&{
&&&&[application&registerForRemoteNotifications];
-&(void)application:(UIApplication&*)application&didRegisterForRemoteNotificationsWithDeviceToken:(NSData&*)deviceToken&{
&&//&...&(no&changes&needed)
-&(void)application:(UIApplication&*)application&didFailToRegisterForRemoteNotificationsWithError:(NSError&*)error&{
//&...&(no&changes&needed)
}与之前相比多了一个回调，下面是这几步的简要解释：首先创建一个UIUserNotificationSettings，一个定义了App显示通知类型的设置对象，其中也包括定义操作的类目（categories）。调用-registerUserNotificationSettings:，传入设置对象。这会向用户请求许可。当用户给予回应，新的delegate方法-application:didRegisterUserNotificationSettings:被调用。这里传入的notificationSettings与第二步传入的那个对象不一定相同。这个只描述得到了用户许可的权限。查看types就可以验证用户许可了那些权限。如果成功获得用户许可，现在可以调用-registerForRemoteNotifications。注意这个方法不再接受参数了。现在设置信息已经被设置对象捕获，这里只要请求接受远程通知。此后依然能像往常一样通过相同的回调来获取设备令牌（device token）。第6条：友好的二次许可请求如果用户在询问首次出现时拒绝许可，那么以后就不再弹出询问。如果用户拒绝了一个必要的许可，常见的情形是在App中显示错误页面，或是告诉用户如何到&设置隐私&中开启相应许可的提示。上述做法多少显得有些笨拙，也有不少App因此得到了差评。iOS 8提供&UIApplicationOpenSettingsURLString&来简化这部分工作。这个字符串常量的特性是：把它传入-openURL:方法会直接让用户跳转到相应App的设置。这样一来，请求许可省了不少事。正确的使用姿势是在一个按钮或提示的操作（Action）中加入这行代码：[[UIApplication&sharedApplication]&openURL:[NSURL&URLWithString:UIApplicationOpenSettingsURLString]];第三小节 – 适配后日谈现在你的App已经完成iOS 8适配，可喜可贺，iOS 8的新API正等着你呢。特性适配终于大功告成，App完全可以正常工作了，现在开始享受乐趣吧 :]第7条：释放Swift语言的力量使用Swift语言最明显的好处就是缩减文件数和代码行数。不必用Swift重写任何现有代码，甚至在现有项目中你都可以直接在新类和新文件中开始写Swift代码。以下是确保Swift和Objective-C在项目中和平共处的参考建议：在项目中首次添加Swift文件时，Xcode会为你创建&桥接头文件（bridging header）&。请允许Xcode如此处理。如果想在Swift文件中使用Objective-C类，请用一条标准#import语句将Objective-C头文件导入桥接头文件。如果想在Objective-C代码中使用Swift类，请将包罗头文件（umbrella header）ProductModuleName-Swift.h导入相应的.m文件，其中&ProductModuleName&是模块名，多数情况下是项目名称，但还是去项目设置里仔细检查一下比较好。确保你的Swift类要么继承一个Objective-C类（例如NSObject），要么使用@objc注明类名和方法名。要深入了解Swift，请参阅我们的还有，其中多数教程已经为Swift更新或谈及Swift。如果想深入学习如何协同使用Swift和Objective-C，请参阅Apple的指南。第8条：重要的API隐退或更新信息iOS 8更新了Cocoa Touch的一些基本成分。UIAlertView，UIActionSheet还有UISearchDisplayController都有了用起来更顺心的替代品，而UIPresentationController在视图控制器的呈现过程中会发挥大家喜闻乐见的作用。UIAlertController&取代了UIAlertView和UIActionSheet，提供基于block回调的优雅接口。举个例子：UIAlertController&*&alert&=&[UIAlertController&alertControllerWithTitle:@"Are&you&sure?"&message:@"Once&deleted&this&item&cannot&be&recovered."&preferredStyle:UIAlertControllerStyleAlert];
[alert&addAction:&[UIAlertAction&actionWithTitle:@"OK"&style:UIAlertActionStyleDefault&handler:^(UIAlertAction&*&action)&{&[self&deleteItem&]}];
[alert&addAction:&[UIAlertAction&actionWithTitle:@"Cancel"&style:UIAlertActionStyleCancel&handler:{}];
[self&presentViewController:alert&animated:YES&completion:nil];如你所见，再也不用指定delegate了，想呈现就调用-presentViewController:，看着多舒服，&就是这个味儿。UIAlertController也带来了一些新功能，比如多按钮还有文本框的简单配置。想了解更多，请参阅&NSHipster&上的这篇精品文章：&（）。UIPresentationController&让你在呈现视图控制器时随心所欲。以优雅的、可重用的方式来随意操控呈现的色调、位置和动画效果。要深入了解呈现控制器（Presentation controller），请参阅或的第六章“呈现控制器简介”。第9条：新增的酷炫视觉效果模糊效果是iOS 7广受喜爱的新特性之一。Apple终于在iOS 8中公开了这个API：全新的&UIVisualEffectView&和&UIVibrancyEffectView&类！UIVisualEffectView&是一种弱化背景的有效方式，而&UIVibrancyEffectView&会让前景更加艳丽。这两个类都已经做过优化，但滥用的话，它们会拖慢你的App性能，一定要谨慎使用。想入门iOS 8视觉效果的话，请看我们的&。第10条：新选择，新世界本教程的主要内容是如何让你的App在iOS 8上运行，按着前面的这些小贴士来，干得漂亮！好（坏？）消息是这&还&只是刚开始，iOS 8带来的东西太多啦！在iOS 8中扩展App功能的方法很多，把以前的不可能化为可能。以下是为你的App锦上添花的几点参考：利用&WatchKit&为你的App创建手表扩展。创建&Today Extension&，让用户在通知中心关注信息。利用&Document Provider&实现应用间的文件共享。在通知中添加&Action&操作。集成&Touch ID&方便用户进行身份认证。要深入了解关于iOS 8和WatchKit的更多内容，请参阅&&还有&。何去何从？iOS 8前所未有地为更多功能敞开了大门。带着这些新工具，似乎再次迎来了一个新的开端。希望您喜欢这篇文章，从这些小贴士中获益。朋友们，继续前进，用代码创造欢声笑语！ :]本篇教程内容纷纭杂沓，但愿我表达足够清晰。以下链接供读者参考：（本文为CocoaChina组织翻译，本译文权利归译者所有，未经允许禁止转载。）
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
点击量4372点击量4109点击量3724点击量3460点击量3235点击量3189点击量3077点击量2951点击量2946
&2015 Chukong Technologies,Inc.
京公网安备89