手机应用软件项目设计备忘——J2ME版

[fangtian3133]

手机应用软件项目设计备忘——J2ME版

手机软件开发也做了快6年了，在项目设计中遇到一些问题，也许是大家也遇到的，记录下来，作为经验备忘，和大家一起分享。下面以一款手机收发mail的软件为例子说明一些问题。
引言 ‘设计’这个事。
很多人问我手机软件怎么优化？我一般会问他：“项目进展到什么程度了？”。如果项目刚启动，好，这就是最好的优化时机。如果项目到代码都已经写完开始适配机型的阶段，那你基本已错过最好的优化机会。宜未雨而绸缪，毋临渴而掘井。

备忘一，不是一个部门的事。
借盗墓之语：手机软件开发不是请客吃饭，不是做文章, 不是绘画绣花,不能那样雅致, 那样从容不迫,文质彬彬, 那样温良恭俭让，手机软件开发是一个公司行为，是一个公司各个部门，成员相互作用的结果。
手机软件开发绝不是开发部门自己的事，一款手机软件从公司业务说，它是公司经营的一个产品，从产品的起始（需求，定位，创意，立项）就不单是开发部门自己说了算的，它是公司经营决策所决定的。将要开发的产品是一款什么样的产品，它的定向，定性，目标，直接影响着开发的方向，工期，和用什么样的方式来解决开发中的问题。
如果上面说的是公司和市场之间的博弈，那么还有另一种博弈。伟人说过：有人的地方就有斗争。一款产品的产品目标制定出来后，在进行技术目标分解时，同样是各部门相互左右。比如：用手机接受邮件，如果手机客户端部门强势，会要求服务器端不管连接什么样的邮箱返回统一的格式，把邮件解析放在服务器去完成。如果服务器端部门强势会要求手机客户端去解析邮件，服务器只提供邮件的传输。
说这些可能让人有些无奈，不想说教企业政治，但请注意你不是一个人，如果自己是对的，请坚持你的观点，但要放在整个事情当中找到，做到自己的观点。
备忘二，堆栈还是链表。
现在来说些具体技术问题。在一个界面用户点返回按钮时，怎么处理返回上级界面？我们针对不同的情况可以采取不同的方法。
1， 界面跳转是固定的，界面的数量不多。
这时你可以选择状态机机制，把界面跳转写成不同状态，根据这些状态来进行相应的跳转。
这种方法的好处是当你面临上面条件时容易实现，容易控制，而且如果不是需求有大变动也具有很大的灵活性。
2， 界面跳转是不固定的，界面的数量不多。
这时你可以做一个界面流的堆栈，用户浏览的界面一一入栈。当用户点返回时，在从栈中弹出。这样做的最大好处是可以省心界面的层级，管它浏览多少级，直接入栈，而且界面的状态也可以随着保留。但相应的需要付出额外的堆栈管理，比如用户有跨级浏览时，就要清空堆栈。
3， 界面跳转非常不固定，界面的数量又多。
这时你可以把每一个界面当成链表中的一环，每个界面保留它的上级界面链接。当用户点返回时，根据界面的链接做相应的处理。这样你就更不用管用户的操作顺序了，让他想怎么点就怎么点，想怎么返回就怎么返回。呵呵。但相应的你需要做的管理工作也会更多一些，比如设计的不好，会导致一些内存消耗了，数据状态混乱啊，等等，那是很麻烦的。
备忘三，界面数据的携带。
上边说了界面的后退，我们再来说说界面的前进。当一个新界面需要上一个界面的一些参数时，这些参数怎么传递给新的界面？界面不只是显示的通道，也许我们可以在界面中建立一个数据的通道，当然这个通道时轻量级的通道，主要通道还是数据层和界面层之间的通道。我们可以把上个界面的参数打一个通用的包，传到新的界面，新的界面来解析这个包。像android的intent一样。这其实不是什么特别的想法，但是这有助于清理思路，更简单的构造数据模型。
备忘四，任务的级别。
我们来看一个例子：用户在手机端写好邮件以后，向外发邮件，假设有3封邮件要发，应该怎么处理呢？看下面两种处理方法。
方法1
主处理线程
{
case 1: 发送邮件方法（）
…. {
brake; for( 检查邮件发送队列是否发送完毕)
case 2: {
…… 发送当前邮件
brake; }
case 发送邮件 }
发送邮件方法
brake;
}
方法2
主处理线程
{ 发送邮件线程
case 1: {
….. 1，邮件队列整理
brake; 2，按队列发送邮件
case 2: 3，传递发送状态，处理按键
…… …….
brake; }
case 发送邮件
显示发送进度和提示信息
brake;
}
两种方法都可以发送邮件，最大的区别在于对发送邮件这个任务的级别判断。方法1中，认为发送邮件是一个级别比较低的任务，所以只用了一个简单的循环体处理；方法2中认为发送邮件是一个级别比较高的任务，所以用了一个后台线程去处理。
通常低级别的任务是不包含其他任务，具有不可再拆分的特性，所以我们可以把它对应成单独的方法，我们不需要过多的控制。级别高的任务往往是一些简单任务的组合，需要我们加强控制。比如上面的例子。发送邮件，初一看是一个简单任务可定为低级别的任务，就发邮件嘛，于是把它对应成一个方法。其实发松邮件这个任务其中还包含了对发送队列的管理，在发送邮件过程中于界面的交互，在发送邮件过程中对按键的响应等，这就不是一个简单的低级别的任务了，所以对应了一个后台线程。
在设计时对于任务的级别判断会直接影响我们的处理逻辑。所以在软件设计阶段认真分析这个软件所要完成的功能，这些功能需要执行什么样的任务，这些任务是什么样的级别，我们要怎么处理这些任务。软件的处理逻辑大多来源此时对任务的分析。把握好了任务的级别就能帮你梳理软件的处理流，而且还能帮你规避掉一些后期才发现的控制点上的失误。比如上面发邮件，如果采用方法1，当用户按取消按钮时，怎样处理？如果采用方法2，就有明显的按键处理位置。
任务的级别判定如此重要当然值得我们下些功夫来分析它。分析好任务的级别后，我们要做的就是规划这些任务的执行顺序。准确的级别判定，加上合理的执行顺序是保证我们的处理逻辑流畅的条件之一。
备忘五，服务线程。
如果在你在手机软件里设计了后台服务线程，比如预处理一些将要显示的数据。有2点要注意：
1， 这个服务线程是一旦启动就不退出，一直在等待执行，还是触发启动，执行一次就结束。
2， 如果某个操作依赖于这个服务，是否有条件判断这个服务已经完成。

