七
11
2011
在测试Tomcat对断点续传的支持中发现，Tomcat是支持静态内容的断点续传的，但是，它无法支持动态内容的断点续传。比如我有一些客户定制化数据，只有登录的用户才能下载。如果放在静态目录下，安全就形同虚设。
因此，在Grails中一般要放在WEB-INF目录的子目录下。比如：
这样的内容需要自己创建文件，然后输出到response的输出流上。因此断点续传必须自己实现。
七
11
2011
虽然看Tomcat api中提供了对断点续传的支持。但是要确定下来就需要做实验。
还是借助编写断点续传客户端代码中的示例。另外，启动Grails项目（Grails实现复杂的数据录入），先测试一下静态资源文件：
链接是：
Grails降级后（Grails从1.4m1版本回退到1.3.7）后会不会使用的是jetty啊，测试一下：
日志引用
七
11
2011
在HttpClient下载二进制文件的基础是编写断点续传代码。
断点续传的基本原理是，客户端在发送请求中可加入比如这样的请求头：
Range: bytes=3-
表示，要服务器发送从第四个字节开始的内容。如果服务器端支持断点续传，则返回响应的码不再是200，而是206。并且发送的内容是从第四个字节开始。
下面编写了两段代码，其中第一段，模拟正常请求，但是在读取到11个字节时停止。
日志引用
七
11
2011
使用httpclient编写最简单的应用，获取我博客的主页。
httpclient在：
首先要下载分发包。然后将分发包解压缩，将lib目录下的jar文件，导入到项目中来，比如这样：
七
11
2011
Grails引入了flash作用域的概念。这是很多高级web框架都引入的概念了。在Servlet中没有这个作用域。如果要处理这样的场景，比如更新（新建）表单提交，又重定向到表单页面，用户看不到什么变化。
比如这个界面（详见Grails实现复杂的数据录入），保存前后，都是相同的界面和相同的链接。无法让客户看出是否真的更新了。
七
11
2011
Android的Wifi，默认情况下是不接受组播的，见：http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
默认情况下，应用是不接收组播信息的，这样要接收处理的报文太多，很快就会把电池用尽。要知道移动设备（特指电话一类的，平板要好得多）目前最重要的因素是电量。
要想打开组播功能，有以下几个步骤：
- 在Manifest文件中加入：android.permission.CHANGE_WIFI_MULTICAST_STATE，这个权限
- 获取到MulticastLock对象，这个对象不能直接实例化，要通过WifiManager间接得到，工厂模式
- 调用MulticastLock对象的acquire方法，获取到组播锁
- 相应的，用完组播，为了不浪费电力，要调用MulticastLock的release方法释放锁
下面写了个简单示例，通过组播发现服务器。
七
10
2011
比如，由管理员手工挑选图书的相关图书。从用户体验上，这个选择，应该是异步的。即使用ajax。
当用户在图书编辑页面时，点击相关图书的增加按钮，应该弹出对话框，对话框中包含了可选的备选图书。
这里要保证，如果是编辑（不是新的图书），那么不能包含自身，也不能包含已经选择了的相关图书。
日志引用
七
10
2011
创建和更新实体，是使用相同的视图还是不同的视图。这需要权衡。如果我来写，一般我希望是相同的，即，无论是新建图书还是编辑图书，使用相同的gsp页面。好处是便于维护。如果新建和编辑的流程出入较大，也是出于维护的角度，可能会考虑使用不同的视图。
以下写个简单的使用相同视图实现创建和更新的示例。示例是在Grails开发环境下如何生成模拟测试数据基础上做了改动。
实现的效果类似这样，如果是新增，链接中没有参数，显示空白的表单页面：
否则：
