CN107526581B - 数据更新提醒方法及装置 - Google Patents

数据更新提醒方法及装置 Download PDF

Info

Publication number
CN107526581B
CN107526581B CN201610612980.XA CN201610612980A CN107526581B CN 107526581 B CN107526581 B CN 107526581B CN 201610612980 A CN201610612980 A CN 201610612980A CN 107526581 B CN107526581 B CN 107526581B
Authority
CN
China
Prior art keywords
time interval
waiting time
updating
update
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201610612980.XA
Other languages
English (en)
Other versions
CN107526581A (zh
Inventor
郭力
苏楠
贺啸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Tencent Cloud Computing Beijing Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201610612980.XA priority Critical patent/CN107526581B/zh
Publication of CN107526581A publication Critical patent/CN107526581A/zh
Application granted granted Critical
Publication of CN107526581B publication Critical patent/CN107526581B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种数据更新提醒方法及装置。其中，该方法包括：接收使用第一账号登录的客户端发送的数据更新请求，其中，数据更新请求用于请求对客户端当前所使用的第一版本进行更新；判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；在判断出接收时间满足等待时间间隔条件时，向客户端发送更新提醒信息，其中，更新提醒信息用于提醒客户端将当前所使用的第一版本更新为服务器记录的第二版本，其中，第二版本的发布时间晚于第一版本的发布时间。本发明解决了采用现有的数据更新提醒方式所导致的效率较低的技术问题。

Description

数据更新提醒方法及装置
技术领域
本发明涉及计算机领域，具体而言，涉及一种数据更新提醒方法及装置。
背景技术
为了适应不断变化的应用需求，应用客户端往往会进行定期的版本数据更新。在进行版本数据更新前，应用客户端往往会弹出更新提醒信息框，用于提示用户执行更新操作。
目前，常用的版本数据更新提醒方式包括以下两种：1)使用第三方应用分发平台进行更新提醒，如应用助手、应用商城等，其工作原理是：在进入上述第三方应用分发平台后，在检测到某个应用有新版本发布时，则通过该平台向用户提醒更新应用版本，但由于第三方应用分发平台使用频率不高，被关注度较低，从而导致采用这种方式时数据更新提醒的效率较低的问题；2)通过应用客户端自身进行更新提醒，也就是说，在每次启动该应用客户端时，都会弹出对应的更新提醒信息框，这种多次弹框提示的方式，不仅会造成对用户的干扰，使得用户需要频繁地关闭弹框，影响用户体验，而且还会使得用户在关闭弹框后忽略数据更新提醒的具体提醒内容，难以保证及时更新应用客户端的版本数据，从而导致采用该方式时数据更新提醒的效率较低的问题。
针对上述的问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种数据更新提醒方法及装置，以至少解决采用现有的数据更新提醒方式所导致的效率较低的技术问题。
根据本发明实施例的一个方面，提供了一种数据更新提醒方法，包括：接收使用第一账号登录的客户端发送的数据更新请求，其中，上述数据更新请求用于请求对上述客户端当前所使用的第一版本进行更新；判断接收到上述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；在判断出上述接收时间满足上述等待时间间隔条件时，向上述客户端发送更新提醒信息，其中，上述更新提醒信息用于提醒上述客户端将当前所使用的上述第一版本更新为上述服务器记录的第二版本，其中，上述第二版本的发布时间晚于上述第一版本的发布时间。
根据本发明实施例的另一方面，还提供了一种数据更新提醒装置，包括：接收单元，用于接收使用第一账号登录的客户端发送的数据更新请求，其中，上述数据更新请求用于请求对上述客户端当前所使用的第一版本进行更新；第一判断单元，用于判断接收到上述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；提醒单元，用于在判断出上述接收时间满足上述等待时间间隔条件时，向上述客户端发送更新提醒信息，其中，上述更新提醒信息用于提醒上述客户端将当前所使用的上述第一版本更新为上述服务器记录的第二版本，其中，上述第二版本的发布时间晚于上述第一版本的发布时间。
在本发明实施例中，在接收到客户端发送的用于请求对客户端当前所使用的第一版本进行更新的数据更新请求后，通过判断接收到上述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，从而实现根据判断结果动态控制是否向客户端发送用于提醒客户端将当前所使用的第一版本更新为服务器记录的第二版本的更新提醒信息，其中，第二版本的发布时间晚于第一版本的发布时间。也就是说，在接收到数据更新请求后，通过判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，以实现根据服务器配置的等待时间间隔条件动态控制对客户端的数据更新提醒，而不再由固化在客户端中的数据更新提醒控制方式进行固定的数据更新提醒，以克服相关技术中数据更新提醒的效率较低的问题，进而实现提高数据更新提醒的效率，减少对用户干扰的效果。
此外，在本实施例中，服务器预配置的等待时间间隔条件还可以根据不同需求实时调整更新，以达到对数据更新提醒的灵活控制，保证数据更新提醒的灵活性。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的一种可选的数据更新提醒方法的应用环境示意图；
图2是根据本发明实施例的一种可选的数据更新提醒方法的流程图；
图3是根据本发明实施例的另一种可选的数据更新提醒方法的流程图；
图4根据本发明实施例的一种可选的数据更新提醒装置的示意图；
图5是根据本发明实施例的一种可选的数据更新提醒方法的实施流程图；以及
图6是根据本发明实施例的一种可选的数据更新提醒服务器的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例1
在本发明实施例中，提供了一种上述数据更新提醒方法的实施例。作为一种可选的实施方式，该数据更新提醒方法可以但不限于应用于如图1 所示的应用环境中，终端102中安装有使用第一账号登录的客户端，服务器106通过网络104接收上述客户端发送的数据更新请求，其中，该数据更新请求用于请求对客户端当前所使用的第一版本进行更新；然后，服务器106判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；并在判断出接收时间满足等待时间间隔条件时，向客户端发送更新提醒信息，其中，更新提醒信息用于提醒客户端将当前所使用的第一版本更新为服务器记录的第二版本，其中，第二版本的发布时间晚于第一版本的发布时间。
在本实施例中，在接收到客户端发送的用于请求对客户端当前所使用的第一版本进行更新的数据更新请求后，通过判断接收到上述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，从而实现根据判断结果动态控制是否向客户端发送用于提醒客户端将当前所使用的第一版本更新为服务器记录的第二版本的更新提醒信息，其中，第二版本的发布时间晚于第一版本的发布时间。也就是说，在接收到数据更新请求后，通过判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，以实现根据服务器配置的等待时间间隔条件动态控制对客户端的数据更新提醒，而不再由固化在客户端中的数据更新提醒控制方式进行固定的数据更新提醒，以克服相关技术中数据更新提醒的效率较低的问题，进而实现提高数据更新提醒的效率，减少对用户干扰的效果。此外，在本实施例中，服务器预配置的等待时间间隔条件还可以根据不同需求实时调整更新，以达到对数据更新提醒的灵活控制，保证数据更新提醒的灵活性。
可选地，在本实施例中，上述终端可以包括但不限于以下至少之一：手机、平板电脑、笔记本电脑、台式PC机、数字电视及其他运行有应用客户端的硬件设备。上述网络可以包括但不限于以下至少之一：广域网、城域网、局域网。上述只是一种示例，本实施例对此不做任何限定。
根据本发明实施例，提供了一种数据更新提醒方法，如图2所示，该方法包括：
S202，接收使用第一账号登录的客户端发送的数据更新请求，其中，数据更新请求用于请求对客户端当前所使用的第一版本进行更新；
S204，判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；
S206，在判断出接收时间满足等待时间间隔条件时，向客户端发送更新提醒信息，其中，更新提醒信息用于提醒客户端将当前所使用的第一版本更新为服务器记录的第二版本，其中，第二版本的发布时间晚于第一版本的发布时间。
可选地，在本实施例中，上述数据更新提醒方法可以但不限于应用于不同的终端应用中或第三方应用分发平台中，其中，上述终端应用可以包括但不限于：即时通讯应用、游戏应用、视频播放应用等等。上述第三方应用分发平台可以包括但不限于：应用商城、应用助手等等。这里第三方应用分发平台中可以但不限于用于管理上述不同的终端应用。也就是说，上述仅是一种示例，可以用于提醒更新终端进行应用版本数据更新的执行实体均适用上述数据更新提醒方法，本实施例中对此不做任何限定。
需要说明的是，在本实施例中，在接收到数据更新请求后，通过判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，以实现根据服务器配置的等待时间间隔条件动态控制对客户端的数据更新提醒，而不再由固化在客户端中的数据更新提醒控制方式进行固定的数据更新提醒，以克服相关技术中数据更新提醒的效率较低的问题，进而实现提高数据更新提醒的效率的效果，并达到减少对用户干扰的目的。此外，在本实施例中，服务器预配置的等待时间间隔条件还可以根据不同需求实时调整更新，以达到对数据更新提醒的灵活控制，保证数据更新提醒的灵活性。进一步，在数据更新提醒效率提高的情况下，将更有利于客户端版本的及时统一更新，避免不同用户采用不同客户端本本所造成的版本碎片化的问题。再者，本实施例中提供的灵活高效的数据更新提醒方法，还将为在户外适用客户端的用户账号节省移动流量、电池消耗，以达到节省资源成本的目的。
可选地，在本实施例中，上述服务器预配置的等待时间间隔条件可以但不限于存储在服务器预配置的配置表的配置项中。也就是说，通过灵活配置在服务器的配置表的配置项中存储的上述等待时间间隔条件，实现对是否向客户端发送用于提醒客户端进行版本更新的更新提醒信息的动态控制。其中，上述配置项的配置方式可以包括但不限于以下至少之一：自定义配置、默认配置。上述仅是一种示例，本实施例中对此不做任何限定。
需要说明的是，在本实施例中，上述服务器预配置的配置表的配置项中可以包括但不限于：数据更新请求中携带的请求标识、等待时间间隔条件所指示的等待时间间隔、在接收到数据更新请求之前上一次发送更新提醒信息的第一时间及三者之间的映射关系。其中，上述请求标识可以包括但不限于以下至少之一：第一账号、客户端所在终端的终端标识。这里，上述第一账号可以但不限于在不同的终端上登录相同的应用客户端，本实施例中对此不做限定。此外，上述终端标识可以但不限于为通用唯一标识码(Universally UniqueIdentifier，UUID)。例如，如表1所示为一种可选的服务器预配置的配置表，其中，等待时间间隔以天为单位。
表1
Figure BDA0001062999670000071
也就是说，在本实施例中，上述服务器可以但不限于利用上述配置表来判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，其中，具体可以包括但不限于：
S1，获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔；
S2，判断接收时间与第一时间的差值是否大于等于等待时间间隔，其中，第一时间用于标识在接收到数据更新请求之前上一次发送更新提醒信息的时间；
S3，在接收时间与第一时间的差值大于等待时间间隔时，则判断出满足服务器预配置的等待时间间隔条件。
例如，以接收到第一账号“张三”使用终端“deviceUUID1”登录客户端发送的数据更新请求为例，如表1所示，根据请求标识(即第一账号“张三”与终端“deviceUUID1”)获取到配置表中对应的配置项(序号1) 中的等待时间间隔为3天，此外，从该配置项(序号1)还获取到上次发送更新提醒信息的第一时间为时间戳“1463970955”，进一步，假设接收时间为T，则判断接收时间T与第一时间(时间戳“1463970955”)的差值是否大于上述等待时间间隔3天，假设上述差值大于上述等待时间间隔，则可判断出接收到数据更新请求的接收时间T满足服务器预配置的等待时间间隔条件，进而执行向客户端发送更新提醒信息。
可选地，在本实施例中，在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，还包括：在配置表中查找与数据更新请求中携带的请求标识匹配的配置项；在查找到配置项时，获取配置项中与请求标识匹配的等待时间间隔及第一时间；在未查找到配置项时，在配置表中创建与请求标识匹配的配置项。
需要说明的是，在本实施例中，为了节省存储空间，在服务器预配置的配置表中对于与已执行的更新操作对应的配置项可以但不限于执行删除处理，对于与还未执行的更新操作对应的配置项可以但不限于执行保存处理。也就是说，在上述服务器预配置的配置表中，与数据更新请求中携带的请求标识匹配的配置项可以但不限于仍然保存在配置表中，即，对应的更新操作还未被执行；也可以但不限于已从配置表中删除，即，对应的更新操作已被执行，需重新创建与数据更新请求的请求标识匹配的配置项。
这里，对于首次创建的配置项可以包括但不限于：请求标识、等待时间间隔，其中，上述等待时间间隔可以但不限于为默认时间间隔，如 global_interval_day。也就是说，对于首次创建的配置项中不包括上一次发送更新提醒信息的第一时间。
可选地，在本实施例中，在判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件之前，还包括：判断服务器中是否记录有第二版本；在判断出服务器记录有第二版本时，获取数据更新请求的接收时间。也就是说，在判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件之前，判断服务器是否存储有相对于第一版本发布时间更晚的最新版本(即第二版本)，并在判断出服务器记录有第二版本时，再获取接收到数据更新请求的接收时间。从而实现提高数据更新提醒的有效性，以避免在第一版本已是最新版本的情况下，执行数据更新提醒过程。
需要说明的是，在本实施例中，在查找服务器是否记录有第二版本时，可以但不限于查找应用版本号。也就是说，通过比对数据客户端当前使用的第一版本的版本号与服务器记录的版本号，来确定服务器记录的是否为比第一版本发布时间更晚的第二版本，以达到提高服务器的查找效率的目的。
可选地，在本实施例中，在向客户端发送更新提醒信息时，还可以包括但不限于：更新配置表的配置项中记录的第一时间。也就是说，在向客户端发送更新提醒信息的同时，利用当前的发送时间更新服务器配置表的配置项中的第一时间，即，将当前发送更新提醒信息的发送时间作为下一次发送更新提醒信息的第一时间。以表1为例，在向客户端发送更新提醒信息时，利用发送时间更新与请求标识对应的第一时间(lastAlertTime)中的取值。
可选地，在本实施例中，在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，还包括：更新配置表中记录的等待时间间隔条件。其中，更新配置表中记录的等待时间间隔条件可以包括但不限于以下至少之一：
1)接收配置请求；根据配置请求更新配置表中记录的等待时间间隔条件所指示的等待时间间隔；
2)接收客户端发送的操作指令，其中，操作指令用于指示客户端是否允许执行将第一版本更新为第二版本的更新操作；根据操作指令更新配置表中记录的等待时间间隔条件所指示的等待时间间隔。
也就是说，在方式1)中，可以但不限于根据配置请求所请求的等待时间间隔，对服务器配置表的配置项中的等待时间间隔进行更新，如自定义配置等。在方式2)中，可以但不限于根据客户端发送的操作指令，来确定是否更新配置表中记录的等待时间间隔。其中，在操作指令指示允许执行更新操作时，删除与更新操作对应的等待时间间隔所在的配置项；在操作指令指示拒绝执行更新操作时，更新与更新操作对应的等待时间间隔，其中，更新后的等待时间间隔根据预设延迟步长确定。
具体结合以下示例进行说明，如图3所示步骤S302-S310，终端302 上使用第一账号ID-1登录的应用客户端App- 1向服务器304发送用于更新当前所使用的第一版本V1.0的数据更新请求，服务器304在接收到上述数据更新请求后，比对第一版本V1.0与服务器304记录的最新版本，若二者版本一致，则退出流程；若服务器304记录的最新版本为发布时间晚于第一版本V1.0的第二版本V2.0，则判断出需要执行更新操作，在服务器预配置的配置表中查找与上述数据更新请求中携带的请求标识匹配的配置项，若查找到该配置项，则判断接收到数据更新请求的接收时间是否满足配置项中的等待时间间隔条件，在判断出满足等待时间间隔条件时，向终端302上的客户端发送更新提醒信息。
通过本申请提供的实施例，在接收到数据更新请求后，通过判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，以实现根据服务器配置的等待时间间隔条件动态控制对客户端的数据更新提醒，而不再由固化在客户端中的数据更新提醒控制方式进行固定的数据更新提醒，以克服相关技术中数据更新提醒的效率较低的问题，进而实现提高数据更新提醒的效率的效果，并达到减少对用户干扰的目的。
作为一种可选的方案，判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件包括：
S1，获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔；
S2，判断接收时间与第一时间的差值是否大于等于等待时间间隔，其中，第一时间用于标识在接收到数据更新请求之前上一次发送更新提醒信息的时间；
S3，在接收时间与第一时间的差值大于等待时间间隔时，则判断出满足服务器预配置的等待时间间隔条件。
具体结合表1所示进行说明，以接收到第一账号“张三”使用终端“deviceUUID1”登录客户端发送的数据更新请求为例，如表1所示，根据请求标识(即第一账号“张三”与终端“deviceUUID1”)获取到配置表中对应的配置项(序号1)中的等待时间间隔为3天，此外，从该配置项 (序号 1)还获取到上次发送更新提醒信息的第一时间为时间戳“1463970955”，进一步，假设接收时间为T，则判断接收时间T与第一时间(时间戳“1463970955”)的差值是否大于上述等待时间间隔3天，假设上述差值大于上述等待时间间隔，则可判断出接收到数据更新请求的接收时间T满足服务器预配置的等待时间间隔条件，进而执行向客户端发送更新提醒信息。
又例如，假设又以接收到第一账号“张三”使用终端“deviceUUID3”登录客户端发送的数据更新请求为例(即相同账号在不同终端登录该客户端)，如表1所示，根据请求标识(即第一账号“张三”与终端“deviceUUID3”) 获取到配置表中对应的配置项(序号3)中的等待时间间隔为4天，假设接收时间为T，且接收时间T与第一时间(时间戳“1463912584”)的差值小于上述等待时间间隔4天，则可判断出接收到数据更新请求的接收时间T不满足服务器预配置的等待时间间隔条件，则暂不向客户端发送更新提醒信息。
通过本申请提供的实施例，在获取接收到数据更新请求的接收时间与上一次发送更新提醒信息的第一时间的差值后，通过比对上述差值与服务器预配置的配置表中记录的等待时间间隔，从而实现利用在服务器灵活配置的等待时间间隔对客户端的数据更新提醒的动态控制，以减少相关技术中需要多次弹框提示更新客户端版本对用户所造成的干扰，进而改善用户体验；进一步，在保证数据更新提醒信息不被频繁关闭的情况下，还将达到提高更新提醒信息的关注度的目的，进而实现提高数据更新提醒的效率的效果。
作为一种可选的方案，在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，还包括：
S1，在配置表中查找与数据更新请求中携带的请求标识匹配的配置项，其中，配置项用于存储请求标识、等待时间间隔及第一时间三者之间的映射关系，请求标识包括以下至少之一：第一账号、客户端所在终端的终端标识；
S2，在查找到配置项时，获取配置项中与请求标识匹配的等待时间间隔及第一时间；
S3，在未查找到配置项时，在配置表中创建与请求标识匹配的配置项。
具体结合表1所示，在配置表的一条配置项中可以包括但不限于：请求标识(如登录客户端的第一账号(username)、登录时所在终端的终端标识(deviceUUID))、上一次使用该请求标识发送更新提醒信息的第一时间 (lastAlertTime)、等待时间间隔(nextAlertInterval)。
需要说明的是，在本实施例中，为了节省存储空间，在服务器预配置的配置表中对于与已执行的更新操作对应的配置项可以但不限于执行删除处理，对于与还未执行的更新操作对应的配置项可以但不限于执行保存处理。也就是说，在接收到客户端发送的数据更新请求后，在上述服务器预配置的配置表中，与上述数据更新请求中携带的请求标识匹配的配置项可以但不限于仍然保存在配置表中，即，对应的更新操作还未被执行(如一直接收到客户端发送的拒绝执行更新操作的操作指令)；也可以但不限于已从配置表中删除，即，对应的更新操作已被执行(如接收到客户端发送的执行更新操作的操作指令)，在这种情况下，则需重新创建与数据更新请求的请求标识匹配的配置项。
通过本申请提供的实施例，在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，判断是否可以在服务器预配置的配置表中查找到对应的配置项。也就是说，在本实施例中，为了节省存储空间，在有限的存储空间中存储还未执行的更新操作对应的配置项，以达到提高配置表中配置项的利用率的目的。
作为一种可选的方案，在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，还包括：
S1，更新配置表中记录的等待时间间隔条件。
可选地，在本实施例中，更新配置表中记录的等待时间间隔条件的方式可以包括但不限于以下至少之一：
1)作为一种可选的实施方式，更新配置表中记录的等待时间间隔条件包括：S11，接收配置请求；S21，根据配置请求更新配置表中记录的等待时间间隔条件所指示的等待时间间隔。
也就是说，在本实施例中，可以但不限于根据配置请求所请求配置的等待时间间隔，对服务器配置表的配置项中的等待时间间隔进行更新，如根据需求进行自定义配置等。例如，为了在预定周期内消除客户端版本碎片化的问题，则在该预定周期内可对该客户端进行高频率更新提醒，如自定义配置等待时间间隔，将默认时间配置1周更新调整为1天。
通过本申请提供的实施例，根据接收到的配置请求所请求配置的等待时间间隔实现对配置项中的等待时间间隔的动态更新调整。
2)作为另一种可选的实施方式，更新配置表中记录的等待时间间隔条件包括：S11，接收客户端发送的操作指令，其中，操作指令用于指示客户端是否允许执行将第一版本更新为第二版本的更新操作；S21，根据操作指令更新配置表中记录的等待时间间隔条件所指示的等待时间间隔。
可选地，在本实施例中，根据操作指令更新配置表中记录的等待时间间隔条件所指示的等待时间间隔包括：
1)在操作指令指示允许执行更新操作时，删除与更新操作对应的等待时间间隔所在的配置项；
2)在操作指令指示拒绝执行更新操作时，更新与更新操作对应的等待时间间隔，其中，更新后的等待时间间隔根据预设延迟步长确定。
也就是说，在本实施例中，可以但不限于结合客户端发送的操作指令，来确定是否更新配置表中记录的等待时间间隔，其中，上述操作指令可以但不限于在客户端接收到更新提醒信息后，客户端根据接收到的用于指示是否允许执行更新操作的指示操作所生成的操作指令。例如，客户端在接收到更新提醒信息后，将弹框显示该更新提醒信息，进一步，若客户端获取到允许执行更新操作的指示操作，则向服务器发送操作指令，该操作指令用于指示删除与该更新操作对应的配置项；若客户端获取到拒绝执行更新操作的指示操作，则向服务器发送操作指令，该操作指令用于指示更新与该更新操作对应的配置项。
需要说明的是，在本实施例中，上述预设延迟步长可以但不限于根据不同场景设置为不同取值，例如，在判断出第一账号在户外使用客户端时，可以但不限于预设延迟步长配置为A，在判断出第一账号在室内使用客户端时，可以但不限于预设延迟步长配置为B，其中，A>B。上述仅是一种示例，本实施例中对此不做任何限定。
通过本申请提供的实施例，结合从客户端接收到的操作指令，实现对配置项中的等待时间间隔的动态更新调整，以使调整后的等待时间间隔更加符合用户需求，更有利于解决客户端碎片化的问题。
作为一种可选的方案，更新与更新操作对应的等待时间间隔包括：
Ti+1＝Ti+S (1)
其中，Ti+1用于表示第i+1次发送更新提醒信息前的等待时间间隔，Ti用于表示第i次发送更新提醒信息前的等待时间间隔，S用于表示预设延迟步长，i为大于等于1的整数，在i＝1时，T1为默认时间间隔。
需要说明的是，在本实施例中，在i＝1时，初始值T1可以但不限于为默认时间间隔，如global_interval_day。从第2次(T2)起开始，第i+1次发送更新提醒信息前的等待时间间隔(即nextAlertInterval)，等于上一次 (即第i次)发送更新提醒信息前的等待时间间隔与预设延迟步长Step二者之间的和，即nextAlertInterval＝nextAlertInterval+Step。
例如，假设上一次(即第i次)发送更新提醒信息前的等待时间间隔为3，预设延迟步长Step为1，且接收到操作指令指示拒绝执行更新操作时，则第i+1次发送更新提醒信息前的等待时间间隔为3+1＝4，进一步，若仍接收到操作指令指示拒绝执行更新操作，则第i+2次发送更新提醒信息前的等待时间间隔将为4+1＝5。依次类推，本事示例在此不再赘述。
通过本申请提供的实施例，在操作指令指示拒绝执行更新操作时，结合预设延迟步长实现对数据更新提醒的灵活动态控制，保证数据更新提醒的灵活性。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如 ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。
实施例2
根据本发明实施例，还提供了一种用于实施上述数据更新提醒方法的数据更新提醒装置，如图4所示，该装置包括：
1)接收单元402，用于接收使用第一账号登录的客户端发送的数据更新请求，其中，数据更新请求用于请求对客户端当前所使用的第一版本进行更新；
2)第一判断单元404，用于判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；
3)提醒单元406，用于在判断出接收时间满足等待时间间隔条件时，向客户端发送更新提醒信息，其中，更新提醒信息用于提醒客户端将当前所使用的第一版本更新为服务器记录的第二版本，其中，第二版本的发布时间晚于第一版本的发布时间。
可选地，在本实施例中，上述数据更新提醒装置可以但不限于应用于不同的终端应用中或第三方应用分发平台中，其中，上述终端应用可以包括但不限于：即时通讯应用、游戏应用、视频播放应用等等。上述第三方应用分发平台可以包括但不限于：应用商城、应用助手等等。这里第三方应用分发平台中可以但不限于用于管理上述不同的终端应用。也就是说，上述仅是一种示例，可以用于提醒更新终端进行应用版本数据更新的执行实体均适用上述数据更新提醒方法，本实施例中对此不做任何限定。
需要说明的是，在本实施例中，在接收到数据更新请求后，通过判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，以实现根据服务器配置的等待时间间隔条件动态控制对客户端的数据更新提醒，而不再由固化在客户端中的数据更新提醒控制方式进行固定的数据更新提醒，以克服相关技术中数据更新提醒的效率较低的问题，进而实现提高数据更新提醒的效率的效果，并达到减少对用户干扰的目的。此外，在本实施例中，服务器预配置的等待时间间隔条件还可以根据不同需求实时调整更新，以达到对数据更新提醒的灵活控制，保证数据更新提醒的灵活性。进一步，在数据更新提醒效率提高的情况下，将更有利于客户端版本的及时统一更新，避免不同用户采用不同客户端本本所造成的版本碎片化的问题。再者，本实施例中提供的灵活高效的数据更新提醒方法，还将为在户外适用客户端的用户账号节省移动流量、电池消耗，以达到节省资源成本的目的。
可选地，在本实施例中，上述服务器预配置的等待时间间隔条件可以但不限于存储在服务器预配置的配置表的配置项中。也就是说，通过灵活配置在服务器的配置表的配置项中存储的上述等待时间间隔条件，实现对是否向客户端发送用于提醒客户端进行版本更新的更新提醒信息的动态控制。其中，上述配置项的配置方式可以包括但不限于以下至少之一：自定义配置、默认配置。上述仅是一种示例，本实施例中对此不做任何限定。
需要说明的是，在本实施例中，上述服务器预配置的配置表的配置项中可以包括但不限于：数据更新请求中携带的请求标识、等待时间间隔条件所指示的等待时间间隔、在接收到数据更新请求之前上一次发送更新提醒信息的第一时间及三者之间的映射关系。其中，上述请求标识可以包括但不限于以下至少之一：第一账号、客户端所在终端的终端标识。这里，上述终端标识可以但不限于为通用唯一标识码(Universally UniqueIdentifier，UUID)。例如，如表2所示为一种可选的服务器预配置的配置表，其中，等待时间间隔以天为单位。
表2
Figure BDA0001062999670000171
也就是说，在本实施例中，上述服务器可以但不限于利用上述配置表来判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，其中，第一判断单元404具体可以包括：
(1)第一获取模块，用于获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔；
(2)判断模块，用于判断接收时间与第一时间的差值是否大于等于等待时间间隔，其中，第一时间用于标识在接收到数据更新请求之前上一次发送更新提醒信息的时间；在接收时间与第一时间的差值大于等待时间间隔时，则判断出满足服务器预配置的等待时间间隔条件。
例如，以接收到第一账号“张三”使用终端“deviceUUID1”登录客户端发送的数据更新请求为例，如表2所示，根据请求标识(即第一账号“张三”与终端“deviceUUID1”)获取到配置表中对应的配置项(序号1) 中的等待时间间隔为3天，此外，从该配置项(序号1)还获取到上次发送更新提醒信息的第一时间为时间戳“1463970955”，进一步，假设接收时间为T，则判断接收时间T与第一时间(时间戳“1463970955”)的差值是否大于上述等待时间间隔3天，假设上述差值大于上述等待时间间隔，则可判断出接收到数据更新请求的接收时间T满足服务器预配置的等待时间间隔条件，进而执行向客户端发送更新提醒信息。
可选地，在本实施例中，在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，还包括：在配置表中查找与数据更新请求中携带的请求标识匹配的配置项；在查找到配置项时，获取配置项中与请求标识匹配的等待时间间隔及第一时间；在未查找到配置项时，在配置表中创建与请求标识匹配的配置项。
需要说明的是，在本实施例中，为了节省存储空间，在服务器预配置的配置表中对于与已执行的更新操作对应的配置项可以但不限于执行删除处理，对于与还未执行的更新操作对应的配置项可以但不限于执行保存处理。也就是说，在上述服务器预配置的配置表中，与数据更新请求中携带的请求标识匹配的配置项可以但不限于仍然保存在配置表中，即，对应的更新操作还未被执行；也可以但不限于已从配置表中删除，即，对应的更新操作已被执行，需重新创建与数据更新请求的请求标识匹配的配置项。
这里，对于首次创建的配置项可以包括但不限于：请求标识、等待时间间隔，其中，上述等待时间间隔可以但不限于为默认时间间隔，如 global_interval_day。也就是说，对于首次创建的配置项中不包括上一次发送更新提醒信息的第一时间。
可选地，在本实施例中，还包括：1)第二判断单元，用于在判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件之前，判断服务器中是否记录有第二版本；2)第二获取单元，用于在判断出服务器记录有第二版本时，获取数据更新请求的接收时间。
也就是说，在判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件之前，判断服务器是否存储有相对于第一版本发布时间更晚的最新版本(即第二版本)，并在判断出服务器记录有第二版本时，再获取接收到数据更新请求的接收时间。从而实现提高数据更新提醒的有效性，以避免在第一版本已是最新版本的情况下，执行数据更新提醒过程。
需要说明的是，在本实施例中，在查找服务器是否记录有第二版本时，可以但不限于查找应用版本号。也就是说，通过比对数据客户端当前使用的第一版本的版本号与服务器记录的版本号，来确定服务器记录的是否为比第一版本发布时间更晚的第二版本，以达到提高服务器的查找效率的目的。
可选地，在本实施例中，上述装置还包括：1)第一更新单元，用于在向客户端发送更新提醒信息时，更新配置表的配置项中记录的第一时间。也就是说，在向客户端发送更新提醒信息的同时，利用当前的发送时间更新服务器配置表的配置项中的第一时间，即，将当前发送更新提醒信息的发送时间作为下一次发送更新提醒信息的第一时间。以表2为例，在向客户端发送更新提醒信息时，利用发送时间更新与请求标识对应的第一时间(lastAlertTime)中的取值。
可选地，在本实施例中，在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，还包括：更新配置表中记录的等待时间间隔条件。其中，更新配置表中记录的等待时间间隔条件可以包括但不限于以下至少之一：
1)接收配置请求；根据配置请求更新配置表中记录的等待时间间隔条件所指示的等待时间间隔；
2)接收客户端发送的操作指令，其中，操作指令用于指示客户端是否允许执行将第一版本更新为第二版本的更新操作；根据操作指令更新配置表中记录的等待时间间隔条件所指示的等待时间间隔。
也就是说，在方式1)中，可以但不限于根据配置请求所请求的等待时间间隔，对服务器配置表的配置项中的等待时间间隔进行更新，如自定义配置等。在方式2)中，可以但不限于根据客户端发送的操作指令，来确定是否更新配置表中记录的等待时间间隔。其中，在操作指令指示允许执行更新操作时，删除与更新操作对应的等待时间间隔所在的配置项；在操作指令指示拒绝执行更新操作时，更新与更新操作对应的等待时间间隔，其中，更新后的等待时间间隔根据预设延迟步长确定。
具体结合以下示例进行说明，如图3所示步骤S302-S310，终端302 上使用第一账号ID-1登录的应用客户端App- 1向服务器304发送用于更新当前所使用的第一版本V1.0的数据更新请求，服务器304在接收到上述数据更新请求后，比对第一版本V1.0与服务器304记录的最新版本，若二者版本一致，则退出流程；若服务器304记录的最新版本为发布时间晚于第一版本V1.0的第二版本V2.0，则判断出需要执行更新操作，在服务器预配置的配置表中查找与上述数据更新请求中携带的请求标识匹配的配置项，若查找到该配置项，则判断接收到数据更新请求的接收时间是否满足配置项中的等待时间间隔条件，在判断出满足等待时间间隔条件时，向终端302上的客户端发送更新提醒信息。
通过本申请提供的实施例，在接收到数据更新请求后，通过判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，以实现根据服务器配置的等待时间间隔条件动态控制对客户端的数据更新提醒，而不再由固化在客户端中的数据更新提醒控制方式进行固定的数据更新提醒，以克服相关技术中数据更新提醒的效率较低的问题，进而实现提高数据更新提醒的效率的效果，并达到减少对用户干扰的目的。
作为一种可选的方案，第一判断单元404包括：
1)第一获取模块，用于获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔；
2)判断模块，用于判断接收时间与第一时间的差值是否大于等于等待时间间隔，其中，第一时间用于标识在接收到数据更新请求之前上一次发送更新提醒信息的时间；在接收时间与第一时间的差值大于等待时间间隔时，则判断出满足服务器预配置的等待时间间隔条件。
具体结合表2所示进行说明，以接收到第一账号“张三”使用终端“deviceUUID1”登录客户端发送的数据更新请求为例，如表2所示，根据请求标识(即第一账号“张三”与终端“deviceUUID1”)获取到配置表中对应的配置项(序号1)中的等待时间间隔为3天，此外，从该配置项 (序号 1)还获取到上次发送更新提醒信息的第一时间为时间戳“1463970955”，进一步，假设接收时间为T，则判断接收时间T与第一时间(时间戳“1463970955”)的差值是否大于上述等待时间间隔3天，假设上述差值大于上述等待时间间隔，则可判断出接收到数据更新请求的接收时间T满足服务器预配置的等待时间间隔条件，进而执行向客户端发送更新提醒信息。
又例如，假设又以接收到第一账号“张三”使用终端“deviceUUID3”登录客户端发送的数据更新请求为例(即相同账号在不同终端登录该客户端)，如表2所示，根据请求标识(即第一账号“张三”与终端“deviceUUID3”) 获取到配置表中对应的配置项(序号3)中的等待时间间隔为4天，假设接收时间为T，且接收时间T与第一时间(时间戳“1463912584”)的差值小于上述等待时间间隔4天，则可判断出接收到数据更新请求的接收时间T不满足服务器预配置的等待时间间隔条件，则暂不向客户端发送更新提醒信息。
通过本申请提供的实施例，在获取接收到数据更新请求的接收时间与上一次发送更新提醒信息的第一时间的差值后，通过比对上述差值与服务器预配置的配置表中记录的等待时间间隔，从而实现利用在服务器灵活配置的等待时间间隔对客户端的数据更新提醒的动态控制，以减少相关技术中需要多次弹框提示更新客户端版本对用户所造成的干扰，进而改善用户体验；进一步，在保证数据更新提醒信息不被频繁关闭的情况下，还将达到提高更新提醒信息的关注度的目的，进而实现提高数据更新提醒的效率的效果。
作为一种可选的方案，还包括：
1)查找单元，用于在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，在配置表中查找与数据更新请求中携带的请求标识匹配的配置项，其中，配置项用于存储请求标识、等待时间间隔及第一时间三者之间的映射关系，请求标识包括以下至少之一：第一账号、客户端所在终端的终端标识；
2)第一获取单元，用于在查找到配置项时，获取配置项中与请求标识匹配的等待时间间隔及第一时间；
3)创建单元，用于在未查找到配置项时，在配置表中创建与请求标识匹配的配置项。
具体结合表2所示，在配置表的一条配置项中可以包括但不限于：请求标识(如登录客户端的第一账号(username)、登录时所在终端的终端标识(deviceUUID))、上一次使用该请求标识发送更新提醒信息的第一时间 (lastAlertTime)、等待时间间隔(nextAlertInterval)。
需要说明的是，在本实施例中，为了节省存储空间，在服务器预配置的配置表中对于与已执行的更新操作对应的配置项可以但不限于执行删除处理，对于与还未执行的更新操作对应的配置项可以但不限于执行保存处理。也就是说，在接收到客户端发送的数据更新请求后，在上述服务器预配置的配置表中，与上述数据更新请求中携带的请求标识匹配的配置项可以但不限于仍然保存在配置表中，即，对应的更新操作还未被执行(如一直接收到客户端发送的拒绝执行更新操作的操作指令)；也可以但不限于已从配置表中删除，即，对应的更新操作已被执行(如接收到客户端发送的执行更新操作的操作指令)，在这种情况下，则需重新创建与数据更新请求的请求标识匹配的配置项。
通过本申请提供的实施例，在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，判断是否可以在服务器预配置的配置表中查找到对应的配置项。也就是说，在本实施例中，为了节省存储空间，在有限的存储空间中存储还未执行的更新操作对应的配置项，以达到提高配置表中配置项的利用率的目的。
作为一种可选的方案，还包括：
1)第二更新单元，用于在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，更新配置表中记录的等待时间间隔条件。
可选地，在本实施例中，第二更新单元可以包括但不限于以下至少之一：
1)作为一种可选的实施方式，第二更新单元包括：
(1)第一接收模块，用于接收配置请求；
(2)第一更新模块，用于根据配置请求更新配置表中记录的等待时间间隔条件所指示的等待时间间隔。
也就是说，在本实施例中，可以但不限于根据配置请求所请求配置的等待时间间隔，对服务器配置表的配置项中的等待时间间隔进行更新，如根据需求进行自定义配置等。例如，为了在预定周期内消除客户端版本碎片化的问题，则在该预定周期内可对该客户端进行高频率更新提醒，如自定义配置等待时间间隔，将默认时间配置1周更新调整为1天。
通过本申请提供的实施例，根据接收到的配置请求所请求配置的等待时间间隔实现对配置项中的等待时间间隔的动态更新调整。
2)作为另一种可选的实施方式，第二更新单元包括：
(1)第二接收模块，用于接收客户端发送的操作指令，其中，操作指令用于指示客户端是否允许执行将第一版本更新为第二版本的更新操作；
(2)第二更新模块，用于根据操作指令更新配置表中记录的等待时间间隔条件所指示的等待时间间隔。
可选地，在本实施例中，第二更新模块通过以下步骤实现根据操作指令更新配置表中记录的等待时间间隔条件所指示的等待时间间隔：
S1，在操作指令指示允许执行更新操作时，删除与更新操作对应的等待时间间隔所在的配置项；
S2，在操作指令指示拒绝执行更新操作时，更新与更新操作对应的等待时间间隔，其中，更新后的等待时间间隔根据预设延迟步长确定。
也就是说，在本实施例中，可以但不限于结合客户端发送的操作指令，来确定是否更新配置表中记录的等待时间间隔，其中，上述操作指令可以但不限于在客户端接收到更新提醒信息后，客户端根据接收到的用于指示是否允许执行更新操作的指示操作所生成的操作指令。例如，客户端在接收到更新提醒信息后，将弹框显示该更新提醒信息，进一步，若客户端获取到允许执行更新操作的指示操作，则向服务器发送操作指令，该操作指令用于指示删除与该更新操作对应的配置项；若客户端获取到拒绝执行更新操作的指示操作，则向服务器发送操作指令，该操作指令用于指示更新与该更新操作对应的配置项。
需要说明的是，在本实施例中，上述预设延迟步长可以但不限于根据不同场景设置为不同取值，例如，在判断出第一账号在户外使用客户端时，可以但不限于预设延迟步长配置为A，在判断出第一账号在室内使用客户端时，可以但不限于预设延迟步长配置为B，其中，A>B。上述仅是一种示例，本实施例中对此不做任何限定。
通过本申请提供的实施例，结合从客户端接收到的操作指令，实现对配置项中的等待时间间隔的动态更新调整，以使调整后的等待时间间隔更加符合用户需求，更有利于解决客户端碎片化的问题。
作为一种可选的方案，第二更新模块通过以下步骤实现更新与更新操作对应的等待时间间隔包括：
Ti+1＝Ti+S (2)
其中，Ti+1用于表示第i+1次发送更新提醒信息前的等待时间间隔，Ti用于表示第i次发送更新提醒信息前的等待时间间隔，S用于表示预设延迟步长，i为大于等于1的整数，在i＝1时，T1为默认时间间隔。
需要说明的是，在本实施例中，在i＝1时，初始值T1可以但不限于为默认时间间隔，如global_interval_day。从第2次(T2)起开始，第i+1次发送更新提醒信息前的等待时间间隔(即nextAlertInterval)，等于上一次 (即第i次)发送更新提醒信息前的等待时间间隔与预设延迟步长Step二者之间的和，即nextAlertInterval＝nextAlertInterval+Step。
例如，假设上一次(即第i次)发送更新提醒信息前的等待时间间隔为3，预设延迟步长Step为1，且接收到操作指令指示拒绝执行更新操作时，则第i+1次发送更新提醒信息前的等待时间间隔为3+1＝4，进一步，若仍接收到操作指令指示拒绝执行更新操作，则第i+2次发送更新提醒信息前的等待时间间隔将为4+1＝5。依次类推，本事示例在此不再赘述。
通过本申请提供的实施例，在操作指令指示拒绝执行更新操作时，结合预设延迟步长实现对数据更新提醒的灵活动态控制，保证数据更新提醒的灵活性。
实施例3
本发明实施例的应用环境可以但不限于参照实施例1中的应用环境，本实施例中对此不再赘述。本发明实施例提供了用于实施上述数据更新提醒方法的一种可选的具体应用示例。
作为一种可选的实施例，假设上述数据更新提醒方法可以但不限于应用于终端上安装的应用App-1中，具体过程可以结合图5所示示例进行说明：
在终端上启动应用App-1时，向服务器发起数据更新请求，服务器通过应用App-1当前所使用的第一版本(如版本号为V1.0的版本)对比判断服务器中是否记录有新版本(如发布时间较晚版本号为2.0的版本)，如果没有，则退出流程；反之根据接收到的数据更新请求的请求标识(如 userName+deviceUUID)查找是否存在与该请求标识匹配的配置项，如果存在，则计算接收到数据更新请求的接收时间与配置项中记录的上一次发送更新提醒信息的第一时间(即lastAlertTime)时间差，并比较上述时间差与配置项中记录的等待时间间隔(即nextAlertInterval)，若上述时间差大于等待时间间隔(即nextAlertInterval)，则表示自上一次发送更新提醒后，已经过去了等待时间间隔(即nextAlertInterval)，可以再次下发更新提醒信息，反之，小于等待时间间隔(即nextAlertInterval)，则表示没达到发送更新提醒信息的最小时间间隔(即等待时间间隔)要求；如果未查找到该配置项，则新建一条与请求标识匹配的配置项，并且以默认时间间隔(即global_interval_day)作为等待时间间隔(nextAlertInterval)，并下发更新提醒信息；
若终端收到了更新提醒信息，则会弹框提示检测到新版本更新，如果接收到允许执行更新操作的操作指令，则删除对应的配置项，同时引导客户端将该应用客户端的版本更新为版本号2.0的版本；如果接收到拒绝执行更新操作的操作指令，例如“暂不更新”或“取消更新”，则服务器会调整更新配置项等待时间间隔(nextAlertInterval)，并加上预设延迟步长 global_step_day，即nextAlertInterval＝nextAlertInterval+global_step_day。
在本实施例中，在接收到数据更新请求后，通过判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件，以实现根据服务器配置的等待时间间隔条件动态控制对客户端的数据更新提醒，而不再由固化在客户端中的数据更新提醒控制方式进行固定的数据更新提醒，以克服相关技术中数据更新提醒的效率较低的问题，进而实现提高数据更新提醒的效率的效果，并达到减少对用户干扰的目的。
实施例4
根据本发明实施例，还提供了一种用于实施上述数据更新提醒方法的数据更新提醒服务器，如图6所示，该服务器包括：
1)通讯接口602，设置为接收使用第一账号登录的客户端发送的数据更新请求，其中，数据更新请求用于请求对客户端当前所使用的第一版本进行更新；
还设置为在处理器604判断出接收时间满足等待时间间隔条件时，向客户端发送更新提醒信息，其中，更新提醒信息用于提醒客户端将当前所使用的第一版本更新为服务器记录的第二版本，其中，第二版本的发布时间晚于第一版本的发布时间；
2)处理器604，与通讯接口602连接，设置为判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；
3)存储器606，与通讯接口602及处理器604连接，设置为存储第二版本及更新提醒信息。
可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。
实施例5
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以位于网络中的多个网络设备中的至少一个网络设备。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：
S1，接收使用第一账号登录的客户端发送的数据更新请求，其中，数据更新请求用于请求对客户端当前所使用的第一版本进行更新；
S2，判断接收到数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；
S3，在判断出接收时间满足等待时间间隔条件时，向客户端发送更新提醒信息，其中，更新提醒信息用于提醒客户端将当前所使用的第一版本更新为服务器记录的第二版本，其中，第二版本的发布时间晚于第一版本的发布时间。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
S1，获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔；
S2，获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔；
S3，在接收时间与第一时间的差值大于等待时间间隔时，则判断出满足服务器预配置的等待时间间隔条件。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，在配置表中查找与数据更新请求中携带的请求标识匹配的配置项，其中，配置项用于存储请求标识、等待时间间隔及第一时间三者之间的映射关系，请求标识包括以下至少之一：第一账号、客户端所在终端的终端标识；在查找到配置项时，获取配置项中与请求标识匹配的等待时间间隔及第一时间；在未查找到配置项时，在配置表中创建与请求标识匹配的配置项。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在向客户端发送更新提醒信息时，更新配置表的配置项中记录的第一时间。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在获取服务器预配置的配置表中记录的等待时间间隔条件所指示的等待时间间隔之前，更新配置表中记录的等待时间间隔条件。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (23)

