移动应用的生成方法和装置技术领域
本申请涉及移动应用开发技术领域，尤其涉及一种移动应用的生成方法和装置
背景技术
对于信息管理移动化的解决方案，目前大多数采用编码开发的方式，开发移动应
用(APP)的一个一个的页面。但是，移动应用的开发门槛高，开发周期长，对于一些碎片化的
信息管理投入较高。
发明内容
本申请旨在至少在一定程度上解决相关技术中的技术问题之一。
为此，本申请的一个目的在于提出一种移动应用的生成方法，该方法不需要对移
动应用进行一页一页的开发，而是通过模型自动生成移动应用，以降低移动应用生成所需
时间及降低成本。
本申请的另一个目的在于提出一种移动应用的生成装置。
为达到上述目的，本申请第一方面实施例提出的移动应用的生成方法，包括：接收
移动端发送的待生成的移动应用的标识；获取与所述标识对应的预先定义的应用模型；根
据所述应用模型，生成移动应用。
本申请第一方面实施例提出的移动应用的生成方法，通过根据预先定义的应用模
型生成移动应用，可以实现移动应用的自动生成，从而降低移动应用生成所需时间及降低
成本。
为达到上述目的，本申请第二方面实施例提出的移动应用的生成装置，包括：接收
模块，用于接收移动端发送的待生成的移动应用的标识；获取模块，用于获取与所述标识对
应的预先定义的应用模型；应用生成模块，用于根据所述应用模型，生成移动应用。
本申请第二方面实施例提出的移动应用的生成装置，通过根据预先定义的应用模
型生成移动应用，可以实现移动应用的自动生成，从而降低移动应用生成所需时间及降低
成本。
本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变
得明显，或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得
明显和容易理解，其中：
图1是本申请一个实施例提出的移动应用的生成方法的流程示意图；
图2是本申请另一个实施例提出的移动应用的生成方法的流程示意图；
图3是本申请实施例中实体及实体间关联关系的示意图；
图4是本申请实施例中定义应用模型的流程示意图；
图5是本申请实施例中一种展现模板的示意图；
图6是本申请实施例中另一种展现模板的示意图；
图7是本申请实施例中根据应用模型生成移动应用的流程示意图；
图8是本申请实施例中入口实体的展现示意图；
图9是本申请实施例中底部菜单的展现示意图；
图10是本申请一个实施例提出的移动应用的生成装置的结构示意图；
图11是本申请另一个实施例提出的移动应用的生成装置的结构示意图。
具体实施方式
下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终
相同或类似的标号表示相同或类似的模块或具有相同或类似功能的模块。下面通过参考附
图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。相反，本
申请的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同
物。
图1是本申请一个实施例提出的移动应用的生成方法的流程示意图。
如图1所示，本实施例的流程包括：
S11：接收移动端发送的待生成的移动应用的标识。
其中，移动应用可以由移动应用生成引擎生成，当需要在移动端生成移动应用时，
该移动端可以向移动应用生成引擎发送超文本传输协议(HyperText Transfer Protocol，
HTTP)请求，该请求中包含待生成的移动应用的标识，比如，用户在移动端选择待生成的移
动应用，而每个移动应用被预先分配唯一的标识，从而移动应用生成引擎可以接收到移动
端发送的待生成的移动应用的标识。
S12：获取与所述标识对应的预先定义的应用模型。
在移动应用生成引擎中，可以预先定义每个移动应用对应的应用模型，并建立移
动应用的标识与应用模型之间的对应关系，因此根据该对应关系可以获取与接收的标识对
应的应用模型。
S13：根据所述应用模型，生成移动应用。
其中，应用模型中可以定义移动应用正常展现所需的内容、展现形式等，从而根据
应用模型可以生成移动移动。具体的应用模型的定义以及根据应用模型生成移动应用的流
程可以参见后续实施例。
本实施例中，通过根据预先定义的应用模型生成移动应用，可以实现移动应用的
自动生成，从而降低移动应用生成所需时间及降低成本。
图2是本申请另一个实施例提出的移动应用的生成方法的流程示意图。
如图2所示，本实施例包括：
S21：定义实体及实体间关联关系。
实体是指具有相同属性的某类数据对象，例如：班级、学生、课程、教师等，同时实
体包含其自身属性的定义。以班级为例，该实体的属性例如包括：班级号、班级名、专业、人
数等。如图3所示，给出了一种实体及其属性，以及实体间关联关系的示意图。
该步骤属于全局设置，即多个移动应用均可以引用上述的实体及相互关系。
S22：对应每个移动应用，定义应用模型，以及建立移动应用标识与应用模型之间
的对应关系。
其中，在定义应用模型时，可以生成移动应用的唯一标识，从而可以建立移动应用
标识与应用模型之间的对应关系。另外，在定义应用模型时可以采用可视化工具实现。
如图4所示，定义应用模型的流程可以包括：
S41：定义移动应用的基本信息。
基本信息例如包括名称、图标等，另外，在定义基本信息时会对应每个移动应用生
成唯一的标识，以建立标识与应用模型的对应关系。
S42：定义移动应用的入口实体。
其中，入口实体是指在用户启动移动应用后，首页内容对应的实体，如首页展现学
生相关内容，则入口实体为学生。
S43：定义移动应用包括的实体的展现模板。
其中，实体的展现模板用于表明实体的展现形式，例如列表形式或栅格形式等，具
体如图5和图6所示，分别给出了两种展现模板。
S44：定义移动应用包括的实体的处理内容。
处理内容用于表明如何处理。
处理内容例如包括：当一个实体被选中后的处理内容，如显示底部菜单，以及，在
显示底部菜单时，处理内容还可以包括底部菜单中包括的具体内容，例如，具体内容包括查
看与被选中的实体相关联的其他实体(可以根据定义的关联关系确定)、查看统计信息、查
看搜索信息、对自身进行编辑等。
当底部菜单包括查看统计信息时，还可以进一步定义目标实体(即统计对象)及统
计维度，比如目标实体是学生，则需要对学生的相关信息进行统计，且上述的相关信息可以
由统计维度确定，比如，统计维度是男女生比例，则对学生的男女生比例进行统计。
类似的，当底部菜单包括查看搜索信息时，则可以定义目标实体及搜索维度，比如
目标实体是学生，搜索维度是性别，则表明按照性别对学生进行搜索。
通过上述的流程，可以定义生成移动应用对应的应用模型，之后在需要生成移动
应用时，可以根据应用模型生成。
S23：在需要生成移动应用时，移动应用生成引擎接收移动端发送的请求，该请求
中包含待生成的移动应用的标识。
S24：移动应用生成引擎根据已建立的移动应用标识与应用模型之间的对应关系，
获取与接收的移动应用标识对应的应用模型。
S25：移动应用生成引擎根据应用模型生成移动应用。
如图7所示，根据应用模型生成移动应用的流程包括：
S71：显示应用模型中定义的移动应用的基本信息。
比如，初始时显示移动应用的图标或名称等基本信息。
S72：在用户根据所述基本信息启动移动应用后，根据应用模型定义的入口实体和
展现模板，获取入口实体对应的实体数据和入口实体对应的展现模板。
比如，当用户点击移动应用的图标后，则可以启动移动应用。
应用模型中定义了入口实体，因此根据应用模型可以确定入口实体，以及，应用模
型中还定义了每种实体的展现模板，因此在确定入口实体后可以获取入口实体对应的展现
模板。另外，实体数据的初始值可以设置为默认值，之后可以由用户根据需要对实体进行实
例化，从而得到实体对应的实体数据。
其中，实体数据是指对实体进行实例化后的具体数据，比如入口实体是学生，学生
会有很多属性，如年龄、性别等，而实体数据是指这些属性的具体值，如年龄是10岁，性别是
男等。
S73：根据获取的实体数据和展现模板，渲染页面，所述页面内包括入口实体对应
的一个或多个实体数据模块。
其中，通过渲染，可以以定义的展现形式展现入口实体的具体内容。
例如，参见图8，以入口实体是学生为例，则可以在移动应用的首页按照定义的展
现形式展现具体学生的信息，比如包括学生A的实体数据，学生B的实体数据、学生C的实体
数据等。每个学生的实体数据例如包括：具体的名字(如张三)、年龄(如10岁)、性别(如男)
等。
S74：在用户选中一个实体数据模块后，根据应用模型定义的处理内容对选中的模
块进行处理。
比如，应用模型中定义了当实体被选中后显示底部菜单以及定义了底部菜单包括
的内容，则当用户选中一个模块后，可以显示如图9所示的底部菜单，该底部菜单中的内容
是可定义的，可以包括对选中的实体进行操作和/或对与选中的实体相关联的实体进行操
作。具体如：“查看统计信息”、“查看实体1”、“查看实体2”、“编辑”等。其中，当用户点击“查
看统计信息”后，可以根据应用模型中定义的目标实体和统计维度进行统计，得到统计信
息，在得到统计信息后可以显示在定义的位置上，如显示在页面顶部。“实体1”和“实体2”是
指与当前实体(如学生)相关联的其他实体，具体的可以根据全局定义的实体间的关联关系
确定，比如全局定义时学生关联老师和班级，则“查看实体1”和“查看实体2”可以具体为“查
看老师”和“查看班级”。底部菜单中的“编辑”是指对选中的模块进行编辑，比如增加、删除
或修改一些内容等。
本实施例中，通过定义，可以将移动应用进行模型化，从而在生成移动应用时直接
根据应用模型自动生成，不需要编写代码，从而降低移动应用生成所需的时间以及降低成
本，可快速提高业务信息移动化的处理速度。
图10是本申请一个实施例提出的移动应用的生成装置的结构示意图。
如图10所示，该装置100包括：接收模块101、获取模块102和生成模块103。
接收模块101，用于接收移动端发送的待生成的移动应用的标识；
获取模块102，用于获取与所述标识对应的预先定义的应用模型；
应用生成模块103，用于根据所述应用模型，生成移动应用。
一些实施例中，参见图11，该装置100还包括：
模型定义模块104，用于定义移动应用对应的应用模型；
标识生成模块105，用于生成移动应用标识；
关系建立模块106，用于建立移动应用标识与应用模型之间的对应关系。
一些实施例中，所述模型定义模块104具体用于：
定义移动应用的基本信息；
定义移动应用的入口实体；
定义移动应用包括的实体的展现模板；
定义移动应用包括的实体的处理内容。
一些实施例中，所述应用生成模块103具体用于：
显示应用模型中定义的移动应用的基本信息；
在用户根据所述基本信息启动移动应用后，根据应用模型定义的入口实体和展现
模板，获取入口实体对应的实体数据和入口实体对应的展现模板；
根据获取的实体数据和展现模板，渲染页面，所述页面内包括入口实体对应的一
个或多个实体数据模块；
在用户选中一个实体数据模块后，根据应用模型定义的处理内容对选中的模块进
行处理。
一些实施例中，所述处理内容包括：
显示底部菜单，所述底部菜单中的内容包括：对选中的实体进行操作和/或对与选
中的实体相关联的实体进行操作。
可以理解的是，本实施例的装置与上述方法实施例对应，具体内容可以参见方法
实施例的相关描述，在此不再详细说明。
本实施例中，通过根据预先定义的应用模型生成移动应用，可以实现移动应用的
自动生成，从而降低移动应用生成所需时间及降低成本。
可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中
未详细说明的内容可以参见其他实施例中相同或相似的内容。
需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不
能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义
是指至少两个。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括
一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部
分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺
序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请
的实施例所属技术领域的技术人员所理解。
应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述
实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件
或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下
列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路
的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场
可编程门阵列(FPGA)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步
骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介
质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以
是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模
块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如
果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机
可读取存储介质中。
上述提到的存储介质可以是只读存储器，磁盘或光盘等。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示
例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特
点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不
一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何
的一个或多个实施例或示例中以合适的方式结合。
尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例
性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述
实施例进行变化、修改、替换和变型。