移动书店
参加了MOTOROLA的新亮点挑战赛，没有入围，还是写出来吧，算对自己有个交待。 做<移动书店>的主要原因是为移动拍卖平台做准备，现在这个也没法做了，唉。这个系统是spring+hibernate+j2me，数据库 用的是大象PostgreSQL 8.1，开始时候用的mysql，结果到最后出现BUG，郁闷了我好几天，还好大象能用。从33月份开始做，到5月末基本结束，6月看了个世界杯，到7月 实在不爱弄了，随便测试了几下，弄点测试用例，文档都是抓图。在整个过程中有几个难点的地方，大概1个是hibernate颗粒度和j2me的一致性问 题，1个是j2me做缓存于分页时的问题。隔太久想不起来了，边写边想吧。
首先这个软件要完成的功能是网上买书，类似在线购书的功能基本 上都可以实现，用户可以通过手机而不用电脑可以查书，买书，评书，可以下订单，查询订单，基本上满足了用户需要，完成度还是比较高的。没有对安全性做过多 的处理，1方面需要加密的数据十分少，2来做https的协议怕时间上完不成，本来想做完有时间就试试，结果赶上万恶的世界杯。。。开发环境是 eclipse，虽然官方要求用NetBeans，可没用过也不爱用，eclipse+eclipseMe+MyEclipse,myeclipse不知 道用到多少功能，用着用着就不好事了，后来都是ant解决的。
首先这是开始菜单，没工夫做9宫图，用个list了事，一样方便。
这里基本上是按照SmartTicket的套路，MVC，多线程，查询表，想必这些都已经是J2ME做软件的经典套路了。进入之后是两个进程，一个用Gauge显示进度，另1个做网络通讯获取数据。这里测试用例很简单，只分了几个类：
别看少，手工输入起来够我受的，各种数据。。。
然后得到图书列表，懒得找书，就用了一个原是数据做了循环
这个列表做了缓存。只在第一次访问时候到服务器取，后来都是到RMS。
选择一本书进入：
这里只选取了典型数据，像什么“字数”的就懒得做了。每本书都做了缓存。由于屏幕有限，所以书的信息可以做成用户定制，只选取用户关心的数据。这里没有实现这个功能，有所保留。
然后是详细的信息：
显示封面有些问题，下面再说。书评，勘误，打分，基本满足需要吧。
然后是查书：
挺好用的。当然可以做的更复杂，我这里做的不好，耦合太多，因为闲麻烦，针对hibernate翻页传递了几个参数，不通用，如果后台换掉hibernate，这里就不好弄了，下次改进，如果有下次的话。
购物车：
购物车里的项显示起来比较别扭，当买了几本书的时候，名字又长，数量和价钱就会显的很乱，用ChoiceGroup也没有更多的办法。
查询订单：
自己YY的订单形状，可能这些信息够用了吧。买过的书也都有记录，可以查询，跟这个类似，就不贴图了。
书店信息：
把 焦点放在电话号码上理论上是可以拨号的，不过模拟器不支持，不知道烧到手机中能行不。用了缓存，因为想到用户如果是到银行汇款，那么打开手机查看书店帐号 的时候，如果需要上网可能没有信号，所以做成脱机的，可脱机的不知道书店什么时候会更新导致数据不一致，所以加了一个“更新”按钮，手动更新。由于 http连接没有推技术，不能自己更新，只好这么做，当然要用注册机的话比较先进，可我费劲。要说可以用注册机的地方多了去了，书店发货的时候可以发一条 通知手机开机，要不发短信也行。如果现实应用的话，很多地方还值得推敲。
书店新闻系统和系统属性：
做的很简单，要复杂的可以用走马灯在顶上做广播，属性也可以做得细点，包括上面说得用户定制书目信息。
用户注册和登陆窗口：
注 册的邮编地址什么的在提交表单的时候会自动填入，在涉及到个人信息的时候都会要求先登陆。这里如果不是自动登陆，那么手机不会保存任何用户信息，所以说是 非常安全的，除非你刚登陆手机就被人抢了。如果是自动登陆，当手机丢失的之后就处于不设防状态，个人信息，电话，住址什么的都是存在服务器端，但这时密码 还是安全的，得不到密码只能使用也不能更改，如果有个GPS什么的就好了，可以把小偷的位置传到服务器，没准还能抓到。当然要改进这个也非常容易。比如加 开机密码，到服务器端验证，那么即使别人捡到手机，也进不去。所以这个系统没有做本地加密，因为我找不到需要加密的数据。要说不安全，只有连接不安全，用 https就好多了。计算方式这里比较模糊，如果是传统的到邮局到银行汇款那么没有任何问题，如果是直接通过手机进行银行转账那么就需要很小心，这里我没 有做这些东西，因为我不清楚到底会是怎么转。如果把个人信用卡存在本地，那么会危险一些，即使加密了；存在服务器端用户自己不放心，书店也不放心，所以这 个基本不存在可能。所以我试想会不会有种手机钱包什么的，对应到手机上，然后让客户输入手机银行的密码进行转账，这样可能安全些，但具体是什么样我也不清 楚，就想象了一个“手机转账”。平时没消费的习惯，对这些不了解，可能已经有一些合理科学的方式存在吧，呵呵，当然一切都是建立在连接安全上。
j2me本身很简单，这里看图就可以知道大部分情况，里面复杂的地方就是缓存。如果只是单独做一下缓冲那么很容易，但为了保持数据的一致性使事情复杂起 来，有些时候不禁要问，这个到底用不用缓冲。开始的时候觉得可以为用户省钱，什么都 缓冲，后来考虑分页的时候，对缓冲的算法提出了更高的要求。首先很多活动使需要验证用户是否登陆，这里又分成几个步骤，首先在一个全局变量中判断是否登 陆，如果没有登陆在系统属性里找到是否自动登陆，如果是自动登陆那么需要到RMS中找到相应的位置，提取用户名和密码，那么还要判断这个用户名和密码是否 有效，如果无效则转到登陆界面，重新登陆；有效就用这个在背景里练到服务器验证。如果 没有登陆还需要注册那么就先注册再登陆，然后再回到原始菜单，这里有个栈记录窗口顺序，为了可复用性这里需要很好的设计每个窗口。这里懒得用UML图了， 因为我可能转行了，连程序都不写了。不行，有MM上线了，有时间接着写吧。