Fluid idea for Life

读《万历十五年》

walktree — 2011-12-30 14:37

1587年，辽东巡抚注意到一个酋长在开拓疆土，他察觉后力主派兵征讨，扼杀在摇篮中，但师出不利。部下不照命令行事，坚持改剿为抚，上奏到北京后，引发上面争执。首辅申时行认为小事一件，出面调停，从而和谐收场。该酋长得以扩张地盘，发展为千秋大业。他就是努尔哈赤，也就是若干年后的清太祖。

与StageWebView的页面进行交互

walktree — 2011-08-16 21:10

之前看文档，不记得哪些看到，ActionScript无法与StageWebView加载的网页进行交互，后来看到一篇Blog写关于invoke javascipt in StageWebView的技巧，原来是：

stageWebView.loadURL("javascript:jsFunc('From ActionScript')");

原文在这里。

由PhoneGap想到的

walktree — 2011-07-13 11:54

这两天试用了PhoneGap，将SDK中自带的sample编译放到Nexus One上跑了下，感觉还不错，之前看到有人说UI反应慢，性能不好，但在真机上的效果并没有那么不堪，还可以接收。当然，我没有跑过复杂的web应用，有机会可以将一些HTML5游戏放上去跑跑看。

移动应用Web化，这个趋势似乎不可阻挡，对于HTML5来说，自然是好消息。和Adobe AIR相比，使用PhoneGap这类开发的好处在哪里？就我目前想到的，首先是不需要Runtime的配合，程序的个头没那么大；其次现在的JavaScript库很多，开发应用和游戏都很方便；最后当然是跨平台了，Android，iOS，Blackberry，WebOS，Symbian，Bada，一网打尽，PhoneGap的野心不可谓不大，从这点来看，连AIR都没法比。

不过，跨平台真这么重要？对开发者确实重要，但对用户来说，性能和用户体验才是王道。古往今来，多少跨平台的平台无疾而终。对PhoneGap，我暂时保留意见。

AIR Android开发（三）使用apk-tool整合native程序时的注意事项

walktree — 2011-06-27 15:03

在很早之前，我曾经写过一篇博客，谈到了AIR与本地程序通信，也就是使用apk-tool整合AIR Android的技巧，后来在国外的Blog上看到几篇关于实现的具体说明，有朋友也给我发过邮件询问详细做法，我都是直接将其他人的Blog文章发过去。

在产品开发中，我发现了整合native程序时的一个小问题，在其他Blog上都忽略了这个问题，那就是整合后的程序在Google电子市场上对设备没有正确过滤。正常情况下，使用AIR开发的Android程序，要求系统必须是2.2及以上版本，且CPU必须是ARM v7或更高版本，但是有些手机，比如HTC Legend，可以升级到2.2，但仍不能跑AIR程序，因为CPU版本低了。而使用Flash Builder或Flash CS5等发布的AIR程序是可以正确过滤的。

如果使用apk-tool反编译AIR的安装apk文件，或其他AIR程序的apk文件，或发现其中有了lib目录，下面有个库文件：lib/armeabi-v7a/libNativeABI.so，从文件名分析，这个库应该是用来判断CPU型号的库。只要将lib目录也一并打包到apk中，即可正确过滤所有设备。

PS，如果我们用apk-tool解包AIR的apk文件，还能看到很多有趣的东西，比如AIR中CameraUI，CameraRoll，StageWebView的代码。

AIR Android开发（二）关于程序的版本号

walktree — 2011-02-24 10:59

在发布程序时，需要设置版本号，需要注意这里有两个地方要设置，一个是version，一个是versionLabel，这两者有什么区别？

如果你的程序是上传到电子市场上，那就要格外注意了。第一个参数是系统用来识别程序版本之用，为整数，每次升级程序这个值必须比上一个版本大。另外，这个值采用的是 000.000.000的格式，1.0.0表示是1.000.000，而不是1。

在Google电子市场，上传程序文件时，系统会验证这个值，如果非法，比前一个版本的要小，都会提示错误。

第二个参数，是供显示之用，字符串格式，比如 v1.0，v0224等等，可以随便点。

在产品开发中，版本号的管理也是非常重要的。

人生就是不断重构

walktree — 2011-02-21 21:15

