CN108154569B

CN108154569B - 一种基于对象模型化配置的巡查采集方法

Info

Publication number: CN108154569B
Application number: CN201711443711.6A
Authority: CN
Inventors: 包世泰; 韦秋月; 韩勤; 彭进双; 李德文; 程林峰; 许慈銮; 梁泽峰
Original assignee: Augur Intelligence Technology Guangzhou Co ltd
Current assignee: Ogilvy Technology Co.,Ltd.
Priority date: 2017-12-27
Filing date: 2017-12-27
Publication date: 2021-02-12
Anticipated expiration: 2037-12-27
Also published as: CN108154569A

Abstract

本发明为一种基于对象模型化配置的巡查采集方法，包括以下步骤：根据巡查采集需求建立巡查对象模型，根据需求确定构成巡查对象的每个属性以及对应的控件类型；调整控件位置及数据属性，针对每个控件具体设置对应数据属性以满足表单界面元素加载时的数据初始化；解析构造移动应用的采集界面，服务端通过配置生成移动应用界面的配置JSON文件，移动应用在线获取或下载配置结果的JSON文件，通过动态界面构造引擎把JSON文件中的界面元素的布局与对应的数据字典、接口进行绑定，最终生成巡查采集移动应用产品。该方法可以大幅度提高开发效率，几乎“零编码”的配置提供高扩展能力的移动巡查采集应用。

Description

一种基于对象模型化配置的巡查采集方法

技术领域

本发明涉及移动应用生成技术领域，具体为一种基于对象模型化配置的巡查采集方法。

背景技术

移动互联网的高度发达和手持终端设备的普及让移动应用成为一种新的生产、生活方式。通过移动端APP，人们可以随时随地的查看数据，可以把原来通过纸质手写或电脑录入的方式转变为通过移动终端采集录入，信息化、智能化极大地方便了工作与生活。

虽然移动端数据采集都是表单录入，但是不同业务下表单属性多样，甚至会有个性化需求。在开发一款移动巡查采集应用APP时，除了服务端开发人员需要创建表单、提供表单增删改查，移动端人员还需要花费大量时间进行表单界面开发、数据初始化、提交接口开发和联调。

移动原生语言开发门槛高，开发周期长，当需要支持多操作系统时，投入人力成本更高。传统移动端采集可复用性差和维护强度大，移动应用对服务端过分依赖，既无法快速响应用户需求的变化，也无法通过简单配置就运用到同类项目场景中。支撑移动端采集的服务端程序一般作为大型应用程序的一部分，既不能独立部署运行，也不可以把移动端采集的数据共享给第三方服务。

在现有的同类技术中，有一部分技术实现方案与本发明相近，下面选取两个比较有代表性的技术方案进行分析。

同类技术1是一种持续集成的混生移动应用在线生成服务。前端应用层通过HTML、CSS、JavaScript所构成的工程实现混生移动应用主体开发，底层运行环境通过通信组件与后台支撑系统交互、通过下载器模块进行前端应用层压缩包或编码包的下载与更新、通过解释器进行解压或解码、通过运行时环境为前端应用层开放数据与功能接口以实现对设备功能的调用。同类技术1中存在一定局限：

1、前端应用层使用HTML、CSS、JavaScript所构成的工程开发的，虽然解决了不用频繁更新上架APP的问题以及多平台问题，但是客户需求一旦变化，前后端甚至APP端都有一定开发工作量，而且复用性不高。

2、前端应用层使用的HTML、CSS、JavaScript技术注定了开发出来的移动应用只能是简单数据展示或表单录入功能，性能和展示效果比不上原生APP，而且无法在无网络连接的时候完成特定分析功能。

同类技术2使用配置文件和接口实例完成移动端表单生成。主要原理是通过表单结构配置文件控制表单布局，控件配置文件控制控件属性，接口实例实现数据填充，APP运行时下载服务端的配置文件，根据约定的控件项标签生成表单，通过XML、JSON或哈希表数据初始化控件数据，流程图如图1。同类技术2中存在一定局限：

1、表单和控件配置文件只是XML文件，无可视化界面。因此表单的配置工作只能是技术人员进行操作，即使如此，技术人员也无法预览配置效果。出现这种问题的原因可能是该技术初衷定位就是给技术人员进行配置。

