一种云应用的客户端的制作方法

文档序号:18141691发布日期:2019-07-10 11:08阅读:179来源:国知局
一种云应用的客户端的制作方法

本发明实施例涉及应用开发领域,特别涉及云应用的客户端。



背景技术:

云计算相关技术发展至今已趋于成熟,由此衍生出了相关的技术,如云网吧、云桌面这类将主机部署于云端,以此让用户在享用高配置的应用体验时不必考虑用户终端设备的高配置要求。传统的应用开发模式,基本都是需要借助用户终端设备的cpu(centralprocessingunit,中央处理器)、gpu(graphicsprocessingunit,图形处理器)负责计算大量复杂的数据,并渲染至界面上,以此呈现出应用的各种ui界面。但云网吧、云桌面这类技术,是将这部分工作都交给云端的主机设备,这样一来,用户终端就需要同步呈现云端主机渲染后的ui(userinterface,用户界面)界面,而这个传输的过程通常需要借助相关协议实现,如spice协议。数据传输后,用户终端仍旧需要解析协议,才能同步渲染相关ui,这工作量、难度都很大,因此通常ui方面,会选择借助基于相关协议封装的跨平台ui框架,如spice-gtk。

假设,把运行在用户终端上同步呈现云端主机界面的这部分模块称为client端,这类应用通常呈现模式如下:client端是直接同步的云端主机ui,那么通常运行在用户终端设备上的云网吧、云桌面应用会在client端外层再包裹一层ui控制层,用于操作各种业务需求,如管理用户可否使用client端的相关业务逻辑等等,假设把外层包裹的这层ui模块称为终端ui。

之所以说这种应用模式,传统的应用开发模式已不适用的原因是因为,传统的应用开发模式都是只使用一套ui框架来进行界面的渲染。

而如果仍旧只选择统一的一套ui框架来开发云应用类终端应用,那么有两个选择:

1.选择基于协议的跨平台ui框架开发client端和终端ui;

2.选择设备原生native的ui框架开发client端和终端ui;

两种模式都存在一些不足:第一种模式由于使用的是跨平台的ui框架,那么跨平台的相关弊端也就都存在,如无法像原生ui框架那样实现炫酷的ui效果,ui渲染性能方面较弱等,如果产品对这方面有需求,这种方案就不适用。

第二种模式是传统应用开发中选择最多的一种模式,都是借助系统原生的nativeui框架绘制界面,但由于传统应用的界面数据来源通常都直接后端接口获取,开发上难度较低。但云网吧、云桌面这类应用都需要有一个client端,这个client的界面数据来源是基于相关协议传输,如spice协议,如果要基于相关协议使用原生nativeui开发界面,等于是要自己做一套spice-gtk,难度和工作量都特别大。



技术实现要素:

本发明实施方式的目的在于提供一种云应用的客户端,使得ui界面的渲染效果好,还能降低工作量和开发难度。

为解决上述技术问题,本发明的实施方式提供了一种云应用的客户端,包括:第一ui控制模块、第二ui控制模块和适配模块;所述第一ui控制模块和所述第二ui控制模块基于不同的ui框架开发得到;所述第一ui控制模块与所述第二ui控制模块之间的通信方式包含:将要发送给对方的待发送数据发送至所述适配模块;所述适配模块接收所述待发送数据,将所述待发送数据的格式转换为所述对方可识别的格式,并将转换后的所述待发送数据发送至所述对方。

本发明的实施方式还提供了一种云计算应用系统,所述系统包含云端主机,及通过互联网与所述云端主机进行交互的客户端,其中,所述客户端包含如上述的云应用的客户端。

本发明实施方式相对于现有技术而言,主要区别及其效果在于:建立由不同框架开发的ui控制模块,现有不同框架开发的ui控制模块无法直接进行数据传输,从而无法实现交互事件,本申请通过新增的适配模块进行数据格式的转换及转发,实现两个ui控制模块之间的数据可以互相识别,从而实现两个ui控制模块之间的事件交互,使得云应用的客户端可以采用不同框架开发得到的ui控制模块,不仅利于降低开发难度,还能提升云应用的客户端的ui渲染效果。

作为进一步改进,所述适配模块将操作系统生成的ui交互事件进行拦截,并将所述ui交互事件转发至所述第一ui控制模块或所述第二ui控制模块。本实施例利用适配模块统一拦截交互事件并分发,实现对所有交互事件的集中管理。

作为进一步改进,所述适配模块在转发所述交互事件前,基于所述ui交互事件的属性信息确定目标接收者,所述目标接收者为所述第一ui控制模块或所述第二ui控制模块。本实施例明确具体分发方式。