最近负责的项目，已经进行有接近半年的时间了，中间经过很多曲折，过程大约是软件开发的典型路线，曲折不优美。对于某些问题，我用了有点变态、非常规的解决方法。

随着项目的持续，代码量的增加，如何高效的维护成了一个重要的问题。解决方法无它，不断整理调整结构，也就是所谓的“重构“。

在我开始写代码时，我并不确定自己会在这条路上继续走下去，或者说，我不确定这就是比较好的选择，直到有一天，我有意识地开始审视自己编写的一大段代码（其实也就一、两千行而已），重新组织代码、设计结构，我找到了一点感觉。

直面自己以前的代码，犹如直面自己的回忆，好的、不好的，这个过程都值得珍惜，只有这样，才能变得更好。

祝福（读我博客的朋友，你懂的！）

walktree — 2010-12-31 17:38

var s:String = "78 DA 7B 36 6D C3 D3 9D 5B 9E EE 5F FD 64 E7 04 45 00 44 76 09 1C";
var stream:ByteArray= new ByteArray();
var arr:Array = s.split(" ");
for (var i:int = 0; i < arr.length; i++)
{
stream.writeByte ( parseInt(arr[i], 16) );
}
stream.uncompress();
trace(stream);

让那白马飞一会

walktree — 2010-12-30 14:02

白马也，白驹过隙的那匹，跑慢点，多飞一会，别一不留神就到了2012了。

2011年，有新的打算，就是开始一段新的历程，到底做什么还没想好，可能是写一部酝酿了好多年的侦探小说，也可能是别的，总之就是，make the change。

我翻阅了以前的博客，发现有几篇是这样的，***之一，然后后面就没了。比如AIR Android开发之一，然后就没了。这个习惯很不好，有了之一，起码得有之二才行，来年一定把之二补上，随便写点什么，滥竽充数，非弄个之二不可。

AIR开发新浪微博Android客户端

walktree — 2010-12-08 12:26

新浪微博提供了AIR的SDK，这给Flash开发者提供了开发机会，目前AIR已经支持Android平台，针对iOS和Blackberry的开发工具也在更新中，如果能使用新浪提供的SDK开发移动应用，还是很有吸引力的，毕竟微博现在已经成为了时下最热门的web站点。

不过如果直接使用新浪提供的SDK来开发Android程序，还需要做一番DIY。上次为了参加上海的Flash技术交流会，我准备了一个Demo，就是使用AIR为Android开发新浪微博客户端，花了点时间将新浪的SDK作了一番修改，解决了一些问题，这里分享下其中的过程，如果有朋友有兴趣做类似的事，可以省一番功夫。

新浪微博的SDK，提供了两种远程登录方式：

1. 通过常规的HTTP请求来验证，客户端将帐号和密码发送至服务器端进行验证，客户端接收返回结果。这种方式简单易用，但缺点也是很明显的，那就是不安全，首先客户端需要获取帐号和密码，然后再发送情况，所有的请求都是明文，而且如果有恶意程序，那账户的安全没法保障，因此，这种方式是不推荐的。

2. 通过oauth协议，这可以说是目前最流行的方式，Facebook、Twitter等都采用了这种方式。如果不了解oauth协议的详情可以google。使用oauth协议的一个好处是第三方程序不会接触账户信息，登录过程是在服务器的网页上完成的，整个过程安全、简单。通过验证和授权后，第三方程序才能访问服务器上的数据信息。

使用oauth协议，在验证账户时，需要打开服务器上的登录页面，用户输入账户密码登录成功后，再回到程序。

新浪的做法是，打开浏览器进入到登录页面，登录成功后，显示一个pin码，然后用户手工将pin码输入到客户端页面，再进行验证。然而，这一过程在手机上很难操作，基本上不具备可用行。

为了自动获取登录成功后的pin码，最好的方式是AIR程序中直接嵌入网页，并且能捕获到登录成功后的pin码信息。幸运的是，新浪的API提供了这种可能性。

在demos.zip中，有个QuickSharePhoto，是使用Flash Build Burrito开发的微博客户端程序，可以拍照，发送微博，其中包括了改动后的新浪AIR SDK。主要的修改在com.sina.microblog.MicroBlog这个类中，使用了AIR Android特有的StageWebView来实现嵌入浏览器页面这个功能。