2、虽然是配置了表单，但是最终移动端数据提交，还需要服务端另外开发代码，出现这种问题的原因可能是该技术只解决表单生成工作。

由于没有解决数据提交问题，因而也无法解决数据与第三方服务端同步的问题。

3、只有简单的地图服务地址配置项，只能实现地图定位功能，地图点查、地图服务权限等更多高级功能无法配置。

4、移动端APP必须每次在线获取配置文件，无法在无网络连接的情况下操作。

发明内容

为了解决现有技术中巡查采集开发存在的问题，本发明提供一种基于对象模型化配置的巡查采集方法。该方法可以大幅度提高开发效率，几乎“零编码”的配置提供高扩展能力的移动巡查采集应用。

本发明采用如下技术方案来实现：一种基于对象模型化配置的巡查采集方法，包括以下步骤：

根据巡查采集需求建立巡查对象模型，根据需求确定构成巡查对象的每个属性以及对应的控件类型；

调整控件位置及数据属性，针对每个控件具体设置对应数据属性以满足表单界面元素加载时的数据初始化；

解析构造移动应用的采集界面，服务端通过配置生成移动应用界面的配置JSON文件，移动应用在线获取或下载配置结果的JSON文件，通过动态界面构造引擎把JSON文件中的界面元素的布局与对应的数据字典、接口进行绑定，最终生成巡查采集移动应用产品。

优选地，所述根据巡查采集需求建立巡查对象模型的步骤中，将通用字段库和行业地址采集字段库进行筛选组合，定制成符合业务需求的地址采集对象，构造成巡查对象的属性。

优选地，所述根据巡查采集需求建立巡查对象模型的步骤中，控件类型包括附件控件、文本控件、下拉控件和地图控件；每一类控件都对应一个默认的类型标识码，移动应用在解析构建采集界面时，通过标识码加载对应控件。

优选地，所述解析构造移动应用的采集界面的步骤中，动态界面构造引擎包括：

1)TableItem类：表单界面元素，循环配置文件中的每一项控件，调用该方法把控件添加到整个界面Container中，同时完成控件的数据设置；

2)TableNetService类：进行一系列的网络请求，网络请求包括解析配置文件、调用数据接口、提交数据；

3)TableDBService类：把数据保存到移动端数据库中；

4)TableDataManager类：为切换TableNetService和TableDBService的路由，是所有需要使用表单元素数据的类操作对象，负责处理何时从网络下载更新配置文件，何时从本地数据库读取配置文件；

5)TableViewManager类：界面构造类，通过使用TableDataManager提供的数据，逐项构造组装移动端界面的控件View。

优选地，所述解析构造移动应用的采集界面的步骤中，构造无须初始填充值的控件过程如下：

首先从服务端解析配置文件，并把配置文件里面的所有表单界面元素TableItem进行排序；循环遍历已排好序的TableItem,其中一个control_type显示为无须初始填充值的控件；新增一个与控件相应的组件容器ViewGroup；最后把包含组件容器添加到应用界面所在的Container中；

所述无须初始填充值的控件包括文本框、文本域、日期选择器、图片选择或本地模糊查询；

构造需要进行初始赋值的控件过程，首先根据控件类型构造对应的UI组件，然后赋予初始值。

优选地，所述巡查采集方法还包括步骤：提交移动应用采集的数据，服务端与移动端约定数据提交的接口相对地址，接口提交的表单数据构造成一个由表单字段和对应录入值构成的对象；服务端接收所述对象并存入数据库或根据映射关系提交到第三方行业系统。

优选地，所述巡查采集方法还包括步骤：配置移动端的功能页面，将功能页面元素分解为标签项；根据待生成功能页面的内容需要将标签进行拼装组合，形成功能页面动态模版；根据待生成功能页面的功能类型建立标签属性与功能执行逻辑的关联关系；移动端根据功能页面动态模版和关联关系完成功能页面的加载和功能实现；需要修改功能页面时，通过对功能页面进行配置修改。

优选地，所述配置移动端的功能页面，具体步骤如下：

将功能页面元素分解为多个标签项，有层级关系的继续细分子标签项、孙子标签项；一个标签包括显示名称、控件类型和填充值；

根据功能页面拖拽组合标签项，形成功能页面动态模版，并选取待生成的功能页面的功能类型；

