忙碌的一周

预告过了, 这周主要参加了两个活动. 周四在上海的Ruby Conference China 2009, 可以说相当成功. Matz 绝对是现场最耀眼的明星, 他的演讲非常有趣, 充满了程序员的智慧. 他提到编程语言应该有common sense, 程序员即使是在为生计编程, 也不应该放弃对fun的追求. 每个ruby程序员都知道这不是泛泛的说道, 因为我们都能确切的体验到这种common sense,以及ruby编程给我们带来的快乐. 以前听过Bjarne Stroustrup和James Goslin的演讲, 和这些编程语言之父面对面的交流总是让人有颇多的收获. javaeye的Robbin Fan的演讲也非常精彩, 分享的内容是国内ruby/rails社区极为宝贵的经验. 有一个小插曲, Robbin演讲当中, 接到了一个网警要求删贴的电话, 不得不马上处理. 老大哥的无处不在让人啼笑皆非. 另外, 这次上海之行, 看到这样一个没有做太多宣传的活动, 一下就聚集了全国各地四百多人, 会上会下都以javaeye会员相称, 着实见识了一下javaeye的号召力. 借这次活动, 看到了ThoughtWorks的郑烨, 图灵的刘江老师, 杭州的ashchan, Kernel1983, 吕国宁等等很多神交已久的朋友, 也结识了象薄荷网的谢文威等等的新朋友, 可谓不虚此行. 今天下午在奇遇花园的技术沙龙也不错, 来了不少人, 对iPhone感兴趣的人还不少. 因为Tinyfool告诉我最好不要超过二十分钟, 所以没有准备太多内容, 做开发的可能会觉得没啥意思, 不做开发的可能又觉得太偏技术,不过最后回答了一些大家的问题,也算有点补偿了. 其实技术沙龙就应该是这样, 上面讲的人只是抛砖引玉, 大家的交流才最关键. 我自己的体会也是这样, Read more about 忙碌的一周[…]

MacWorld reviews BuddyFeed!

一直以来,都把在mac和iphone做cocoa编程当成业余爱好,是自己的20% projects。要做什么,首先肯定是自己要用的,能做到自己满意也就差不多了。 做BuddyFeed也是这样。觉得在iPod Touch上看完twitter,看完google reader,好像还想读点东西,FriendFeed刚好是个不错的选择,但是一直都不太喜欢FriendFeed以前的界面,就干脆自己为iphone/ipod touch做了这个客户端程序。界面设计上我也没有太多想法,第一版借鉴Twitterrific和Twittelator多一些,后来老用Tweetie,觉得它的界面更合理,第二版就更多借鉴了Tweeite的设计。 上周末新版通过审核发布了。昨天晚上,突然看到MacWorld的iPhone Central频道review了BuddyFeed 2.0,虽然以前在Marshable和其它一些blog也有过,但从来不会想到MacWorld,所以还是惊喜了一下。基本上一个业余cocoa coder的虚荣心已经完全得到满足了。

下周的两个活动

下周准备参加两个活动. 一个是五月二十一号在上海的Ruby Conference China 2009. 终于有人走出这第一步了. 很佩服javaeye和Shanghai Rails Group的勇气. 虽然我们并没有什么在技术性会议上做宣传的需求, 也没有太多的钱, 但还是希望能和大会组织者一起, 为国内Ruby社区尽一点点力. Louie和我会在二十号到达上海, 二十二号返回. 其实比起Matz, 更想见见南方ruby圈子里的朋友. 希望到时候可以见到大家. 第二个活动是beta技术沙龙第四期[iPhone开发入门]. beta技术沙龙是一个在奇遇花园每月一次的聚会,每次会有一个主题,几个主讲,但更主要的是大家互相之间的交流. 这次的主题是iPhone开发, 银杏的Tinyfool和我主持这次活动, 我们各作一个二十分钟左右的演讲, 然后大家可以一起聊一聊, 有什么感兴趣或者疑惑的问题可以现场切磋.

小议iPhone OS 3.0