1.一种数据更新提醒方法，其特征在于，包括：
接收使用第一账号登录的客户端发送的数据更新请求，其中，所述数据更新请求用于请求对所述客户端当前所使用的第一版本进行更新；
判断接收到所述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；以根据所述等待时间间隔条件动态控制对所述客户端的数据更新提醒；所述服务器预配置的等待时间间隔条件存储在服务器预配置的配置表的配置项中，所述服务器预配置的配置表的配置项中包括：数据更新请求中携带的请求标识、等待时间间隔条件所指示的等待时间间隔、在接收到数据更新请求之前上一次发送更新提醒信息的第一时间及三者之间的映射关系；
在判断出所述接收时间满足所述等待时间间隔条件时，向所述客户端发送更新提醒信息，其中，所述更新提醒信息用于提醒所述客户端将当前所使用的所述第一版本更新为所述服务器记录的第二版本，其中，所述第二版本的发布时间晚于所述第一版本的发布时间。
2.根据权利要求1所述的方法，其特征在于，所述判断接收到所述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件包括：
获取所述服务器预配置的配置表中记录的所述等待时间间隔条件所指示的等待时间间隔；
判断所述接收时间与第一时间的差值是否大于等于所述等待时间间隔，其中，所述第一时间用于标识在接收到所述数据更新请求之前上一次发送所述更新提醒信息的时间；
在所述接收时间与所述第一时间的差值大于所述等待时间间隔时，则判断出满足所述服务器预配置的所述等待时间间隔条件。
3.根据权利要求2所述的方法，其特征在于，在所述获取所述服务器预配置的配置表中记录的所述等待时间间隔条件所指示的等待时间间隔之前，还包括：
在所述配置表中查找与所述数据更新请求中携带的请求标识匹配的配置项，其中，所述配置项用于存储所述请求标识、所述等待时间间隔及所述第一时间三者之间的映射关系，所述请求标识包括以下至少之一：所述第一账号、所述客户端所在终端的终端标识；
在查找到所述配置项时，获取所述配置项中与所述请求标识匹配的所述等待时间间隔及所述第一时间；
在未查找到所述配置项时，在所述配置表中创建与所述请求标识匹配的所述配置项。
4.根据权利要求3所述的方法，其特征在于，在向所述客户端发送所述更新提醒信息时，还包括：
更新所述配置表的所述配置项中记录的所述第一时间。
5.根据权利要求2所述的方法，其特征在于，在所述获取所述服务器预配置的配置表中记录的所述等待时间间隔条件所指示的等待时间间隔之前，还包括：
更新所述配置表中记录的所述等待时间间隔条件。
6.根据权利要求5所述的方法，其特征在于，所述更新所述配置表中记录的所述等待时间间隔条件包括：
接收配置请求；
根据所述配置请求更新所述配置表中记录的所述等待时间间隔条件所指示的所述等待时间间隔。
7.根据权利要求5所述的方法，其特征在于，所述更新所述配置表中记录的所述等待时间间隔条件包括：
接收所述客户端发送的操作指令，其中，所述操作指令用于指示所述客户端是否允许执行将所述第一版本更新为所述第二版本的更新操作；
根据所述操作指令更新所述配置表中记录的所述等待时间间隔条件所指示的所述等待时间间隔。
8.根据权利要求7所述的方法，其特征在于，所述根据所述操作指令更新所述配置表中记录的所述等待时间间隔条件所指示的所述等待时间间隔包括：
在所述操作指令指示允许执行所述更新操作时，删除与所述更新操作对应的所述等待时间间隔所在的配置项；
在所述操作指令指示拒绝执行所述更新操作时，更新与所述更新操作对应的所述等待时间间隔，其中，更新后的所述等待时间间隔根据预设延迟步长确定。
9.根据权利要求8所述的方法，其特征在于，所述更新与所述更新操作对应的所述等待时间间隔包括：
Ti+1=Ti+S,
其中，所述Ti+1用于表示第i+1次发送所述更新提醒信息前的所述等待时间间隔，所述Ti用于表示第i次发送所述更新提醒信息前的所述等待时间间隔，所述S用于表示所述预设延迟步长，所述i为大于等于1的整数，在i=1时，T1为默认时间间隔。
10.根据权利要求1所述的方法，其特征在于，在所述判断接收到所述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件之前，还包括：
判断所述服务器中是否记录有所述第二版本；
在判断出所述服务器记录有所述第二版本时，获取所述数据更新请求的所述接收时间。
11.一种数据更新提醒装置，其特征在于，包括：
接收单元，用于接收使用第一账号登录的客户端发送的数据更新请求，其中，所述数据更新请求用于请求对所述客户端当前所使用的第一版本进行更新；
第一判断单元，用于判断接收到所述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件；以根据所述等待时间间隔条件动态控制对所述客户端的数据更新提醒；所述服务器预配置的等待时间间隔条件存储在服务器预配置的配置表的配置项中，所述服务器预配置的配置表的配置项中包括：数据更新请求中携带的请求标识、等待时间间隔条件所指示的等待时间间隔、在接收到数据更新请求之前上一次发送更新提醒信息的第一时间及三者之间的映射关系；
提醒单元，用于在判断出所述接收时间满足所述等待时间间隔条件时，向所述客户端发送更新提醒信息，其中，所述更新提醒信息用于提醒所述客户端将当前所使用的所述第一版本更新为所述服务器记录的第二版本，其中，所述第二版本的发布时间晚于所述第一版本的发布时间。
12.根据权利要求11所述的装置，其特征在于，所述第一判断单元包括：
第一获取模块，用于获取所述服务器预配置的配置表中记录的所述等待时间间隔条件所指示的等待时间间隔；
判断模块，用于判断所述接收时间与第一时间的差值是否大于等于所述等待时间间隔，其中，所述第一时间用于标识在接收到所述数据更新请求之前上一次发送所述更新提醒信息的时间；在所述接收时间与所述第一时间的差值大于所述等待时间间隔时，则判断出满足所述服务器预配置的所述等待时间间隔条件。
13.根据权利要求12所述的装置，其特征在于，该装置还包括：
查找单元，用于在所述获取所述服务器预配置的配置表中记录的所述等待时间间隔条件所指示的等待时间间隔之前，在所述配置表中查找与所述数据更新请求中携带的请求标识匹配的配置项，其中，所述配置项用于存储所述请求标识、所述等待时间间隔及所述第一时间三者之间的映射关系，所述请求标识包括以下至少之一：所述第一账号、所述客户端所在终端的终端标识；
第一获取单元，用于在查找到所述配置项时，获取所述配置项中与所述请求标识匹配的所述等待时间间隔及所述第一时间；
创建单元，用于在未查找到所述配置项时，在所述配置表中创建与所述请求标识匹配的所述配置项。
14.根据权利要求13所述的装置，其特征在于，该装置还包括：
第一更新单元，用于在向所述客户端发送所述更新提醒信息时，更新所述配置表的所述配置项中记录的所述第一时间。
15.根据权利要求12所述的装置，其特征在于，该装置还包括：
第二更新单元，用于在所述获取所述服务器预配置的配置表中记录的所述等待时间间隔条件所指示的等待时间间隔之前，更新所述配置表中记录的所述等待时间间隔条件。
16.根据权利要求15所述的装置，其特征在于，所述第二更新单元包括：
第一接收模块，用于接收配置请求；
第一更新模块，用于根据所述配置请求更新所述配置表中记录的所述等待时间间隔条件所指示的所述等待时间间隔。
17.根据权利要求15所述的装置，其特征在于，所述第二更新单元包括：
第二接收模块，用于接收所述客户端发送的操作指令，其中，所述操作指令用于指示所述客户端是否允许执行将所述第一版本更新为所述第二版本的更新操作；
第二更新模块，用于根据所述操作指令更新所述配置表中记录的所述等待时间间隔条件所指示的所述等待时间间隔。
18.根据权利要求17所述的装置，其特征在于，所述第二更新模块通过以下步骤实现根据所述操作指令更新所述配置表中记录的所述等待时间间隔条件所指示的所述等待时间间隔：
在所述操作指令指示允许执行所述更新操作时，删除与所述更新操作对应的所述等待时间间隔所在的配置项；
在所述操作指令指示拒绝执行所述更新操作时，更新与所述更新操作对应的所述等待时间间隔，其中，更新后的所述等待时间间隔根据预设延迟步长确定。
19.根据权利要求18所述的装置，其特征在于，所述第二更新模块通过以下步骤实现更新与所述更新操作对应的所述等待时间间隔包括：
Ti+1=Ti+S,
其中，所述Ti+1用于表示第i+1次发送所述更新提醒信息前的所述等待时间间隔，所述Ti用于表示第i次发送所述更新提醒信息前的所述等待时间间隔，所述S用于表示所述预设延迟步长，所述i为大于等于1的整数，在i=1时，T1为默认时间间隔。
20.根据权利要求11所述的装置，其特征在于，该装置还包括：
第二判断单元，用于在所述判断接收到所述数据更新请求的接收时间是否满足服务器预配置的等待时间间隔条件之前，判断所述服务器中是否记录有所述第二版本；
第二获取单元，用于在判断出所述服务器记录有所述第二版本时，获取所述数据更新请求的所述接收时间。
21.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一段程序，所述至少一段程序由处理器加载并执行如权利要求1-10任一所述的数据更新提醒方法。
22.一种客户端设备，其特征在于，所述设备包括处理器和存储器，所述存储器中存储有至少一段程序，所述至少一段程序由所述处理器加载并执行以实现如权利要求1至10任一所述的数据更新提醒方法。
23.一种服务器设备，其特征在于，所述设备包括处理器和存储器，所述存储器中存储有至少一段程序，所述至少一段程序由所述处理器加载并执行以实现如权利要求1至10任一所述的数据更新提醒方法。
CN201610612980.XA 2016-07-28 2016-07-28 数据更新提醒方法及装置 Active CN107526581B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610612980.XA CN107526581B (zh) 2016-07-28 2016-07-28 数据更新提醒方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610612980.XA CN107526581B (zh) 2016-07-28 2016-07-28 数据更新提醒方法及装置