移动端根据功能类型建立标签属性和功能执行逻辑的关联关系；

移动端获取动态模版，形成最终的功能页面。

优选地，所述巡查采集方法还包括步骤：与行业表进行字段映射，把巡查对象的字段与第三方行业系统的表字段进行映射，从而将移动端提交的采集数据同步到第三方行业系统中。

优选地，所述与行业表进行字段映射的步骤中，通过数据库连接把第三方行业系统的数据库表和字段读取出来，然后把所构成的巡查对象的字段与第三方行业的表字段进行一一匹配；在经过表字段匹配之后，在移动端提交采集数据的接口中，根据字段匹配的情况，把字段和值一并构建行第三方业系统需要的实体JSON，最后调用第三方行业系统原有的数据接口把采集数据插入到第三方行业系统数据库中。

与现有技术相比，本发明具有如下优点和有益效果：

1、解决了传统巡查采集应用开发要进行表、实体创建的问题，同时省去了服务端和移动端两个部分的开发工作量。即使不懂技术的普通用户也可以通过简单可视化的界面去配置巡查采集应用，不管多少个表单、表单字段发生如何的变化，移动应用的APP都不需要重新开发、发布。

2、与本发明相近的技术只解决了表单生成、控件初始化和数据获取等问题，本发明还解决了移动应用采集数据提交的问题，同时使得多平台运行和离线采集成为可能。

3、本发明支持独立部署运行，也可以将数据共享给第三方服务端，实现移动巡查采集与行业系统对接，动态生成的APP通过配置好的接口直接对接行业系统进行巡查任务流转。

4、本发明中巡查对象的候选字段库中既有通用字段也有行业模版字段，供用户快速创建巡查对象，完成表单设计。

5、除了巡查采集表单的设计，本发明还可以配置地图资源，使得巡查对象可以采集空间位置，并且在APP中可以加载查看各类地图。

6、本发明通过将功能页面元素分解为标签，可以为不同功能所用，提高了页面功能项的重用性；功能页面标签项的配置是通过可视化界面拖拽而成，实现了功能页面的动态生成，即使没有开发经验的用户也可以自由定制使用。既减少了开发工作量，保证程序代码稳定重用，又使得用户可以享受智能定制移动端功能页面的体验。

附图说明

图1是同类技术2的流程图；

图2为巡查抽象对象模型的创建示意图；

图3是通用字段库的示意图；

图4是国土行业中地址采集字段库的示意图；

图5是通用字段库和地址采集字段库的字段组合结果示意图；

图6是匹配行业字段的示意图；

图7是本发明中巡查采集移动应用配置流程示意图；

图8是本发明中移动应用解析构造界面的过程示意图；

图9是服务端意见模版可视界面图；

图10为功能页面分解示意图；

图11为标签项组合结果示意图。

具体实施方式

下面通过实施例，并结合附图，对本发明的技术方案做进一步具体的说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

实施例

本实施例针对市政设施养护、资源调查采集等行业应用场景，提出一种基于采集对象模型化配置的巡查采集方法，将市政设施、执法对象、调查对象抽象为巡查事件/实体(属性、附件、时间、空间位置)，用户不需要任何编程技术，根据需求通过可视化的几步简单操作完成表单、地图资源、接口服务的定制，移动端通过获取配置结果JSON数据动态生成巡查采集APP，同时支持与行业服务端进行数据同步。移动端动态生成的APP分为两种，一种是原生Android应用，一种是HTML5应用。前者解决离线采集，后者支持多平台使用。两者均使用动态界面构造引擎，通过约定接口完成动态界面构造和数据提交。

在本实施例中，基于对象模型化配置的巡查采集方法，包括以下步骤：

S1、根据巡查采集需求建立巡查对象模型。

如图2，将市政设施、执法对象、调查对象抽象为巡查事件/实体，巡查事件/实体包括空间位置、属性和时间三个要素。其中，空间位置为xy坐标或某个设施对象位置/地址引用；而不同行业的属性差别大，因而通过属性来自定义数据标准，实现跨行业应用。

