gaosboy 发布的文章

使用Three20

记:Three20(简称:TT)是Facebook维护的一个开源iPhone应用框架。框架封装了一系列视觉控件,网络组件,和工具方法。最近使用TT重构了一个app,这个app在1万行规模使用的是原生代码,架构非常简单。增长到2万行规模,这个原生的架构已经疲于应付迅速变化的业务需求,因此我们采用TT进行了重构。这里,简单介绍一下使用TT开发的app采用了怎样的架构,以及开发过程中的经验和教训。

app基于TTTableViewController的架构进行设计,主要分为三层:ViewControlelr,DataSource和Model。另外,平行于这三层设有Service和Util,封装一些通用逻辑和工具,例如:登陆,URLEncode等。最底层是Manager,封装网络控件,缓存控制等。除了这些还有独立封装的组件和对系统组件的扩展,如SegmentedControll,滚动图片等。这个架构不做赘述,说一说在这个架构下遇到的几个问题,以及解决方案。

1、TT对系统控件的封装无法满足个性化需求。

TT对很多系统控件进行封装,拿之前提到过的TTTableViewController举例,所有的cell都被封装,对框架使用者透明,而TT封装的cell类型无法完全满足需求,我们往往需要格式更加丰富的cell样式。

在这种情况下,我们选择对TT方法进行重写。Objective-c提供指定类指定方法的重写,因此集中把需要个性定制的TT控件进行重写,完全不修改TT本身的代码。这样操作,既满足了需求,又使在日后对TT框架进行升级变的非常方便,几乎不需要考虑升级造成的不兼容。

2、Cell的默认操作过分单一

