SharedObject多人聊天室完工

其实 SharedObject 用法很简单，客户端声明一个 _so，然后服务器端随便开个应用——比如范例里的SOSample，其实直接指向了ApplicationAdpater——连接起来，侦听 SyncEvent.SYNC 事件，就可以了。

结果我仍然花了1天多时间才弄好，而且最后都不知道哪儿出错了。现在虽然程序运行正常，但是我还是不知道原先错在哪里……

在这个应用中，我设计了两个slot（共享对象的一个概念，其实就是一个变量）：String onLineList，这个字符串用来存储在线列表；Object msg，这个对象用来存储发言，其中又有3个属性userid、command、msg，其含义如其名。

某客户端连接服务器成功后，会调用服务器的 refreshOnlineList 方法，遍历所有的客户端后生成字符串，更新到so的onLineList里，然后就回同步到所有客户端。某客户端断开也是一样。

发言时，客户端直接更新so，生成msg对象并赋给so，然后自动通过服务器同步到所有客户端，完成一次发言。

运行通过，测试了下没什么问题。不过因为公司没有对外的red5服务器，所以demo只能对内。那么放一点截图吧，虽然比较丑……


既然说这个东西很简单那为什么会弄这么久呢？事情多当然是一个原因，还有一个原因就是莫名其妙的bug。

首先我google到一些资料，说as3的Array对应java的LinkedHashMap，所以我上去就直接生成一个map然后赋给服务器端的so，然后就死循环，java在cpu占用100%，直到我关闭它。反复尝试之后，决定还是用字符串切割来做。

然后我想到，服务器端有个appConnect事件，在客户端连接时触发，把so更新直接放在这里，省去客户端连接完成后再调用这步，可是结果一旦所有客户端都断开，服务就死了。Jim怀疑是session的问题，但是我把so改成persistent（永久型）也不行。

最后，每次appConnect的时候，用来存客户端的map都已经更新了，但是我遍历去取得时候总得不到当前连接。但是等so也连接完毕再取就没问题了。

三座大山，哎，于是只有从旁边绕过去，还好效率上没有什么太大的差异。近期太忙了，今儿一天就8个专题，算上蜂鸟包版就9个，实在没时间慢慢琢磨，先这样继续推进吧，说不定哪天正确答案就自己蹦出来了呢。

下一步：stream
stream即流，显然是流媒体的重要组成部分。视频/音频的播放都依赖它存在，很多独特的应用也很突出，比如：视频会议，语音聊天等。下一步就把它的应用琢磨一下。