从最终生成的移动应用界面的角度看，巡查对象由控件组成；从服务端存储的角度看，巡查对象由字段组成。所以在创建巡查对象的这一步，主要是根据需求确定构成巡查对象的每个属性以及对应的控件类型。控件类型包括附件控件、文本控件、下拉控件、地图控件等。每一类控件都对应一个默认的类型标识码，移动应用在解析构建界面时，通过标识码加载对应控件。

为简化用户的操作，本发明方法把通用表单字段和市政、水务、国土、规划各行业的行业扩展字段制作成一个字段候选库，用户只需要在字段候选库中选取字段，即可快速构建巡查对象。图3是通用表单字段库，即不论什么行业，采集表单中几乎都会包含和使用的通用性字段。

在具体行业应用中，仅使用通用字段并不能完全描述巡查对象，往往会有行业特有的属性，下面以国土行业中地址采集类业务为例进行说明。在地址采集中往往把位置信息按村、街道、门牌拆分，使室外采集人员使用APP可以快速定位到某栋建筑物，照片需要近景、全景两种。如图4所示，就是具备强烈行业特色的字段。

因此，当用户需要一个可以完成地址采集的APP时，可以将通用字段库和行业地址采集字段库进行合理的筛选组合，最终定制成符合具体业务需求的地址采集对象，见图5，构造成巡查对象的属性。通用字段库和行业地址采集字段库是经过很多项目的积累和总结的，几乎能囊括上文提到四大行业的需求，如果具体巡查采集需求中仍存在通用和行业字段库中所未提及的属性，用户可以额外添加其它字段。

由于每个巡查对象都是动态生成的，所以在存储移动应用提交的数据时与传统的一个巡查实体对应一张数据库表不一样，采用的是字段key和value的方式实现表单提交。

S2、调整控件位置及数据属性。

用户可以通过可视化的拖拽方式调整控件的显示位置，在这里只需控制控件之间的排列顺序。同时针对每个控件，具体设置对应数据属性以满足表单界面元素加载时的数据初始化；例如附件控件的显示名称为“添加照片”，下拉控件填充的数据字典，文本控件进行模糊查询调用接口url，地图控件加载的地图服务地址等。数据字典以编码号与控件关联，支持无限级联、多级联动；地图服务支持多种类型。

S3、与行业表进行字段映射。

这一步为可选步骤。把配置好的巡查对象的字段与第三方行业系统的表字段进行映射，就可以把移动设备提交的采集数据同步到第三方行业系统中。

如图6所示，通过数据库连接把第三方行业系统的数据库表和字段读取出来，然后把步骤S1构造的巡查对象的字段(左侧)与第三方行业的表字段(右侧)进行一一匹配，图6中字段中文为表字段的备注。

在经过表字段匹配之后，在移动设备提交采集数据的接口中，根据字段匹配的情况，把字段和值一并构建行业系统需要的实体JSON(即按行业系统表结构组装)，最后调用行业系统原有的数据接口把采集数据插入到行业系统数据库中(也包括附件文件流的传送)。行业系统就可以对接采集数据做后续业务的处理、流程流转等。这样一来，行业系统就不需要专门为移动端APP写后台接口代码。

S4、解析构造移动应用的采集界面。

如图7、8所示，服务端通过配置生成移动应用界面的配置JSON文件，移动应用从rest接口在线获取或下载配置结果的JSON文件，通过动态界面构造引擎把JSON文件中的界面元素的布局与对应的数据字典、接口进行绑定，最终生成巡查采集移动应用产品。

动态界面构造引擎包括以下几个部分：

1)TableItem类：表单界面元素，即addTableItemView，循环配置文件中的每一项控件，调用该方法把控件添加到整个界面Container中，同时完成控件的数据设置。控件类型是构造界面元素的重要条件，每一种控件都有默认构造的方法。目前已支持的控件有：文本框、文本域、日期选择器、图片选择、本地模糊查询、下拉框、复选框、地图、webview地图、在线模糊查询、意见模版及自定义等。文件中字段构成如下表格1：

表格1

字段	说明
		html_name	显示在前端控件前的名称
control_type	控件类型
		dic_code	数据字典编码
children_code	级联的下一表单项
		if_required	是否必填项
if_hidden	是否隐藏
		display_order	控件顺序，值越小越在前

2)TableNetService类：进行一系列的网络请求，包括解析配置文件、调用数据接口、提交数据等。

