手机网络应用客户端软件开发实践简介

网络应用与客户端软件

说到移动网络应用,前几年大家首先想到的就是WAP应用。最近随着市场上手机的可编程能力越来越强,手机软件开发平台和产业链的逐渐成熟,手机上的网络应用软件逐渐多了起来,如移动QQ、PICA、掌讯通等等。这些客户端软件凭着丰富的应用、以用户为中心的体验、良好的业务感知度逐渐成为WAP业务之后的又一类重要网络应用。目前的移动软件开发已经逐渐从传统的嵌入式开发中相对独立出来, 主要指手机上的上层应用软件开发,最近也成为了软件行业的新兴热点。

作为业务运营的手机网络应用客户端软件要求能够部署到大量的手机终端,并注重和网络服务器端业务的结合,目前这方面的开发参考资料还比较少。本文以手机报项目为基础,简单探讨一下手机网络应用客户端软件开发实践中的几个关键问题,希望对新进入者有所帮助。假设我们需要开发一个高可用的手机网络应用客户端软件,用于在线定购和阅读电子报刊业务,覆盖目前移动梦网用户中占有率最高的几十款手机,下面结合KJava开发介绍一下我们的一些实践心得。

用户界面设计

问题:目前很少有人有手机客户端软件的用户界面(UI)的设计经验,UI设计开发的原则和流程是怎么样的?

手机客户端软件的UI设计和开发在整个软件开发过程占据相当重要的比重,对于没有相关积累的团队来说,我们估计,软件UI开发占软件全部工作量的40%左右。和其他面向最终用户的软件一样,客户端软件UI设计的原则是:以人为本,保证简单易行的操作方式,同时兼容最大范围的手持设备。目前的手机用户界面主要分为两类:通过导航键单手操作方式和触摸屏方式。这两者在操作方式上有着较大区别,但实际项目中如果软件的UI不是太复杂,出于开发成本考虑,UI设计可以主要针对方向键操作的手机,在此基础上再稍做改动以兼容触摸屏手机,这样也是可以接受的。除此之外,手机客户端软件的UI开发还有如下几点经验:

程序开发人员早期介入

目前市场占有率较高的手机大部分还只提供KJava开发接口,它的高级UI控件很难满足我们的要求,如果要达到设计的效果一般需要直接使用底层API自己实现。在UI设计开发的流程上,对于没有UI开发经验积累的团队,建议在需求阶段以后先进行原型界面开发,一是为了确认用户的体验需求;二是通过开发人员早期介入确保UI设计人员的设计效果是可以在确定的时间内实现的。第二点很重要,在手机这样一个资源和能力都受限的平台上如果仅仅从UI人员的角度去设计界面,很容易导致无法按时实现或者在真机上的效果太差。UI界面开发阶段一般的流程是这样的:先由UI工程师和开发人员自由讨论,定义出UI元素和大致操作流程,接下来是由开发人员进行实现,最后再由UI人员在已经实现的基础上进行美学创作。

建议制定一个适合项目实际情况的UI设计开发流程,注意和UI相关的功能一定要在真机上多测试。

程序界面的有限设计原则

我们的客户端软件不是浏览器,这点要时刻牢记。客户端软件所能处理的服务器端的内容和业务流程都是相对受限的,也正是因为客户端应用软件对于其他环节的限制要求,才能保证客户端应用相对于浏览器应用更好的用户体验。例如,在实践中无论是服务器传回的内容格式,还是客户端界面层次级别,都是可以要求确定的,其他如软件报刊阅读界面上的字体大小、间距、可下拉屏幕的最大长度等都是可以在需求的时候就确定下来的。

支持多款手机平台

问题:KJava平台上的程序离“一次编写,到处运行”还差得很远:不同手机的屏幕大小相差很大,程序需要重新调整界面;不同终端的能力层次不齐;即便是同样的功能,不同型号手机在具体支持程度和方式上也有差别;有些手机终端还有自己特有的BUG。如何让我们的程序支持这几十款手机?

一般在开发的时候我们先基于SUN公司的标准WTK或者是某款非常典型而且移植性比较好的手机(一般是Nokia)来开发一个基础版本,然后在此基础上按照目标终端的大类做移植,再在大类的基础上做更细的移植,移植的过程如一颗树状展开,最后达到支持所有目标手机终端的目的。以下是一些开发和移植过程中的心得。