今天凌晨,苹果宣布了iPhone OS 3.0 。上午起来看了视频,又翻了翻文档。从开发者的角度,说说我比较感兴趣的几个更新。 Apple Push Notification Service 一直被当作后台运行程序的替代品。仍然不能有后台运行程序,解释的也很清楚了,是耗电量和待机时间不允许。但可以通过Push来唤醒应用程序。这种方式的特点是无触发不执行,执行是被动的。虽然不可能100%解决所有后台运行程序的需求,但也算提供了一种比较通用的模式。 基本原理如下图所示: 先将消息推送给Apple的APNS,由它转发到相应的iPhone上,再由iPhone OS通知到相应的程序。 可以看到,所有的消息都不是通过网络直接发送到iPhone,而是通过苹果的APNS服务转发的。这将对APNS服务有很高的要求。这也是苹果一再推迟这一功能的原因。以往年苹果网络服务的经验来看,这个服务在推出以后也许要经过一段时间才会稳定。希望苹果这次是有备而来吧。 Accessory Support 我个人认为这个功能是这次升级的一个亮点,有极大的想像空间。附属外设可以通过30-pin连接头或者蓝牙接入。我大概看了下文档,和我想像的有些出入的地方是,附属设备必须预先支持iPhone,即使用蓝牙接入方式也一样。iPhone OS 3并没有象Mac OS X 10那样,提供一个完全的蓝牙API,而是做了更高层次的封装,只有符合协议(技术层协议)的设备才能接入。想通过iPhone OS 3直接读取Wii Balance Board 中的数据目前还不可行。 In App Purchase Support 商业模式上的扩展。SDK中新加入了Store Kit 。苹果还是挺狡猾的。这个事情,它不做,总有人会做,与其让别人做,不如自己先做了,还能再收个30%。对于最终用户,直接使用iTunes帐号付款也比再引入一个付款方式要简便,也许不少应用不得不因此屈尊交这笔苹果税了。 Peer to Peer Support 这一功能是以Game Kit的方式加入的,不过苹果一再声明完全可以用在非游戏的应用上。这一功能建立在蓝牙之上的,但同样做了封装,应用仍然无法直接和蓝牙接口打交道。连接服务以session的方式维护,一个应用可以这个P2P网络中扮演三种角色,server, client, 或者peer(server+client)。两个设备之间只能有一条蓝牙连接,但是在这一个连接上可以支持多个sessions的服务。传输内容并不受限制,可以自己定义。 Core Data 其实我们早就可以在iPhone中使用SQLite,不过到iPhone OS 3,才有了类似Mac OS X中的Core Data 。这意味着,对开发者来说,使用SQLite的门槛降低了。其他好像也没什么了。

iPhone开发内存管理

开发iPhone 应用程序并不难,基本上就是三个词 – “memory, memory, memory” 。iPhone OS 对内存的要求很严格,有memory leak ,杀掉; 内存使用超限额,杀掉。一个经过测试的程序,在使用过程中90%以上的崩溃都是内存问题造成的。在这里简单总结一下Object-C 内存管理。 基本概念 Object-C 的内存管理基于引用计数(Reference Count)这种非常常用的技术。简单讲,如果要使用一个对象,并希望确保在使用期间对象不被释放,需要通过函数调用来取得“所有权”,使用结束后再调用函数释放“所有权”。“所有权”的获得和释放,对应引用计数的增加和减少,为正数时代表对象还有引用,为零时代表可以释放。 函数 获得所有权的函数包括 alloc – 创建对象是调用alloc,为对象分配内存,对象引用计数加一。 copy – 拷贝一个对象,返回新对象,引用计数加一。 retain – 引用计数加一,获得对象的所有权。 另外,名字中带有alloc, copy, retain 字串的函数也都认为会为引用计数加一。 释放所有权的函数包括 release – 引用计数减一,释放所有权。如果引用计数减到零,对象会被释放。 autorelease – 在未来某个时机释放。下面具体解释。 autorelease 在某些情况下,并不想取得所有权,又不希望对象被释放。例如在一个函数中生成了一个新对象并返回,函数本身并不希望取得所有权,因为取得后再没有机会释放(除非创造出新的调用规则,而调用规则是一切混乱的开始),又不可能在函数内释放,可以借助autorelease 。所谓autorelease , 可以理解为把所有权交给一个外在的系统(这个系统实际上叫autorelease pool),由它来管理该对象的释放。通常认为交给 autorelease 的对象在当前event loop 中都是有效的。也可以自己创建NSAutoreleasePool 来控制autorelease的过程。 据苹果的人说,autorelease效率不高,所以能自己release的地方,尽量自己release,不要随便交给autorelease来处理。 规则 引用计数系统有自己的引用规则,遵守规则就可以少出错: 获得所有权的函数要和释放所有权的函数一一对应。 保证只有带alloc, Read more about iPhone开发内存管理[…]