3)TableDBService类：把配置文件、数据字典等数据保存到移动端数据库中，为离线操作巡查采集APP做数据支撑。

4)TableDataManager类：作为切换TableNetService和TableDBService的路由，是所有需要使用表单元素数据的类操作对象，负责处理什么时候该从网络下载更新配置文件，什么时候从本地数据库读取配置文件。

下面重点介绍一下界面构造过程。

由于表单界面可以分为首次编辑和阅读(或再次编辑)两种状态，TableViewManager类提供了两种状态的构造函数，阅读(或再次编辑)这种状态相比首次编辑状态需要多传入表单数据进行表单初始化。

在移动端构造界面时主要分为两步：

1)从服务端获取配置文件；

2)按照配置文件设定的控件顺序，逐一根据配置文件中通用属性将控件添加到应用界面中。

下面以移动应用界面的文本框控件的生成进行说明：首先从服务端解析配置文件，并把配置文件里面的所有表单界面元素TableItem进行排序。循环遍历已排好序的TableItem,其中一个control_type显示为文本框。新增一个包含输入框EditText的组件容器ViewGroup(HTML5应用中为包含输入框text的组件容器DIV)。左侧使用一个TextView显示该界面元素的名称，TableViewManager根据配置文件中更多的构造属性控制文本框的最多输入字数、是否在界面中隐藏以及提交时是否验证必填等。最后把包含这个文本框控件的组件容器ViewGroup(DIV)添加到应用界面所在的Container中，从而完成文本框的整个构造过程。

其它控件，如文本域、日期选择器、图片选择、本地模糊查询等无须初始填充值的控件构造过程与上述文本框类似，根据不同的control_type在移动应用或HTML5应用中构建对应的UI组件。这类控件的配置关系对应表如表格2所示。

表格2配置文件‐控件(无初始赋值)对应关系表

对于像下拉框、地图定位选点等与初始赋值密切相关的控件，除了TableViewManager根据控件类型构造对应UI组件，还需要TableDataManager赋予初始值，才能完成每个控件的构造过程。

1)下拉框/复选框

对应TableItem的control_type显示为下拉框/复选框，新增一个包含下拉框Spinner/复选框Checkbox的组件容器ViewGroup(HTML5应用中为包含下拉框select/复选框Checkbox的组件容器DIV)。TableDataManager根据dic_code数据字典码从本地数据库中查询出填充列表数据，并把列表数据给到下拉框Spinner的适配器/复选框Checkbox，设置默认选中值。

2)地图

地图控件在移动应用中定义为MapView(HTML5应用中控件同名)。MapView是自定义UI控件，具备地图服务加载、定位、点查等基本地图功能。TableDataManager把服务端授权的地图服务(url)列表、地图初始参数(地图初始中心点、初始比例尺)给到地图控件MapView，MapView逐一按顺序进行添加服务并准备好缩放和移动的初始位置。地图控件构造的重要属性如表格3所示。

表格3地图控件构造重要属性

属性	说明
		MAP_URL	地图服务访问地址
MAP_TYPE	地图服务类型，如WMTS、WMS
		MAP_EXTENT	地图可视范围
MAP_center	地图初始中心点

3)webview地图

webview地图控件只是针对Android应用，具体地图的加载由HTML5应用的包含地图控件的页面完成。TableDataManager把服务端中包含MapView的HTML的访问地址给到WebView。最后把包含WebView的组件容器ViewGroup(DIV)添加到应用界面所在的Container中，Android设备就可以进行地图服务加载、缩放和移动。

4)在线模糊查询

在线模糊查询控件AutoCompleteNet是文本框控件的升级，TableDataManager把服务端配置文件中在线模糊匹配的访问接口地址给到AutoCompleteNet，AutoCompleteNet把文本框输入的文字作为请求参数，通过网络请求匹配的接口url执行模糊查询，最后查询结果填充到文本框中。

5)意见模版

意见模版控件OpinionTemplateEditView是文本域控件的升级，界面上除了EditText/textarea控件，同时组合了一个查询模版的button。TableDataManager把配置的文本模版查询接口地址给到OpinionTemplateEditView，查询模版的button点击事件绑定了从查询接口地址获取文本的动作。模版返回的文本带有控件名称作为标签，可以快速把界面中的其他控件的值进行自由组合。比如：“【上报时间】，在【所在路段】发现【问题类型】，上报人【username】”，中括号【】里的是html_name(控件名称)，这些被命中html_name的控件的填充值都会替换掉中括号里的内容，为用户快速在移动设备编辑大段文字提供便捷。用户可以通过服务端可视界面维护更多模版，如图9所示。