作为进一步改进,所述目标接收者对所述ui交互事件进行响应,若所述响应中包含ui控制模块间的通信需求,则所述目标接收者根据所述通信需求发送通信数据。本实施例明确还可以根据ui控制模块间的通信需求发送,实现ui控制模块的数据识别。

作为进一步改进,所述云应用的客户端中的业务需求基于所述第一ui控制模块进行处理;所述云应用的客户端与云端主机的交互基于所述第二ui控制模块实现。本实施例明确两个ui控制模块的功能划分。

作为进一步改进,所述第一ui控制模块基于原生native的ui框架开发得到,所述第二ui控制模块采用基于协议的跨平台ui框架开发得到。本实施例明确两个ui控制模块分别的开发模式。

作为进一步改进,所述第一ui控制模块和所述适配模块采用分层模块的结构。本实施例明确适配模块和ui控制模块分层,简化开发过程。

作为进一步改进,所述第二ui控制模块和所述云端主机采用spice协议进行交互。

作为进一步改进,还至少包括:第三ui控制模块,所述第三ui控制模块采用与所述第一ui控制模块或所述第二ui控制模块不同的框架开发得到;所述适配模块,在接收到待发送至所述第三ui控制模块的数据时,将数据转换为所述第三ui控制模块可解析的格式的数据后,发送至所述第三ui控制模块。本实施方式明确在一个云应用的客户端中,可以采用更多的开发模式开发ui,实现更为灵活的ui开发。

作为进一步改进,所述云应用为云网吧或云桌面。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明,这些示例性说明并不构成对实施例的限定,附图中具有相同参考数字标号的元件表示为类似的元件,除非有特别申明,附图中的图不构成比例限制。

图1是根据本发明第一实施方式中的云应用的客户端的示意图;

图2是根据本发明第二实施方式中的云应用的客户端的示意图;

图3是根据本发明第三实施方式中的云应用的客户端的示意图;

图4是根据本发明第四实施方式中的云应用的客户端的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合附图对本发明的各实施方式进行详细的阐述。然而,本领域的普通技术人员可以理解,在本发明各实施方式中,为了使读者更好地理解本申请而提出了许多技术细节。但是,即使没有这些技术细节和基于以下各实施方式的种种变化和修改,也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便,不应对本发明的具体实现方式构成任何限定,各个实施例在不矛盾的前提下可以相互结合相互引用。

本发明提供的云应用的客户端,基于云应用的新型应用场景,提出一种新型的应用开发模式,通过融合多种不同ui框架,建立不同ui框架之间的通信适配层,达到减少工作量、工作难度的同时,还能够根据产品需要实现炫酷的界面效果的目的。具体的说,传统的应用开发模式中,因为只存在客户端与后台交互的场景,因此只使用一套ui框架即可。但云网吧、云桌面这类新型的应用开发场景,就需要考虑ui方案的实现了。云应用的客户端不仅需要实现客户端的ui,同时还要实现client端的ui。但client端的界面数据来源是基于与云端主机之间的相关协议基础的,比如spice协议,而协议并不像与后台通过接口通信这么简单,所以传统方式开发云应用,通信难度的问题无法解决。

本发明的第一实施方式涉及一种云应用的客户端。其结构示意图如图1所示,具体包括:第一ui控制模块121、第二ui控制模块122和适配模块123,第一ui控制模块121与用户终端1的后台管理系统11连接,第二ui控制模块122与云应用对应的云端虚拟主机2相连。云应用的客户端中的业务需求基于第一ui控制模块121进行处理,实际应用中第一ui控制模块121和后台管理系统11间可以运行用户账号管理相关的业务逻辑;云应用的客户端与云端主机的交互基于第二ui控制模块122实现,实际应用中第二ui控制模块122同步呈现云端虚拟主机2中应用程序的界面等,云端主机2中运行多个虚拟主机(主机21、主机22、主机23)。

具体的说,上述第一ui控制模块121可以用于操作云应用的客户端中各业务需求,可以基于原生native的ui框架开发得到,上述第二ui控制模块122可以用于与云应用对应的云端主机交互,可以采用基于协议的跨平台ui框架开发得到。本实施方式中,第一ui控制模块121和第二ui控制模块122开发架构的层级关系为第一ui控制模块121包裹在第二控制模块的外层。

举例来说,第二ui控制模块122负责与云端主机交互,以同步展示云应用的渲染界面,而其他的业务逻辑,比如账号登录、充值、余额管理、查看哪些云端主机是否可用等等这些业务相关的功能都可以另外在第二ui控制模块122外层包裹的第一ui控制模块121中实现。