http://www.fluidea.cn/20101128/demos.zip

昨天的技术交流会

walktree — 2010-11-06 23:38

昨天去参加纬度网举办的技术交流会，活动组织的很不错，也有幸认识了一些久闻大名的同行，见到了在网上认识很久的Y.Boy，还有维度网的老大。

不过略有遗憾的是，演讲时感觉发挥的不够好，一些计划内的东西没讲出来。下午有段时间困得厉害，有时候直接忘词了，口误比较多。

附上ppt和demo程序：

ppt: http://www.fluidea.cn/20101128/ppt.zip

demo: http://www.fluidea.cn/20101128/demos.zip

ppt中可能有不准确或错误的地方，可以给我发邮件或加Gtalk：walktree#gmail.com

谈AIR Android开发（一）

walktree — 2010-10-12 11:08

这段时间使用AIR开发Android程序，有些经验收获。手机开发和桌面、web开发有很大的不同，我觉得有两点比较明显，这两点，在程序设计过程中，要时刻放在心上：

一、受限于有限的资源。狭窄的手机屏幕，即使像Iphone这样的手机，盯着屏幕的时间稍长，眼睛也会感到疲惫；cpu、内存、带宽等资源等和PC无法相比。这些都对程序提出更高要求，性能优化，会占到很大的比重。

二、相对复杂的运行环境。在设计程序时，系统来电、屏幕锁定、电池、网络状况、分辨率...，这些因素都必须考虑到。有时候，即使是一个很简单的应用，也可能会比较复杂。

转到正题上来，AIR开发Android手机程序时，程序一般要实现以下功能：

1、处理状态，程序时刻要保存当前的状态，因为程序随时可能被终止或者转入后台，也可能随时被激活。这个可以通过事件监听来做到：

NativeApplication.nativeApplication.addEventListener( Event.ACTIVATE, appStatusHandler );
NativeApplication.nativeApplication.addEventListener( Event.DEACTIVATE, appStatusHandler );

2、实现多屏操作，也就是Multi-Screen。

观察手机程序，会发现一个特点。从UI角度看，每个功能操作页面往往可以独立，这样方便加一些转场动画，程序看起来比较酷，另外，将程序拆分为多个Screen，且每个Screen保存自己的状态，对于处理全局状态，会比较容易，也算是很面向对象了。

3、处理系统事件，最常见的就是Back和Menu按钮事件。

使用Back按钮是程序中常用的操作方式，符合用户的使用习惯。如果要很好的处理Screen之间的切换，就需要在设计时就考虑清楚。

Menu，应该是Android特有的处理方式，使用AIR来表现Menu是没有问题的，关键是要根据不同的状态给出不同的Menu，这同样和Screen的设计息息相关。

NativeApplication.nativeApplication.addEventListener( KeyboardEvent.KEY_DOWN, onKeyUpHandler );

function onKeyUpHandler(e:KeyboardEvent):void
{
    switch( e.keyCode )
    {
   case Keyboard.MENU:
        //显示自制的menu
        break;
   case Keyboard.BACK:
        e.preventDefault(); //什么时候阻止系统默认事件，什么时候不阻止？是个问题
        break;
   case Keyboard.LEFT:
   case Keyboard.RIGHT:
   case Keyboard.UP:
   case Keyboard.DOWN:
        //响应方向键
        break;
    }
}

4、UI。目前来看，还没有成熟的UI框架可用，使用Flash CS组件或Flex组件并不是很好的选择，会碰到这样或那样的问题，因为这些组件都没有针对移动设备进行优化，举个简单的例子，List组件，在手机上，滚动条并没有多少价值，对触摸屏来说，最便捷的操作方式是拖拽，滚动条很小，手指都很难点上，没什么意义。

这里推荐：
仿Android皮肤组件，http://blog.kevinhoyt.org/?p=548
as3flobile components，http://custardbelly.com/blog/?p=173

在这个页面http://www.adobe.com/devnet/devices/fpmobile.html，Code samples下面的Control examples，是个很好的例子，千万不能错过。

目前Flex Hero已经放出了开发中的版本，还没有机会研究。不过看了文档，感觉设计思路和我的想法比较接近。