6)自定义

其中自定义控件类型是指现有的控件项的功能不能满足用户需求时，开发者可以自行实现CustomTableListener的addCustomTableItems方法，自己去完成自定义控件的界面加载和数据设置。具体加载过程与其它控件相同，在此不再重复叙述。

S5、提交移动应用采集的数据。

服务端与移动端约定了数据提交的rest接口相对地址(服务器IP地址由APP登录时用户指定)，接口提交的表单数据构造成一个由name和value组成的FormBody，即表单字段和对应录入值构成的对象。服务端接收FormBody并存入数据库或根据映射关系提交到第三方行业系统。

S6、配置移动端的功能页面。

将功能页面元素分解为标签项；根据待生成功能页面的内容需要将标签进行拼装组合，形成功能页面动态模版；根据待生成功能页面的功能类型建立标签属性与功能执行逻辑的关联关系；移动端根据功能页面动态模版和关联关系完成功能页面的加载和功能实现；需要修改功能页面时，对功能页面进行配置修改即可。

移动端的功能页面配置，具体步骤如下：

步骤S61：将功能页面元素分解为多个标签项，有层级关系的可以继续细分子标签项、孙子标签项；一个标签包括显示名称、控件类型和填充值。如图10所示，查询图层(单选)为标签项，建设项目布局图层为子标签项，查询字段为显示名称，查询/清除为功能执行控件类型，项目名称可填写或下拉选择相应的填充值。

一个功能页面为包括功能名称、功能编码、功能图标、标签项所构成的动态模版。功能名称显示在移动端APP标题栏，功能编码用于唯一标识功能页面，功能图标作为功能页面的入口。

步骤S62：根据功能页面拖拽组合标签项，形成功能页面动态模版，并选取待生成的功能页面的功能类型；组合结果如图11所示；

功能类型相当于本发明中可支持动态配置的功能种类，如表格4所示，可分为功能大类和功能小类；服务端根据支持的功能类型构建标签项候选库，即预先提供候选的功能页面标签项，用户只需组合标签项和修改标签项的填充值就可以完成功能页面的配置。

表格4功能类型

步骤S63：移动端根据功能类型建立标签属性和功能执行逻辑的关联关系；

移动端针对功能类型的标签项候选库建立逻辑关联关系，比如“单个图层查询”这种功能类型，识别出的作用表/图层、查询条件、查询范围这几个标签的填充值就会用于构造最终“查询”这个按钮的点击时所需要的一系列参数。

步骤S64：移动端获取动态模版，形成最终的功能页面；

移动应用从rest接口读取或下载功能页面配置结果的JSON文件，通过动态界面构造引擎把JSON文件中的标签项与对应的数据字典、接口进行绑定，最终形成功能页面。

需要修改功能页面时，对功能页面进行配置修改即可。这样一来，本发明可以使类似的功能在不同的项目中重复使用，也可以在同一项目中通过配置快速构建移动APP功能页面，功能页面元素得到不断复用。过程中几乎没有技术人员参与代码开发，既减少了开发工作量、保证程序稳定性，又让用户参与了定制功能的过程。

如上所述，便可较好地实现本发明。上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims

1.一种基于对象模型化配置的巡查采集方法，其特征在于，所述巡查采集方法将市政设施、执法对象、调查对象抽象为巡查事件/实体，移动端通过获取配置结果JSON数据动态生成巡查采集APP，完成表单、地图资源、接口服务的定制；移动端动态生成的巡查采集APP包括用于解决离线采集的原生Android应用、用于支持多平台使用的HTML5应用，两者均使用动态界面构造引擎，通过约定接口完成动态界面构造和数据提交；包括以下步骤：

解析构造移动应用的采集界面，服务端通过配置生成移动应用界面的配置JSON文件，移动应用在线获取或下载配置结果的JSON文件，通过动态界面构造引擎把JSON文件中的界面元素的布局与对应的数据字典、接口进行绑定，最终生成巡查采集移动应用产品；

