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

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

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

原文在这里。

这两天试用了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与本地程序通信，也就是使用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的代码。

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

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

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

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

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

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

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

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

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

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);

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

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

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

新浪微博提供了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

 昨天去参加纬度网举办的技术交流会，活动组织的很不错，也有幸认识了一些久闻大名的同行，见到了在网上认识很久的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