MVC设计模式 模型-视图-控制器(Model-View-Controller,MVC)设计模式及其派生无疑是UI模型的最佳实践,手机应用软件上更是如此。不同手机的屏幕大小差异非常大,在手机客户端应用程序移植的过程中最大的困难就来自于UI界面的移植,MVC设计模式可以很好地使UI界面和程序的数据、控制相分离,从而把后期应用程序的移植这个难题基本控制在界面移植这个范围之内。 MVC设计模式这里就不介绍了,要注意的是整个应用程序大小的限制可能会约束设计模式的实现,即使是最小的类也会使整个应用程序的尺寸增大200字节。实际中可能需要减少类的层次来保持JAR文件在一个合理的大小范围之内,也尽量不要使用单独的类或者匿名类来做控制器,我们的实践中使用一个控制器类来处理所有的业务逻辑,虽然这个类看起来有点臃肿,但是在这种限制条件下,有时候不得不做这种让步。

建立设备库资料库

所谓磨刀不误砍材功,对于开发跨平台的应用来说,建立一个目标手机设备资料库非常重要,其中至少要包含我们的应用软件所要用到的各种终端能力特性。网上能查到各种手机终端所支持的Java API等资料,这很方便但是除了屏幕大小外有时候有些参数不可*,而手机设备的一个错误的参数或者BUG会耽误我们开发调试过程中大量的时间。根据我们的客户端应用程序所要用到的终端能力,可以做一个测试程序,用来测试各款手机终端对于这些能力的支持情况,例如:KJava平台的RMS存储限制、最大内存限制、程序所能使用的屏幕大小、支持本地播放的多媒体内容类型、支持网络在线播放的多媒体类型、对联网能力的支持、程序运行时系统对电话呼入的处理以及对Push Registry程序自启动的支持情况和表现等等。我们可以通过自己的测试工具来建立目标终端上的这些属性的资料库,并不断扩充。注意,以真机上运行的结果为准,很多时候模拟器的表现和真机的表现是不一致的,基本上模拟器普遍都存在“缺陷”。

规范使用资源文件

为了方便移植,可以将所有的UI界面的图片、提示文字等元素都抽取为资源文件,采用资源文件可以使得资源和代码相分离。在设计阶段注意制定UI元素资源的命名规范,这样移植的时候就可以方便地替换。这种“Skin”的方式,也便于后期方便地更换程序的界面风格。对UI元素资源的规范也有利于UI开发人员的素材积累。

时间: 2024-12-02 08:10:47

手机网络应用客户端软件开发实践简介的相关文章

《.NET 2.0面向对象编程揭秘》作者—金旭亮与您探讨.NET软件开发实践经验

问题描述 10月26日,CSDN将举办第二次SD俱乐部活动,活动邀请到拥有十多年的软件开发实践经验的北京理工大学计算机系教师--金旭亮,他将结合自己多年来的软件开发实践经验,现场编程展示实际软件开发过程,点出技术关键,并加以适当的扩充与引申,帮助程序员们加深对复杂编程技术的理解与把握,增强开发能力.[讲座主要内容]:[限制50人]第一部分从理论到实践(OOD,OOP,OOT的实例):这部分以一个支持括号与运算符优先级的四则运算器为实例,先在理论上设计出可行的计算机算法,紧接着将数据结构与算法转化

敏捷软件开发实践-Sprint Story Point Estimation

介绍: 对于story来说,一个很重要的衡量它的大小的因素就是story point,它不等同于软件工作量评估中的Function Point,因为story point只是用来粗略的相对的估计story的大小,而Function Point则是用来衡量功能模块的精确大小并且要参与到公式计算的,这里澄清下. story point的估算是一门很深的学问,而且我们不能马虎,因为如果我们估算少了,那么就会导致实际我们的花费时间远高于估算时间从而导致team加班加点,如果估多了,会导致我们team很闲

敏捷软件开发实践:概括