以云桌面应用的客户端为例,第二ui控制模块122同步远端服务器的界面,作为云桌面应用客户端的核心,与此同时,客户端在提供这个功能给用户使用时,需要对用户账号进行管理,确定用户是否有权限使用第二ui控制模块122对应的云桌面功能,选择可连接的云桌面机器,这部分管理控制功能由第一ui控制模块121实现,第一ui控制模块121可以控制用户是否能够运用第二ui控制模块122提供的功能。

第一ui控制模块121和第二ui控制模块122由不同的框架开发得到,若相互之间有通信需求,则无法法直接进行通信,本实施方式中可通过增设适配模块则可解决该问题。具体的说,第一ui控制模块121在需要向第二ui控制模块122发送数据时,将待发数据发送至适配模块123,第二ui控制模块122在需要向第一ui控制模块121发送数据时,将待发数据发送至适配模块123。适配模块123在接收到待发送数据后,可将其转发至目标ui模块(第二ui模块或第一ui模块)。

还需说明的是,操作客户端上的ui时,交互事件直接分发给客户端的第一ui控制模块121处理;操作client端内的云桌面、云网吧时,交互事件直接分发给第二ui控制模块122。但如果第一ui控制模块121接收到交互事件后的响应是需要更新client端的ui,也就是说,需要由第一ui控制模块121处理,这就涉及到不同ui框架间的协调,系统无法帮忙处理,所以只能引入适配模块123来解决。

继续说明,如图2所示,适配模块123接收用户操控ui13发来的待发送数据,将待发送数据的格式转换为对方可识别的格式,并通过分发控制124将转换后的待发送数据发送至对方。实际应用中,适配模块123在接收到待发送至第二ui控制模块122的数据时,将数据转换为第二ui控制模块122可解析的格式的数据后,发送至第二ui控制模块122;或者,在接收到待发送至第一ui控制模块121的数据时,将数据转换为第一ui控制模块121可解析的格式的数据后,发送至第一ui控制模块121。

具体的说,第一ui控制模块121和第二ui控制模块122之间,由于不是同一套ui框架了,所以需要先将通信信息发送至适配模块123,适配模块123进行格式转换后,再进行转发。比如,将a框架发送的消息格式a1,重新根据b框架的消息通信原理封装成b1,再发送给b框架处理。可见,本实施方式为了能够解决不同ui框架之间的通信问题,本实施方式在原本云网吧、云桌面这类应用的系统框架之间,额外增加了一层ui适配层,统一管理、分发ui交互事件,然后在这个适配层中再根据这些消息的接收者,先转换成目标接收者所需的消息格式、消息接收方式,接着发给对应ui框架去进行界面绘制处理。

更具体的说,第一ui控制模块121和适配模块123可以采用分层模块的结构,适配模块123可以和第一ui控制模块121相对独立地开发。

本实施方式中第二ui控制模块122和云端主机采用spice协议进行交互。与传统应用开发模式相比,本实施方式中的云应用的客户端在开发时,只需了解spice-gtk的消息通信原理,懂得如何封装成目标ui控制模块能够接收和处理的消息即可。相比原本要了解spice协议本身,并将其gtk抽离替换成nativeui框架的工作量和难度都大大减少。同时,客户端ui仍旧可以使用nativeui框架,不存在跨平台的弊端。

综上,本实施方式相对于现有技术而言,主要区别及其效果在于:建立由不同框架开发的ui控制模块,现有不同框架开发的ui控制模块无法直接进行数据传输,从而无法实现交互事件,本申请通过新增的适配模块123进行数据格式的转换及转发,实现两个ui控制模块之间的数据可以互相识别,从而实现两个ui控制模块之间的事件交互,使得云应用的客户端可以采用不同框架开发得到的ui控制模块,不仅利于降低开发难度,还能提升云应用的客户端的ui渲染效果。具体明确两个ui控件模块分别的开发模式,一个采用原生native的ui框架进行开发,另一个采用基于协议的跨平台ui框架进行开发,兼容了两种开发模式的优势,降低了开发难度。

另外,本实施方式中的适配模块123可以和第一ui控制模块121相对独立地开发,实际应用中,ui适配层可不用独立出,可以内置于第二ui控制模块122中。这样,即使云网吧、云桌面这类应用项目本身的系统框架设计已经足够复杂,不想再额外增加一些层次来增加架构的复杂度,那么也可以实现,不会过于增加客户端的复杂度。

本发明的第二实施方式涉及一种云应用的客户端。第二实施方式在第一实施方式的基础上做了进一步改进,主要改进之处在于:在本发明第二实施方式中适配模块123新增拦截交互事件的功能,使得适配模块123可以统一调配交互事件,便于信息管理。