5、可能的话，还有处理自动缩放，包括屏幕旋转自适应，这一点其实和PC上基本相同。对于支持物理感应的设备，还可以加上更酷的功能。

--------------------------------------------------------------------------------------------------

本文系原创，转载请注明出处，谢谢。

First Nobel Prize of Chinese

walktree — 2010-10-08 17:12

And, the first winner in prison.

历史再次被改写！

AIR for Android发布了

walktree — 2010-10-08 15:02

AIR Runtime for Android已经发布到电子市场了，今天试着在线安装了一遍。发布的这个版本也就是9/30发布的版本，应该说，已经比较稳定了，程序的启动速度比较快，但比起Native程序，还是有差距。

八卦一下，这个版本和我有点关系，因为其中的一个bug是我提交上去的，Bug #2723863。

哪些机器可以跑AIR？起码得支持Android 2.2，但支持2.2，并不一定可以跑AIR。看这里（需要登录才能看），按照官方开发人员的说法，需要是ARMv7-A以上处理器的才可以，比如：

HTC Desire
HTC EVO
HTC Incredible
HTC Nexus One
HTC Triumph / Desire / Bravo
HTC Vision Blaze / Desire Z
HTC Ace / myTouchHD / Desire HD
HTC (T-Mobile) G2
HTC Merge / Lexicon

要求还比较高，Adobe的东西总是让人觉得有点不舒服。

不管咋样，这东西出来了，好歹也是个进步。电子市场上已经有几个AIR程序出现了，还是有不少支持者！

敲敲代码，看看文人八卦

walktree — 2010-10-06 19:05

《民国风流》，是我LP的新书，已经上市。

在介绍这本书之前，容我讲一个小故事：

一年前，某一天的中饭时间，几个同事（一群程序员）照常在以前吃饭，闲聊的时候，某位年长的同事，习惯性地开始讲一些历史人物故事，忘了是什么原因，讲到了廖仲凯，还有何香凝，然后我插了一句，大约是说何香凝和廖仲凯这对夫妇的传奇爱情之类的话，我这位同事惊奇地说，他记得何香凝是廖仲凯的妈。他的语气很肯定，而我也不是很有信心，于是脸红着说自己大概是记错了。

后来，我回去google之，大笑。（不明白的请自行google)

---------------------------------窘迫的分界线-----------------------------------------------------------

讲这个故事，是想告诉我的同行们：为了避免我和我的同事们这类尴尬，买本《民国风流》，时时翻看，多了解些民国八卦，是非常有必要的。

这本书花了半年时间，期间修修改改，花费了很多心血，内容是很丰富的，看了就知道，我就不多说了。有兴趣的朋友支持下，先谢谢了！

详细介绍看豆瓣：

http://book.douban.com/subject/5299120/，目前卓越网已有售。

盗梦空间

walktree — 2010-09-06 22:43

周日去看了早场的《盗梦空间》，中途憋尿，出来了片刻，回去后，发现还在枪战，甚感无聊。总的来说，比较好看，场面宏大壮观，Leonardo的情感戏演绎很精彩，由于事前看到了太多的好评，看完略感失望，觉得并没有传说中的那么好。

Leonardo最近拍的电影，都很不错，比如《禁闭岛》，其中有复杂的心理戏戏分，比《盗梦空间》中的要来得曲折多变，更好看。压抑的时候压抑的透不过气；爆发的时候像火山喷发；也有平静下的汹涌暗潮，相比起来，《盗梦空间》里的心理戏只能说吸引人，我觉得是可以更好的。

我觉得《盗梦空间》最好看的地方，还是在于导演的想象力，天马行空，但看上去又逻辑性极强，也就是所谓的“高智商”。制造梦境，而在梦境中虚拟出显示，还有人本能的守护行为，应该是电影中最有意思的地方。高智商，加上逼真的视觉效果，确实看的过瘾。

另我感到最不爽的是冗长的动作戏，感觉像是为了拖延时间，凑戏分。影片后期，无休止的枪战和飙车戏，单调，简单，和整个戏分有点不搭调的感觉，一段复杂的枪战场面，看的人都快睡着了，很失败。还不如请个国内的动作指导，比如某某大哥，摆弄几个很酷的造型，那样更有观赏性，还能兼管中国市场，何乐而不为。

