分类 猪在写代码 下的文章

iOS开发中的单元测试(三)——URLManager中的测试用例解析

本文首发于 InfoQ中文站

URLManager是一个基于UINavigationController和UIViewController,以URL Scheme为设计基础的导航控件,目的是实现ViewController的松耦合,不依赖。

准备框架,定义基类

首先按照之前的两篇文章介绍的方法导入单元测试框架和匹配引擎框架,建立好测试Target,并配置编译选项。

定义测试用例基类:UMTestCase(代码1),其他用例全部继承自UMTestCase。

#import 
@interface UMTestCase : GHTestCase
@end

代码1,UMTestCase,用例基类

构建用例

URLManager工具类(UMTools)测试用例(UMToolsTestCase)。UMTools中扩展了NSURL,NSString和UIView,方法涉及到给URL添加QueryString和从QueryString中读取参数,对字符串做子串判断,进行URL的编码和解码,对UIView的x,y,width和height的直接读写等。需要在用例中定义测试过程中会使用到属性(代码2), 并在setUpClass中初始化他们(代码3)。

- 阅读剩余部分 -

iOS开发中的单元测试(一)

本文首发于 InfoQ中文站

导读:本文不讨论单元测试是什么,或者它之于一个工程的利弊,我认为单元测试是一个开发者保证产出代码质量的有效工具。本文从使用者的角度对比当下比较流行的两款单元测试框架,给大家提供一些选用建议。如果你还不甚了解单元测试在工程中所起到的作用,或者还不知道TDD的开发模式,可参考:Test-Driven DevelopmentUnit Testing

本文对比两个iOS开发中常见的单元测试框架:OCUnit,被官方集成进XCode 4.x版本中;GHUnit,被推荐最多的测试框架,带GUI界面。初窥两款测试框架非常相似,而上手使用就会发现其中的区别。细节上的区别使两款框架在不同角度各有优劣。


- 阅读剩余部分 -

对比iOS中的四种数据存储

本文首发于InfoQ中文站

你是用什么方法来持久保存数据的?这是在几乎每一次关于iOS技术的交流或讨论都会被提到的问题,而且大家对这个问题的热情持续高涨。本文主要从概念上把“数据存储”这个问题进行剖析,并且结合各自特点和适用场景给大家提供一个选择的思路,并不详细介绍某一种方式的技术细节。

谈到数据储存,首先要明确区分两个概念,数据结构和储存方式。所谓数据结构就是数据存在的形式。除了基本的NSDictionary、NSArray和NSSet这些对象,还有更复杂的如:关系模型、对象图和属性列表多种结构。而存储方式则简单的分为两种:内存与闪存。内存存储是临时的,运行时有效的,但效率高,而闪存则是一种持久化存储,但产生I/O消耗,效率相对低。把内存数据转移到闪存中进行持久化的操作称成为归档。

二者结合起来才是完整的数据存储方案,我们最常谈起的那些:SQLite、CoreData、NSUserDefaults等都是数据存储方案。当然在这些框架提供的方案之外,我们自己也可以按照个性化需求订制方案。这些存储方案侧重不同,支持的形式和方式也各不相同,在不同的使用场景下表现也是各有优劣。但万变不离其宗,无论什么方案都可以用下图来解释。

图1,存储方案示意图

- 阅读剩余部分 -

对比iOS网络组件:AFNetworking VS ASIHTTPRequest

本文首发于 InfoQ中文站

在开发iOS应用过程中,如何高效的与服务端API进行数据交换,是一个常见问题。一般开发者都会选择一个第三方的网络组件作为服务,以提高开发效率和稳定性。这些组件把复杂的网络底层操作封装成友好的类和方法,并且加入异常处理等。

那么,大家最常用的组件是什么?这些组件是如何提升开发效率和稳定性的?哪一款组件适合自己,是 AFNetworking(AFN)还是 ASIHTTPRequest(ASI)?几乎每一个iOS互联网应用开发者都会面对这样的选择题,要从这两个最常用的组件里选出一个好的还真不是那么容易。

单单从两个控件版本提交的时间节点来看,AFN的第一个提交是2011年的1月1日,那个时候ASI早已是1.8+的版本了;而当AFN发布1.0版,2012年10月份的时候,ASI早早的已经停止更新了。这样看起来,AFN是ASI的继任者,似乎不存在之前提到的选择困难的问题,而事实并非如此。本文将从用法、功能、性能和原理几个方面对二者进行简单对比,看看二者之间到底存在着怎样的区别,到底应该如何选择。

- 阅读剩余部分 -

iOS应用2.0版怎么做

首发于InfoQ中文站

移动互联网如火如荼,iOS 应用+ Android 应用+ 手机站似乎成了所有互联网公司的标配,你的网站要是还没有个iOS 应用,似乎都不好意思跟人打招呼。

iOS 应用诞生毕竟才只有不到5年的时间,各个方面还都处在起步阶段。不管是出于团队缺乏经验,还是那个“唯快不破”的铁律,往往这些iOS 应用的第一个版本都比较简陋,尤其在技术架构上。这篇文章,我想跟大家探讨的就是这个问题,当你的iOS应用已经有一个版本在线的情况下,如何去构建一款可以支持高效迭代,快速响应的2.0版。 首先,应用的架构要层次清晰。把不依赖版本更新变化的,以来版本更新变化的,不需要变化的,业务逻辑,视图逻辑,工具,等这些内容梳理清楚,单独处理。


图1,应用整体架构

- 阅读剩余部分 -