我的iOS成长之路-2-我的第一个iOS Demo

看到这篇博文,想起我的毕业设计了..

转自:http://beyondvincent.com/2014/01/06/2014-01-05-126-my-iOS-growth-path-2/

注1：本文是我在2011年9月花了两周时间做了我的第一个iOS Demo。这篇文章是我的iOS成长之路系列文章中的第二篇文章，第一篇文章请来这里看iOS成长之路-1-入门

下面先来看看本文的目录

1. 概述
2. 业务需求
3. 框架
4. UML图(用例图、类图和时序图)
5. 小结

通过2周时间的开发，我的第一个iOS程序基本做成。下面对此次开发进行一个总结。以便清楚的认识到开发中的一些不足之处，并积累下经验，为后续的开发提供参考依据。

概述

由于时间紧迫，在这里做了一个精简版的移动办公软件。主要功能有如下：

1. 登录
2. 查看公司发文待办
3. 查看文件单信息(包括意见信息)
4. 浏览正文
5. 浏览附件
6. 填写意见
7. 发送文件

下面将主要从此次开发涉及到的业务，结合使用到的框架、类图和时序图进行优势和缺陷总结。

业务需求

本次开发中涉及到的业务逻辑并不复杂，可以用下图进行表述：

我们可以把整个过程理解为：数据获取->数据展现->数据采集->数据反馈

根据以往开发经验，手机终端的移动办公业务逻辑基本上都可以从上图中的流程演变而来。针对这样的业务需求，下面进行适合这种业务的框架设计介绍。针对不同的开发平台，这种框架会有一些缺陷，同样也会在此进行描述，并希望能够找到相关好的解决方案。

框架

下图是此次MOA开发过程中的整体框架图。此图分为3个层面。最上面一层是UI显示层，在这一层主要是做UI方面的显示，是直接面向用户的。中间一层是DataAccess层，该层主要的职责是把所有的数据访问都封装起来。第三层封装了网络访问、文件操作、XML文件解析等。

下面将根据此次开发的情况，说一下该框架的优点和缺陷

优点：

1. 整体层次清晰，不复杂，无论是老手还是新手，都能够很容易的理解并在上面进行开发。
2. 实现了UI与数据的分离，降低了业务数据与UI界面的耦合度，无论是UI需求的变更，还是业务数据逻辑的变化，都减小了UI与数据之间的影响。
3. 模块的独立性，各个模块之间能够做到到低耦合、高内聚，这样不仅在此次开发中方便使用，在今后的相关开发项目中，也可以直接拿过来就使用，加强了软件的复用性原则。

缺陷：

1. 数据的凌乱性。在此次开发中，数据全部放在DataAccess里面，这样加深了UI界面与DataAccess层的耦合度，在一定程度上，不利于UI与数据分离。
2. 有时会导致级联修改。尤其是体现在至上而下的方向。如果在表示层需要增加一个功能，为保证其设计符合分层结构，可能在第二层，第三层都需要做相应的调整。
3. 第三层里面的封装性不强，特别是XML解析的封装。在针对面向对象开发，应该加强XML解析的抽象封装力度，否则编写的代码就是一次性的，不符合软件开发的复用性原则，同时也增加了代码的无用性，并不利于后期的变更维护。
4. 目前设计中存在一个严重的缺陷，现在只能同时并发一个网络异步请求。这在前期的设计中没有做详细的考虑，下一步需要对此进行改进，已达到支持多个异步请求操作。

一些思考：

1. 为了加强UI与数据之间的高度分离，有必要对DataAccess进行职责细化。在第二层里面增加一个模块：model[数据模型]，把DataAccess中的数据提取到model里面，DataAccess和UI涉及到的数据都存放在model模块中。这样更加利于DataAccess层的职责单一，以及数据与UI能够更好的进行交互。
2. 在第三层里面，涉及到的一些数据操作，需要加强抽象封装力度，尽量做到软件的复用性。此次开发中，特别是xml数据的解析，前期没有做好充分的考虑与设计，导致后期出现了单纯的copy and paste。非常不好。需要想办法改进。
3. 在iOS中，cocoa touch层已经为开发者提供了视图控制器功能，这在简单UI开发中已经非常够用并实用了。在此，有个预想，如果在遇到UI比较复杂的应用场景时，cocoa touch提供的视图控制器不能满足，可能需要在框架中增加视图管理模块。
4. UI方面积累：iOS在UI方面做得非常到位，做iOS开发，必须在UI方面做出特色，根据相关业务(移动办公)特点，真正使做出的产品是用户需要的、用户想要的。因此，在UI方面，必须要加强技术与经验的积累。

UML图(用例图、类图和时序图)

用例图

此次实现的功能，可以用下图进行描述。主要涉及到的业务是公司的发文。

在此版中，没有进行考虑，并且在今后的版本中需要进行考虑的功能如下：

1. 消息的及时推送功能。此功能非常的有必要去思考并实现。一条待办事项，极有可能是紧急待办处理的，这是就需要用户在第一时间得知消息，并及时的进行处理。并且，在消息的传递过程中，消息应该主动被用户所感知。
   所以一条新消息来了，不能依赖于用户主动的去服务器刷新数据进行检测新消息，应该提供一种机制，当服务器上有某个用户的新消息时，能够及时的传达给用户。
2. 用户使用环境的可配置型。随着用户的办公场景变化、所处网络变化，我们的移动办公系统，最理想的要求就是根据所述变化，智能的进行选择用户环境，最低要求是能够方便用户进行环境的可配置。
3. 日志。把用户的登录、操作信息记录并归档。
4. 意见反馈。通过意见反馈窗口，用户可以方便的把自己对使用软件上的一些想法、建议、问题反馈给我们，我们也能够及时的了解到用户的意见，并对用户意见进行考虑，对我们的软件进行更新升级。

在此版中已经存在的，但是在今后版本中需要加强考虑的功能：

1. 应用与用户交互体验方面(界面易操作、功能易理解、应用的鲁棒性等)

类图

下图展示了此次开发中的类图结构，为了图的层次清晰，图中绘制了主要的相关类，有些使用到的类在图中并没有绘制出来，但他们同样是此次开发中重要的一部分。此次涉及到的类图并不复杂，在此次总结中，不做类图的详细介绍。通过下图，很容易理解类图的结构。

时序图

下面涉及到的内容比较偏重与细节。基于以下原因，在这里只针对登录操作的时序图进行介绍。

1. 本次开发涉及到比较复杂的时序是网络的请求过程。
2. 登录请求的完整过程，与其他请求(待办请求、文件单信息请求等)基本相同。

当用户点击登录按钮进行登录操作时，会走如下流程(正常情况下，即网络通畅，用户名和密码正确)
首先LoginViewController通过DataAccess，调用XMLHandle的方法，组合出请求的数据内容(下图中的第3、4步骤)。

然后DataAccess调用ASIHTTPRequest方法(下图中第5、6步骤)，发起异步登录请求。

其次，当网络请求完毕，ASIHTTPRequest的delegate(第7步骤[DataAccess遵从])会被调用，DataAccess会调用XMLHandle的方法(第8步骤)进行数据解析。

最后DataAccess会调用DataAccess的delegate（第10步骤），通知LoginViewController，登录请求结果，LoginViewController根据请求的结果，如果登录成功，则进入待办列表画面(第11步骤)。