Comments

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

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

继续阅读 →
Comments

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

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

继续阅读 →

在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的特性和用法。

继续阅读 →

在 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代替。

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

继续阅读 →

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

继续阅读 →
Comments

只要是做代码开发,就会遇到代码管理的问题,IOS也不例外。比如你写了一个用于网络图片加载的公共组件EGOImageLoading. 然后这个组件在10个project中被使用。某一天你对这个组件做了一些优化或bug修复,怎么把代码同步到所有工程呢。普通程序员:手动一个一个拷贝到每个工程。文艺程序员:pod update

继续阅读 →