发明内容
本发明的目的是提供一种车载应用商城系统及其实现方法,解决现有技术的车机设备应用程序没有没有平台化管理、兼容性可移植性差的问题。
为了实现上述目的,本发明提供了一种车载应用商城系统实现方法,所述车载应用商城系统包括车机端和平台端,包括以下步骤:
S101所述车机端,根据接收到的应用商城打开指令打开应用商城;
S102所述车机端,获取平台端发布的应用列表和应用信息;
S103所述车机端,显示获取的应用列表和应用信息。
在一实施例中,所述方法,进一步包括以下步骤:
S104所述车机端,判断应用列表中各应用的安装状态,并区分显示。
在一实施例中,所述步骤S104之后还包括以下步骤:
S105车机端,比较平台端的应用软件版本号与本地的应用软件版本号;
S106如果平台端的应用软件版本号大于本地的应用软件版本号,则车机端提示更新软件,并根据输入指令更新软件;
S107如果平台端的应用软件版本号不大于本地的应用软件版本号,则车机端无需更新软件。
在一实施例中,所述平台端,管理应用商城的可用应用,当新增应用时,进一步包括以下步骤:
S211平台端,填写新增的应用信息并上传应用软件包;
S212平台端,更新应用库;
S213平台端,发布更新后的应用列表和应用信息。
在一实施例中,所述平台端,管理应用商城的应用软件,当修改应用信息时,进一步包括以下步骤:
S221平台端,修改应用软件对应的应用信息;
S222平台端,判断是否上传应用软件包;
如果有上传应用软件包,则更新平台端对应的应用软件版本号,并更新应用库;
如果没有上传应用软件包,则直接更新应用库;
S223发布更新后的应用列表和应用信息。
在一实施例中,所述方法,还包括以下步骤:
S311所述车机端,向平台端发布互动信息;
S312所述车机端,接收平台端发送的互动信息统计结果,并按照应用分类分别显示互动信息。
在一实施例中,所述方法,还包括以下步骤:
S321所述平台端,接收车机端发送的互动信息并按互动信息的标题匹配对应的应用软件;
S322所述平台端,判断是否修改互动信息的标题;
如果是,则更新互动信息的标题,合并对应应用软件的互动信息并进入审核;
如果否,则直接进入审核;
S323如果审核不通过,则不做进一步的动作;
S324如果审核通过,则更新并发布互动信息统计结果。
为了实现上述目的,本发明提供了一种车载应用商城系统,包括车机端和平台端:
所述车机端,根据接收到的应用商城打开指令打开应用商城,获取平台端发布的应用列表和应用信息,判断应用列表中各应用的安装状态,并区分显示获取的应用列表和应用信息;
所述平台端,根据应用库发布应用列表和应用信息至车机端。
在一实施例中,所述平台端,管理应用商城的可用应用,填写新增的应用信息并上传应用软件包,更新应用库;
所述平台端,修改应用软件对应的应用信息,如果有上传应用软件包,则更新平台端的应用软件版本号并更新应用库,如果没有上传应用软件包,则直接更新应用库。
在一实施例中,所述车机端,向平台端发布互动信息,接收平台端发送的互动信息统计结果,并按照应用分类分别显示互动信息;
所述平台端,接收车机端发送的互动信息并按互动信息的标题匹配对应的应用;判断是否修改互动信息的标题;如果是,则更新互动信息的标题,合并对应应用的互动信息并进入审核;如果否,则直接进入审核;如果审核不通过,则不做进一步的动作;如果审核通过,则更新并发布互动信息统计结果。
本发明提供的一种车载应用商城系统及其实现方法,通过平台化管理应用商城中的应用,扩展生态服务,降低商务合作成本,降低车机资源占用,且强化用户互动,基于统一底层能力的快应用架构,节省车机端的资源消耗。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释发明,并不用于限定发明。
本发明提供的一种车载应用商城系统及其实现方法,通过一个应用分发平台,整合可在车机中使用的应用软件,使用分布式UI(User Interface,用户界面)策略,同一个应用安装包在不同尺寸比例的车机中可自适应显示最合适的布局样式,使这些应用在多个车机中可正常显示与操作,并且通过类似小程序的快应用架构解决车机端硬件资源的占用问题,同时通过评论、请愿等实现互动社交功能。
图1揭示了根据本发明一实施例的车载应用商城系统实现方法流程图,如图1所示的车载应用商城系统实现方法,车载应用商城系统包括车机端100和平台端200,包括以下步骤:
S101所述车机端100,根据接收到的应用商城打开指令打开应用商城;
S102所述车机端100,获取平台端200发布的应用列表和应用信息;
S103所述车机端100,显示获取的应用列表和应用信息。
更进一步的,所述方法还包括以下步骤:
S104所述车机端,判断应用列表中各应用的安装状态,并区分显示。
S105车机端,比较平台端的应用软件版本号与本地的应用软件版本号。
S106如果平台端的应用软件版本号大于本地的应用软件版本号,则车机端提示更新软件,并根据输入指令更新软件;
S107如果平台端的应用软件版本号不大于本地的应用软件版本号,则车机端无需更新软件。
本发明提出的车载应用商城系统,通过平台端200的管理后台管理应用商城中的可用应用,并通过车机端100进行下载安装和使用。
车机端100,与平台端200通过无线通讯方式进行数据通信传输。
平台端200,可以是服务器或者云平台。
如图1所示,所述平台端200,管理应用商城的应用软件,当新增应用时,进一步包括以下步骤:
S211平台端200,填写新增的应用信息并上传应用软件包;
S212平台端200,更新应用库;
S213平台端200,发布更新后的应用列表和应用信息。
如图1所示,所述平台端200,管理应用商城的应用软件,当修改应用信息时,进一步包括以下步骤:
S221平台端200,修改应用软件对应的应用信息;
S222平台端200,判断是否上传应用软件包;
如果有上传应用软件包,则更新平台端200对应的应用软件版本号,并更新应用库;
如果没有上传应用软件包,则直接更新应用库;
S223发布更新后的应用列表和应用信息。
更进一步的,本发明提出的车载应用商城系统,平台端200采用快应用框架管理应用商城的应用软件。
快应用是基于移动终端硬件平台的新型应用形态,无需安装可直接点击运行,通常需要在快应用平台上运行。
平台端200,使用快应用方案,基于一套具有通用底层能力的框架开发出类似小程序的应用软件,并上传到应用商城,车机端100仅需加载一个很小的文件即可使用应用。
快应用使用前端技术栈开发,原生渲染,同时具备H5页面和原生应用的双重优点。
快应用的基础是一个软件平台框架,也就是宿主,通过宿主提供的开放组件、方法可快速开发体量很小的程序,以实现各业务的定制需求,但必须在宿主的现有能力和规则范围之内。
本发明提出的车载应用商城系统,自由扩展延伸社交互动功能,实现如评论、请愿等社交属性。
以下以互动流程为用户请愿流程为例,说明本发明的车载应用商城系统的互动流程。
图2揭示了根据本发明一实施例的车载应用商城系统的用户请愿流程图,如图2所示的车载应用商城系统实现方法,所述车机端100,包括以下步骤:
S311所述车机端100,向平台端200发布请愿信息;
S312所述车机端100,接收平台端200发送的请愿信息统计结果,请愿信息的标题所对应的应用软件显示请愿数增加1,并按照应用分类分别显示互动信息。
当用户希望车机端100中实现某个应用软件但还未实现时,可在车机端100提出请愿,其他车主对应的可见该请愿信息和请愿数量,形成良性互动。
如图2所示,所述平台端200,进一步包括以下步骤:
S321所述平台端200,接收车机端100发送的请愿信息并按请愿信息的标题匹配对应的应用软件;
S322所述平台端200,判断是否需要修改请愿信息的标题;
如果是,则更新请愿信息的标题,合并对应应用软件的请愿信息并进入审核;
如果否,则直接进入审核;
S323如果审核不通过,则不做进一步的动作;
S324如果审核通过,则更新并发布请愿信息统计结果,对应的应用软件的请愿数增加1。
平台端200的管理后台可对请愿信息进行审核,审核通过后该请愿信息统计后显示在车机端100,并且当前应用的请愿数增加1;同时,平台端200根据请愿信息内容做跟进,部分请愿应用软件将会被增加至应用商城中。
本发明还提供一种通过上述车载应用商城系统的实现方法实现的车载应用商城系统,图3揭示了根据本发明一实施例的车载应用商城系统的原理框图,如图3所示的车载应用商城系统,包括车机端100和平台端200:
所述车机端100,根据接收到的应用商城打开指令打开应用商城,获取平台端200发布的应用列表和应用信息,判断应用列表中各应用的安装状态,并区分显示获取的应用列表和应用信息;
所述平台端200,根据应用库发布应用列表和应用信息至车机端100。
车机端100,与平台端200通过无线通讯方式进行数据通信传输。
平台端200,可以是服务器或者云平台。
本发明提出的车载应用商城系统的车机端100,可以进行深度管理并进行功能自定义,与其他产品如车厂账号体系、语音控制进行打通。
更进一步的,所述平台端200,管理应用商城的应用软件,填写新增的应用信息并上传应用软件包,更新应用库;
所述平台端200,修改应用软件对应的应用信息,如果有上传应用软件包,则更新平台端200的应用软件版本号并更新应用库,如果没有上传应用软件包,则直接更新应用库。
更进一步的,所述车机端100,向平台端200发布互动信息,接收平台端200发送的互动信息统计结果,并按照应用分类分别显示互动信息;
所述平台端200,接收车机端100发送的互动信息并按互动信息的标题匹配对应的应用;判断是否修改互动信息的标题;如果是,则更新互动信息的标题,合并对应应用的互动信息并进入审核;如果否,则直接进入审核;如果审核不通过,则不做进一步的动作;如果审核通过,则更新并发布互动信息统计结果。
所述平台端200的管理后台,可以是封闭的,也可以是开放的。
所述平台端200的可打造开放后台,由供应商上传应用软件,公司内部人员做审核。
更进一步的,车载应用商城系统的平台端200采用快应用框架管理应用商城的应用软件。
平台端200,使用快应用方案,基于一套具有通用底层能力的框架开发出类似小程序的应用软件,并上传到应用商城,车机端100仅需加载一个很小的文件即可使用应用。
更进一步的,由于平台端200管理应用商城的应用软件,应用软件可以是定制的,也可以是非定制的,可控性强。例如,可以在平台端200通过自研后台对应用软件打视频标签,实现该类应用软件在车速大于指定值时不可使用。
本发明提供的一种车载应用商城系统及其实现方法,通过平台化管理应用商城中的应用,扩展生态服务,降低商务合作成本,降低车机资源占用,且强化用户互动,基于统一底层能力的快应用架构,节省车机端的资源消耗。
尽管为使解释简单化将上述方法图示并描述为一系列动作,但是应理解并领会,这些方法不受动作的次序所限,因为根据一个或多个实施例,一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。
如本申请和权利要求书中所示,除非上下文明确提示例外情形,“一”、“一个”、“一种”和/或“该”等词并非特指单数,也可包括复数。一般说来,术语“包括”与“包含”仅提示包括已明确标识的步骤和元素,而这些步骤和元素不构成一个排它性的罗列,方法或者设备也可能包含其他的步骤或元素。
本领域技术人员将进一步领会,结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性,各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性,但这样的实现决策不应被解读成导致脱离了本发明的范围。
上述实施例是提供给熟悉本领域内的人员来实现或使用本发明的,熟悉本领域的人员可在不脱离本发明的发明思想的情况下,对上述实施例做出种种修改或变化,因而本发明的保护范围并不被上述实施例所限,而应该是符合权利要求书提到的创新性特征的最大范围。