Metro Music for Android 第一个公测版后总结

        这是有多少的历史性呢？我总觉得自己做完了一件事情，虽然不是永远地做完，因为后头的事情有很多         起码算是自己做完了一个产品吧，而且会使用了git。在mac和windows下调试、编译都没有压力。跨平台的JAVA果然还是很犀利的。无可比拟。前几天在人人上看到unix主页君很狂。一开始觉得很不服气。后来，没办法了，算了，人家狂也是因为人家牛X，牛X就有骄傲的资本。我服了。也因此，我决定慢慢放弃windows平台。windows平台日常的易用性是别的平台无法比拟的。但是，它不是一个适合程序员的平台，所以，要想再更上一层楼的话，那只有转战自由的、高伸缩性的类UNIX平台。因为自己有mac，所以mac os这个堪称完美的操作系统，应该是我第一个学习目标了。学校网络的限制，我只能在虚拟机里安装ubuntu  不然上不了网。。。浙江特有的情形，呵呵。

        废话说多了。总结下感触吧。Android的系统架构上，设计的UI线程是一个独立的主线程。这一设计也许很早就有，但是我在桌面编程的时候却没有发现，大概是我没有仔细注意这一点，Android很好地利用了handler解决这一个问题。至于代码设计上，我自从上次Swing项目得出经验后，自己悟出了一点MVC的模型。因为安卓没有一个在SWing中启动的main函数，所以Controller不能外置，我就把它放进了Activity里。既然Android里基本组件的生成和销毁都不是程序员来控制，那么生命周期的控制就起到了很大的作用。Activity的生命周期在这就不贴出来了，谷歌下非常多，我记得Android Developer上有一个专门的图介绍它。

        这里有一个心得 有时候按钮操作后，需要长时间I/O的操作，可以模拟基本组件中的Listener方式进行回调是一个很好的方式，在这个过程中，按钮不能马上可用，因为如果马上可用的话，会触发下一次I/O操作，最终导致程序crash，我采用的方式是将按钮Disabled掉，然后等线程回调之后，再传消息给Handler Enable它，整体流程是这样。

        Media Player这个组件有点变态。一开始在LG P970上测试的时候，发现，竟然会无限出发OnCompletion。我一直找不到原因，我猜想是不是Buffer还没到底，却播放到底的原因呢，然后我在OnBufferingListener中，将position改到50的位置再触发mp.start();而不是在OnPrepare中（prepare过程是异步的）。这样一开始好像好了点，但是，在点下一首多次以后，竟然发现还会触发原来的问题，我彻底崩溃。后来去找源码，因为源码的框架实在看不懂，依然无果。抱着试试看的心理，去看了下OnErrorListener中，有这么一个说法：

public abstract boolean onError (MediaPlayer mp, int what, int extra)

 Returns

True if the method handled the error, false if it didn't. Returning false, or not having an OnErrorListener at all, will cause the OnCompletionListener to be called.

。。。。。好吧。好像找到了救星。在匆忙的情况下，我直接加了这个listener然后什么都不处理返回true。

。。。真的行了= = OMG。。。 

接下来就是BUG的问题了。今天早上发现了一个登陆之后的BUG。还想不出具体原因。

这几天会看一下Objective-C。准备进军iOS。顺便在Android平台上修正好BUG，实现正常的功能。

相信自己是很犀利的！加油