Android上的实验：AIR与本地程序通信

walktree — 2010-08-31 10:40

事实上，标题有点不准确。

几天前，AIR2.5发布了新的版本，Adobe称性能有了很大提高。提高了多少？哪里提高了？这个需要去实验才知道。

三个月前，在prerelease的论坛上，有位仁兄做了个实现，https://prerelease.adobe.com/project/forum/thread.html?cap=E30C51D41E3B4960BC4F1EBD76BEE24D&forid={DE38C2EF-3575-45B9-9320-F3D03884447D}&topid={C7E7AC43-D63B-4A68-8112-FCEB5F51CA48}，很有趣，创意非凡的Idea，连Adobe也没有想到。

昨天终于有时间试了一把，在最新的版本上，运行良好，效果非常好。将本地程序和AIR程序打包在一起，然后两者使用Socket通信，这样，很多AIR无法实现的功能都可以通过这种方式实现。

Android上的AIR开发笔记

walktree — 2010-08-15 23:37

在Android上使用AIR开发已经有一段时间了，感觉还不错，当然，遇到了一些不太友好的问题。目前AIR 2.5还在prerelease的阶段，目前大约2周时间就会发布一个新版本，更新速度很是比较快的，这也说明目前的版本还不是很稳定。

从7月5日发布的版本到现在，就我的发现来看，一些bug被fixed，比如使用了Spark组件的Flex4程序不会crash了，Flash CS5的对app-xml的支持更完善了。另一个目前混乱的问题，是关于硬件加速的问题，官方声称目前已经支持这个功能，可惜我到现在还没有找到详细的说明文档。再，有两个比较大的问题，目前还一直没有解决：

1.使用Flex框架的程序中，如果有文本编辑类组件比如TextInput，当组件失去焦点时，虚拟键盘不会自动消失。这应该和组件的内在机制有关系，很可能其中的某个鼠标事件在移动设备上没有得到支持，而导致无法正确处理焦点事件。

这个问题我想只有在下一代的Flex框架中才能得到完美解决。

2.在播放H.264格式的视频时，性能很差。在Know Issues中，关于视频的Bug一直存在。不过在Nexus One上，使用浏览器看视频，性能却比AIR程序表现更好点。

说到Nexus One，确实是款很不错的手机。IPone我只是看过两眼，没有机会仔细研究。拿到Nexus One已经有一段时间了，性能确实很强劲，Flash Player 10.1的表现值得期待。

why and what

walktree — 2010-08-06 09:31

读到一篇文章，作者谈了一些关于Google Wave倒闭的看法，很值得一看。其中，他的另一篇很早的文章，是关于焦虑的，也很值得看看。

早如今这个的年头，节奏太快，很多时候觉得自己很忙，但仔细想想，却觉得都是些无足轻重的事情，而反而真正重要的事情，却一点进展也没有。

IPad确实很好，有人计划用它来当电子阅读器来使唤，买之前想象着每天躺在床上看书的模样，当买了之后，发现自己只是把它当个游戏机，上个厕所也不忘在里面晃来晃去的。

IPhone是个电话，即使它也可以玩游戏，听音乐，拍照，看电影，聊天，但你用的最多的，还是电话和短信。

Kindle是个阅读器，如果可以玩游戏，听音乐，看电影，那它就是IPad了。

所以，功能多未必是好事，一个东西为什么存在? 只因为它做了该做的。

-----------------------------------------------------------------------------------------------------

经测试，发现上面的链接被墙，需要翻墙可以看。

也许有一天，我也忍不住要去买个IPad

walktree — 2010-07-26 10:17

在大约一周前，同事拿到了IPad，因为有一个应用要迁移到IPad上，等了一段时间，设备终于配下来了。以前一直对IPad有点不屑，可能是由于Apple与Adobe的嘴仗吧，毕竟我也是靠Adobe养家糊口的，但是，玩弄了一把IPad后，还是狠狠地被震撼了。

今天读到一篇文章，Surprise, I’ve bought an iPad，这位老兄，呃，可以算是Adobe技术传道士吧，但最近Blog中Apple出现的频率是越来越多了。

有位回帖的愤青如此形容Flash：It’s a resource pig, slow, bloated, and insecure. 他对Flash的厌恶已经无以复加了。