以上几点笔者记录下来，希望对朋友们工作有所帮助，其中观点也不尽完善希望和大
家一起交流，我的msn: fangtian [e-mail]。
关于序中有乱
我们在设计软件的时候究竟是从那个层次切入呢？其实我们是在做一个序。打个比方：给你一艘船，一堆货物要装到这艘船中。这时我们要做的不是直接去装货，而是定制一个个货柜，让那些货物装到货柜中，然后把货柜码好。这个货柜就是序。乱中有序，序中有乱。我们的切入点就是这个序。

[doney_dongxiang]

的确 一个项目 不是研发部门的事情，而是公司的事情，一个项目的开启，更要了解市场与项目之间的博弈。

不要像我们，老板一句话，两个人 就要做个面向各个行业的自定义报表，真是头大

[fangtian3133]

回复6楼
我们在用堆栈存储页面的时候，其实保存的是用户的一个操作流程。你上面提到的问题，需要判断一下，“点5键跳转操作”如果还在当前流程之内，那就继续入栈，如果不在当前流程，就需要清栈，开始一个新的流程。这时如果分不清情况，问题可能就不是程序的问题，是产品策划的时候操作流程策划失误。

[fangtian3133]

我的msn留错了，不好意思。应该是:[e-mail]

[zhanmeicq]

学习，谢谢分享

[lc402431247]

MARK。

[shao_luck]

学习，谢谢分享

[softice_]

太好了，谢谢楼主分享，即使像我这样的初学者，也能从中获得许多启发

[浩_林]

lz的这些经验很受教。 第2点"堆栈还是链表"
我也遇到过这样的尴尬：
对于页面之间有直接联系的保存一个状态参数，然后触发下级页面，返回时也根据传递的参数继续访问上级页面。这样我觉得是可以，但是 我不知到lz 有没有碰到过 既有快捷方式（如 在某页面 直接按数字键 “5”跳转到某一功能页面）又支持这种符合逻辑的 跳转页面 。
在这两种状况下假如 用堆栈或其他存储，我觉得会很消耗内存。不知lz有什么高见。。

[sforiz]

谢谢分享