本实施方式中云应用的客户端的结构示意图如图3所示,具体如下:

本实施方式中的适配模块123将操作系统14生成的ui交互事件进行拦截,并将ui交互事件转发至第一ui控制模块121或第二ui控制模块122。更具体的说,适配模块123在转发交互事件前,基于ui交互事件的属性信息确定目标接收者,目标接收者为第一ui控制模块121或第二ui控制模块122。

实际应用中,适配模块123可以根据事件的属性确定拦截到的事件指向的目标控件,根据目标控件所在位置,可以确定待发送事件的目标ui控制模块,随后可以将所拦截到的事件发送给目标ui控制模块,其中,上述目标ui控制模块为第一ui控制模块121或第二ui控制模块122。

实际应用中,适配模块123在操作系统生成交互事件,至发送给具体目标控件之间。通过操作系统相关接口,拦截所有产生的交互事件,根据事件中的属性可获得这个交互事件是要被哪个目标控件消费,这些信息足够判断事件是要分发给哪个ui框架,此时可直接分发给对应的ui框架消费事件。

需要说明的是,由于不同的ui控制模块由不同的ui框架开发得到,其接收的数据格式也不相同,如果目标ui控制模块由原生native的ui框架开发得到,那么目标ui控制模块可以识别出后台系统发出的数据,但如果目标ui控制模块并非由原生native的ui框架开发得到,例如由基于协议的跨平台ui框架开发得到,那么目标ui控制模块无法直接识别后台系统发来的数据。本实施方式中由适配模块123在将所拦截的事件发送给目标ui控制模块前,将所拦截的事件转换为目标ui控制模块可解析的格式后再发送。

本实施方式可继续说明,目标接收者在接收到适配模块123分发的交互事件后,对ui交互事件进行响应,若响应中包含ui控制模块间的通信需求,则目标接收者根据通信需求发送通信数据。其中,通信需求可以包括需要响应的内容、响应的格式等,在此不做限定。进一步说,在对交互事件进行响应时,可能需要对另一ui控制模块进行操作,那么此时目标接收者可以先向适配模块123发送,由适配模块123发送至另一ui控制模块进行操作。

可见,本实施方式中利用适配模块123统一拦截交互事件并分发,实现对所有交互事件的集中管理,还具体明确了适配模块123在分发之前可以进行数据格式转换,使得目标ui控件可以准确接收并解析交互事件,完成事件的交互。另外,还明确了当交互事件需要响应时,甚至响应时还需要其他ui控制模块进行操作的处理过程,使得本实施方式符合实际应用场景,明确易实施。

本发明的第三实施方式涉及一种云应用的客户端。本实施方式和第一实施方式大致相同,主要的区别在于:第一实施方式中ui控制模块为两个,分别为第一ui控制模块121和第二ui控制模块122,而本实施方式中新增第三ui控制模块,使得在一个云应用的客户端中,可以采用更多的开发模式开发ui,实现更为灵活的ui开发。

具体的说,本实施方式中云应用的客户端的结构示意图如图4所示,具体如下:

本实施方式中的云应用的客户端,还至少包括:第三ui控制模块125,第三ui控制模块125采用与第一ui控制模块121或第二ui控制模块122不同的框架开发得到。对应地,适配模块123在接收到待发送至第三ui控制模块125的数据时,将数据转换为第三ui控制模块125可解析的格式的数据后,发送至第三ui控制模块125。

具体的说,适配模块123接收到的待发送至第三ui控制模块的数据包括两类:一类为ui控制模块之间的信息交互,一类为适配模块123拦截到的,适配模块123在接收到上述两类数据后,进行数据的解析、转换、封装,获得第三ui控制模块可解析的信息格式,然后再发送给第三ui控制模块去处理。

第三ui控制模块可解析的信息格式可以预先配置在适配模块123中,也可以由用户手动配置,在此不再赘述。

可见,本实施方式明确在一个云应用的客户端中,可以采用更多的开发模式开发ui,实现更为灵活的ui开发。

进一步说,实际应用中,除了上述实施例中的第一ui控制模块121至第三ui控制模块外,还可以新增更多的ui控制模块,进一步丰富云应用的客户端的开发模式,实现灵活的开发过程。

本领域技术人员可以理解,实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序存储在一个存储介质中,包括若干指令用以使得一个设备(可以是单片机,芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解,上述各实施方式是实现本发明的具体实施例,而在实际应用中,可以在形式上和细节上对其作各种改变,而不偏离本发明的精神和范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1