Publications (2)

Publication Number Publication Date
CN107526581A CN107526581A (zh) 2017-12-29
CN107526581B true CN107526581B (zh) 2020-01-31

Family

ID=60748489

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610612980.XA Active CN107526581B (zh) 2016-07-28 2016-07-28 数据更新提醒方法及装置

Country Status (1)

Country Link
CN (1) CN107526581B (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108632078B (zh) * 2018-03-13 2021-07-23 网宿科技股份有限公司 一种配置的获取方法
CN113411460A (zh) * 2020-03-16 2021-09-17 富士施乐实业发展（中国）有限公司 一种定制软件的安装方法及装置
CN112260864A (zh) * 2020-10-16 2021-01-22 杭州易和网络有限公司 对设备配置信息的配置方法
CN112737825B (zh) * 2020-12-23 2022-12-02 携程旅游信息技术（上海）有限公司 基于日志的网络设备关联方法、系统、设备及存储介质
CN113079145A (zh) * 2021-03-25 2021-07-06 深圳友讯达科技股份有限公司 一种微功率无线通信单元批量分拣检测方法及装置
CN113398599A (zh) * 2021-07-16 2021-09-17 广州七七游网络科技有限公司 一种游戏文件的更新方法、装置、设备及可读存储介质
CN116257718B (zh) * 2023-05-15 2023-07-14 飞狐信息技术（天津）有限公司 数据更新方法、装置、电子设备及计算机可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102348195A (zh) * 2011-10-13 2012-02-08 中兴通讯股份有限公司 一种无线通信终端及其软件升级方法
CN103686376A (zh) * 2013-12-06 2014-03-26 乐视致新电子科技（天津）有限公司 智能电视的软件升级方法和装置
CN103970550A (zh) * 2013-01-30 2014-08-06 腾讯科技（深圳）有限公司 一种移动终端的软件更新提示方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102348195A (zh) * 2011-10-13 2012-02-08 中兴通讯股份有限公司 一种无线通信终端及其软件升级方法
CN103970550A (zh) * 2013-01-30 2014-08-06 腾讯科技（深圳）有限公司 一种移动终端的软件更新提示方法及装置
CN103686376A (zh) * 2013-12-06 2014-03-26 乐视致新电子科技（天津）有限公司 智能电视的软件升级方法和装置

Also Published As

Publication number Publication date
CN107526581A (zh) 2017-12-29

Similar Documents

Publication Publication Date Title
CN107526581B (zh) 数据更新提醒方法及装置
US9396005B2 (en) Method, apparatus and computer storage medium for plug-in management and control
CN108156268B (zh) 设备标识的获取方法及服务器、终端设备
WO2020057131A1 (zh) 内容分享方法、终端设备及存储介质
US9602656B2 (en) Method, apparatus and system for providing caller identification
US11221743B2 (en) Information processing method, terminal, server, and computer storage medium
US9317417B2 (en) Smart digital message archival
JP6640855B2 (ja) プッシュ情報を削除するための方法、サーバ、及び端末装置
TW200948100A (en) User directed background transfer and data storage
CN104104971A (zh) 一种视频文件处理方法及系统
CN113055451A (zh) 资源下载方法、装置、电子设备及存储介质
US20110010430A1 (en) Systems And Methods For Scheduling And Delivering Messages Based On Recipient's Time Zone
EP2857948A1 (en) Method, device and system for shunting information in graphic code
CN110502256A (zh) 一种软件升级方法、终端及存储介质
CN103763112A (zh) 一种用户身份保护方法和装置
CN106250536B (zh) 一种空间页面背景设置方法、装置及系统
US10938773B2 (en) Method and apparatus for synchronizing contact information and medium
US20170171339A1 (en) Advertisement data transmission method, electrnoic device and system
CN104579665A (zh) 鉴权方法及装置
US11314803B2 (en) Method for image-processing and mobile terminal
CN104796435A (zh) 一种消息推送方法及服务器
WO2019242279A1 (zh) 一种消息处理方法及装置
CN104735643A (zh) 一种信息处理的方法及数据服务器
US20180276719A1 (en) Method and device for determining area of message operation region and electronic device
CN103338315A (zh) 一种信息处理方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20240102

Address after: 518057 Tencent Building, No. 1 High-tech Zone, Nanshan District, Shenzhen City, Guangdong Province, 35 floors

Patentee after: TENCENT TECHNOLOGY (SHENZHEN) Co.,Ltd.

Patentee after: TENCENT CLOUD COMPUTING (BEIJING) Co.,Ltd.

Address before: 2, 518000, East 403 room, SEG science and Technology Park, Zhenxing Road, Shenzhen, Guangdong, Futian District

Patentee before: TENCENT TECHNOLOGY (SHENZHEN) Co.,Ltd.

TR01 Transfer of patent right