应朋友之邀,我准备写一组文章关于敏捷软件开发的实践,也帮助广大没有用过Agile的或者只停留在书本内容上的朋友亲临敏捷软件开发这个惊心动魄的历程. 所谓敏捷,书本上有很多的介绍,我也不想重复发明轮子了,反正就我的理解,敏捷的精髓就是面向变化,敏捷这个词语,我最早遇到是出现在玩各种游戏中,所谓的"力量型"英雄,"敏捷型"英雄,比如暗黑的亚马逊,比如魔兽世界的猎人,这种职业往往有很高的闪避,而且可攻可守,或者说三国杀里面最典型的赵云"闪杀杀闪闪,能进能退&qu

敏捷软件开发实践-Sprint Status Track

介绍: 对于敏捷软件开发来说,能时刻保持跟进项目的进度是非常重要的,因为你可以随时了解团队的健康状况,并且对各种突发情况进行突发的处理,从而保证每个迭代结束后我们的项目可以按时的交付. 实现方式: 看项目进度的最好的工具当然是burndown chart,我们使用Jira做项目管理工具,Jira中有一个Report视图,可以非常直观的显示story的burn down 曲线,从而让团队直观的明白这个sprint进展的如何. 当然了,这个是从story级别的,它衡量的是随着时间的流失,story

敏捷软件开发实践-Code Review Process

介绍: 在敏捷软件开发中,从代码的产生速度上来看,要比传统Waterfall产生速度高很多.因为我们把时间安排的更加紧凑了.那么这么多的代码,如何能保证这些代码质量呢?很多人可能直接想到静态代码检测工具.没错,那些是可以定义一个代码检查规则来确保代码的质量,但是那个仅仅是从语言角度,那么逻辑是否已经最优化了?可重用性是否已经优化到极致了?这些是静态代码工具不能完成的,所以我们需要Code Review 实现方式: 对于已经在项目组很久的人来说: 虽然传统的code review就是把代码从仓库c

软件开发实践中的入队列和出队列操作的C代码示例

概述 最近有在校的学生朋友在问我,数据结构中的队列在实际的软件开发项目中有什么样的用处. 大家都知道,队列的特点是先入先出,即数据是按照入队列的顺序出队列的.在实际的软件开发项目中,当一个中间模块需要接收和发送大量的消息时,队列就可以大展身手了.我们可以将接收到的数据存储在一个全局队列中,然后在另外的程序流程中将数据从同一个全局队列中取出来,经过一定的处理之后将消息发送到另外的模块.这样做可以降低程序的性能瓶颈. 本文用实际的C代码示例了简单的数据入队列和出队列的方法,大家可据此了解队列的实际用

敏捷软件开发实践-Team Management

介绍: 对于敏捷开发团队来说,团队管理也是必不可少的,我带领的团队分2部分,1个是开发团队,一个是测试团队.开发团队,我大体上比较放心,因为毕竟已经运行1年多了,文档充足,而且技术方面也有很多资料或者现成代码可以参考,测试团队是刚组建没多久的,因为原来测试团队放在onshore那边,但是现在他们测试团队解散了,所以我们这边就组建了一个测试团队.这里共享下我管理团队的一些经验. 实现方式: 其实我也不是一个专职的团队管理者,因为我是一个纯粹做技术的人,我甚至连PMP都没有.我曾经做过专栏,我做过云

敏捷软件开发实践-Sprint Setup Meeting

介绍: 对于一个迭代周期Sprint来说,最先开始的活动并且也是最重要的活动之一就是Sprint Setup Meeting. 在这个会议上,我们主要会去探讨一些这个Sprint我们需要完成哪些story,并且这些story的具体需求是什么.其实,我们公司走的是离岸开发模式,这种模式下,我们由于和我们的客户有个时差(9小时) ,所以很难大家坐在一起然后和标准的Sprint Setup Meeting一样开始plan. 在这种模式下,我们有2种方式来实现. 实现方式: 一种实现方式是,我们offs

敏捷软件开发实践-Sprint Task Split

介绍: 在开完了Sprint Setup Meeting,并且吧所有的Story Point都合理的估算之后,下面一步就是吧story细分到每个开发者/测试者手里,让他们在story下面建sub-task. 这里最关键的问题是,如何更高效的利用团队的人力资源并且做最合理的分配. 实现方式: 这个其实都是根据skill set来的,因为大家都知道,一个团队的人的水平,经验都层次不齐,有高级/中级的工程师,有这个领域专家,有的擅长另外一个领域. 所以我们团队,去年刚建立的时候,第一件事情就是收集下每