Comments

最近做项目时,因为iPhone6和iPhone6Plus的兼容,我们启用了Autolayout. 以前是因为不用也能满足需求,也是因为懒,没有认真使用,只是了解过。经过一段时间的使用,做下总结,希望给大家些帮助哈。

以前我写过IOS自动布局之Autoresizing是关于Autoresizing的介绍,在简单的布局上比较有用,今天总结的是更强大的Autolayout.

本文不是从零开始入门级的介绍,主要介绍了学习过程中遇到一些问题的解决方案,希望给大家帮助,如果初学者请先看看苹果文档,玩玩Autolayout.

PS: Autolayout的强大是毋庸质疑的,当你熟悉了它之后,你肯定会喜欢上它,布局将会比使用frame的绝对坐标时还方便。如果还没有用Autolayout,这已经是最后的时机啦,再不学就out了。

Read on →
Comments

在工程拆分的架构中,一般会有一个主工程(上图中的MainProject), 很多个子工程(上图中的subProject). 它们可能是在一个workspace中,也可能作为subProject等. 但是一般子工程的代码都会打包为静态库.a或framework来使用.

考虑一个使用场景: 在subProject中使用resource怎么处理呢? 这个方案大家应该很容易想到,使用bundle来管理resource. 没错,我们也是这样用的, 但是如果我们想要更近一步,使用xib呢。本文给出我们使用的方案,文中的顺序会按照我发现解决问题的思路来陈述。

Read on →
Comments

浮点数不准,这个貌似基本都知道。但是在开发中很多人没有对它的使用产生警觉。如果你在开发Cocoa应用,你可能使用过如下代码判断系统版本:

1
2
3
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 7.0) {
  //something support for ios7
}

这样一段代码也的确工作良好,但是注意了如果你把比较的数值改为7.1,那么很有可能就会出问题。

Read on →
Comments

随着IOS的不断升级,我们需要app的icon的尺寸也越来越多,如下:

如果让设计同学一张一张给,可能也会有些麻烦,在AppStore发现了一款工具叫 Appicon and Launchimage Maker, 用来自动生成xcode所需要的icon的所有size,还挺方便的,但是这个工具在Mac Retina上生成的图片的size都是实际需要尺寸的2倍,推测他们应该是用CoreGraphics重新绘制的,但是貌似这个App的开发者没有修复这个的打算,于是我想到了AppleScript.

Read on →
Comments

GCD 对于cocoa和cocoa Touch的开发者来说已经是在熟悉不过了,相信有些基础的人都能说出一些特性。但是今天我们不是讲GCD的介绍和使用bulabulabula. 本文就介绍下使用dispatch_async的一个小妙用,且看下文分解。

我们都知道dispatch_async可以用来异步执行代码。你的第一反应的可能是后台、多线程 这样的字眼,但是异步执行不是就代表多线程,它只是代表代码的执行方式,知道这点可以做更多事情。

Read on →

在IOS上进行JSON解析已经有了很多成熟的组件,如 json-framework, JSONKit 等等。还有cocoaTouch在IOS5之后推出的API: NSJSONSerialization。 起初我想当然的认为系统原生的肯定就是最好的,最适合的,但是还是实践出真知, NSJSONSerialization 对于我们不是最适合的,甚至有点糟糕: 在IOS6上会crash.

crash的原因

在测试中,我听到了说JSON解析崩溃的问题,起初很惊讶,但是经过在网上一番搜索,发现stackoverflow上可以搜到NSJSONSerialization在IOS6上崩溃的问题。经过小伙伴们一系列的定位,终于确定NSJSONSerialization在IOS6上是有崩溃的问题了。你可能会问了,我也一直在用NSJSONSerialization,但是从来就没崩溃过啊。是的,在标准的JSON解析中,它的确工作良好,但是在不标准的JSON面前就会有问题。最后发现问题的原因:

在同一个dic内有重复的key值,如:

1
2
3
4
{
  "name": "jason",
  "name": "jason"
}

而且在arm架构上会crash,在x86和i386架构上不会crash, 即在模拟器上不会崩。

凑巧我们的接口返回的JSON不是标准JSON,而是在jsp、freemarker等页面里面开发人员拼的JSON(对于这种情况已无力吐槽),这种情况下各种不标准的JSON情况层出不穷…

其他场景

stackoverflow上标出了另一种崩溃场景: http://stackoverflow.com/questions/12842481/nsjsonserialization-results-in-exc-bad-access.

就是遇到了用Unicode编码代替字符的时候也会导致崩溃, 如 \u00e4 来表示 ä.

小结

在任何关于框架级的设计和更改时,一定要谨慎,最好的不一定是最适合的。全面的测试是必要的。

对于IOS的app开发者来说,不会像Android开发者一样为很多的屏幕尺寸来做界面适配,因此硬编码的坐标也能工作良好,但是从设计模式上来说这不是好的做法。而且也还有一些问题,如iPhone5的适配,横竖屏的切换等。或许你可以做两套UI方案来做适配,但是这样增加重复工作量,而且不够高端,万一有出新的屏幕大小了呢。哲理就将介绍IOS中的两大自动布局利器:AutoresizingAutolayout。 autoresizing是UIView的属性,一直都有,使用简单,但是没有autolayout强大。autolayout是IOS6以后的新技术,更加强大。本文主要介绍Autoresizing的特性和用法。

Read on →

在 IOS7 以前,在IOS中实现二维码和条形码扫描,我们所知的有,两大开源组件 ZBarZXing. 这两大组件我们都有用过,这里总结下各自的缺点:

  • ZBar

ZBar在扫描的灵敏度上,和内存的使用上相对于ZXing上都是较优的,但是对于 “圆角二维码” 的扫描确很困难。如:

  • ZXing

ZXing 是 Google Code上的一个开源的条形码扫描库,是用java设计的,连Google Glass 都在使用的。但有人为了追求更高效率以及可移植性,出现了c++ port. Github上的Objectivc-C port,其实就是用OC代码封装了一下而已,而且已经停止维护。这样效率非常低,在instrument下面可以看到CPU和内存疯涨,在内存小的机器上很容易崩溃

  • AVFoundation

AVFoundation无论在扫描灵敏度和性能上来说都是最优的,所以毫无疑问我们应该切换到AVFoundation,需要兼容IOS6或之前的版本可以用zbar或zxing代替。

下面介绍本文的重点,无论你是用以上哪一种或其他的解决方案,都需要知道下面两点。

Read on →

目前在 iOS 和 OS X 中有两套先进的同步 API 可供我们使用:NSOperation 和 GCD 。其中 GCD 是基于 C 的底层的 API ,而 NSOperation 则是 GCD 实现的 Objective-C API。 虽然 NSOperation 是基于 GCD 实现的, 但是并不意味着它是一个 GCD 的 “dumbed-down” 版本, 相反,我们可以用NSOperation 轻易的实现一些 GCD 要写大量代码的事情。 因此, NSOperationQueue 是被推荐使用的, 除非你遇到了 NSOperationQueue 不能实现的问题。

Read on →