提交移动应用采集的数据，服务端与移动端约定数据提交的接口相对地址，接口提交的表单数据构造成一个由表单字段和对应录入值构成的对象；服务端接收所述对象并存入数据库或根据映射关系提交到第三方行业系统；

配置移动端的功能页面，将功能页面元素分解为标签项；根据待生成功能页面的内容需要将标签进行拼装组合，形成功能页面动态模版；根据待生成功能页面的功能类型建立标签属性与功能执行逻辑的关联关系；移动端根据功能页面动态模版和关联关系完成功能页面的加载和功能实现；需要修改功能页面时，通过对功能页面进行配置修改；所述配置移动端的功能页面，具体步骤如下：

根据功能页面拖拽组合标签项，形成功能页面动态模版，并选取待生成的功能页面的功能类型；移动端根据功能类型建立标签属性和功能执行逻辑的关联关系；

移动端获取动态模版，形成最终的功能页面；

所述解析构造移动应用的采集界面的步骤中，动态界面构造引擎包括：

1）TableItem类：表单界面元素，循环配置文件中的每一项控件，调用该方法把控件添加到整个界面Container中，同时完成控件的数据设置；

2）TableNetService类：进行一系列的网络请求，网络请求包括解析配置文件、调用数据接口、提交数据；

3）TableDBService类：把数据保存到移动端数据库中；

4）TableDataManager类：为切换TableNetService和TableDBService的路由，是所有需要使用表单元素数据的类操作对象，负责处理何时从网络下载更新配置文件，何时从本地数据库读取配置文件；

5）TableViewManager类：界面构造类，通过使用TableDataManager提供的数据，逐项构造组装移动端界面的控件View；

其中，对于无须初始填充值的控件，TableViewManager在移动端构造界面的过程包括：

1）从服务端获取配置文件：把配置文件里面的所有表单界面元素TableItem进行排序；

2）按照配置文件设定的控件顺序，逐一根据配置文件中通用属性将控件添加到应用界面中：循环遍历已排好序的TableItem，根据不同的控件类型构建对应的UI组件；新增一个包含输入框的组件容器，使用一个TextView显示该界面元素的名称，TableViewManager根据配置文件中更多的构造属性控制控件的最多输入字数、是否在界面中隐藏以及提交时是否验证必填；最后把包含该控件的组件容器添加到应用界面所在的容器中；

对于与初始赋值相关的控件，除了TableViewManager根据控件类型构造对应UI组件，还需要TableDataManager赋予初始值；与初始赋值相关的控件包括下拉框/复选框、地图控件、webview地图控件、在线模糊查询控件及意见模版控件。

2.根据权利要求1所述的基于对象模型化配置的巡查采集方法，其特征在于，所述根据巡查采集需求建立巡查对象模型的步骤中，将通用字段库和行业地址采集字段库进行筛选组合，定制成符合业务需求的地址采集对象，构造成巡查对象的属性。

3.根据权利要求1所述的基于对象模型化配置的巡查采集方法，其特征在于，所述根据巡查采集需求建立巡查对象模型的步骤中，控件类型包括附件控件、文本控件、下拉控件和地图控件；每一类控件都对应一个默认的类型标识码，移动应用在解析构建采集界面时，通过标识码加载对应控件。

4.根据权利要求1所述的基于对象模型化配置的巡查采集方法，其特征在于，所述解析构造移动应用的采集界面的步骤中，构造无须初始填充值的控件过程如下：

5.根据权利要求1所述的基于对象模型化配置的巡查采集方法，其特征在于，所述巡查采集方法还包括步骤：

与行业表进行字段映射，把巡查对象的字段与第三方行业系统的表字段进行映射，从而将移动端提交的采集数据同步到第三方行业系统中。

6.根据权利要求5所述的基于对象模型化配置的巡查采集方法，其特征在于，所述与行业表进行字段映射的步骤中，通过数据库连接把第三方行业系统的数据库表和字段读取出来，然后把所构成的巡查对象的字段与第三方行业的表字段进行一一匹配；在经过表字段匹配之后，在移动端提交采集数据的接口中，根据字段匹配的情况，把字段和值一并构建第三方行业系统需要的实体JSON，最后调用第三方行业系统原有的数据接口把采集数据插入到第三方行业系统数据库中。