TT是使用Navigator和ULR的策略(欲了解该策略请参考TT官方网站http://three20.info)来管理整个应用的ViewController的。

在TableView中没一个cell带有URL,这个URL表明了点击cell后要跳转到的viewController,同时TT还认为如果一个cell没有URL那么他就是不可点击的,而往往存在这样的需求,cell可点击,但点击操作却不是跳转到某个ViewController。

针对这种情况,我们定义空URL,空URL不指向任意ViewController的类,而是指向nil。带有空URL的cell既可点击,又不会跳转到任意ViewController。

3、构造ViewController的URL不支持中文

之前说了,TT使用URL管理ViewController。有些ViewController的参数是中文,而且需要通过URL传递,而Navigator不支持汉字URL。

增加URLEncode方法,对每一个配置到URL中的参数编码,生成编码后的URL就可以正常使用。另外,TT会自动Decode的URL,无需开发者处理。

但TT的在URL策略中“/”无法使用,即使进行Encode之后,放入URL仍无法使用。这就需要开发者在构造URL过程中,检查每一个参数,确保不出现“/”。

4、稳定版TT(v1.0.5)不支持ios3.1及以下版

根据我们对客户端使用ios版本的统计,3.1及以下版的用户仍然占一定比例,还不能放弃支持。因此,考虑到支持3.1及以下版本的ios设备,需要使用v1.1 TT进行开发。

开发过程中遇到的问题很多,以上是比较明显的几个,接下来聊一聊开发经验。

1、一个界面一个ViewController

在一个应用中,ViewController往往通过简单的配置就可以复用,可以控制多个界面,但我建议ViewController不复用。复用ViewController必然导致在类中出现用于区分不同界面的逻辑,如果界面上的逻辑稍有变动,这个被复用的Controller要跟着修改,随着发展,代码会越来越复杂,因此,保证一个界面一个ViewController。

对于那些确实可以复用的逻辑,可以采用继承的方式。把可以的复用逻辑封装在一个类中,每一个直接控制界面的ViewController继承自这个父类,针对各自的个性逻辑重写相应的方法。

2、不过分使用URL

之前我们提到多次通过URL控制ViewController,Controller中的参数也可以通过URL传进去,但过度使用URL构造Controller可能会埋下隐患。URL不仅是初始化的时候使用,在运行过程中可能还需要使用这个URL在池中取出该对象。如果在URL中定义了多个参数,在获取对象的过程中,必须拿到这些参数值才能准确定位到相应对象,往往这些参数都不是全局的,所以这个过程就会非常麻烦。

因此,在某些非终端的类中,尽量不使用URL构造对象,需要传递的参数使用ApplyQuery的方式,使用一个字典构造Query,使用URLAction构造对象。

3、封装两个网络控件,带缓存/不带缓存。

TT封装的网络控件叫TTURLRequest,在TTURLRequest中允许使用缓存,默认缓存1天。在应用中,有些请求要求实时性,不允许使用缓存,尤其是一些写操作的请求。

应用本身也要对TTURLRequest进行一层封装,就是之前提到过的Manager,在NetworkManager中封装两个方法,使用缓存/不缓存。

4、使用延迟加载操作

所谓延迟操作,指的是在某个界面上加载某个组件的时候,如果直接调用addSubview方法可能会出现加载失败等诡异问题。是由于iPhone渲染一个界面需要时间,加载自己的组件需要在渲染界面之后,而调用viewLoad,甚至是viewDidLoad方法在TT框架下不能保证在渲染完成之后。因此在加载个人组件时,可能需要延迟加载,即,延迟0.3或0.5秒后再加载。TT框架本身也采用了许多延迟加载,使用[NSTimer scheduledTimerWithTimeInterval:(NSTimeInterval) invocation:<#(NSInvocation *)#> repeats:<#(BOOL)#>]方法。

 

以上介绍了8个经验和教训,希望能对大家在使用TT进行开发过程中提供一些帮助,少走弯路。

从wwdc2011 keynote看apple的生态系统

去年wwdc 2010的余温还在,iphone4的热乎劲儿还没过,wwdc 2011就来了。乔布斯走上来就告诉大家,今儿咱们不聊硬件,聊聊软件。说实话,刚刚听到没有硬件发布的时候,心里还是有点小失望,但随着演讲进行,一个又一个的软件产品,不亚于新硬件带来的惊喜。三个主题,osx 10.7,ios5和iCloud,具体的内容不聊了,大家可以在视频里了解,说说看了这个keynote的一点感受。(视频地址:http://itunes.apple.com/us/podcast/apple-keynotes/id275834665

三两个月以前,就在朋友的air上体验了10.7,感受最深的还是“multi-touch”,配合各种手势,mission control和launchpad都显得很自然。个人感觉mission control和launchpad,甚至包括full screen app这些,都是早已存在的feature,只是在等待一个完美的入口。终于,multi-touch成熟了,这些功能可以一股脑的出来了。

说道multi-touch,必须提Lion里对scroll bar的弱化。之前,我们的mac trackpad也有双指滚动,但这个双指是对scroll bar的操作,也就是说双指向下,页面向上的这种反向操作,而10.7里弱化scroll bar以后,双指直接操作页面,跟之前的方向相反。开始上手,确实需要一段时间适应这个操作。

还有其他很多特性,包括keynote里提到的mail,都在向ios靠拢。从Lion各个新特性来看,触屏的影子越来越重,或许触屏macbook离我们不远了。触屏macbook带来的将不只是操作体验上的大幅提升,更重要的是没有了键盘依赖,mbp的移动性更好,我想今年发布的那73%笔记本用户比例,上升到90%都很正常。

这些年一直聊的很热的“移动”,似乎大家都关注在手机和平板上,看apple在Lion这个系统中的动作,接下来apple要把mac推进移动市场了。apple接下来一定又会告诉我们“it changes everything again”,移动领域不是只有phone和pad,notebook也要是移动领域的重要元素。几年前就推出了触屏电脑的ibm,hp这次很可能又要在这块领域被apple打的体无完肤了。

而近年来大热的ios,此次推出的ios 5,却让开发这们有点伤感了。新功能确实不少,但这些又酷又炫的新功能可是抢了不少第三方app开发者的饭碗。camera,twitter,reminders,notification还有iMessage,几乎涵盖了能想到的所有应用领域。要在这些领域里争一口饭吃,开发者们似乎就剩下“跨平台”这一跟稻草了。

虽说ios 5把很多开发者们的财路给堵了,但iCloud的发布,而且开发了api,绝对是给开发者们打开另外一扇窗,这时候我不由得想:Jobs还真是上帝啊!看iCloud的很多特性,以及超低成本,不得不怀疑ios 5中apple做的那些抢饭碗的事情是故意为之,故意要把开发者们赶到云应用的这块土地上。这块土地无疑是超级肥沃的,apple自己种不过来,只有借助第三方开发者的力量,一起耕耘,才能在这块肥沃的土地上获得丰收。说句题外话,ibm,intel还有oracle等等这些做云很长时间了,但似乎都不瘟不火,google的云也总是没有想期望中那样火爆起来,但我看apple这朵iCloud又要给这些公司上一课了。

说回来iCloud,apple自己做了文档,音乐,应用,通讯录等等一些基础的云应用。接下来基于这个云平台的应用可以衍生出更多好玩的东西,同步只是其中很小的一部分,我认为互动和分享将成为接下来云应用的一块主阵地。那种“情侣台灯”式的应用,一定很有市场。独立的ios开发者可以真的可以开始考虑这方面的东西了,似乎能感觉到当年app store刚出来时的那种新生力量,一年百万美元入帐的传说,可能要重演了。

单看keynote的三个段落,给大家带来的是各种各样的小惊喜,而把三个段落连起来却发现apple是在布局,一个网络生态系统。从i7的mbp到10寸最薄的air;有用来打电话的iPhone,还有更轻量的ipod touch;更大更休闲的ipad;甚至apple tv,在所有段位给消费者提供选择。让所有设备接入云,做好多apple设备体验,把所有用户圈到apple的这个系统里。让第三方开发者在需要的领域进行开发,帮助apple把可能性做大,把体验做到极致。这个系统建成,apple将成为一个王国,是前所未有的,ibm没有做到过,微软没有做到过,google没有做到过,没有任何人做到过,我想,apple可以做到。

职业

回家两天多了,吃饱了喝足了,也睡够了,干点正事,写写这一年的总结。

我想,现在还远远没到年底可以盘点生活的岁数,年纪轻轻的,似乎只有职业是值得盘点的,也似乎只有职业可以盘点。

翻了翻去年的总结,写在2009年的12月,那时候刚刚走出学校,来到这个操蛋的社会上,其实没太多可总结,也没太多可展望,只是给自己写了三个目标:

1、为父母做点什么,让他们感觉自己长大了

怎么说呢,一年过去了,给妈买了母亲节礼物,好像没给爸买过什么,年底给家里长辈们包了红包。做的不多,但总算做了一些。

2、为团队做点什么,回报团队

这一年,项目换了一个又一个,欣慰的是,在每一个团队里都发挥了一些作用,敢说没有辜负同学们的信任吧。

3、为朋友做点什么,他们的信任应该是正确的

这个,似乎没有做太多。大家都在各自的路上奔跑着,我只是往常一样的在朋友问起的时候,聊一聊自己对职业的观点。

年底盘点,自己似乎收获了不少,算是按照自己的规划在走吧。

昨天,2010年的最后一个应用,发布了,算是完完整整的过完了一年。

2010年在公司里做了好多事,做了一个平台,做了一个工具,做了一个应用,还开源了一些代码,在写Java,在写Perl,在写PHP,在写C,在写Objective-c,在玩Linux,在玩Oracle,在关注性能,偶尔还弄弄MySQL,还有No-SQL。2010中期总结的时候,对自己的评价是:自己不能Focus在某一个领域,是因为觉得,不多看看,不多折腾折腾,心里不踏实。所以这一年,其实还是非常丰满的。

过完这丰满的一年,不得不说,真是有点舍不得,做了那么多可以吹牛的事,过去了,就再也不能提了。2011年,还得做更多更牛B的事,要不然,到了年底,没的吹,还真是受不了。这其实压力还是有点大。

2011年,选择专注一些,玩那么两三个东西,就行了。本职的Objective-c,必须做好的;性能,做,推动;Share,互联网时代,用代码推动互联。

早早的在Twitter上写过三个量化的目标:

1、长10斤肉,我现在瘦的自己都受不了了

2、开源5000行以上的代码,自我感觉没有什么压力

3、站在台上说一次话,这个,怎么说呢,我是个虚荣的孩子

行了,就这样吧,2010过去了,过去的牛B,属于过去的一年,接下来要做的就是牛B的过完2011。

聊聊汉字微博客那140个字的限制

元旦了,大家都在为跨年做着各种各样的事,我考虑也干点啥~~于是一觉醒来,我想把白天欠的债补上。

白天发了一条twitter,说中国为什么出现不了Facebook或Twitter这样的牛B公司,因为大家都在不求甚解的模仿别人,甚至是那140个字的限制。那么我就解释一下,twitter那140个字到底是为了什么,顺便也聊聊我认为汉字微博应该如何限制。

Twitter的140个英文字符限制缘起英文短信中160个字符限制,Twitter减去20个是因为要预留20个字符的位置存放发布者的ID。那么再问一句,英文短信中160个字符的限制是从何而来呢?这就要追溯到上世纪80年代(靠,那时候我还没出生...)。

一个叫Friedhelm Hillebrand的德国人做了一项研究,他在格纸上用打字机随即的去写一些句子,然后统计这写句子的长度,结果发现往往一句完整的话都在1到2行,160个字符以下。160,这个数字也被人们称为:Hillebrand's Magick Number。在随后的研究中,人们更加印证了Hillebrand的这个理论,渐渐的160就成为了手机短信的标准长度。

知道了Twitter那140个字的限制的原因,我们回到主题上看看汉字微博的限制。

首先,140明显不太合适,因为这个Magic Number是人家根据英文特点制定的,我们这么悠久的汉语一定会水土不服。当然我不是掉书袋,大家各自想一想,是不是当我们要表达一个意思的时候140个字往往显得太多了,或者当我们去读一些接近甚至写满140个字的微博的时候会觉得这很拖沓,已经背离了微博之根本意义。至少我是这么觉得。

那么,如果说140个字不合适,多少个字合适呢?模仿Twitter,根据短信长度去限制?我们知道,汉字短信的限制是70个字。我在网上搜了一下,确实没发现这70个字的限制是什么人根据研究结果订出来的,所以实在是不敢追随。我的建议是,有这个技术实力的公司或机构,应该做点什么,为汉字微博做出这样一个统计,分析,还有建议。比如新浪,新浪博客开的如火如荼,那么我认为新浪应该基于博客数据,选取一些具有代表意义的博主的全部博文,进行分析,看往往表达一个意思,或者更简单点说,一句话,占用了多少汉字。给出这样一个标准,一个建议。

--------------辞旧迎新的分割线----------------

正事说完,该祝大家新年快乐,在新的一年里心想事成,万事如意,活的有滋有味有尊严!

【译】Emiller Nginx模块开发指南(第二部分)

由于格式问题,这篇文章看起来可能会不太舒服,可以直接阅读我的google doc:

中文版       中英对照版

2. Components of an Nginx Module

2. nginx模块的各个组件

 

As I said, you have a lot of flexibility when it comes to making an Nginx module. This section will describe the parts that are almost always present. It's intended as a guide for understanding a module, and a reference for when you think you're ready to start writing a module.

正如我所说的,开发一个nginx模块的时候,具有非常非常强的灵活性。这部分就介绍一下这些东西。类似于理解模块的一个指南或者是你觉得你已经准备好开始开发模块的时候的一个参考资料。(译注:这一部分是最重要的,而且在日后的开发中,这部分可以当作字典来用)

 

2.1. Module Configuration Struct(s)

2.1. 模块配置结构

- 阅读剩余部分 -