热门论文
最新论文
基于Android平台数字化协同移动办公信息管理系统的设计与实现
发布时间：2023-01-03 13:37
目录
第一章 绪论 1
1.1 研究背景介绍 1
1.2移动办公研究现状介绍 2
1.2.1 国内研究现状 2
1.2.2 国外研究现状 3
1.3 论文的主要研究内容 4
第二章 相关技术介绍及其实现思路 5
2.1数字化协同办公信息管理系统简介 5
2.2移动平台的对比及选择 5
2.2.1 智能手机终端市场占有率对比 6
2.2.2 应用数量对比 6
2.2.3 第三方应用对比 7
2.3Android 平台 8
2.3.1Android 体系结构 8
2.3.2Android 的类介绍 9
2.3.3Android 项目的目录结构 11
2.4XML解析技术分析 13
241文件对象模型(DOM )解析技术 13
242事件驱动型(SAX)的XML解析技术 14
243 PULL解析技术 14
2.5Android 客户端安全接入方案 16
2.5.1Android 客户端安全接入方案简介 16
2.5.2Android 客户端安全接入平台功能介绍及其实现方法 16
2.6Android Native 客户端---前置服务器架构 17
2.6.1前置服务器 17
2.6.2Native App 架构 18
2.6.3整体架构方案 19
第三章 系统需求分析 21
3.1可行性分析 21
3.2 项目软件生命周期的选择 22
3.3协同办公系统的相关功能 23
3.3.1 行政管理 24
3.3.2工作流程管理 25
3.3.3公文管理 25
3.3.4项目管理 26
3.4Android 协同移动办公子系统功能需求分析 26
3.4.1系统用例分析 27
3.4.2系统流程图 28
3.4.3 主要功能模块的需求分析 29
3.5系统非功能需求分析 30
3.5.1系统运行效率 30
3.5.2数据安全性 30
3.5.3可维护性 31
3.5.4 可扩展性 31
第四章 系统总体设计 32
4.1 系统整体架构设计 32
4.2 前置服务器的实现 33
4.2.1 传输加密层功能说明 35
4.2.2协议适配层功能说明 35
4.2.3终端适配层功能说明 35
4.2.4 业务逻辑层功能说明 36
4.2.5 内容聚合层功能说明 36
4.2.6 系统服务层功能说明 36
4.3移动客户端的分析设计 36
4.4安全接入平台模块设计 38
4.5XML数据解析模块设计 39
4.6数字签名模块设计 39
4.7附件下载和查看模块设计 39
4.8客户端更新模块设计 40
4.9数据交互接口设计 40
第五章 系统详细设计与实现 42
5.1 系统架构实现 42
5.2移动客户端主要功能模块的具体实现 47
5.2.1系统开发环境 48
5.2.2Android 运行环境 48
5.2.3用户登陆模块实现 49
5.2.4待办事项模块实现 51
5.2.5公文管理模块实现 52
5.2.6附件下载模块实现 56
5.2.7自动更新模块的具体实现 61
5.2.8Android 客户端扩展功能 63
5.3移动客户端与协同办公系统数据交互实现 64
5.3.1XML 解析器的创建 65
5.3.2SAX方式的具体实现 65
5.3.3XML数据交互实现 66
5.4数据交互接口实现 67
5.5 本章小结 70
第六章 系统测试 71
6.1功能测试 71
6.2测试结果 74
6.3本章小结 74
第七章 总结与展望 75
致谢 76
参考文献 77
第一章 绪论
本章首先阐述了本文的研究背景、深入调研了数字化协同移动办公信息管理 系统的现状,接着介绍了本课题目的及意义，最后提出本文的主要研究内容并给 出论文的组织结构。
1.1 研究背景介绍
随着信息化的不断发展，人们日常的工作和生活与计算机和网络联系的更为 紧密了。随着网络应用的不断发展，许多企事业单位的信息化建设已经比较成熟， 他们在日常的办公中对计算机和网络的依赖逐渐加深。由于很多规模较大的企事 业单位在各地设立了分部，业务也遍布全国各地，因此这些企事业单位的员工频 繁外出、出差，这就衍生出很多问题。传统有线网络下的办公系统无法满足这类 企事业单位的需求，这就导致这些企事业单位的管理上会出现一定的问题，降低 了这些企事业单位员工的工作效率。因此，企事业单位需要一种更加便捷的办公 方式。为此，采用了数字化协同移动办公系统，这可以让企事业单位降低了运营 成本，并且能够提高其管理决策的科学性和实效性。可以让员工通过使用智能手 机客户端登陆数字化协同移动办公系统，实现了随时随地的工作，极大的提升了 工作效率。
现阶段基于移动手机的数字化协同移动办公在我国拥有广泛的应用前景，首 先让我们看看由中国互联网信息中心（CNNIC）发布的一些权威的统计数据。⑴
（1） 截至2013年12月底，我国手机网民规模为5亿，较上年增加约6440 万人，年增长率为19 .1%，在整体网民中的占比由2012年底的74. 5%提升至81%， 远高于其他设备上网的网民比例，第一上网终端的地位更加稳固。
（2） 手机网民的手机上网粘度较大，平均每天累计使用手机上网时长为 124 分钟，每天上网 4 小时以上的重度手机网民比例高达 22.0%，手机上网逐渐成为 一种常态化的生活习惯。
（3） 相比 2012年，我国手机网民年龄呈现成熟化趋势，30 岁以上手机网 民的比例明显上升，整体从 2010 年底的 33.3%上升至 2012 年底的 39.2%。这主 要是由于智能手机的普及及3G网络的成熟使得手机上网的门槛降低。
以上数据说明：我国拥有全球最多的手机用户，国民的手机人均拥有量已经 远远超过计算机的人均拥有量。近年来随着第三代移动通信技术的发展以及城市 中无线热点的部署，移动无线带宽也得到很大的改善，且移动终端性价比在逐步 提高，这些都为数字化协同移动办公的进一步发展创造了良好的条件。
1.2移动办公研究现状介绍
在全球信息化及移动宽带网络高速发展的今天，企事业单位对数字化协同移 动办公信息管理系统有着极大的需求，显而易见，移动办公系统有着极为光明的 前景。移动办公系统的出现，使得通常的0A系统摆脫了对固定办公环境，固定 工作时间，固定电脑设备和网络的依赖，将信息化无缝延展到每个人手中，使得 信息化从此可以随时随地的跟随着人走。它是对原有信息化的补充，也是对信息 化本身的发展和跃变。数字化协同移动办公信息管理系统与传统的基于桌面的办 公系统最主要的区别是真正实现了在任何时间，任何地点都能办公的目标。这体 现了办公的时效性，使得人们的办公不再局限与特定的时间与特定的地点，这就 让人们的工作效率得到极大的提升。因此，随着国内信息化的发展，对内部办公 自动化的及时处理也已经成为影响单位办公效率的重要环节。将办公自动化系统 向移动终端延伸的实际需求也越来越迫切。
1.2.1 国内研究现状
我国高度重视发展软件和信息服务业，自 2000 年以来，国家出台一系列支 持软件和信息服务发展的政策措施，助推软件业持续走强。
近年来协同 0A 软件市场快速增长，市场规模从 2008 年的 29.5 亿元大幅增 长至45.1亿元，增长率为40.1%。2010-2013年，协同OA软件市场年复合增长 率仍将保持为30%左右， 2013年市场总额将达到132.2亿元。 [2]可以预见，未来 两三年协同OA仍将高速成长，这10年来中国OA业持续增长，一方面得益于 中国日益坚实的软件和信息服务产业基础，日益成熟的科研和教育系统，丰富的 人力资源优势和不断深入的国际合作，另一方面也得益于国家对软件业的各项政 策支持，营造了良好的投资环境。 2011 年，国务院发布了《进一步鼓励软件产 业和集成电路产业发展的若干政策》（号称“新 18号文”），从财税、投融资、进 出口等七个方面进一步优化产业发展环境。[3]2011年以来，协同OA行业市场渐 趋成熟，宣布进入行业发展的黄金10年。
而在政策利好的不断支持、需求市场的日益成熟、国内OA软件厂商技术水 平和应用能力提升的帮助之下，相比于国外厂商，国内厂商在今后的OA办公自 动化市场将更具优势。据一项权威统计数据显示，目前国产OA已占整个办公自 动化市场 70%以上的份额，未来 5 年将有可能提高到80%以上，一统办公自动 化市场江山。 [4]
随着移动技术的高速发展，我国各地逐步都加大了数字化移动协同办公平台 的关注力度，目前国内数字化移动协同办公平台的使用主要集中在通信基础设施 比较完善的发达地区，欠发达地区起步较晚，但发展也颇为迅速。我国的信息化
Android手机的出货量都远远高于其他智能手机平台，因此，基于Android平台 的这些优势，本论文就选择了安卓智能终端设备作为数字化协同移动办公系统所 使用的终端设备平台。
2.3Android 平台
Android手机操作系统是由谷歌公司于2007年正式推出的，最大的特点是平 台的真正开放性。到目前为止， Android 手机操作系统的最新版本为 4.0，具有广 泛的应用和发展前景。Android系统的使用率占据全球智能手机系统将近80%的 份额，尤其在中国市场的占有率更高，接近90%[8]。与其他手机操作系统相比， Android 具有最大的优点就在于它的开放性和平台开发的便捷性，不同的厂商可 以根据自己的需求对平台进行扩展开发，而且无需支付任何费用。采用 Android 操作系统的智能手机越来越受到人们的青睐。Android是以Linux系统为基础， 能更好地满足电脑爱好者的需求。另外Android的安全性也比较完善。
2.3.1Android 体系结构
Android 手机操作系统平台整合了操作系统、中间件和应用程序三大块。
Android操作系统之所以会受到各厂家的青睐,真是因为它的真正开放的优越性。
Android的架构从下图来看，软件层次结构自上而下共分为以下4个层，如图2-2
所示：
(1)应用程序(Application)
应用程序(Application)主要是用来设计用户操作界面的，用Java语言来编 写，主要是被用户访问。Android自身提供了一些核心的应用程序，如主屏幕、 联系人、电话、浏览器等，因为Android是开放式的操作系统，所以用户可以根 据自己的要求，利用已有的框架来编译、开发程序。 Android 应用程序中 UI 组 件所需的控件首先由本层提供。如View(UI组件)，包括了列表、文本框、按钮 等，这些组件构成了程序的视图部分。
(2)应用程序框架(Application Framework)
开发者接触最多的就是应用程序框架，它给开发者提供了应用程序层的 API，开发者在开发时都是基于框架的。其上层的应用程序基本都是以Java语言 来编译的，应用程序框架提供所有用户界面设计所需的控件。终端界面能够显示 出来让用户看到的的所有图形都是些文本框、按钮和列表等控件，它们组成了应 用程序的界面系统。开发者在开发时可以完全通过应用程序框架的视图系统、电 话管理器等各个部分来进行软件的开发。
(3)库和 Android 运行环境
通过Android平台来开发程序的过程，是由各类组件来调用Android的后台 库来实现系统开发的，而这些库都是一些用C或C++来编译的库函数。安卓系 统包含了一套功能强大的运行库，它主要为实现Java语言的运行而服务。每个 Android应用程序的进程都是基于寄存器的Dalvik虚拟实例，所需要的资源也相 对比较少。Android系统是基于Linux的，所以Linux作为底层为Dalvik虚拟机 提供了一些内核的功能，如线程机制、内存管理机制。 Dalvik 虚拟机的可执行 文件格式是.dex类型的，这种文件格式是被优化过的,所以占用的内存最小［9］。
(4)操作系统层(OS)
Android SDK是运行于Linux上的，它只是以Linux内核来管理硬件资源的， 不同于 Linux。 Linux 内核同时作为软、硬件栈间的抽象层，进行相互沟通的工 作。
2.3.2Android 的类介绍
Android 手机区别于其它一些智能手机就在于它有自己的组件。本段内容就 会对 Android 的部分组件作详细的介绍。
(1) Activity 简介
Activity 是应用程序的表示层。它在 Android 应用中主要是用来创建和显示 窗口的。系统的用户界面就是一个Activity对象，作一个很形象的比喻，在手机 游览器中一个网页就是一个Activityo 一般，一个Android应用会包含很多个 Activity，它们之间是可以自由地进行相互跳转的，就像网页的跳转一样。但 Activity和网页跳转的区别就是可能存在返回值。
Activity栈可以用来管理系统中的Activity。当启动一个新的activity时，它 会被放置在activity栈顶部，并成为running状态的activity，之前的activity也在 activity栈中，但总是被保存在它的下边，只有当这个新的activity退出以后之前 的 activity 才能重新回到前景界面。
Android 中每个 activity 都是一个用户界面，要想实现各界面之间的转换就需 用到 Android 的 Intent 类。 Intent 类运行时包含两个部分，动作和动作对应的数 据。
Activity 有两个方面，既可以调用其他请求，也可以被其它请求调用。在设 计开发系统时，Activity主要负责窗口的创建工作，其次利用set Content View方 法将窗口显示出来，实现与用户的交互。
(2)Service 简介
Service级别和Activity差不多，都是Android的四大组件之一，一般使用 Service实现后台的一些长期运行的应用程序的服务工作。虽然是用户看不见的， 但在系统运行中的作用却是非常重要的。 Service 能够在后台运行并和其它组件 进行交互。 Service 的启动有两种方式，这两种方式可以混合使用：第一种是调 用 context.bindService()启动，调用和 context.unbindService()结束，第二种是通过 调用 context.startService()启动，调用 context.stopService()结束，
(3)BroadcastReceiver 简介
BroadcastReceiver 是用户接受广播通知的组件。广播是一种同时通知多个对 象的时间通知机制。 Android 中的广播通知要么来自系统，要么来自普通应用程 序。
为了响应不同的事件通知，应用程序可以注册不同的BroadcastReceiver。而 所有的BroadcastReceive都继承自基类BroadcastReceive。而用户图形界面并不 能通过 BroadcastReceive 来 进 行 实 现 ， 但 是 当 它 收 到 通 知 消 息 后 ， BroadcastReceive 可以启动 Activity 作为响应，或者通过 NotificationManager 来 提醒用户。
(4)ContentProvider 简介
在Android中，所有的数据都是私有的，要想实现在各个应用程序中自由地 使用各类数据，Android中的ContentProvider则可以实现，它通过统一的标准的 接口进行每个应用中各类数据的共享。外界可根据权限级别利用一套标准统一的 接口和程序对数据进行共享。
(5)Intent 简介
Intent 是连接组件的纽带，在上述 4 种基本组件中，除了 ContentProvider 是通过 ContentResolver 激活外， 其他三种组件 Activity 、 Service 和
BroadcastReceiver 都是由一种名为 Intent 的异步消息激活。 Intent 在不同的组件 之间传递消息，将一个组件的请求意图传给另一个组件。因此，Intent是个包含 具体请求信息的对象。
一般来说一个完整的 Android 应用程序应该包含 Activity 、 Intent Receiver、 Service、 Content Provider 和每个 Android 应用所相应的配置文件 XML。 Android
图 2-2 Android 应用程序工作流程
2.3.3 Android 项目的目录结构
Android项目的目录结构如图2-3所示，为了使开发的Android应用项目效 果更好，在开发 Android 项目的过程中必须要做到灵活运用。
图 2-3 Android 项目的目录结构
Android项目的目录的主要功能如下：
(1)default.properties 文件
default.properties文件的作用是记录项目中对应的环境配置，一般就采用默 认配置，无需自行修改。
(2)AndroidManifest.xml 文件
AndroidManifest.xml文件是Android项目的总配置文件，Android项目中所使 用到的各种组件都被记录在这个配置文件中。Android应用使用到的服务,如互联 网服务、GPS定位服务、通信服务等都是记录在AndroidManifest.xml这个文件中。 当添加一个全新的Activity时，也必须配置AndroidManifest.xm 1这个文件，只有将 这个 XML 文件配置好后，才能调用此 Activity a application permissions、Activities、 intent filters 等都包含在 AndroidManifest.xml 文件中。
⑶res文件夹
res文件夹是存放资源的目录，它包含了Android软件项目中的资源文件并将 这些文件编译进Android客户端。向此目录添加资源时，会被R.java自动记录。res 目录下存在layout、values、、drawabe这三个子目录，layout目录中存放的是界面 布局文件，values目录中存放的是显示各种文字的XML文件，drawabe目录中则 存放各种图标文件。
(4)assets文件夹
assets文件夹则放置了 Android客户端应用所需的各类多媒体文件。
(5)Android 2.x.x 文件夹
Android 2.x.x目录下有个一个Java归档文件，文件名是android.jar，其中包 含了开发Android应用所需要的APIS(应用程序接口 )和 SDK(软件开发工具包)库。 它通过android.jar将自己的应用程序绑定到Android Emulator和Android SDK，这 允许你使用所有Android的库和包，并且允许你在适当的环境中调试应用程序。
(6)gen文件夹
gen文件夹下面有一个在建立Android应用时生成的只读归档java文件，文件 名是Rjava。在这个只读归档文件中有一个R类被定义，这个R类定义了该软件项 目中所有资源的索引，很多静态类被包含在R类中，且res中的每一个名字都与静 态类的名字相对应。我们通过Rjava可以方便快捷的找到我们所需要的资源， Rjava列表中的资源也被编绎器进行检查是否被使用过。为了尽可能的减少 Android客户端应用的体积，提高Android客户端应用的执行效率，我们利用R.java 筛选出那些没有使用到的资源，使其不被编译进软件中，这样可以减少应用在手 机占用的空间。
(7)src文件夹
该文件夹内放置的是Android客户端软件的源代码。
2.4XML解析技术分析
XML解析是指：为满足XML语法的结构化组件的把代表XML文档的一个 无结构的字符序列转换过程［10］。因为安卓智能手机的系统资源有限，开发者为 了更有效的使用其有限的系统资源，必须选择相应的XML解析技术，方可达到 安卓应用优化的目的。本节将简单分析对比Android平台中三种常用的XML解 析方法。
2.4.1文件对象模型(DOM )解析技术
Android能够完全支持文件对象模型(DOM)解析。我们利用DOM中的对象， 可以读取、搜索、修改、添加和删除XML文档。
我们在使用DOM对操作XML文件时，第一就要解析文件，将文件分为独 立的注释、属性、元素等，第二我们要通过节点树访问文档的内容，就必须以节 点树的形式在内存中对XML文件进行表示，并根据需要修改文档，这就是DOM 的工作原理［11］。第三DOM实现时首先为XML文档的解析定义一组接口，解析 器读入整个文档，然后构造一个驻留内存的树结构，这样代码就可以使用DOM 接口来操作整个树结构。
文件对象模型(DOM)解析XML的流程如下图2-4所示：
图 2-4 文件对象模型 (DOM) 解析 XML 流程图
2.4.2事件驱动型(SAX)的XML解析技术
SAX(Simple API for XML)XML 简单应用程序接口是一个公共的基于事 件的XML文档解析标准。它以事件作为解析XML文件的模式，它将XML文 件转化成一系列的事件，由不同的事件处理器来决定如何处理。 SAX 是一个解 析速度快并且占用内存少的xml解析器，非常适合android等移动设备，SAX 解析XML文件采用的是事件驱动，也就是说，它并不需要解析完整个文档，在 按内容顺序解析文档的过程中，SAX会判断当前读取到的字符是否合法xml语 法中的某部分，如果符合就会触发事件。
SAX解析XML的流程如下图2-5所示：
图 2-5 SAX 解析 XML 流程图
2.4.3 PULL解析技术
在 Android API 中，另外提供了 Android.util.Xml 类，同样可以解析 XML 文 件，使用方法类似SAX,也都需编写Handler来处理XML的解析，但是在使用 上却比 SAX 来得简单。它允许用户的应用程序代码从解析器中获取事件，这与 SAX解析器自动将事件推入处理程序相反。Pull解析器运行方式与SAX解析器 类似，它提供了类似ide事件，如：开始元素和结束元素，使用parser.next()可 以进入下一个元素并触发相应的事件。事件作为数值代码被发送，因此可以使用 一个switch对感兴趣的事件进行处理。当元素 开始解析时，调用parser.nextText() 方法获取一个Text类型的节点的值。
PULL解析XML的流程如下图2-6所示：
对三种解析技术的比较：
对于Android的移动设备而言，因为Android手机一般都使用ARM低功耗 处理器，配置的系统内存也不会太高，所以这就决定了 Android移动设备的硬件 性能有一定的限制，所以我们需要选择适合的技术来解析XML,这样有利于降 低 Android 移动设备的系统资源利用率。
(1)DOM 在处理 XML 文件时，它是在内存中处理已解析程树状结构的 XML 文件。当 XML 文件较小时，我们可以选择相对简单直观些的 DOM。
(2)SAX则是以事件作为解析XML文件的模式，它将XML文件转化成一 系列的事件，由不同的事件处理器来决定如何处理。XML文件较大时，选择SAX 技术是比较合理的。虽然代码量有些大，但是它不需要将所有的 XML 文件加载 到内存中。这样对于有限的 Android 内存更有效，而且 Android 提供了一种传 统的 SAX 使用方法以及一个便捷的 SAX 包装器。
(3)PULL解析在开始处完成了大部分的处理工作，它没有像SAX解析那样 监听元素的结束。这种处理方法机极大的降低了解析的时间，对XML文件的载 入速度有了很大的提升。对于移动设备在网络速度不佳的环境中，这种优化显得 尤为重要。综上所述，在XML文档较大，但软件无需第一时间全部载入XML文 档时，PULL解析器的执行效率更高。
2.5 Android 客户端安全接入方案
由于 Android 客户端需要通过公共移动网络接入各企事业单位内部办公网 络，这必然会带来有些安全性的问题，因此，如何保障远程用户能够合法、安全 地接入数字化协同移动办公信息管理系统是本方案需要考虑的问题。
2.5.1Android 客户端安全接入方案简介
在网络接入层次上，使用硬件VPN解决方案，防止用户直接从互联网接入 而导致网络安全问题，这就解决了数据在互联网传输中的安全问题。
在客户端应用层次上，我们设计了一个基于 Android 的安全接入平台的应 用，这个应用先于Android协同移动办公的模块启动，以此来给Android协同移 动办公客户端创建一个较为安全地运行环境。该应用的运行流程如下：在启动此 安全接入软件通过身份认证之后，开始检测Android系统的后台进程，并将相应 的不可信任的进程强行杀掉，最后再加载Android协同移动客户端的业务功能模 块。这就在一定程度上解决了 Android手机客户端系统本身存在的安全问题。
2.5.2Android客户端安全接入平台功能介绍及其实现方法
Android客户端安全接入平台设计了一个专属存储空间，它从Android系统 中单独划出一块存储空间，用于存储其专用数据，这样可以在很大程度上与其他 软件的隔离开来，使得其他软件无法访问该专属存储空间。该安全平台还能阻止 第三方应用对该平台内部的应用及其数据的访问和调用，同时也禁止平台内的应 用对第三方应用及其数据的访问和调用。
Android 客户端的登陆界面就是安全接入平台的专用登陆入口，客户端用户 使用相应的登录名和没密码通过安全接入平台的验证。客户端的安全接入平台将 可信任的软件纳入白名单，利用该白名单来检测Andriod系统后台运行的软件是 否可信。
Android 客 户 端 安 全 接 入 平 台 最 重 要 的 一 个 功 能 是 将 平 台 内 的 应 用 和 Android系统的第三方应用之间的通讯进行隔离。安全接入平台内的应用可以共 享存储空间，可以在平台内实现数据的调用或者通讯。而安全平台之内的应用以 及安全平台之外的第三方应用则利用“沙盒”原理来实现通讯数据之间的隔离。
Android 客户端的安全接入平台为实现安全接入平台和第三方应用之间的通 讯隔离,采用以下两种种方式来实现：
(1)在开发协同移动办公Android客户端时，需要对其源代码进行缺陷分析和 漏洞分析，确保客户端软件没有安全漏洞。
(2)在安装Android应用时，为控制应用的访问权限，本文设计了一个应用安 装管理器，应用安装管理器对应用所需的权限进行审核，一旦发现有非正常权限， 如企图与安全接入平台进行通信，则立即停止安装该应用。
(3)在运行应用时，为防止有违反安全隔离规则的现象，本文设计了一个权 限管理器，用来在系统后台实时监测安全接入平台内外的违规交互通信行为。
2.6 Android Native客户端…前置服务器架构
2.6.1前置服务器
协同移动办公系统将一个精简版的协同移动办公系统服务器作为前置服务 器,这台前置服务器提供外界 Android 移动手机终端接入协同移动办公系统平台 的功能。系统移动办公系统的前置服务器系统并不具备完备的协同移动办公系统 的功能,而仅仅是设计出和现有的协同办公系统对接的接口模块来实现业务流程 的操作。前置服务器的使用专用密码机来保障密码的高安全性。前置服务器跟后 端的协同办公系统服务器之间采用 HTTP/HTTPS 来进行通讯，而前置服务器和 Android移动客户端之间则采用HTTPS/XML来进行通讯。设计前置服务器的目 的如下：
(1)Android 客户端软件通过前置服务器和数字化协同办公系统之间进行数 据的传输，这样在协同办公信息管理系统进行更新或修改时，可以保持 Android 客户端软件的相对稳定。只需要在前置服务器系统上做相应的修改和更新,而 Android 客户端几乎不需要做太大的修改，甚至无须做任何更新;
(2)前置服务器专门为 Android 客户端和原始的数字化协同办公系统之间提 供数据中转服务。通过这种访问模式，Android客户端因请求所响应的数据相比 直接访问数字化协同办公系统服务器的数据量，大为降低,这就使得服务器能够 承载更大的客户访问量，使得服务器的网络延迟也大为降低,最为显著的就是增 强了用户在 Android 客户端上的体验性;
(3)Android客户端通过前置服务器来访问位于内网的数字化协同办公系统， 可以在很大程度上保证数字化协同办公系统的安全，并且可以提供更为安全地连 接方式;
(4)前置服务器对Android客户端应用提供升级服务支持。前置服务器除了通 过HTTPS协议来保证数据通讯安全，还提供利用服务器系统自带的防火墙功能来 防护来自网络的攻击行为。
2.6.2Native App 架构
Android客户端分为两种，一种是本地应用(Native App)，另一种是网页应用 (Web App)。如今，在手机移动应用领域，对于未来是Native App的天下，还是 Web App的天下，客户端软件设计者和开发者是应该努力以提升客户端的体验， 还是优化设计Web应用，这是安卓移动互联网领域备受关心的问题。
(1)Web App
因为Web App不需要安装，所以其对移动终端设备的适应能力优于Native App，它可以在任意移动终端的浏览器中执行(通过XHTML、HTML5和CSS)。 随着安卓移动手机终端内置WebKit浏览器的性能升级，这让在基于WebKit浏 览器的移动终端设备上开发的Web App上的用户体验，得以媲美Native App的 流畅性。
Web App 有以下优点：它能够能够比较容易的匹配各种移动终端设备，能 够较为以较低的开发成本来实现跨平台的开发和较低的终端部署成本，迭代更新 比较容易，因在终端无安装程序，所以部署成本几乎为零。但Web App的也存 在一定的缺陷，比如以下几个方面：无法充分发挥系统特性(调用系统服务、内 存管理等) ;无法操控设备硬件(如相机、蓝牙、振动器等)；对于复杂应用， web app受限于浏览器，性能不佳；在用户体验方面尚无法超越Native App，且 在调用本地文件的能力方面无法与Native App相媲美。
(2)Native App
Native App的开发成本要高于Web App，但其对于本地资源的调用的兼容性 要好于 Web App， Naitve App 可以支持本地资源的访问，推送信息，摄像头功能 的调用以及拨号或者 GPS 定位功能的调用。但是由于移动终端设备碎片化，导 致本地应用的开发成本较高，还需要花费大量的工作用以维持多个版本的更新升 级，并且对用户的操作水平也有较高的要求。
Native App 有以下优点：本地应用在用户体验上做的更好，可以针对不同的 手机终端做最优化的匹配，可以提升用户的体验。Native App能够在一定程度上 降低数据通讯量，从而降低带宽的成本。Native App能够可以实现调用本地的软 硬件资源。但 Native App 也存在一定的缺点：在不同的平台上进行移植，较为 麻烦，工作量较大，维持多个应用版本的成本较高。
通过以上对网页应用(Web App)和本地应用(Native App)的说明介绍以及这 两者之间各自的优点和缺点,并从本项目的实际需求出发,本文最终选择了本地应 用(Native App)为该项目客户端的实际解决方案。本项目的客户端采用Native app 的方案基于如下几点理由，首先本地应用(Native App)可以提供最佳的用户体验, 最优质的用户UI,良好的交互性，而这些方面是Web应用(Web App)无法给予的。 本地应用(Native App)可以提供给用户最华丽用户界面，而拥有一个优良的用户界 面不仅仅可以吸引客户来使用本地应用(Native App)，还可以提高客户的对应用 的使用率；第二,使用本地应用(Native App)能够实现可信安全卡的功能集成，更好 的保障本项目的移动客户端的接入安全，而这点在网页应用(Web App)上的实现 难度则远大于本地应用(Native App)。考虑到以上几点原因以及移动网络的稳定 性及其有限的带宽，为保证用户对协同移动办公客户端的良好体验，故选择数据 通讯量较少，且对带宽要求较低的本地应用(Native App)。
2.6.3 整体架构方案
如图2-7所示，本项目采用了在Android移动客户端和数字化协同办公系统之 间架设前置服务器的特殊架构方案。该方案使用 Android 软件开发工具包 (Android SDK)来开发Android移动客户端应用。通过选择几个常用的组件，开发 出有着较好用户体验的本地应用界面,开发出适合安卓手机移动终端的数字化协 同办公信息管理系统。Android移动终端和现有的协同办公信息管理系统利用前 置服务器进行通讯连接,前置服务器将移动终端的客户请求数据通过转发发给协 同移动办公信息管理系统，协同移动办公信息管理系统再把相应客户端的请求回 应给前置服务器，再由前置服务器反馈给Android移动终端。前置服务器和原有 的协同移动办公信息管理系统使用(HTTPS/XML)协议来进行通信，以保证数据 的安全性；两者通过相应的接口模块来实现彼此之间的数据调用。最终将用户的 请求结果输出为适合 Android 移动客户端的显示格式。
图 2-7 系统架构示意图
该方案的优势如下所述：
(1)各种Android组件的使用，可以为终端用户的体验提供更好的Android优 良的系统特性。
(2)该方案专为移动终端用户定制,为提供简洁且易于操作的用户界面,过滤 了很多不需要的信息，从而降低了客户端与服务器端之间的数据传输量，减少网 络流量,为终端用户提供良好的操作体验。
(3)该方案的 Android 客户端并不直接和数字化协同办公信息管理系统服务 器相连，因此协同办公系统的前台Web界面的更新不会影响到Android客户端用 户的正常使用。
(4)该方案很容易扩展到其他类型的移动终端。
(5)该方案可以通过 Java 的 JCA(Java Connector Architecture)和 JCE(Java Cryptography Extension )构建任何安全系统的客户端。
(6)该方案通过前置服务器的相关加密设置,可以更好的保障内外网信息通 讯的数据安全。
该方案劣势如下所述：
Native App 应用客户端的开发工作量较大，不同移动终端版本的适配较复 杂。
第三章 系统需求分析
本章主要基于Android平台数字化协同移动办公信息管理系统进行本系统的 需求分析。本项目的后续工作主要以基于Android平台数字化协同移动办公信息 管理系统的需求分析为指导和参照,不考虑未在系统需求分析中体现的内容。本 需求分析主要是针对Android平台数字化协同移动办公信息管理系统的功能需求 和非功能需求。本需求分析作为运行系统设计、实现、测试人员的指导文档,对 基于 Android 平台数字化协同移动办公信息管理系统的实施人员来说,需要以此 为参照,重复或冲突部分以本需求分析为准。本需求分析作为运行系统设计、实 现、测试人员的指导文档。
3.1 可行性分析
当今的移动互联网技术正处于迅猛的发展期，目前的移动终端平台市场主要 以 IOS 和 Android 为主，在当前的移动终端市场的占有率方面， Android 已超出 IOS。基于IOS的应用执行效率较高且界面简洁，但因IOS系统代码并不开源，使 得IOS应用的开发入门门槛较高，因此IOS系统的这些局限性使初级开发者的 开发积极性不及开源的 Android 系统。而 Google 的 Android 操作系统一经推出, 就以其开源性备受手机制造商及世界各地研发者的青睐。根据Vision Mobile提 供的数据， 34.4%的研发者现在会选择 Android 作为他们首要的研发平台，而选 择iOS作为其首要研发平台的比例为32.7%。平均而言，移动研发者通常会专注 2.9 个不同的应用平台，但在选择首要平台时，更多的研发者现在倒向 Android。
Android智能设备几乎得到了目前所有手机制造商的支持，因此它在设备出 货量上占据了主导地位，目前主流Android移动终端的硬件配置都比较高，具备 了高分辨率，尺寸较大且触摸灵敏的电容屏，并且有着极高的CPU和GPU配置， 这使得Android的运算能力、图形显示能力得到了极大的提升。而在无线通信技 术方面，目前发展已极为迅速，2G的GPRS网络已经成熟，3G已经完成了全面 覆盖，而4G也已开始逐步推广，而在城市中,WIFI无线热点已经覆盖了绝大部 分区域，这基本上完成了无线信号的全面覆盖，使得移动终端设备随时随地均可 联网。移动互联网的迅速发展是建立在移动终端设备以及无线网络的高速发展之 上。
目前在各企事业单位使用的传统的基于桌面浏览器的数字化协同办公信息 管理系统已经比较成熟,但它在目前的办公应用方面存在一定的局限性,使用者必 须在固定的地点才可以连入网络使用数字化协同办公信息系统,不能够随时随地 的使用办公信息系统。因此,传统协同办公系统不能满足企事业单位对于信息化 系统的移动访问的需求，尤其在发生紧急突发性事件时，企事业单位对于通过移 动网络访问数字化协同办公信息管理系统的需求尤其突出。
基于 Android 平台的数字化协同移动办公系统的设想即由此产生,由于无线 网络的快速发展，移动网络的带宽问题已基本解决，本文主要需要解决是用户通 过移动终端接入的数据安全问题，此外还需要考虑移动终端通过无线网络传输时 产生的交互数据通信量过大的问题。如果不解决这两大问题，无线移动协同办公 系统在数据安全方面存在的问题会影响到企事业单位的数据安全，而无线通信网 络交换数据效率上的低效则会影响到用户的良好体验并且会增大服务器的负载。
在安全方面我们需要采取如下两大措施：在数据应用层的安全方面,我们采 用国际上较为成熟的智能卡技术,将用户的数字证书下载到存储卡中，通过SSL协 议连接服务器调用 API 接口,利用用户的数字证书完成电子签章、对称加密解密 技术等数据信息安全方面的技术来保障移动终端连接服务器的安全性。而在网络 层面的安全方面，我们需要购置VPN设备、硬件防火墙以及入侵防御检测系统 来搭建网络层次的安全保障体系，将企事业单位内部的核心业务服务器与存在 安全风险的互联网隔离开来。
为解决移动终端与服务器的通信交换数据效率上低效问题,本文在办公平台 前端架设一台前置服务器，该服务器主要是起到内网协同办公系统服务器和移动 终端设备之间的数据转换及安全隔离的作用。前置服务器可以将移动终端和内网 协同办公服务器端之间的交互通信数据进行压缩简化,在数据通过该前置服务器 时，处理掉部分不必要的数据,并进行压缩，得以最大化降低Android移动终端和 内网协同办公服务器之前的通信数据量。通过在原协同办公服务器前端部署前置 服务器,不仅降低了开发成本，也在一定程度上提升了开发效率，减少了相应的 开发周期。并且，在移动终端和原始协同办公系统服务器之间使用前置机隔离开 来，使得原办公系统服务器不直接暴露在外网上，进一步提升了该移动协同办公 系统的整体安全性。
由上论证，可通过以上两大主要问题的解决方案,再结合企事业单位原有办 公系统，以及安卓平台的简单易用的特点,可以根据企事业单位的具体需求来设 计开发出安全高效的基于Android平台数字化协同移动办公信息管理系统。
3.2 项目软件生命周期的选择
在移动终端上开发应用软件可以归纳如下几个特点：应用的开发周期相对桌 面软件而言较短;但在软件的创新性方面有着更高的要求;针对客户的需求分析需 要做的更为细致，移动平台软件的开发较桌面平台软件更新更快。这就要求移动 应用的开发必须适应企事业单位的需求,从而要求移动应用的开发必须迅速快捷, 必须将新的移动应用在较短的时间内开发出来。在如今快速发展的移动应用市 场，只有高效的开发才能满足市场的需求，所以敏捷开发成为了首选的软件生命 周期，而敏捷开发的最佳软件开发模型则是Scrum。
由上图充分了解实施Scrum的过程，Scrum模型的一个显著特点就是响应变 化，它能够尽快地响应变化。因此Scrum的优势就在于:敏捷开发;Scrum模型将 软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的 最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战， 确保每天、每个阶段都朝向目标有明确的推进。 [12]
Scrum 开发模式的优势结合移动互联网应用的特点,不仅能够满足移动互联 网用户多变的需求,又能很好的控制整个移动应用的项目进行。虽然移动应用的 开发模式种类不仅仅只有Scrum这一种，但在研发人员的眼中，Scrum开发模式 是最适合移动互联网应用项目,因为Scrum开发模式使得开发移动应用开发效率 相比较其他开发模式而言，显然在管理性及开发效率上面表现更好。
综上所述，本项目的开发模式选择了更适合移动互联网应用的Scrum开发模 式，这种模式可以提升本项目的开发效率，减少开发周期。
3.3 协同办公系统的相关功能
目前使用的协同办公平台几乎覆盖企业的各个部门，囊括行政管理、人力资 源、业务流程、知识库、项目管理等功能：并且，系统集成专业的报表工作，可 提供全方面、准确的业务数据；开放相应的功能接口，企业可根据自身需求自定
义配置平台的功能模块与业务流程等。现将主要该协同办公系统的主要功能模块 做如下介绍。
3.3.1行政管理
行政管理，是企业管理中最基础的业务功能，也是数据比较琐碎的功能模块； 其主要针对企业内部员工进行信息化、自动化的管理。行政管理模块中又分为工 作报告、工作计划、部门管理等子模块。
工作报告子模块包括工作日报、周报与月报，员工可自行创建新的工作报告； 而工作报告的填写时间与填写期限则由管理人员进行设定，逾期则不可再补录遗 忘填写的工作报告。
1工作曰报 周报"报 月统计I需计II勳］曰报I
按详细方式査看 2014 s/| 1月2月3月4月5月6月7月8月9月10月11月12月 全
星期 曰期 内容 记录时问 操作1
办理擁：0个文件柜：0个计刘进度：°个妙督办：0个 微信娜；
1 Lark^S5^册；
树、微信轴 2014-09-01 00:00:00 倏改点评
办理艇：0个文件柜:Q个计划进度：0个妙督办:0个 微信;
微信目;
2 有些功；
瞬 2014-09-24 14:10:39
W-T! 2014-09-02 00:00:00 修改点评
图 3-2 工作报告功能截图
工作计划子模块实现对个人工作计划进行周期性、流程性的管理与维护， 提供多样化的计划管理方式与工具，对计划在各个阶段的数据进行有效全面的整 合。
图 3-3 工作计划功能截图
部门管理子模块在领导层需要随时掌握、了解员工的工作状态、工作计划安 排，以便及时的调整工作安排，该模块则实现对工作人员的工作报告、考勤记录 以及工作计划负荷等信息进行管理。
部门用户 曰抿 周抿月报 工作计划负荷 曰考勤月考勤
图 3-3 部门管理功能截图
3.3.2 工作流程管理
工作流程是企业各部门进行联动的业务模块，流程数据可灵动性的在各部门 之间进行流转。工作流程模块中又包含了发起流程和代办流程子模块。
发起流程子模块在进行实际业务操作时，工作人员可根据自身需要发起相应 的流程；而工作人员可发起的流程类型则由管理人员进行了权限设置。
已保存草稿 ◎提交丨恣加签丨亡拟文 tn删除 金須图 护关联项目 偽网盘附件
审批： □郝炜 □箔售人 回短信回消息與醒
圖晋通O❶重要OQ紧急ID : 8084标题:［镇江技术部］赵琦请假申请2014-10-24 卿人:赵琦 我的备注:| 「 ◎
ib&A 任务 开始时问 处理丽 剩余时问 用时（小肘） 绩效 fib® -
镇江技术部：赵 琦 申请 14-10-2416:12 0.0 0.00
请点击此文件
申请人 |老琦 ―| 申请日期 12014-10-24 | 0
图 3-4 发起流程功能截图
待办流程子模块的在工作人员对该模块中个人待处理的流程进行统一管理， 流程流转至当前用户时，平台可通过短消息、手机短信进行提醒。多样化的流程 处理方式，满足不同业务流程的具体需求，如“指派”，将该流程指派至其他人员 进行处理； “挂起”，暂时不处理该项流程；“加签”，增加其他人员共同对该流 程进行处理。
公文管理，主要针对收文流程、发文流程进行综合的维护与管理；支持对发 文的“回收”操作；对发文进行进一步的处理。工作人员可将流程中的附加文件 分发至其他工作人员，实现资源的共同快速分享；同时，可将流程中的附加文件 进行快速归档，增强管理。公文管理包含了收发文处理、归档记录、办理记录、 流程分发等子模块。
收发文处理实现对平台内的发文流程、收文流程进行统一的管理与维护，可 在该模块中查看流程的详细信息，包括流程审核的相关信息；也可直接参与流程 的审核，对流程进行处理。
归档记录则是工作人员可对审核完毕的公文进行归档操作，形成卷宗，该操 作有利于公文的有效管理。工作人员可在该模块中添加归档操作，对指定归档的 具体流程；模块支持自定义、多条件的检索方式，便于归档记录的查询。
办理记录模块以列表的样式对当前工作人员所办理的各类流程进行记录，并 可查看该流程的详细信息、各阶段的处理情况；同时，还可对流程进行相应的操 作，如催办、撤回、重激活等。
流程分发则是工作人员将发文流程进行分发操作，即将该发文流程的文档分 发至其他部门、人员查看。工作人员可选择相应的部门、人员查看，而未选择的 用户则不会接收到该流程分发信息，也无法查看。
3.3.4项目管理
建立完善的项目管理机制，对项目进行全面性、专业化的整体维护，包括项
目成员、项目费用、与该项目的相关的流程、文档、交流等。
图 3-6 项目管理功能截图
3.4 Android协同移动办公子系统功能需求分析
为了满足公司在外人员的移动办公要求，本系统需要实现对移动办公的支 持，开发Android手机客户端应用，允许员工通过智能手机终端通过前置服务器 访问公司内网的数字化协同办公管理信息系统。
Android移动办公手机客户端可以理解为把原来需要通过Web方式访问的功 能移植到Android手机客户端上，但安卓手机客户端并不需要实现原数字化协同 办公管理信息系统的全部功能，主要有以下两个原因：
首先，经常通过安卓手机终端访问协同办公管理信息系统的多为经常在外办 事或出差的领导和员工，他们并不需要原0A系统所有的功能，他们在外经常用 到的功能是公文审批，公文查询，公文下载等功能。
其次，手机的屏幕和输入速度无法和电脑相比，如发起新的公文，流程设计 等功能则不适合在手机终端上实现。
综上所述， Android 协同移动办公子系统的主要功能性需求如下：
1.待办事项：审批待审批公文，未阅读的公文或消息等
2.公文查询：查询历史公文信息
3.附件下载：下载 word、excel、pdf 格式的附件。
4.个人设置：密码修改，网络设置等。
本文重点对三个方面进行论述，这三个重点方面分别是系统用例、系统流程 图和主要功能模块需求。
3.4.1 系统用例分析
图 4-2 是 Android 版协同移动办公客户端的系统用例图。
本项目在开发前必须先进行深入调研，了解用户的当前协同移动办公系统， 并对用户的对于移动终端应用的需求进行深入分析，本次开发的数字化协同移动 办公系统的移动客户端首先需要提供一个安全接入接口,该安全接口在数据应用 层次上来保证用户数据和客户端的运行环境的安全，其次本文开发的数字化协同 移动办公系统的客户端应该有一个登录模块,该登陆模块用以验证用户身份的合 法性，在通过身份验证后，用户方可登录数字化协同办公系统。在Android移动客 户端中用户可以进行如图4-2系统用例图中的各项操作，如果能够遵循系统用例 图进行设计，则该系统基本能够满足用户对协同办公系统移动Android客户端的 需求。
图 3-7 系统用例图
3.4.2系统流程图
图3-8是Android版协同移动办公客户端的流程图
图 3-8 数字化协同移动办公系统客户端流程图
3.4.3 主要功能模块的需求分析
基于Android平台的数字化移动协同办公系统的客户端主要模块功能分析如 下：
安全接入模块的设计是结合存储卡以及个人数字证书使用的功能模块,它是
从Android系统移动终端进入协同移动办公系统的唯一的安全接入入口。其主要 作用是在验证用户身份（存储卡上的个人数字证书）后,首先扫描后台当前运行的 进程,系统自动关闭不受信任的后台驻留的进程，仅保留白名单中的受信任的进 程。在自动关闭后台驻留的不信任进程后,此时移动终端才会进入到协同移动办 公系统的主界面，供用户使用该移动协同办公系统的各项功能。
Android客户端自动更新升级模块，当用户打开Android移动协同办公系统软 件后,后台的更新进程会同步启动，先从服务器侧获取当前版本，再提取本地手 机客户端的版本信息，并进行比较,若需要更新,则自动从服务器端下载最新版本 的软件并进行强制升级更新，要求客户端版本必须与服务器端一致后方可正常进 入系统使用。
登录模块,是用户在通过 Android 移动终端应用登陆协同移动办公系统所必 须使用的具备身份识别和身份验证的模块，该模块身份验证通过前置服务器与身 份认证服务器进行交互,并返回认证结果给客户端。
流程处理模块,是系统用于处理系统各项流程所调用的模块，用户通过身份 验证后,仅可以看到该身份所分配的权限能使用的功能,用户可以在授权范围内来 进行相应的移动办公操作。在用户的每一次的流程处理的操作中,都会使用存储 卡上的个人证书进行数字签名,实现数字签章的功能，以保证数据的不可抵赖性。
附件的处理模块,附件是在流程流转时所附加的各种文件，当然并不是所有 的流程都有附件。Android移动办公客户端必须可以根据附件的文件格式来调用 手机终端上的移动应用来正确的打开阅读或编辑。根据客户的需求，目前该客户 端只需要支持.pdf、.word、.xls、.xml文件格式。
3.5系统非功能需求分析
3.5.1系统运行效率
系统运行效率是是指与在规定的条件下软件的性能水平与所使用资源量有 关的一组属性。本项目在此次Android客户端设计中，尽可能使新的系统与原有的 系统完美无缝对接,在原则上不修改原服务器的所有工作流程，并且客户端软件 图形界面方面设计的更符合企事业单位的形象，并为使用数据过滤和数据压缩技 术来降低数据通信量，从而提升用户移动客户端的性能，使得Android客户端处 理的数据量大大减少，全面提升了用户使用数字化协同移动办公系统的体验。
3.5.2数据安全性
因为数字化协同移动办公系统可以让用户只要持有一部Android移动终端就 可以在任何地点使用办公系统，从另一方面讲，这也必然产生一定的安全隐患， 从而必须采取一定的措施来保证用户数据的安全性。本项目在对用户的环境做过 详细的调研后，从网络和软件应用层上等多个方面来保护用户的办公系统的数 据。此外，由于Android平台是Google免费提供的开源平台，它本身也会存在一定
的安全隐患，这就必须依赖系统及应用软件的更新来弥补这些安全漏洞。
3.5.3可维护性
维护性是指与进行指定的修改所需的努力有关的一组属性。本次开发的数字 化协同移动办公客户端首先应定义统一格式的日志，方便研发人员进行开发，测 试，故障的定位及修复。
3.5.4可扩展性
作为系统设计人员，除了关注产品的功能和性能外，还应多考虑系统结构的 可扩展性，可扩展性是指软件扩展新功能的难易程度。可扩展性越好，表示软件 适应快速发展的需求的能力就越强。本项目的初始需求可能不能满足未来发展的 需要，这时可扩展性就显得尤为重要，因为如果推到原有项目，重新建设， 无 论是经济成本还是时间成本对于企事业单位而言都难以接受。因此本文在设计的 初期必须将未来的扩展性考虑进去，这样才能满足企事业单位日益增长的功能需 求。
第四章 系统总体设计
系统总体设计是移动学习终端平台开发过程中一个重要的阶段，系统设计分 首先是数字化协同移动办公平台总体结构设计，然后根据功能将系统分解为若干 子系统，完成每个子系统的设计。
4.1系统整体架构设计
本系统的架构设计需要考虑到网络安全、数据安全，因此设计如下整体架构 图。在本系统平台的架构中，我们使用包过滤防火墙来保护前置服务器的网络安 全，手机终端用户需连接前置服务器时，必须先通过硬件防火墙的数据包安全检 测，而前置服务器和原协同移动办公平台之间则使用隔离网闸来保证内网服务器 安全性。在应用服务方面，本项目设计主要分为三个部分:原数字化协同办公系 统服务器、前置服务器以及Android手机客户端。
图 4-1 服务器系统及网络拓扑图
(1)原协同办公系统服务器:本项目是在原有的数字化协同办公系统上进行 二次开发，必须使移动终端和桌面终端可以同时使用，系统的数据库仍采用原有 的协同办公系统的数据库,因此本文就采用原始的协同办公系统服务器作为业务 处理和数据库的服务器。在不变动原有功能的基础上扩展出移动办公的功能。
(2)用户身份验证服务器：该服务器的作用是辨别用户身份并根据他们的身 份为其提供相应的应用服务，它同时提供桌面和手机终端用户登陆的用户验证服 务。
(3)前置服务器:前置服务器上的应用服务则是移动办公系统的重点开发的对 象，前置服务器的作用是在移动终端和原有的数字化协同办公系统之间作数据处 理和数据中转之用，为了提高Android客户端和原数字化协同办公系统服务器之 间数据传输的效率，本设计方案通过数据压缩及去冗余的方法降低两者之间的交 互数据的通信量，这实际上是起到了数据过滤的功能。而数据的转发则在数据的 过滤之后，它将自动生成的XML数据传输给协同办公系统和Android移动客户 端，客户端在接收到XML数据后，再调用移动应用客户端上相应的数据解析模 块对XML数据文件进行解析，并显示到移动终端的桌面上。而移动终端发送至 前置服务器的数据，则通过该服务器解析成原数字化协同办公系统所能识别的原 始数据，再发送至原办公系统服务器上由原服务器来处理相应的业务流程。
⑷Android移动应用客户端:Android客户端是安装在用户的Android移动终 端设备之上，它的主要作用是和后端的服务器进行通信，并通过图形化的方式显 示在移动终端设备的屏幕上。 Android 客户端界面设计是本项目的重中之重， Android 客户端除了必须满足用户的功能性需求外，还必须将客户端连入服务器 的安全保障以及友好易用的用户界面考虑进去。Android客户端的主要功能模块 包括登录、安全接入平台、流程处理、XML解析、用户设置、附件处理、客户 端更新等模块,整体功能结构图如图 4-2 所示。
图 4-2 Andriod 客户端功能结构图
4.2前置服务器的实现
前置服务器是专门为移动客户端提供服务的，它并不提供办公系统的核心功 能。它是通过调用原有的数字化协同办公系统的接口来实现与移动客户端的通信 请求。这就避免了需要重新为移动平台定制全新的应用系统的重复工作，极大的 降低了开发成本，提升了开发效率，并且为客户节约了新开发全新协同办公应用 系统的资金。
前置服务器还可以使客户端在向服务器请求数据时的响应数据比原始的服 务器少很多，可以降低网络延时，增强用户体验。前置服务器还可以对移动客户 端的升级维护进行支持，降低原办公服务器的负载。
前置服务器还可以从安全方面来保障企事业单位的数据安全性，同时还可以 给予终端客户良好的使用体验。前置服务器通过HTTPS加密协议来保证数据的 安全，同时系统自带的防火墙的功能来对进出的通信数据进行包过滤的检测来阻 止外网上的一些攻击行为。
前置服务器在逻辑上分为六层：传输加密层、协议适配层、终端适配层、业 务逻辑层、内容聚合层、系统服务层，每层都有各自的作用。在实际部署前置服 务器时，我们可以搭建一个虚拟化服务器平台，将不同的层分别部署在不同的虚 拟服务器之上，并且可将不同的功能模块部署到虚拟化服务器平台不同等级的安 全区域。不同的层次和功能模块在具体的方案中要进行必要的裁剪,以适应各个 企事业单位的需求。根据方案的复杂程度,可能只需要某些层次的某些模块就能 满足要求,在后面的设计中,可以看到模块裁剪的案例。
图 4-3 前置服务器架构图
4.2.1 传输加密层功能说明
传输加密层可以使用软件加密，也可是硬件加密。本项目的传输层是通过 SSL的方式进行加密，同时如有必要还可以使用国密加密。在数据传输过程中， 服务器向客户端发送数据是以加密的方式在互联网上传输，当到达客户端后，则 由客户端进行解密操作，而客户端向服务器发送数据时，也需要先加密数据，再 进行传输，最后再由接受到数据的服务器进行解密。如果使用国密加密，则移动 客户端也需要相应的解密软件或者解密芯片才能实现国密的加密方式。
4.2.2 协议适配层功能说明
因为移动终端用户可能使用不同的应用层协议,而协议适配层可以实现兼容 各种移动终端，由协议适配层来完成的协议的适配工作。本项目所开发的移动客 户端的最佳应用协议为XML/HTTPS,如果使用Web App的方式来开发，则使用 的最合适的应用协议是 HTML/HTTPS。
4.2.3 终端适配层功能说明
终端适配层可以根据不同类型，不同大小，不同分辨率的屏幕将最佳的显示 效果显示在Android手机移动终端显示器上。终端适配层会根据移动终端在请求 中自带的 Agent 信息来自动判断最合适的终端类型,也支持用户个性化自定义的 终端类型。
4.2.4 业务逻辑层功能说明
业务逻辑层主要是前置服务器所有可能的包含前置机所有可能的和业务相 关的模块。在图5-3的前置服务器结构图中仅仅列出了用户可能使用到的一些功 能模块，但根据不同的企事业单位客户的需求，会有不同的功能模块。
4.2.5 内容聚合层功能说明
内容聚合层就是将多个业务模块的数据进行聚合,通常用于登陆首页的信息 展示。内容聚合层可以在不同的用户通过验证后，根据其自身所拥有的权限来显 示相应的功能模块，隐藏其无权使用的功能模块，并将多个功能模块聚合在一个 数据包中，通过终端适配层和协议适配层将要用户的内容返回并显示在用户的移 动终端的显示屏幕上。
4.2.6 系统服务层功能说明
系统服务层包括了一下四个模块:
安全子系统模块:用于实现用户认证,权限管理,签名校验的各种技术方案,包 括PKI, CPK，双通道,OAuth （主要用于微博）认证等。除此之外还实现单点登录的 功能,让用户在不同的系统之间统一认证,根据系统对安全的需求不同,实现多重 认证,认证升级,降级认证等功能。
接口服务子系统模块:该模块为前置服务器提供接口和外部系统进行调用和 通讯。数据路由和格式转换:和现有系统进行集成的工具（例如和数字化协同办公 信息管理系统）。
日志服务和监控审计模块:是数字化协同办公信息管理系统的最基本的安全 要求和保障。
数据压缩和格式转换模块：用于数据传输的压缩及在移动客户端和原协同办 公系统之间进行数据的转换。
4.3移动客户端的分析设计
本文是基于Android客户端平台并使用Scrum软件开发模型来开发移动客户 端应用软件。移动客户端的架构如图5-4 所示,本文采用了比较流行的
MVC(Model View Controller)框架，它是是模型(model)一视图(view) — 控制器 (controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离 的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及 用户交互的同时，不需要重新编写业务逻辑。 MVC 被独特的发展起来用于映射 传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。从图 5-4 中可以看出，前置服务器通过HTTPS加密通道将来自原办公系统服务器的数据转 换成特定的XML数据，再发送给Android客户端,Android客户端在接收到XML 数据后再调用XML解析模块来还原数据，最后通过用户的移动终端显示器显示
图 4-4 客户端整体框架图
本文之所以选择MVC设计模式，是因为它是一个非常适合Android应用开发 的框架形式。视图层一般采用XML文件进行界面的描述，使用的时候可以非常 方便的引入。同时便于后期界面的修改。逻辑中与界面对应的 id 不变化则代码 不用修改，大大增强了代码的可维护性。Android的控制层的重任通常落在了众 多的 Acitvity 的肩上，这句话也就暗含了不要在 Acitivity 中写代码，要通过 Activity 交割 Model 业务逻辑层处理，这样做的另外一个原因是 Android 中的 Acitivity的响应时间是5s,如果耗时的操作放在这里，程序就很容易被回收掉。 模型层将对数据库的操作、对网络等的操作都应该在 Model 里面处理，当然对 业务计算等操作也是必须放在的该层的。 [13]就是应用程序中二进制的数据。由 于 Android 移动应用的需求变化和添加比较不稳定,各模块灵活改动和增添的 MVC 框架在此尤为合适。 MVC 设计模式不仅是 Google 官方推荐的设计开发模 式，同时也是广大的Android开发人员所优先使用的开发模式。
4.4安全接入平台模块设计
安全接入平台本身就是一个Android应用，而Android的安全在很大程度上依 赖于Linux操作系统层的安全机制，尤其对于进程和用户级别的边界限制。由于 Android 面向的是个人设备，即个人持有和使用的设备， Android 巧妙地利用了 Linux内在的多用户支持特性：为每个应用供应商创建一个单独的用户。这意味 着每个应用以不同的用户权限运行（除了那些来自同一个供应商的）。在默认情 况下，一个应用所拥有的文件，其他应用是无法访问的。可以把它理解成一个" 沙盒"。它提供了安全的空间为本项目所研发的Android移动应用在其中运行，将 Android 系统本身的一些风险与客户端应用隔离开来。这种方式带来的直接影响 是由于每个应用在自己的“独立运行空间（silo）”中执行，因而安全性得到了 提高。它是本文所有应用和功能的总入口。当用户在Android移动终端启动移动 办公客户端软件时,首先启动是安全接入平台,安全接入平台在运行后，首先会查 杀后台运行的非白名单中的可疑进程,然后再通过服务器进行用户的验证，在验 证完用户后再加载该用户权限之内能够使用的功能模块,最后会屏蔽 Android 手 机上的 HOME 键,防止移动客户端应用非正常返回桌面，启动其他应用程序。
当 Android 移动终端通过用户认证服务器验证用户的身份和权限后,此时用 户的数据的可信环境将由安全接入平台负责,安全接入平台系统采用白名单机制 来监测Android的移动终端上的后台软件进程,。安全接入平台系统上的白名单不 可自行添加后台应用进程，对用户不可见，统一由安全接入平台模块负责，并随 着软件的更新升级而更新白名单软件,用户无法在安全接入平台的白名单中自定 义非系统指定的软件进程,只能在系统初始化或升级时进行软件的安装、升级或 卸载。
4.5XML数据解析模块设计
由于本文主要的通信数据格式都是XML,那么本文就需要设计出XML数据 的解析模块。当客户端发送一个request请求，服务端就会以xml的数据格式返 回一个response响应。但是在客户端界面展示xml数据并不是那么人性化与现实, 所以在此之前，会对xml进行数据解析。纵观软终端的大部分项目中，在客户端 进行数据解析采用的是SAX（Simple API for XML）,这是有道理的。SAX的工作原 理简单地说就是对文档进行顺序扫描，当扫描到文档（document）开始与结束、 元素（element）开始与结束、文档（document）结束等地方时通知事件处理函 数，由事件处理函数做相应动作，然后继续同样的扫描，直至文档结束。因为 SAX 具有解析速度快，内存消耗少，可以有多个 ContentHandler 对象，所以本 文觉得SAX的XML解析方式更适合本项目的Android移动客户端的XML数据 的解析。
4.6数字签名模块设计
因为考虑到用户操作的数据安全性以及不可抵赖性，本文设计了这套数据签 名模块，凡是在协同移动办公系统中重要的操作流程均需要个人数字签名数据, 数字签名技术是将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接 收者只有用发送者的公钥才能解密被加密的摘要信息，然后用 HASH 函数对收 到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的 信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签 名能够验证信息的完整性。［14］本文目前涉及到数字签名功能使用的地方主要是 流程处理模块中对流程的处理中送下一结点、回退和直送三种处理过程均需要完 成数字签名过程。
4.7附件下载和查看模块设计
本文设计了一个附件下载管理器，通过验证的用户可以根据服务器授予的权 限，自动调用下载管理器来下载相应的附件。Android移动客户端通过XML数 据流来获得附件的下载列表以及下载地址链接。移动客户端进入到下载列表后， 在这里登录用户可以对附件进行下载。当点击“下载”按钮后，后台线程便开始 进行进行附件的下载。当附件下载完毕，如需立即查看附件，本文将自动调用 Android 设备上已经安装的与附件格式匹配的相应的客户端应用进行查看。
4.8客户端更新模块设计
客户端的更新升级非常重要，不但可以及时通过升级的方式来解决移动客户 端在设计中的BUG,还可以在需要做功能模块的扩展时，及时更新移动终端的 客户端软件，使之可以及时使用扩展的功能。
本文开发时，将在客户端的和前置服务器的相应的XML文件中存放Android 协同移动办公系统客户端的版本信息,并且将最新的客户端应用的安装文件放在 前置服务器上。当应用软件启动后，后台的更新模块的进程将分别获取本地和前 置服务器上的版本信息,并进行比对,若前置服务器的版本号高于移动终端客户端 的版本好,则会自动启动下载进程来下载新版本的客户端软件。当新版客户端软 件下载完成后,将自动关闭本地的客户端进行更新安装。具体流程图如下图所示：
图 4-5 客户端自动更新流程图
4.9数据交互接口设计
数字化协同办公系统在该企业的整个信息化架构中处于管理信息化层，作为 管理信息化系统的一部分，数字化协同办公系统与前置服务器应用系统、已建成 或将建设的多个信息系统都存在数据的交互关系。
本项目在数据交互接口设计方案中采用以下几种技术来实现应用系统间的 数据交互。通过以下提供的几种数据交互机制，可以实现数字化协同办公系统与 其他应用系统间的应用互连。
1.数据库集成技术
在数字化协同办公系统中可以使用数据库集成机制实现与第三方应用系统 集成。数字化协同办公系统和前置服务器应用系统可以通过JAVA数据库连接技 术来实现在数据库层上的数据集成。
2.网址页面集成技术
在数字化协同办公系统中可以使用网址页面集成机制实现与第三方系统应 用集成，用户可以通过点击数字化协同办公系统中的网址链接进入第三方应用系 统。
3.基于文件交换的集成技术
这种基于文件交换的技术主要是针对一些对实施数据传输延时不敏感的应 用系统，且因其系统的相对封闭性仅能提供传统接口方式来进行数据交换。采用 基于文件交换的集成技术，数字化协同办公系统需要与目标系统协商需要交互的 文件内容及其格式，目标系统在规定的时间调度内将包含源数据的文件发送到数 字化协同办公系统指定的文件目录中，数字化协同办公系统处理这些文件后可以 获得需要的数据，并根据需要决定是否返回处理结果给目标系统。
4.基于特定网络协议集成技术
基于特定网络协议的技术在数字化协同办公系统来实现与第三方系统应用 集成与数据交互，通常可以在两者之间通过HTTP协议来完成两大系统的数据传 递工作。
5.Web Service
Web Services就是应用程序，它设计了一个能够通过Web进行调用的API。 而这个API的作用就是通过编程的方法来调用相关的应用程序。Web Services是 建立可互操作的分布式应用程序的新平台之上的， Web Services 平台是一套标 准，它定义了应用程序如何在Web上实现互操作性。用户可以用任何语一言， 在任何平台上写 Web Services，我们可以通过 Web Services标准对这些服务进 行查询和访问。
数据交互接口实现方式说明：对于系统数据传输量不大的交互，采用 Web Service实现应用系统的集成。Web Service适用于不用语言不同平台的应用程序 集成，便于跨防火墙的通信，实现方便。对于系统数据传输量较大的交互，根据 原有系统的实际情况，优先选择SOA的方式，如XML；其次选择数据库级别或 者导出文件的方式。
第五章 系统详细设计与实现
本章节主要是根据以上两个章节对Android数字化协同移动办公信息管理系 统进行深入的设计。并且对系统的各个功能组成模块的具体技术进行深入分析， 对Android数字化协同移动办公信息管理系统进行了具体的设计实现。对各功能 模块使用的具体技术和实现方法进行了详细的描述。
5.1 系统架构实现
本系统的分层架构图如下所示：
表现层(JSP)
控制层(Con troller)
业务逻辑层(Service)
数据访问层(Da。)
持久化层(P0)
数据库(DB)
图 5-1 系统分层架构图
1. 表现层
传统的 JSP 技术实现。 JSP 经过多年的发展，应用广泛而稳定，能够很好的 将信息显示给客户。 JSP 页面接受客户的具体请求，并对用户输入的数据进行简 单的格式验证，然后发送给控制层相应的Action类，并获得返回数据显示在JSP 页面上。
本系统表现层的具体结构如下图所示：
d 曲 WebRoot t> 已 images
META-INF
script style WEB-INF
> & jsp [::'I i b
爲f mis.tld 冈 web.xml 宙 bottom.jsp 』center.jsp j* index.jsp 笑 initDbFinish.jsp C? I&ftjsp E? loginULjsp C? logoutjsp ® noPrivilege.jsp C? rightjsp 居 W.jsp 国 welcome.jsp
图 5-2 系统表现层结构图
图6-2中各个文件夹及JSP文件的具体作用如下表所示。
表 5-1 表现层主要文件夹 /文件介绍
序号 文件夹/文件 功能介绍
1 images jsp页面中所要用到的图片资源
2 script 各个页面用到的javascript脚本的集合
3 style jsp页面所用的css样式
4 WEB-INF/jsp 系统所有需要登录才能访问的jsp页面
5 index.jsp 系统首页
6 welcome.jsp 登陆成功的欢迎界面
2. 控制层
即MVC模式里面的“C"(controller)，负责控制业务逻辑层与表现层的 交互，由Struts2来实现。当用户通过JSP页面发送一个请求时，Struts2会把请 求转发给对应的 Action 类， Action 类通过调用业务逻辑层接口来得到用户请求 的数据，再发送给相应的JSP页面。
本系统控制层的具体结构如图 5-3 所示：
图 5-3 系统控制层结构
控制层主要包和类及其功能的介绍如下表所示：
表 6-2 控制层主要包或类介绍
序号 包/类 功能介绍
1 contract 包 办公管理相关功能的Action类，主要有ContractAction.java、 CapRtnAction.java、ImplCostAction.java、
ContractIndustryAction.java、 FncAction.java、 PchAction.java、 SaleAction.java 等
2 interceptor 包 struts2拦截器，用于检测用户是否登录，请求数据的用户未登 录则转发页面到首页，包含 AuthInterceptor.java 和 PrivilegeAuthTag.java
3 user 包 用户相关信息 Aciton 类，包括 DepAction.java， RoleAction.java， DutyAciton.java， UserAciton.java 等。
4 BaseAction.java 继承Struts2的ActionSupport.java，实现了大量常用方法，本 系统的所有Aciton类都继承该类。
5 ExcelWorkSheet.j ava 需要生成excel报表并下载的Action需要使用该类。
6 J qGridB aseAciton.j ava 如果JSP页面需要使用JqGrid表格，则需要继承该类
7 InitDbAction.j ava 初始化测试数据的Action
3. 业务逻辑层
负责实现管理业务逻辑。业务逻辑层接口的方法被 Action 调用后，会调用
DAO层的接口从数据库读取数据，并对读取的数据进行一定的处理并返回。
本系统业务逻辑层的具体结构如图 5-4 所示：
幅 Package Explorer日 爲> a B
"曲 service
t> S bws
>田 contract
田 cus
>由 pdt
卜田&p
丿田user
/ S impl
>[7] DepSerlmpl.java
>[T] DutySerlmpl.java
>[T] ResSerlmpl.java
>[?] RoleSerlmpl.java
|> [7) SearchRoleSerlmpl.java
t> [T] UserSerlmpl.java
l> ① DepSer.java
A E) DutySer.java
> ® ResSer.java
t> [T] RoleSer.java
l> 2] SearchRoleSer.java
t> ® UserSer.java
图 5-4 系统业务逻辑层结构
业务逻辑层的主要包和类及其功能的介绍如下表所示：
表 5-3 业务逻辑层主要包和类介绍
序号 包/类 功能介绍
1 contract 包 该包都是接口，定义了办公系统所需业务方法的名称，主要有
ContractSer.java、CapRtnSer.java、ImplCostSer.java、
ContractIndustrySer.java、FncSer.java、PchSer.java、SaleSer.java 等
2 contract.impl 包 contract包中的接口的实现类，主要有ContractSerlmpl.java、 CapRtnSerImpl.java、ContractIndustrySerImpl.java、
FncSerImpl.java、 PchSerImpl.java、 SaleSerImpl.java 等等
3 user 包 和用户相关的一些信息的处理的接口，主要有UserSer.java、 DepSer.java、 RoleSer.java 等。
4 user.impl 包 user包中接口的实现类，主要有UserSerlmpl.java、 DepSerImpl.java、 RoleSerImpl.java 等。
4. 数据访问层
即Dao层，负责与持久化对象PO交互。本系统的该层封装了数据的增删查 改基本操作，供 Service 层调用。不过为其降低模块耦合，提高代码规范， Service 层的类并不直接访问Dao层的实现类，而是其对应的接口。
(e Package Explorer 仔爲▽ 1=1 亡
"® dao Ij
d 田 contract
t> ffi impl
t> 国 CapRtnDaojava
t> 国 ContractDaojava
> [j] ContractlndustryDaojava
t> 国 ContractPropertyDaojava
t> 2) ContractTypeDaojava
t> [j] DepPercentDaojava
t> 2) FncDaojava
t> [J) ImpICostDaojava a
t> 国 ImpICostTypeDao.java
t> [J] PayTypeDaojava
t> 国 PchDaojava
t> ① PchPayDaojava
t> PchPdtDaojava
t> 国 RdCostDaojava
t> 2) SaleDaojava _
t> [J] SaleRewardDao.java
t> [7) TaxBillTypeDao.java
r> $ cus
>$ pdt
>$ sp
>$ user
>[T| BaseDao.java
>[I] BaseDaoImpl.java
>冈 Criterionjava
图 5-5 数据访问层结构
数据访问层主要包和类及其功能的介绍如下表所示：
表 5-4 数据访问层主要包和类介绍
序号 包/类 功能介绍
1 contract 包 该包都是接口，主要有 ContractDaojava、CapRtnDaojava、
ImplCostDao.java、 ContractIndustryDao.java、 FncDao.java、 PchDao.java、 SaleDao.java 等
2 contract.impl 包 contract包中的接口的实现类，主要有ContractDaolmpl.java、 CapRtnDaoImpl.java、 ContractIndustryDaoImpl.java、
FncDaoImpl.java、 PchDaoImpl.java、 SaleDaoImpl.java 等等
3 user 包 和用户相关的一些信息的处理的接口，主要有UDaoDao.java、 DepDao.java、 RoleDao.java 等。
4 user.impl 包 user包中接口的实现类，主要有UserSerlmpl.java、 DepSerImpl.java、 RoleDaoImpl.java 等。
5 BaseDao.java Dao层的核心类，定义大量的通用方法，如对数据库表的增删 改查等，本层的其他接口或类只要继承BaseDao.java就可少写 大量代码
6 BaseDaoimpl.java BaseDao.java 接口的实现类，通过 Spring 的 SessionFactory.java 来获得数据库会话，事务直接配置给Spring
1. 实体层
本系统采用 Hibernate 框架作为 ORM 框架，实体层的每一个实体类都对应
着数据库中的一个表，通过对实体类的增删改查，就能够很方便的对数据库中的 相应数据进行相同的操作。
对于实体类的生成，可以用一些工具（如Power Designer）将关系型数据库 的数据映射通过逆向工程为生成相应的实体类，不过这种方法有很大的缺点，比 如进行了不大的改动也要重新对所有的实体类重新生成，太过依赖开发工具，而 且对多对多和一对一的支持也不好，现在已经很少有人用逆向的方式来生成实体 类。
现在使用 Hibernate 框架的开发者绝大多数都是用正向的方式来一个一个的 手写实体类，虽然初期可能工作量较大，但后期的修改很方便，而且能够加强开 发者对Hibernate框架的了解。
该层的主要类和hbm文件如下图所示：
图 5-6 实体层类结构
5.2移动客户端主要功能模块的具体实现
5.2.1系统开发环境
开发语言：JAVA
开发平台： 2.3 版本以上的 Android 系统
操作系统平台： WINDOWS 7
系统结构： C/S
开发工具： Eclipse3.6+ADT2.1+SDK1.6+Tomcat6.0
5.2.2Android 运行环境
1．Android 开发资源获取
(1)java JDK 下载:
进入该网页: http://java.sun.com/javase/downloads/index.jsp 选择 Download JDK只下载JDK，无需下载jre.
(2)eclipse 下载
进入该网页:http://www.eclipse.org/downloads/ (或者直接点击下载:BT下载、 HTTP 下载)我们选择第一个(即 eclipse IDE for java EE Developers)
(3)下载 Android SDK
说明:Android SDK两种下载版本，一种是包含具体版本的SDK的，一种是 只有升级工具，而不包含具体的SDK版本，后一种大概20多M,前一种70多 M。
完全版下载 (android sdk 2.1 r01) 升级版下载 (建议使用这个，本例子 就是使用这个这里面不包含具体版本，想要什么版本在Eclipse里面升级就行)
2. 软件安装
(1)安装 jdk 6u19 安装完成即可，无需配置环境变量
(2)解压 eclipse eclipse 无需安装，解压后，直接打开就行
(3)解压 android sdk 这个也无需安装，解压后供后面使用
3. Eclipse 配置
(1)安装 android 开发插件
打开 Eclipse, 在菜单栏上选择 help->Install New SoftWare 输入网址: https://dl-ssl.google.com/android/eclipse/(如果出错，请将 https 改成 http)点击 Next-->Next 按钮，选择 I accept the terms of the license agreements 点击 Next,进入 安装插件界面，安装完成后，点击Yes按钮，重启Eclipse.
(2)配置 android sdk
点击菜单window->preferences，选择你的android SDK解压后的目录，选错了 就会报错，这个是升级工具，目前还没有一个版本的SDK；升级SDK版本，选择 菜单 window->Android sdk and avd manager 选择 update all 按钮，选择左边的某 一项，点击accept表示安装，点击reject表示不安装，我这里只选了 SDK 2.1和 samples for api 7 , 自己可以任意自定义，确定后，选择 install 按钮，进入安装； 新建 AVD(android vitural device)和上面一样，进入 android sdk and avd manager, 选中Vitural Devices在点击New按钮，点击New按钮后名称可以随便取，target 选择你需要的SDK版本，SD卡大小自定义，点击Create AVD,得到如下结果显示 创建 AVD 完毕。
图 5-7 创建 AVD 过程结果完成截图
(3)新建 Android 项目
选择菜单file->new->other进入如下界面:选择新建Android Project项目，点 击Next按钮，名称自定义，应用程序名自定义，报名必须包含一个点以上，min SDK version里面必须输入整数，点击Next，注：若有错误如:Project ... is missing required source folder: 'gen'，则将 gen->Android.Test->R.java 这个文件删掉? Eclipse 会为我们重新生成这个文件，并且不会报错。
5.2.3 用户登陆模块实现
图 5-7 登录流程图
登录模块实现， 跟通常的验证方法一样， 本文主要使用开源的 DefaultHttpClient 包，通过对 http 协议的各种操作封装，以便此次开发的使用。 登录验证时，移动客户端需要post两个必填参数，一个是用户名，一个是密码。 前置服务器对用户名和密码验证通过后，返回 cookie 值，客户端进行保存，后 续的 http 操作都要使用这个 cookie 值作为必要的参数保证进行通信安全，前置 服务器会根据 cookie 的值对当前登录用户的会话状态维护。
登录成功后移动客户端会get到当前登录用户的待办事项的XML数据流， 解析之后得到具体数据信息，再保存到具体实例类里。移动客户端会根据流程的 数量，对主界面中的“待办事项”图标进行重绘。这里本文是使用OpenGL的开 源类库提供的方法实现的，对"待办事项"的图标进行了重绘，根据待办事项的数 量在应用图标的右上角新建了一个canvas，来绘制了图示样式的待办事项个数， 然后合并图层，达到提示效果。
5.2.4 待办事项模块实现
成功登录后，点击"待办事项"图标进入待办事项界面，界面左侧使用 Android 的Listview控件，显示每条待办事项的具体信息，这些数据信息在用户成功登录 时就已经从前置服务器端get到,并存放在了相应的实体类里只要取出显示即可。 进入待办事项页面时，本文通过改写的BaseAdapter将Listview与数据源建立对
应关系。
每当用户访问视图列表中的内容时，Listview的具体信息会被显示出来。用 户访问Listview过程中，系统通过后台的线程，从前置服务器上获取对应流程具 体的 XML 数据流，并使用 XML 解析器进行数据解析，将数据存放到对应的 实体类中，最后使用硬编码的方式将实体类中存储的数据显示在对应的组件中。
5.2.5 公文管理模块实现
系统能实时的接收内部0A系统发来的公文清单，归类到“待办公文”中，当 公文处理完毕后，将公文归类到“已办事项”目录中。如下图所示：
已办清单
"已办事项列表（） 十月份收支明细表 〉
所得税收政策 >
部门员工调整计划 〉
召开2010年股东大会、
预案 ?
本月财务收支明细表>
共5条记录页首页上一
页下一页
图 5-12 已办公文列表
公文以文件的传递为主，处理选定公文后，服务器将会把公文的状态更改为 “处理中”状态，手机客户端根据用户的选择从服务器下载相关的公文（权限允许 的情况下），在当前用户处理完公文前，其他用户不允许下载处理该公文。打开 公文后，可以在附件中查看公文的内容，然后对公文作两种形式的处理。一是“领 导批示” 指的是使用客户端的用户角色为领导时，可以对公文进行批示，二是“相 关意见”可以填写有关意见，改变公文的审批状态。对公文进行批示后将批示信 息反馈到服务器，服务器会将对应公文的的批示状态信息会改变。
图 5-13 待办公文列表
公文处理的实现的主要代码如下：
public void initializeResolveListener() {
mResolveListener = new NsdManager.ResolveListener() {
@Override
public void onResolveFailed(NsdServiceInfo serviceInfo， int errorCode) {
Log.e(TAG， "Resolve failed" + errorCode);
@Override
public void onServiceResolved(NsdServiceInfo serviceInfo) {
Log.e(TAG， "Resolve Succeeded. " + serviceInfo);
if (serviceInfo.getServiceName().equals(mServiceName)) {
Log.d(TAG， "Same IP.");
return;
}
mService = serviceInfo;
int port = mService.getPort();
InetAddress host = mService.getHost();
}
protected void onPause() {
if (mNsdHelper != null) { mNsdHelper.tearDown();
}
super.onPause();
}
@Override
protected void onResume() {
super.onResume();
if (mNsdHelper != null) {
mNsdHelper.registerService(mConnection.getLocalPort()); mNsdHelper.discoverServices();
}
@Override
protected void onDestroy() {
mNsdHelper.tearDown();
mConnection.tearDown();
super.onDestroy();
}
public void tearDown() { mNsdManager.unregisterService(mRegistrationListener); mNsdManager.stopServiceDiscovery(mDiscoveryListener);
}
公文查询功能可以查看公文的详细内容和公文的审批过程。当一个教师使用 手机客户端对公文进行处理后，信息反馈到服务器是，对这份公文的相关数据库 的字段就会更新，另外一个用户如果在更新后下载这份公文进行处理，就会得到 最新的公文审批信息。
图 5-15 公文详细情况
实现公文查询的主要代码如下：
i@Qv 亡 mckd
public void onReceive|(Context context, Intent intent) {心
String action = intent. getActionOs
if (WifiP2pManager.W7IFI_P2P_STATE_CHANGED_ACTION.equals(action)) 2
// Determine if Wifi Direct mode is enabled or not, alerts
// the Activity.a
int state = intent.getIntExtra(WifiP2pManager.EXTRA_XV7IFI_STATE, -1);^
if (state = WifiP2pManager AVTFI_P2P_STATE_ENABLED) {w activityr.setIsWifiP2pEnabled(true)；4J
} ehe {a
activity. setIsWifiP2pEnabled(false)屮
} else if(WifiP2pManager.\MFI_P2P_PEERS_CHANGED_ACTION.equals(action)) 2
// The peer list has changed! We should probably do something about^
// that>'
} else if(^4fiP2pManager.\KTIFI_P2P_CONNECTION_CHANGED_ACTION.equals(action)) {a
//' Connection state changed? We should probably do something about*-'
// that-d
} else if(^7ifiP2pManagerAKIFI_P2P_THIS_DE\rICE_CHANGED_ACTION.equals(action)) {a DeviceListFragment fragment = (DeviceListFragment) activity.getFragmentManagerO^-1
.findFragmentBvId(R. id.fragjist):^
fragment.updateThisDevice((WifiPlpDevice) intent. getParcelableExtra(*-'
WifiP2pManager.EXTRA_X\Tn_P2P_DE\lCE));p
5.2.6 附件下载模块实现
本 Android 移动办公系统暂时不提供在手机上编辑公文文件的功能，所以公 文以及公文的附件都需要上传到服务器或者从服务端下载的操作。
在附件下载模块，登录用户可以根据权限，下载其负责的项目的附件。解析 服务器发送的XML数据流中，得到附件下载列表和下载地址链接信息，移动客户 端在显示下载列表信息时，先根据项目分类，再根据可下载附件个数进行分页。
进入到下载列表后，在这里登录用户可以对附件进行下载。当点击“下载” 按钮后，后台线程便开始进行附件下载，此时下载按钮被屏蔽无法点击，而是显 示文字“正在下载”。
在Android平台中，对比较耗时的操作，一般推荐在新线程中进行，在附件下 载时，本文就是新建了多个下载线程进行多线程下载
客户端实现的“下载管理器”是 DownloadManager 的一个实例， DownloadManager 的设计采用的是单例模式，即每个用户登录成功后只生成唯一 的一个“下载管理器”实例来维护当前账户下所有附件的下载。
这里以XML文件的上传下载为例阐述这项应用的具体实现。
（1）Android 平台文件的上传
一个文件上传的内容的实现，Android要实现文件上传，可以利用Socket 上传，也可以模拟 Web 进行上传，但是如果是使用第一种方式上传，严格的话就 得使用TCP，这样容易生成系统死掉，或者是长时间等待，如果是UDP来传，就 容易造成数据丢失，因此在这里选择了 Web进行上传，使用Web进行上传是模拟 的Http Post上传数据，当然，Post上传数据的类，在网上找了一找，方式虽然很 多，但是没有一个感觉是我所使用的，所以参照原理之类的，进行了一下修改， 算是做了一个参考。并且利用这个类完成了文件和表彰的上传服务。
package com.UpLoadFileTest;
import java.io.BufferedReader;
import java.io.DataOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.InputStream;
import java.net.HttpURLConnection;
import java.net.URL;
import java.util.Map;
public class PostFile {
public static String post(String actionUrl, Map<String, String> params,
Map<String, File> files) throws IOException {
String BOUNDARY = java.util.UUID.randomUUID().toString();
String PREFIX = "--", LINEND = "\r\n";
String MULTIPART_FROM_DATA = "multipart/form-data";
String CHARSET = "UTF-8";
URL uri = new URL(actionUrl);
HttpURLConnection conn = (HttpURLConnection)
uri.openConnection();
conn.setReadTimeout(5 * 1000);
conn.setDoInput(true);
conn.setDoOutput(true);
conn.setUseCaches(false);
conn.setRequestMethod("POST");
conn.setRequestProperty("connection", "keep-alive"); conn.setRequestProperty("Charsert", "UTF-8");
conn.setRequestProperty("Content-Type", MULTIPART_FROM_DATA
+ ";boundary=" + BOUNDARY);
StringBuilder sb = new StringBuilder();
for (Map.Entry<String, String> entry : params.entrySet()) { sb.append(PREFIX);
sb.append(BOUNDARY);
sb.append(LINEND);
sb.append("Content-Disposition: form-data; name=\""
+ entry.getKey() + "\"" + LINEND);
sb.append("Content-Type: text/plain; charset=" + CHARSET + LINEND);
sb.append("Content-Transfer-Encoding: 8bit" + LINEND); sb.append(LINEND);
sb.append(entry.getValue());
sb.append(LINEND);
}
DataOutputStream outStream = new DataOutputStream(conn .getOutputStream());
outStream.write(sb.toString().getBytes());
if (files != null)
for (Map.Entry<String, File> file : files.entrySet()) { StringBuilder sb1 = new StringBuilder();
sb1.append(PREFIX);
sb1.append(BOUNDARY);
sb1.append(LINEND); sb1.append("Content-Disposition:form-data;name=\"file\";
filename=\""+ file.getKey() + "\"" + LINEND);
sb1.append("Content-Type:application/octet-stream;charset=" + CHARSET + LINEND);
sb1.append(LINEND);
outStream.write(sb1.toString().getBytes());
InputStream is = new FileInputStream(file.getValue());
byte[] buffer = new byte[1024];
int len = 0;
while ((len = is.read(buffer)) != -1) {
outStream.write(buffer, 0, len);
}
is.close();
outStream.write(LINEND.getBytes());
}
byte[] end_data = (PREFIX + BOUNDARY + PREFIX LINEND).getBytes();
outStream.write(end_data);
outStream.flush();
int res = conn.getResponseCode();
InputStream in = conn.getInputStream();
InputStreamReader isReader = new InputStreamReader(in);
BufferedReader bufReader = new BufferedReader(isReader);
String line = null;
String data = "OK";
while((line = bufReader.readLine())==null)
data += line;
if (res == 200) {
int ch;
StringBuilder sb2 = new StringBuilder();
while ((ch = in.read()) != -1) {
sb2.append((char) ch);
}
}
outStream.close();
conn.disconnect();
return in.toString();
}
}
2)Android 平台文件的下载
要实现的是文件的下载，其实下载文件与打开网页是一样的，打开网页是将
内容显示出来，保存文件就是保存到文件中即可。
实现的代码基本如下:
public void downFile(String url, String path, String fileName) throws IOException { if (fileName == null || fileName == "") this.FileName = url.substring(url.lastIndexOf("/") + 1); else this.FileName = fileName; // 取得文件 名，如果输入新文件名，则使用新文件名 URL Url = new URL(url); URLConnection conn = Url.openConnection(); conn.connect(); InputStream is = conn.getInputStream(); this.fileSize = conn.getContentLength();// 根据响应获取文件 大小 if (this.fileSize <= 0) { // 获取内容长度为 0 throw new RuntimeException(”无 法获知文件大小 "); } if (is == null) { // 没有下载流 sendMsg(Down_ERROR); throw new RuntimeException("无法获取文件”)；} FileOutputStream FOS = new FileOutputStream(path + this.FileName); // 创建写入文件内存流，通过此流向目标 写文件 byte buf[] = new byte[1024]； downLoadFilePosition = 0； int numread； while ((numread = is.read(buf)) != -1) { FOS.write(buf, 0, numread)； downLoadFilePosition += numread } try { is.close()； } catch (Exception ex) { ； } }
通过此代码就可以实现将内容保存到SD卡等设备上，当然要使用网络，必须 得有网络的访问权限。这个需要自己添加，在这里不再添加!
上面的代码没有实现进度条功能，如果要实现进度条功能，我现在考虑到的 就是使用消息进行发送提示，首先实现一个消息。
private Handler downloadHandler = new Handler() { // 用于接收消息，处理进度 条 @Override public void handleMessage(Message msg) { // 接收到的消息，并且对 接 收 到 的 消 息 进 行 处 理 if (!Thread.currentThread().isInterrupted()) { switch (msg.what) { case DOWN_START: pb.setMax(fileSize)； //设置开始长度 case DOWN_POSITION: pb.setProgress(downLoadFilePosition)； // 设置进度 break； case DOWN_COMPLETE: Toast.makeText(DownLoadFileTest.this, " 下 载 完 成 !", 1).show()； // 完 成 提 示 break； case Down_ERROR: String error =
msg.getData().getString("下载出错!")； Toast.makeText(DownLoadFileTest.this, error, 1).show()； break； } } super.handleMessage(msg)； } }；
这样，在下载的时候只要发送相应的消息，即可有相应的提示!
正文： 施方案 (233KB)
附件： 4|附件pdf (132KB) .附件txt (132KB) 附件xls (132KB)
m附件bmp
® (432 KB)
-附件jpg
一 (132KB)
,附件png
■ (132KB)
图 5-18 附件下载列表截图
5.2.7 自动更新模块的具体实现
Android 系统自身并不会检査系统已安装应用程序的版本信息，也不会强制任 何应用升级或兼容，是用户或应用自身对应用的版本有所限制。
Android 系统会自动在应用的 AndroidManifestxml 文件中的＜1113111(651＞标 签中描述当前应用的版本信息(minSdkVersion特性指定)。这样，应用程序就能 指定兼容的最低的系统 API。
1、版本信息的设定和获得
本文开发时在程序的 AndroidManifestxml 文件中＜1113111651＞标签中进行设 定了应用的版本信息。这里有两个属性，而且通常需要将两个值都设定：
(1)android:versionCode 整型：表示应用程序的相对版本，就是版本实际更新 过多少次。整型便于同其它程序比较，检查是应该升级或降级。开发者可以将这 个数值设定为任何需要的值，不过开发者需要保证后续的新版本要比这个值大。 系统虽然不会强制要求此行为，但是随着版本升级数值也增加是正常行为。通常 开发者发布的原始版程序的versionCode设为1 ,之后每次发布都相应的增加，不 论发布的内容是大还是小。这就意味着android:versionCode并不像应用程序的发布 版本(android:versionName)那样显示给用户，应用和发布的服务一般不需要显示 这个值给用户。
(2)androidiversionName 字符串值：表示应用程序版本信息，此信息是需要显 示给用户的。同android:versionCode一样，应用不会为了任何内部的目的去调用这 个值，这个值仅仅是为了显示给用户。发布服务时也要提取该值来显示给用户。
本文先在 AndroidManifest.xml 文件中的 ＜1110111631＞ 标签中定义了这两 个版本的特性。本文依据android:versionCode的值可以知道出当前的apk是哪一版 本释放的代码， 根据 android:codeName 字符串内容得知当前的版本名是 “a20120923”。
Android系统的应用框架层提供一个API专门用来查询应用的版本信息。为了 方便开发过程中获得版本信息，本文专门编写了 getAPKVersion( ) 函数来获得版 本信息。
pg、工实 String getAPKVersionf ) {心
直= nullz+J
Padca^eManager pm =舉疋直虫藝朝戛0*
Eg來 gggbjfe info = null;*-1
to和
mfo — p英:呂宴理來Bgf］殳;foC'qg藝bg刃"a
Paoka匪Nto昭旦-GET—ACTIVITIES)；斗
} catch 0£^£理@巫9理4£馥朋4慫 e) {“
IITODO Auto-generated catch block*-1
5血gS坦強企©f)*1
if (info ! = null) 2
= info:varsionName; a
H
appVersion;^
图 5-19 版本信息获取方法
通过图5-12的方法Native客户端就可以从AndroidManifest.xml文件中获取安 装到终端设备上的应用版本信息。本文将版本信息存放在 appVersion 字符串变量 中。版本号的获取同理，本文在开发过程中没有使用版本号，在此也就不做说明。
2、Android 系统版本设定
如果开发者的应用程序有最低Android API限制，又或者仅仅只是设计用于指 定版本范围的 Android 平台，那开发者就可以在应用的 AndroidManifest.xml 配置 文件中指定API的等级信息。这样做是可以确保应用只会被安装在使用有兼容的 Android系统的终端设备上。常用的Android系统配置属性如下：
(1)android:minSdkVersion：应用能运行的最低版本的Android系统，通过 Android 平台的 API 等级标识来指定。
(2)android:targetSdkVersion:可以指定应用运行需要的API等级。在某些情 况下，可以允许应用显式的指定运行所需的 API 等级，而不是仅仅指定最低运行 所需的 API 等级。
⑶android:maxSdkVersion:应用可以运行需要的最高Android系统版本，通 过 Android 平台的 API 等级标识来指定。
当准备安装应用 apk 时，系统会自动检查这个属性的值同时与系统版本进行 比对。若 android:minSdkVersion 值大于系统版本，系统会自动放弃当前应用的安 装。同样，系统也有只在 androidmaxSdkVersion 与当前系统的版本相互兼容时才 会执行安装。本文在 AndroidManifestxml 文件中只设置了 androidminSdkVersion 的值。
常用的数字签名的功能是通过浏览器的Flash安全插件使用个人证书完成数签 名功能的，本文开发的基于Android平台数字化协同移动办公信息管理系统中，必须 采用另一种最新的方式完成数宇签名功能。
3、Android 客户端最新版本信息的获得、下载和安装
客户端创建并启动一个新的线程checkUpdate，通过http协议从前置服务器上 获取最新的移动客户端的版本名，并存放在newVersion字符串变量中，与之前所 获取的Native客户端的版本信息变量appVersion比较判断是否要进行新版本下载, 同时新版本的 url 也会被保存。
客户端可以通过后台的下载线程，使用 http 协议，获取前置服务器上的最新 版本的 url 来下载最新 APK 安装文件
客户端可以通过installAPK()方法安装并替换已有客户端。本文通过定义自己 的 intent，通过它的 setDataAndType(Uri data, String type)方法，其中参数 type 和 data 分别为 APK 安装文件的 Uri 和操作类型字符串，然后使用方法 startActivity(intent) 启动早已定义的intent，系统便会根据APK的数字签名信息自动匹配旧版本客户 端，提示用户替换更新，完成安装。
5.2.8 Android 客户端扩展功能
本节将会对Android平台应用的一些扩展技术进行介绍，主要从两方面进行介 绍:屏幕的适配和 strings.xml 文件。
1. 屏幕适配
顾名思义，屏幕适配就是为自己开发的应用支持不同终端的分辨率做出的基 本配置，准确的说是适配小、中、大三种密度，其中密度的大小是以dpi为单位区 分的，中密度标准是160dpi,如果大于此值的屏幕密度就为高密度，如果小于此 值的自然为低密度。android:anyDensity=''true"，这一句代码对整个屏幕都起着非常 重要的作用，值为true,本文的应用在安装于不同密度的移动终端上时，应用程序 会根据实际情况自动加载后缀名为 hdpi,mdpi,ldpi 的不同文件夹中的相应资源，主 要包括图片资源、布局文件资源等。
此外，开发者还可以定义名为 layout、 layout-800x480、 layout-1024x600 的布 局文件夹，分别用来存放不同分辨率布局文件，对于具有不同分辨率手机屏幕， Android 系统可以自动加载对应布局文件，从而达到最好显示效果。不过由于如今 Android 系统的手机设备五花八门，开发者应该编写默认的通用的布局文件，以提 供非主流分辨率的屏幕使用，这些布局文件可以存放在 layout 文件夹下，显示的 效果可能会有一定拉伸和压缩的效果，但是不会影响使用功能。
2. string.xml 文件的使用
string.xml 文件在 Android 项目中 res/values 文件夹下，是专门用来存放字符串 和数值常量的。本文之所以特别强调要使用string.xml文件原因如下：
(1)可以减少应用程序占用空间，降低数据的冗余。
假设我们在应用中要使用“系统正在处理”这个字符串常量 10000 次，如果 本文不将“系统正在处理”定义在 strings.xml 文件中，而在每次使用时直接声明 该字符串，这样下来应用程序中将有60000余个字，这60000个字将会占116KB 的空间。而手机的资源十分有限，尤其 CPU 的处理能力和内存是非常有限的， 116KB 对于手机程序来说是一个不小的空间了，开发者在开发手机应用时一定要 牢记“能省内存就省”。如果将这个字符串在 strings.xml 中，在每次使用时通过 Resources类引用该字符串，仅仅占用了 11B而已，可见string.xml对降低应用的 体积效果是非常明显的。
(2)为了更方便的是移动客户端支持多国语言。
Android系统建议将在屏幕上显示的文字都定义在strings.xml文件中，这样如 果今后需要支持多国语言，如开发者开发的应用仅支持中文，未来开发人员希望 将自己的开发手机客户端推向世界，需要支持更多的语种。开发人员为了更方便 的添加多国语言，就必须把使用 strings.xml 文件来定义客户端软件界面的语言， 否则每增加一种语言都会带来相当大的工作量，这样做非常有助于应用的国际化。
5.3移动客户端与协同办公系统数据交互实现
移动客户端与协同办公系统的数据交互是通过本文设计的前置服务器来进行 数据交互的，Android客户端从前置服务器接收到XML数据流后，会调用SAX解 析器进行解析。在嵌入式环境中，尤其在Android平台中，用SAX方式进行XML 数据流的解析并不用将整个XML文档调入内存，从而减少了资源的使用，节省内 存，缓解操作系统运行的压力。
5.3.1XML解析器的创建
在Android平台中用SAX的方式进行XML数据流解析，先要构造处理对应 XML 数据流的 SAX 解析器，这要通过实现 ContentHandler 接口来实现， Android 应用程序开发的常用方法则是继承DefaultHandler类。构造XML解析器的步骤如 下：
首先，先建立两种实体类，分别对应XML文档以及文档的具体条目（后者需 为前者成员变量的类型），以便在解析XML的数据时，可以把解析出来的数据存 放到相应实体类中，这样之后使用数据时就可以直接对实体类操作了。
然后创建一个自己的解析器类，继承DefaultHandler类（DefaultHandler这个 类对 ContentHandler 类进行简单的实现）。本文所需要做的就是针对接收到的不 同类型的XML数据流，重写其中的几个重要方法以满足本文的业务需求。
5.3.2SAX方式的具体实现
SAX是Android系统官方推荐使用的XML文件解析方式，具体步骤如下：
1） 建立一个SAX的解析工厂类SAXParserFactory，代码如下： SAXParserFactory factory = SAXParserFactory.newInstance（ ） ；
2） 让新建立的工厂类Factory生成一个SAX解析类SAXParser实例，代码如 下：
SAXParser parser = factory.newSAXParser( );
3)在解析类Parser中得到一个XMLReader的实例，代码如下 XMLReader reader = parser. getXMLReader( )；
4)把自己写的handler解析器(上一节介绍的内容)注册到reader中，通常最 重要的就是 ContentHandler ,代码如下：
reader. setContentHandler( handler )；
5)把一个从前置服务器发送来的 XML 数据流转成 InputStream 流，正式开 始解析，代码如下：
parser.parse ( is );
以上实现的几个步骤中，最关键的就是第四步handler (解析器)的实现，该类 的具体实现在上一节中已做过详细介绍。
5.3.3 XML数据交互实现
Android移动客户端中的数据是来自于后端服务器，他们之间通过前置服务器 以XML数据格式来进行数据的交互。
1、 手机上的应用程序通过HTTP协议，将请求的URL发送到服务器端。实现代码 如下：
St ring pa th = “ ” ； //服务器的Act ion的访问路径
URL url = new URL(path)； //打开连接，得到连接对象
HttpURLConnection conn = (HttpURLConnection) url.openConnection ();
//设置读取的时间 conn.setReadTimeout (5*1000)； conn.setRequestMethod (“GET”)；
//从服务器输入流中读取数据
Inputstream inStream = conn.getlnputStream ()；
2、 服务器端就会调用对应Action来响应这个请求。因为WEB服务器默认的响应 信息是基于HTML格式的，就需要进行将信息构建为XML格式。这是联系人的XML 文件格式代码：
<%@ page language = “java” contentType二 “text/xml； charset二UTF- 8” pageEncoding = “UTF-8” %>
<%@ taglib uri = “http://java.sun.com/jsp/jstl/core” prefix = “c” %>
<?Xml version = “1.0” encoding= “UTF-8” ?> <EMP〉<c:forEach items= “$ {EMP}” var = “emp” >
<EMP id = “$ {EMP.id}” > <title>$ {EMP.id} </title>
<title〉$ {EMP.name} 〈/title〉
<title〉$ {EMP.dept} 〈/title〉
<title>$ {EMP.tel} 〈/title〉
</EMP〉</c:forEach〉
</EMP>
服务器端Action的响应代码：
Public ActionForward execute(ActionMapping mapping,ActionForm fo rm,HttpServletRequest request,HttpServletResponse response) throws Exception {
//从数据库获取客户端想查询的信息
代码省略
EMP Form formbean =(EMP Form) form；
request.setAttribute( “emps” , emps)；
return mapping.findForward( “emp” )；
}
3、 客户端从来自服务器的输入流中读取XML数据。
Inputstream inStream = conn.getlnputStream ()；
4、 考虑到手机客户端的硬件性能，使用SAX方式，边读取输入流边解析XML数据。
5、 将解析后的数据绑定到手机客户端Activity中，在UI中显示。
List<Video>videos = VideoService.getListEMP()；
List<HashMap<Sting, Object>>data = new ArrayList<HashMap<String, Object>>()；
For(EMP emp： emps) {
HashMap<String,Object>item = new HashMap<String,Object>()；
Item.put( “id” , emp.getid())；
Item.put( “name” , emp.getname())；
Item,put( “tel” , emp.getdept())；
Item,put (“tel” , emp.gettel())；
Data.add(item)；
}
SimpleAdapter adapter = new SimpleAdapter(this,data,R.layout.i tem,new String []{ “id” , “name” , “getdept” , “gettel” },new int []{R・id.name,R・id・gettel,R・id・getemail，R.id.getaddress})； ListView.setAdapter(adapter)；
5.4数据交互接口实现
根据数据交互接口的设计思路，为了方便起见，本文使用Web Service方式实 现了 Android移动平台和原有的数字化协同管理系统的数据交互接口。
下面详细介绍几个协同管理系统的常用数据交互接口：
1. get_contract_by_num:根据相应的编号获得协同管理系统中公文的基本信
息，支持批量操作，并可以根据fileds来限制返回的字段，减少不必要的通信。
表格 5-5 get_contract_by_num 接口
Request Direction 其他系统->Web Service
传输协议 http Get
格式 http://{web_server_ip}/web_service/get_contract_by_num?sessionId
={param}&contractNum={param}&fileds={param}
参数 sessionld:回话 ID
docNum :公文编号，可以多个编号
fields :请求字段
Response Direction Web Service-〉其他系统
传输协议 http+xml
返回数据 按照fields参数中要求的字段返回公文的基本信息
2.get_contract_by_status：根据公文的状态获取公文数据。如请求所有正在流 转中的公文的信息
表格 5-6 get_contract_by_status 接口
Request Direction 其他系统->Web Service
传输协议 http Get
格式 http://{web_server_ip}/web_service/get_contract_by_status?sessionId
={param}&contractStatus={param}&fields={param}
参数 sessionld:回话 ID docStatus：公文状态 fields :请求字段
Response Direction Web Service->其他系统
传输协议 http+xml
返回数据 按照fields参数中要求的字段返回要求状态的公文
3. get_contract_by_begin_end:按照指定的时间范围返回公文信息。该时间指 的是公文的流转时间字段。为避免请求的时间范围过长，公文数据量过大，默认
返回前10条，用户可设置count参数来改变默认值。
表格 5-7 get_contract_by_begin_end 接口
Request Direction 其他系统->Web Service
传输协议 http Get
格式 http://{web_server_ip}/web_service/get_contract_by_begin_end?
sessionId={param}&beginDate={param}&endDate={param}
参数 sessionId:回话 ID beginDate :起始日期 endDate :结束日期 fields :请求字段 count：数量，非必填
Response Direction Web Service->其他系统
传输协议 http+xml
返回数据 返回指定时间范围内的公文信息
4. set_contract_examine_info:系统可以根据此接口向协同办公管理系统传递 公文流转信息，同步公文流转信息。
表格 5-8 set_contract_examine_info 接口
Request Direction 其他系统->Web Service
传输协议 http Post
格式 http://{web_server_ip}/web_service/set_contract_examine_info?sessionId
={param}&contractNum={param}&examine_info={param}
参数 sessionId:回话 ID
docNum :公文编号
examine_info :公文的流转信息
Response Direction Web Service->其他系统
传输协议 http
返回数据 返回一个boolean型，是否更新成功
5.5 本章小结
本章介绍了各个功能模块的具体实现及其效果截图。主要包括移动办公系统
相关模块的实现、移动办公子系统的具体实现以及系统MVC架构的实现。
第六章 系统测试
本章是对开发完毕的系统进行功能测试的的过程，根据软件开发各阶段的规 格说明和程序的内部结构，精心设计一批测试用例（即输入数据及预期输出结果）， 并利用这些测试用例去运行程序，以发现程序可能出现的错误。
6.1 功能测试
软件测试对于一个软件来说是非常重要的，如何以最小的人力成本以及最少 的资源投入，在尽可能短的时间内完成软件测试工作，尽快发现软件系统的BUG, 保证软件优良的品质。。每个软件产品或软件开发项目都要有一套优秀的测试方 案和测试方法。而优秀的测试方案和测试方法可以在一定程度上保证开发出的软 件保持较高的质量，这是每个软件公司探索和追求的目标
设计测试用例的一个基本原则就是测试要尽量完全，而判断一个测试是否完 全的主要评判方法是基于需求的覆盖，通过下面我们设计的测试用例的测试，本 系统已基本完成测试目的。
1、测试点:公文的查询
表格 6-1 公务查询功能测试用例
测试步骤 步骤描述 预期结果
1 点击公文查询按钮 进入公文查询页面
2 不填数据，直接提交，检查是否对
必填字段进行了检查 报错，显示公文查询全部必填项，包括公
文类型、时间范围等，至少填一项
3 检查是否对Date数据进行了校验
（实型）
1、 输入正常的日期 2014-1-2
2、 输入不正确的日期格式 1、 能够正常输入
2、 报错，自动清除错误的日期格式
4 输入公文名称关键字，或整个公文
名称 返回所有名称中含有输入字符的公文信息
5 选择公文类别，并选择时间范围 进入公文查询结果页面，显示在该时间范
围内该类型的公文
2、测试点：待办公文事项
表格 6-2 待办公文测试用例
测试步骤 步骤描述 预期结果
1 登录系统 登录成功后，系统首页显示公文处理提醒、 处理进度提醒等
2 点击公务处理提醒 显示当前用户的待处理公文
3 点击公文进度提醒 显示进度逾期的公文的基本信息，包括该 公文的名称、编号以及负责人等等
4 点击未读消息 查看是否有人给自己发了新消息，点击未 读信息
5 查看待办公文是否包含全部，即是 否包含登录用户的待处理公文、未 读信息是否无遗漏 与当前登录用户的待办信息一致，无任何 遗漏项。
3、测试点：审批管理的新建审批流程功能
表格 6-3 新建公文处理流程功能测试用例
测试步骤 步骤描述 预期结果
1 点击公文处理流程 进入公文处理流程管理界面
2 选择新建公文处理流程 进入新建公文处理流程的输入录入界面
3 直接提交，验证必填字段 报错，显示所有必填字段，如名称、公文 类型
4 添加所有必填项，选择保存 保存成功，数据库中多了一条审批流程
5 进入一个新建立的公文，选择发起 处理 在公文处理流程的选择列表中可以看到刚 才添加的公文处理流程
4、测试点：审批管理的发起审批功能
表格 6-4 发起审批功能测试用例
测试步骤 步骤描述 预期结果
1 选择一个刚刚建立的公务，在公文 信息页面选择发起处理 公文进入待处理状态
2 使用该公文的处理人账户登录 在首页的处理提醒中多了一个公文，即新 发起处理的公文
3 点击新增加的公文 进入公文处理界面，显示公文处理流程进 行到哪一步，以及前后处理人
5、测试点：系统设置
表格 6-5 系统设置测试用例
测试步骤 步骤描述 预期结果
1 以系统管理员身份登录，计入系统 管理模块 登入系统管理界面
2 选择一个测试员工，点击“修改信 息” 进入员工信息修改界面，包括名称、密码、 权限等可修改信息
3 点击权限分配，测试权限分配 修改任意一个测试员工的权限
4 使用该员工账号登陆 该员工的权限发生了相应的改变
5 点击组织机构管理 进入组织机构管理界面，可以添加、修改 公司的组织结构
6 点击字典管理 进入字典管理页面，可以根据自己公司需 要自定义公文的类别、提醒类别等
6、测试点：移动客户端的登录
表格 6-7 Android 移动客户端登录功能测试用例
测试步骤 步骤描述 预期结果
1 在手机上点击客户端应用的图标 进入协同移动办公系统手机客户端的登录 界面
2 直接提交，检测是否为必填 系统报错，并提示“用户名以及密码为必 填字段”
3 检测是否限制了字段输入长度 在各输入框中，输入的内容达到所定义的 长度时，限制无法输入。（如果输入的为中 文字符，则控制到一半的长时就够了）
4 输入非允许的字符如'？ &等 系统自动删除输入的非法字符，并提示用 户正确输入
5 输入正确的用户名和密码 登陆成功，进入应用主界面，显示所有主 要的功能模块
8、测试点：移动客户端的公文文本下载功能
表格 6-8 公文文本下载测试用例
测试步骤 步骤描述 预期结果
1 点击“公务呢信息查询”图表 进入公务信息查询界面，等待输入公务名 称或编号
2 输入要下载的公文名称或编号 返回搜索结果，如果存在则可以下载
3 选择要下载的公务，并点击下载按 钮。 界面跳转到下载管理器，开始下载公文， 同时显示下载历史
4 下载到一半后断网，之后重新连 接，并启动未完成的下载任务，验 证断点传输功能 公文开始从上次下载的部分开始继续下 载，下载完成后经过验证正常。
9、测试点：移动客户端自动更新
表格 6-9 移动客户端自动更新测试用例
测试步骤 步骤描述 预期结果
1 在前置服务器上添加新的移动客 户端版本 登陆后提示“有新版本，是否进行更新？ ”
2 选择“否” 不进行更新，进入主界面
3 选择“是” 弹岀下载管理器，自动开始下载，下载完 成后自动询问是否安装
4 选择“是”，进行安装 成功安装，并自动重启
5 测试新版本添加的新功能 新功能正常使用
6.2 测试结果
系统功能测试严格按照本章 7.1 节所描述的测试用例来进行，所有测试内容均 在预测结果范围之内，基本上满足了系统的功能性需求，系统已经比较成熟。
6.3 本章小结
本章简要介绍了系统功能测试的测试用例，并阐述了测试结果。
第七章 总结与展望
基于 Android 平台数字化协同移动办公系统是企事业单位信息化建设的重要 组成部分，本文将数字化协同办公系统转换为一个可以与其他系统互动，并且覆 盖了办公系统整个生命周期的管理平台，同时为今后的系统功能扩展奠定了基础。
该系统的功能贯穿数字化协同办公系统的整个生命周期，数字化协同办公系 统的各个流程的所有的关键点都有相应的功能支撑。本数字化协同办公系统的移 动办公子系统成功上线，对移动办公提供了强有力的支持，方便外岀的企事业员 工随时随地访问协同办公系统，给予企事业单位的工作人员以及领导极大的便利， 提高了企事业单位的整体办公效率。
数字化协同办公系统作为企事业单位信息化建设和管理的重要内容，它的成 功应用，对公司其他相关业务活动环节均起到了重要的基础支撑作用，对后续业 务的顺利开展以及相关系统的建设和接口实现有较大影响，尤其是移动办公子系 统的成功上线，为今后开发支持公司全部管理信息系统的移动办公平台提供了坚 实的基础。
致谢
在这里，我首先要感谢我的导师杨元杰老师。我在论文的创作过程中碰到许 多的困难和障碍，我得到了杨老师不厌其烦地帮助我进行论文的修改、指导我的 论文，我会铭记在心。他朴实无华、平易近人的人格魅力给了我深远的影响，我 将终生难忘。
谢谢我的企业方导师储久良高级工程师对我的学业倾注了大量的心血! 感谢研究生三年以来所以给我授过课的老师，你们不但教给我专业知识，更 是终身受益的为人处事之道。
最后，我要对参与论文评审和答辩的各位老师表示衷心地感谢，谢谢他们对 我学习成果进行认真的评估，我将在今后的工作学习中加倍努力。
参考文献
[1] 中国互联网信息中心.中国互联网发展状况报告(2014 年 3 月) http://www.cnnic.net.cn/hlwfzyj/hlwxzbg/hlwtjbg/201403/P020140305346585959798.pdf
[2] 2012-2016 年中国办公协同软件市场调研与投资前景评估报告 http://www.ibaogao.com/baogao/0305V2022012.html
⑶温新.浅谈高校办公自动化系统的建设J].中国轻工教育2009年2期
[4]黄艺.浅谈办公自动化的实际应用J].中国电子商务.2010年.第5期.82-84.
[5]张元亮.Android开发应用实践详解[M].第一版.北京.中国铁道岀版社.2011.3-10
[6]李红.手机操作系统Android平台的研究及应用[D].南京:东南大学,2010
[7].E2ECloud 工作室.深入浅岀 Google Android[M] .北京:人民邮电岀版社,2009
[8]余志龙.Google Android SDK开发范例大全[M].第三版.北京人民邮电岀版社.2011.4-15
[9]冯学军.基于SSH框架的Web网站设计与实现[D].长春.长春理工大学.2010年.6-8.
[10]朱前飞，高芒.XML解析技术研究[J].电脑开发与应用,2004.11
[11]张超,王阿川，王智.基于J2ME和J2EE的手机软件的研究J].黑龙江科技信息,2007(3):21,1
87
[12]宋杰.Android OS手机平台的安全机制分析和应用研究[J].计算机技术与发展.2010年. 第 6 期.152-155.
[13]党李成.基于Google Android智能手机平台的研究与应用[D].合肥.安徽大学.2010年.7-9.
[14]李炜.Google Android开发入门指南[M].北京.人民邮电岀版社.2009.39-40.
[15]刘振波，方志刚，徐洁.改进的蚁群算法在智能导游系统路径优化中的应用[J].江南大学学 报,2008(05):561-563
[16]赵世彧，张盛，王玉辉，白岩.智能手机操作系统及其Google Android上的软件开发J].煤炭 技术, 2011,(04):197-199
[17]髙焕堂.UML嵌入式设计[M].北京.清华大学岀版社.2008.33-45.
[18]郭宏志.Android应用开发详解[M].北京.电子工业岀版社.2010.30-33.
[19]王向辉，张国印，沈洁.Android应用程序开发[M].北京.清华大学岀版社.2010.21-27.
[20]Michael Blaha, James Rumbaugh著.车皓阳译.UML面向对象建模与设计[M].北京.人民 邮电岀版社.2011.34-37.
[21]李晓.基于Android平台的手持终端应用功能开发与设计[D].湖北:湖北大学,2010,72-98
[22]公磊，周聪.基于Android的移动终端应用程序开发与研究[J].计算机与现代化,2008,(08):85
[23]杨文志.Google Android程序设计指南[M].北京.电子工业岀版社.2009.5-10.
[24]宛延闾著.实用Java程序设计教程[M].北京.机械工业岀版社.2006. 3-30.
[25]陈国君.Java2程序设计基础[M].北京.清华大学岀版社.2006.12-67.
[26]W Scott Means. The book of SAX: the simple API for XML [M]. San Francisco, Cali f: No Starch Press.2002.33-44.
[27]和凌志，郭世平.手机软件平台架构解析[M].北京.电子工业岀版社.2009.20-29.
[28]党李成.基于Google Android智能手机平台的研究与应用[D].合肥.安徽大学.2010 年.7-9.
[29]王路群.Java高级程序设计[M].北京.中国水利水电岀版社.2006.21-50.
[30]李瑞花.基Android的XML解析技术的分析[J].计算机时代.2010年.第12期.31-33.
[31]郭宏志.Android应用开发详解[M].北京.电子工业岀版社.2010.30-33.
[32]康雁.软件需求工程[M].第一版.北京.科技岀版社.2012.21-23.
[33]郑莉.Java语言程序设计[M].北京.清华大学岀版社.2006.20-100.Calif: NoStarch
Press.2002.33-44.
[34]杨华.XML的编程接口 [J].西部广播电视.2003年.第11期.44-47.
上一篇：供应链管理与经营性营运资金管理绩效: 影响机理与实证检验
相关标签:
