CN117114642A - 活动日历提醒的方法和电子设备 - Google Patents

Abstract

本申请提供一种活动日历提醒的方法和电子设备，该方法包括：在电子设备上显示第一应用的目标活动的第一页面；响应于用户对指示是否参与目标活动的第一控件的确认操作，显示第一弹窗；响应于用户对第一弹窗中指示是否创建日历提醒的第二控件的确认操作，启动日历应用，并创建日历提醒事项；日历提醒事项中包括目标活动对应的提醒时间和第一页面的深度链接；在每次到达提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在电子设备上启动第一应用，并基于深度链接再次加载第一页面。该方案通过在创建日历提醒事项的时候深度链接和提醒时间这些参数的自动写入，使得在提醒时间到达时，能够基于这个深度链接自动跳转到第一页面。

Description

活动日历提醒的方法和电子设备

技术领域

本申请涉及电子设备技术领域，尤其涉及一种活动日历提醒的方法和电子设备。

背景技术

日历提醒的使用日益广泛后，出现了新的需求，那就是用户希望看到提醒弹窗之后能够直接通过提醒弹窗打开相应的应用，省去先退出日历应用，再去查找相应应用并打开的繁琐。比如，用户创建了一个联系提醒：“某年某月某日需要打电话给已存号码的小A”，等提醒时间到了，用户可以直接点击日历提醒弹窗中的提示之后，后台就启动了电话应用，且可以加载出拨号页面，甚至可以将小A添加到联系人一栏中。但是，这个日历提醒事项的事项却还是需要用户手动打开日历应用后，手动创建，而且，这个例子中，为了能够自动跳转出拨号页面，和填入联系人为小A，采用的是简单的关键词（文字）提取和填写的方式，并不适用其他复杂情况的日历提醒。

对于各种游戏、购物等应用而言，为了增加互动性会有很多营销活动，比如连续签到、每日必做任务、定时收菜、定时收能量等等，这类营销活动的互动页面是营销活动的商家提供的，为了吸引消费者还往往有复杂的设计和绚丽的画面，这就导致通过简单的关键词提取和填写的方式，只能还是依赖手动打开日历应用并创建的方式来创建出日历提醒事项，且创建出来的日历事项无法实现跳转至相应互动页面的功能。

因此如何更好地对营销活动进行日历提醒是亟待解决的技术问题。

发明内容

本申请提供一种活动日历提醒的方法和电子设备，能够更好地对营销活动进行日历提醒。

第一方面，提供了一种活动日历提醒的方法，该方法包括：在电子设备上显示第一应用的目标活动的第一页面；响应于用户对指示是否参与目标活动的第一控件的确认操作，显示第一弹窗；响应于用户对第一弹窗中指示是否创建日历提醒的第二控件的确认操作，启动日历应用，并创建日历提醒事项；日历提醒事项中包括目标活动对应的提醒时间和第一页面的深度链接；在每次到达提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在电子设备上启动第一应用，并基于深度链接再次加载第一页面。

在本申请技术方案中，主要通过在创建日历提醒事项的时候加入与目标活动的互动页面对应的深度链接，使得在提醒时间到达时，能够基于这个深度链接直接再次加载出互动页面，简化了操作步骤，提升了用户的使用体验。该方案由于创建日历的参数不需要用户手动输入，加上还可以实现自动跳转回活动页面，使得整个过程对用户使用感受更友好。

结合第一方面，在第一方面的某些实现方式中，在响应于用户对第一弹窗中第二控件的第二操作，启动日历应用，并创建日历提醒事项时，可以包括：在创建日历提醒事项之前，通过桥接器（JSbridge）从H5前端服务器接收第一文件，并从第一文件中得到提醒时间和深度链接；在创建日历提醒事项时，将深度链接和提醒时间写入日历提醒事项。在这种实现方式中，通过桥接器从H5前端服务器来接收出包含有创建日历提醒事项需要的参数的文件，从中解析出参数和写入日历提醒事项中，这个执行过程没有用户的手动参与，且是后台执行，过程不需要呈现给用户看到。

结合第一方面，在第一方面的某些实现方式中，上述在创建日历提醒事项之前，通过桥接器从H5前端服务器接收第一文件，并从第一文件中得到提醒时间和深度链接的步骤，可以包括：在第二操作的触发下，向H5前端服务器发送数据请求，并通过H5前端服务器向第一应用的营销中心服务器转发数据请求；该数据请求包括提醒时间和深度链接；提醒时间包括目标活动日期的开始日期和结束日期，以及目标活动日期中每天内的起始时间和结束时间；数据请求还包括以下至少一项：活动标识（ID）和是否参与目标活动的标识；通过JSbridge从H5前端服务器接收第一文件，第一文件是营销中心服务器在接收到数据请求后，根据数据请求发送给H5前端服务器的；第一文件中包括数据请求对应的目标数据，目标数据包括提醒时间和深度链接，目标数据还包括活动ID和/或是否参与目标活动的标识。在这种实现方式中给出了从服务器拿取数据的具体过程。

为了安全性，对于第三方应用如果想要读写电子设备的内部空间的话，是需要给予访问权限才可以的。所以对于第一应用来说，想要往日历应用（电子设备自身的应用，也就是非第三方应用）读写数据，那么还需要日历应用的授权。所以可以在第一应用首次创建日历提醒事项的时候，先获取日历应用的读写权限再创建。而之后的创建，例如第一应用的其他活动，或者用户取消订阅这个目标活动之后又重新参加这个目标活动，都不需要再去申请读写权限。

结合第一方面，在第一方面的某些实现方式中，在响应于用户对第一弹窗中第二控件的第二操作，启动日历应用，并创建日历提醒事项时，可以包括：获取日历应用的读写权限；在获取到日历应用的读写权限并且接收到第一文件后，启动日历应用并创建日历提醒事项。这种实现方式主要针对的是第一应用首次需要访问日历应用的时候，需要先执行获取日历应用的读写权限再创建，而对于非首次访问则不需要执行这个获取读写权限的步骤。

在一个例子中，在获取日历应用的读写权限时，可以包括：在电子设备的屏幕上显示第二弹窗，第二弹窗中包括授权日历应用的读写权限的确认授权控件；响应于用户对确认授权控件的点击操作，得到日历应用的读写权限。这个例子给出了授权方式的示例，基于用户确认同意授权的操作才给第一应用对于日历应用的读写权限，否则就不给。

结合第一方面，在第一方面的某些实现方式中，上述在每次到达提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在电子设备上启动第一应用，并基于深度链接再次加载第一页面的步骤，可以包括：在每次到达提醒时间时，在电子设备上显示第三弹窗，第三弹窗用于提醒用户是否再次参与目标活动；响应于用户对第三弹窗的点击操作，启动第一应用，并基于深度链接加载出第一页面进行显示，对第三弹窗的点击操作即为再次参与目标活动的确认操作。在这种实现方式中，用户只需要一次对弹窗的点击就能跳转到第一页面了，操作步骤少。

在另一种实现方式中，上述在每次到达提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在电子设备上启动第一应用，并基于深度链接再次加载第一页面的步骤，可以包括：在每次到达提醒时间时，在电子设备上显示第四弹窗，第四弹窗用于提醒用户是否再次参与目标活动；响应于用户对第四弹窗的点击操作，启动日历应用，并显示日历提醒事项；响应于用户对日历提醒事项中的深度链接的点击操作，启动第一应用，并加载出第一页面进行显示，对第四弹窗的点击操作和对深度链接的点击操作的组合即为再次参与目标活动的确认操作。在这种实现方式中增加了先给用户呈现日历提醒事项的步骤，是需要两次点击才会跳转的。

在一种实现方式中，上述在每次到达提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在电子设备上启动第一应用，并基于深度链接再次加载第一页面的步骤，可以包括：检测所述电子设备中是否安装有所述第一应用；当检测到所述第一应用已安装时，启动所述第一应用，并基于所述深度链接跳转至所述第一页面；或者，当检测到所述第一应用没有安装时，显示第五弹窗，所述第五弹窗用于指示用户是否安装所述第一应用。在这种实现方式中，增加了对于有没有安装第一应用的判断，这个判断可以防止用户中途卸载了第一应用导致跳转失败，而用户却只看到跳转失败却不知道失败原因是应用被卸载了。

结合第一方面，在第一方面的某些实现方式中，上述方法还包括：响应于用户对第一控件的第三操作，不显示第一弹窗，第三操作用于表示不参与目标活动。此为兜底方案，就是在已经订阅之后还可以取消订阅，但应理解，如果从初始就不订阅，就不存在第三操作，因为系统会默认初始状态为不参与目标活动，所以这种实现方式只会发生在订阅之后想要取消订阅的时候。

结合第一方面，在第一方面的某些实现方式中，上述方法还包括：响应于用户对第二控件的第四操作，不启动日历应用，第四操作用于表示不创建日历提醒事项。也就是说，对于第一弹窗显示之后，出现了第二控件（是否创建日历提醒事项），此时用户可以根据自己的考虑来选择是否创建，如果选择了不创建就不需要执行后续流程了。

结合第一方面，在第一方面的某些实现方式中，第二弹窗中还包括不允许授权日历应用的读写权限的取消授权控件，上述方法还包括：响应于用户对取消授权控件的点击操作，取消日历应用的读写权限的获取。也就是说，假设用户在这个过程中看到还要让第一应用读写电子设备的日历应用，怕带来安全风险，想要终止创建，就可以基于取消操作来执行。

第二方面，提供了一种执行活动日历提醒的装置，该装置包括由软件和/或硬件组成的用于执行第一方面的任意一种方法的单元。

第三方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，当处理器执行计算机程序时使得该电子设备能够实现第一方面的任意一种方法。

第四方面，提供了一种芯片，包括处理器，该处理器用于读取并执行存储在存储器中的计算机程序，当计算机程序被处理器执行时使得该芯片所在的电子设备能够实现第一方面的任意一种方法。

可选地，该芯片还包括存储器，存储器与处理器电连接。

可选地，该芯片还可以包括通信接口。

第五方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当计算机程序被电子设备执行时能够实现第一方面的任意一种方法。

第六方面，提供了一种计算机程序产品，该计算机程序产品包括计算机程序，当计算机程序被电子设备执行时能够实现第一方面的任意一种方法。

附图说明

图1是hybrid app中H5版块的数据交互过程的示意图。

图2是本申请实施例的活动日历提醒的方法的系统交互图。

图3是本申请实施例的一种活动日历提醒的方法的示意性流程图。

图4是本申请实施例的一种活动日历提醒的方法的执行过程的示意图。

图5是一种游戏app加载H5活动页面的执行过程的示意图。

图6是本申请实施例的一种活动日历提醒的方法的示意性流程图。

图7是本申请实施例的一种通过日历提醒进入活动页面的执行过程的示意图。

图8是本申请实施例的一种活动日历提醒的执行过程的示意图。

图9是本申请实施例的创建好的日历提醒事项的结果示意图。

图10是本申请实施例的一种活动日历提醒的装置的示意图。

图11是本申请实施例的一种电子设备的硬件结构示意图。

具体实施方式

下面结合附图对本申请实施例的方案进行介绍。

图1是hybrid app中H5版块的数据交互过程的示意图。如图1所示，在电子设备A中正运行着一个混合开发应用（hybrid application，hybrid app），且显示的页面就是一个营销活动的互动页面，此处以运行的是一个App-1，且正在显示的营销活动是七天连续签到的活动页面。电子设备A可以是手机、平板电脑、笔记本电脑等终端设备。服务器B为第5代超文本标记语言（简称为H5）前端服务器，也就是H5前端服务器。服务器C是营销中心服务器。

在hybrid app运行的时候，hybrid app可以向服务器B发送请求，例如加载H5的请求，接收网页（html）文件、层叠样式表（cascading style sheets，CSS）文件和脚本语言（javascript，JS）文件等文件的请求等。

服务器B会接收、转发、存储上述请求和可以请求的文件，还可以接收、转发、存储桥接器（JSbridge）文件。例如，可以将从电子设备C接收到的请求转发给营销中心服务器，可以向电子设备C转发来自于营销中心服务器的电子设备C所请求到的文件。

服务器C会维护所有hybrid app的数据，对于H5而言，会接收服务器B发起的POST请求，并返回H5活动基本数据，返回的数据可以JSON格式发送。

对于本申请实施例的方案而言，电子设备C会从服务器B接收来自于服务器C的文件，并从中解析出深度链接以及该H5活动的其他基本数据，例如活动周期，活动时间段等，用来写入日历应用，从而在日历应用中创建出能够自动跳转回H5活动页面的日历提醒事项来。下面结合图2进行详细介绍。

图2是本申请实施例的活动日历提醒的方法的系统交互图。如图2所示，电子设备A上的游戏中心app（下文第一应用的一例，也可以是其他应用，例如购物应用，阅读应用，听书应用等）运行后，在活动页面上会预留JSbridge.js文件，这个文件中会存储有活动相关的参数，包括互动名称或活动标识（ID）、活动是否参与的标识（活动开关状态）、活动的起始日期和结束日期、活动期间每天的起始时间和结束时间和这个页面的deeplink。游戏中心app向H5前端服务器发送HTML/CSS/JS格式的这些文件来请求H5活动相关数据的时候，就可以在其中携带上述与创建日历提醒相关的数据（或者理解为创建日历提醒需要的数据）的请求。H5前端服务器在接收到游戏中心app发送的数据请求后会将数据请求转发给营销中心服务器，营销中心服务器在接收到该数据请求后，就返回H5活动基本数据，营销中心服务器发送给H5前端服务器的是JSON格式的文件，在其中携带H5活动基本数据。而H5前端服务器可以将H5活动基本数据转换成HTML/CSS/JS格式的文件，然后返回给游戏中心app。

在创建日历事项阶段，游戏中心app获取到日历app的读写授权，然后向日历app中写入活动名称、起止日期、每天的活动起止时间、deeplink和其他描述，日历app基于这些写入的数据创建好提醒事项。

在提醒阶段，日历app在监控到提醒时间到了的时候显示提醒弹窗。当用户通过提醒弹窗点击了deeplink后，就可以启动游戏中心app，并且在游戏中心app中直接跳转到H5活动页面。

需要说明的是，游戏中心app和日历app都是同一个电子设备（此处以电子设备A为例）中的app，所以它们之间的数据交互是设备内部实现的，不是跨设备的数据交互。

图3是本申请实施例的一种活动日历提醒的方法的示意性流程图。下面对图3所示各个步骤进行介绍。

S301、在电子设备上运行第一应用，并显示第一应用的第一页面，第一页面为目标活动的互动页面。

在本申请实施例中，第一应用是支持H5技术的应用。

还应理解，混合开发应用（hybrid app）相当于是集合了普通应用的开发技术和H5技术开发出来的。在一定程度上可以认为hybrid app是指内部还会集成有H5小程序的应用，而H5小程序就是营销活动（此处的目标活动）的载体。

在一些实现方式中，第一应用可以是hybrid app，第一页面则是H5页面。

S302、响应于用户对第一页面中的第一控件的第一操作，显示第一弹窗。

第一控件用于指示是否参与目标活动，第一操作用于表示参与目标活动，第一弹窗中包括用于指示是否创建日历提醒的第二控件。

第一操作是确认参与目标活动的操作，也就是订阅通知提醒的操作，下文中对第一控件的第三操作则是不参与目标活动的操作，也就是不订阅通知提醒的操作。在实际中，还可以是提供两个控件，分别对应参与和不参与，但相比而言，用悬浮球的点击选中和点击取消选中来实现的情况更常见，所以会更符合用户操作习惯。

在一种实现方式中，上述方法还包括：响应于用户对第一控件的第三操作，不显示第一弹窗，第三操作用于表示不参与目标活动。此为兜底方案，就是在已经订阅之后还可以取消订阅，但应理解，如果从初始就不订阅，就不存在第三操作，因为系统会默认初始状态为不参与目标活动，所以这种实现方式只会发生在订阅之后想要取消订阅的时候。

S303、响应于用户对第一弹窗中第二控件的第二操作，启动日历应用，并创建日历提醒事项。

日历提醒事项中包括目标活动对应的提醒时间和第一页面的深度链接（deeplink）；第二操作用于表示创建日历提醒事项。

提醒时间中的时间是自然时间，可以是时刻，也可以是时间区间。例如可以是日期+时钟时间。

应理解，在本申请实施例中，日历应用的启动是在第二操作的触发下自动启动，不需要用户手动启动日历应用。在创建日历提醒事项的过程中也不需要用户的任何手动输入，日历提醒事项中的参数是直接获取的，例如是通过H5前端服务器从营销中心服务器获取，不需要手动输入。

在一种实现方式中，上述步骤S303可以包括：在创建日历提醒事项之前，通过桥接器（JSbridge）从H5前端服务器接收第一文件，并从第一文件中得到提醒时间和深度链接；在创建日历提醒事项时，将深度链接和提醒时间写入日历提醒事项。在这种实现方式中，通过桥接器从H5前端服务器来接收出包含有创建日历提醒事项需要的参数的文件，从中解析出参数和写入日历提醒事项中，这个执行过程没有用户的手动参与，且是后台执行，过程不需要呈现给用户看到。

在一种实现方式中，上述在创建日历提醒事项之前，通过桥接器JSbridge从H5前端服务器接收第一文件，并从第一文件中得到提醒时间和深度链接的步骤，可以包括：在第二操作的触发下，向H5前端服务器发送数据请求，并通过H5前端服务器向第一应用的营销中心服务器转发数据请求；该数据请求包括提醒时间和深度链接；提醒时间包括目标活动日期的开始日期和结束日期，以及目标活动日期中每天内的起始时间和结束时间；数据请求还包括以下至少一项：活动标识（identification，ID）和是否参与目标活动的标识；通过JSbridge从H5前端服务器接收第一文件，第一文件是营销中心服务器在接收到数据请求后，根据数据请求发送给H5前端服务器的；第一文件中包括数据请求对应的目标数据，目标数据包括提醒时间和深度链接，目标数据还包括活动ID和/或是否参与目标活动的标识。在这种实现方式中给出了从服务器拿取数据的具体过程。

为了安全性，对于第三方应用如果想要读写电子设备的内部空间的话，是需要给予访问权限才可以的。所以对于第一应用来说，想要往日历应用（电子设备自身的应用，也就是非第三方应用）读写数据，那么还需要日历应用的授权。所以可以在第一应用首次创建日历提醒事项的时候，先获取日历应用的读写权限再创建。而之后的创建，例如第一应用的其他活动，或者用户取消订阅这个目标活动之后又重新参加这个目标活动，都不需要再去申请读写权限。

在一种实现方式中，步骤S303可以包括：获取日历应用的读写权限；在获取到日历应用的读写权限并且接收到第一文件后，启动日历应用并创建日历提醒事项。这种实现方式主要针对的是第一应用首次需要访问日历应用的时候，需要先执行获取日历应用的读写权限再创建，而对于非首次访问则不需要执行这个获取读写权限的步骤。

在一个例子中，在获取日历应用的读写权限时，可以包括：在电子设备的屏幕上显示第二弹窗，第二弹窗中包括授权日历应用的读写权限的确认授权控件；响应于用户对确认授权控件的点击操作，得到日历应用的读写权限。这个例子给出了授权方式的示例，基于用户确认同意授权的操作才给第一应用对于日历应用的读写权限，否则就不给。

在另一个例子中，第二弹窗中还包括不允许授权日历应用的读写权限的取消授权控件，上述方法还包括：响应于用户对取消授权控件的点击操作，取消日历应用的读写权限的获取。也就是说，假设用户在这个过程中看到还要让第一应用读写电子设备的日历应用，怕带来安全风险，想要终止创建，就可以基于取消操作来执行。也就是说，假设用户在这个过程中看到还要让第一应用读写电子设备的日历应用，怕带来安全风险，想要终止创建，就可以基于取消操作来执行。

需要说明的是，一个控件可以开和关两个状态复用，分别对应两个功能，例如第一控件。这事因为第一控件的不被选择，也就是关闭状态可以作为一个默认状态存在。但是对于授权权限的时候而言，用户是有明确的允许或不允许的意愿的，为了防止误操作，一般会设为两个控件中每个控件的选中分别对应一个选择。上述例子中就是用了“允许”和“不允许”两个控件分别对应确认授权和取消授权两个选择。但应理解，在实际中也可以用“确认”和“取消”两个控件分别对应授权和不授权。只是“允许”和“不允许”两个控件是目前在电子设备上使用最多的，所以可以采用这种更符合用户历史认知的设置。

在一种实现方式中，上述方法还包括：响应于用户对第二控件的第四操作，不启动日历应用，第四操作用于表示不创建日历提醒事项。也就是说，对于步骤S302执行之后，出现了第二控件（是否创建日历提醒事项），此时用户可以根据自己的考虑来选择是否创建，如果选择了不创建就不需要执行后续流程了。

应理解，第二控件的第二操作和第四操作分别对应创建和不创建，也就是控件的开关状态分别对应两个选择。在实际中也可以是两个第二控件来实现，那么第二操作和第四操作都可以是点击操作，当点击对应创建的第二控件的时候就是创建，当点击对应不创建的第二控件的时候就是不创建。

在另一种实现方式中，第二操作为点击操作，对第二控件的第二操作即为对第二控件的点击操作，对第二控件的点击操作用于表示创建日历提醒事项，上述方法还包括：响应于用户对第一弹窗中的第三控件的点击操作，不创建日历提醒事项。也就是说，对第三控件的点击操作用于表示不创建日历提醒事项。

在一个例子中，第二控件为“确认”，第三控件为“取消”。在另一个例子中，第二控件为“创建”，第三控件为“不创建”。其他情况不再逐一列举。

S304、在每次到达提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在电子设备上启动第一应用，并基于深度链接再次加载第一页面。

也就是说，每次到达提醒时间，就可以指示用户是否要再次参与，如果用户进行了与再次参与相关的操作，就可以自动跳转到第一应用的第一页面了如果不想再次参与，就不会触发跳转。

在一种实现方式中，上述步骤S304可以包括：在每次到达提醒时间时，在电子设备上显示第三弹窗，第三弹窗用于提醒用户是否再次参与目标活动；响应于用户对第三弹窗的点击操作，启动第一应用，并基于深度链接加载出第一页面进行显示，对第三弹窗的点击操作即为再次参与目标活动的确认操作。在这种实现方式中，用户只需要一次对弹窗的点击就能跳转到第一页面了，操作步骤少。

在另一种实现方式中，上述步骤S304可以包括：在每次到达提醒时间时，在电子设备上显示第四弹窗，第四弹窗用于提醒用户是否再次参与目标活动；响应于用户对第四弹窗的点击操作，启动日历应用，并显示日历提醒事项；响应于用户对日历提醒事项中的深度链接的点击操作，启动第一应用，并加载出第一页面进行显示，对第四弹窗的点击操作和对深度链接的点击操作的组合即为再次参与目标活动的确认操作。在这种实现方式中增加了先给用户呈现日历提醒事项的步骤，是需要两次点击才会跳转的。

在一种实现方式中，上述步骤S304可以包括：检测所述电子设备中是否安装有所述第一应用；当检测到所述第一应用已安装时，启动所述第一应用，并基于所述深度链接跳转至所述第一页面；或者，当检测到所述第一应用没有安装时，显示第五弹窗，所述第五弹窗用于指示用户是否安装所述第一应用。在这种实现方式中，增加了对于有没有安装第一应用的判断，这个判断可以防止用户中途卸载了第一应用导致跳转失败，而用户却只看到跳转失败却不知道失败原因是应用被卸载了。

在图3所示方案中，主要通过在创建日历提醒事项的时候加入与目标活动的互动页面对应的深度链接，使得在提醒时间到达时，能够基于这个深度链接直接再次加载出互动页面，简化了操作步骤，提升了用户的使用体验。该方案由于创建日历的参数不需要用户手动输入，加上还可以实现自动跳转回活动页面，使得整个过程对用户使用感受更友好。

需要说明的是，在本申请实施例中，第一应用是支持H5技术的应用。在H5场景中，才出现了可以拿到深度链接的可能，对于非H5技术下的应用，无法拿到深度链接的情况，是无法用本申请实施例的方法来创建能自动跳转的日历提醒的。可以认为H5使得营销活动有了新的载体形式。

以游戏中心app（第一应用的一例）为例，在传统方案中，为了不让用户错过游戏中心app某一营销类的H5活动，用户需要主动去日历app中新建日历提醒事项，在日历app中手动输入活动提醒的时间和参加的内容，在日历提醒时间点到后，还需要找到游戏中心app点击打开后再找到H5活动页面再进入目标活动页面。

而利用本申请实施例的方案，则只需要用户执行两次对控件的操作就可以创建好日历提醒事项，并且在到了提醒时间的时候，能够基于深度链接直接跳转到H5活动页面，不需要先启动游戏中心app，还要从游戏中心app多次翻找和操作才找到活动页面。

对于传统第三方应用，也就是基于安卓native开发的第三方应用，虽然可以考虑直接在其中集成自动创建日历提醒的功能，但由于这只能在开发初始就植入该功能，也就是需要跟第三方应用的开发同步加入，而且，一旦第三方应用的版本更新之后，该功能也需要应用的厂商在开发过程中同步更新，这给第三方应用的厂商带来了很高的研发成本和拉长了版本更新的时间，最重要的是，如果有很多个营销活动，就得给每个营销活动都要设计独立的自动创建日历提醒的功能，并且，当营销活动发生了增减，这个第三方应用无法同步更新，就得重新出版本，这又会增大成本，所以没有厂商采用这样的方式，这也使得对于纯基于安卓native开发的第三方应用，并没有可以自动跳转到目标页面的日历提醒方案出现。在本申请实施例的方案中，是基于hybrid app出现之后，营销类活动大多以H5技术为载体，方便迭代更新，基于这样的前提，才重新考虑如何实现自动跳转到目标页面的日历提醒，并且最后想到了可以通过从服务器拿取deeplink这些需要的数据来创建日历提醒，实现了更好的日历提醒方案。此外，对于上述可能的假设方案而言，也就是直接在应用中集成每个营销活动的日历提醒的创建功能的方案而言，从用户使用电子设备的角度来说，用户无法自主选择给哪个应用中的哪个活动来创建日历提醒，只能被动的对于个别有自动创建日历提醒功能的第三方应用来选择接受还是拒绝创建，且依然无法跳转到目标页面，最多只能自动启动目标应用，难以满足用户期望。而与之不同的是，本申请实施例的方案是基于H5的活动，能够自动跳转到目标页面，而且，即使应用的版本更新了，这个H5活动的日历提醒依然有效，不会因为版本更新了就无法跳转到相应页面，更加灵活。此外，本申请方案是对于所有H5活动都通用的方案，通用性也相对更高。

图4是本申请实施例的一种活动日历提醒的方法的执行过程的示意图。图4是以游戏app中的连续签到活动为例，但应理解，在实际中其他营销活动都可以作为本申请的目标活动，例如定时收菜、定时收能量、每日必做任务等。第一应用也不是只可以是游戏app，还可以是购物、聊天、阅读等其他应用，不存在限定。

S401、H5端内加载，H5创建DOM节点并挂载JSbridge到DOM节点上。

H5在端内加载是指在电子设备上加载，创建节点也是电子设备上的操作，创建节点是为了后续步骤的执行和使用JSbridge。

还应理解，在用户点击日历提醒开关之前还会有启动并运行游戏app的操作，以及用户在游戏app中找到营销活动的H5活动页的步骤。游戏app会向H5前端服务器请求H5活动页的HTML/CSS/JS文件，游戏app会渲染H5页面。页面加载的过程如图5所示。

图5是一种游戏app加载H5活动页面的执行过程的示意图。

S501、游戏app向H5前端服务器发送请求，请求H5活动的资源文件。

S502、初始化浏览器（init webview）。

S503、webview的JSbridge注入方法读取字段提供给H5调用。

读取字段可以用函数readSchedule（）实现。

S504、HTML/CSS/JS页面渲染。

S505、H5向营销中心服务器请求活动所需基本数据。

此处的请求可以是getPOST请求来实现，基本数据为图片、文案等元素。

S506、页面加载完成。

应理解，图5是H5活动页面的加载过程的示意图。而本申请的方案并没有改变这个执行流程，只是在请求数据的时候增加了对于提醒时间和deeplink这些创建日历需要的数据的请求，以达到创建出更好的日历提醒的目的，是易于实现且不会对其他进程造成影响的方案。

S402、用户点击日历提醒开关。

此处是指电子设备通过传感设备采集用户的操作，可以是用户在电子设备的触摸屏幕上日历提醒开关对应的控件进行了点击，然后电子设备采集到了对这个控件的点击操作。

S403、H5页面弹窗提示“是否开启游戏中心天天签到活动日历通知提醒”。

应理解，此处的弹窗是H5本身绘制的弹窗，不是电子设备的本地系统绘制的。此处的弹窗可以看成是第一弹窗的一个示例。“是否开启游戏中心天天签到活动日历通知提醒”所对应的控件就是第一控件的一个示例。

在首次提醒的时候，会弹窗请求用户授权允许访问日历app，此处的允许访问是允许对日历app进行读写。

S404、 H5向营销服务端请求活动提醒的字段、活动ID、活动时间、当前活动开关状态和deeplink。

用户点击了H5页面弹窗中的确认控件之后，H5就会向营销服务端（营销服务器）请求创建日历提醒需要的数据，请求是通过H5前端服务器转发的。

可以看出，此处可以是随着图5所示过程中的步骤S505的请求的执行一起执行，相当于在请求基本数据的时候还会请求创建日历提醒需要数据。但应理解，也可以是两次请求是分开发送的，并不会影响本申请方案的执行效果。

S405、H5使用JSsbridge桥接方法，将向营销服务端请求的活动提醒的字段、活动ID、活动时间、当前活动开关状态和deeplink传给游戏app端侧。

在请求到数据后，会通过H5调用注入到Jssbridge上的方法readSchedule（），将S404请求到的字段传参到readSchedule中。

S406、游戏app端侧使用接收到的字段向日历app进行读写，写入成功后将开关状态回调给H5。

游戏app拿到步骤S405中存入readSchedule中的字段后，向日历app申请读写权限。

申请读写权限可以表示为：

<uses-permission android:name="android.permission.READ_CALENDAR" />

<uses-permission android:name="android.permission.WRITE_CALENDAR" />

用户点击了日历app的读写授权的权限弹窗后，点击确认控件，就可以获得读写权限。

之后，游戏app会使用新增CalendarScheduleHelper日程写入帮助类将活动字段写入日历app。

之后，游戏app通过readSchedule方法回调给H5写入日历成功，并且将开关状态也回调给H5。

S407、H5收到开关状态后将开关按钮置灰，并toast轻提示“日历提醒订阅成功”。

toast轻提示在到了预设时间后就会消失，能够在达到让用户获知了消息的同时不过久占用显示资源。

S408、用户点击日历日程链接，跳转到H5活动的日历提醒事项的页面。

当到达提醒时间，例如到了某一时间段，如早上9:00-10:00，电子设备通知栏提醒用户参加活动。此处的通知栏即为第四弹窗的示例。用户点击通知栏进入到日程页面。也就是说，点击日历日程链接就是再次参与目标活动的确认操作的一例。

S409、用户点击日历日程https链接中转链接，跳转到H5活动的日历中转页。

https链接中转链接即为上述deeplink链接。

S410、H5根据活动中转页的指示加载H5活动页。

可以通过图5所示过程加载。

S411、进入端内H5活动页。

也就是在电子设备上显示H5活动页面。

图6是本申请实施例的一种活动日历提醒的方法的示意性流程图。图6可以看成是步骤S302-S304的一个示例。

S601、用户点击第一应用的H5活动页面的日历提醒开关。

日历提醒开关也就是第一控件的一例，是指是否有创建日历提醒的需求。

S602、H5弹窗提醒用户是否确认需要开启日历提醒通知。

此处的确认则是在用户确认参与活动之后，知道有提醒需求之后，确认用户确实想要创建日历提醒。此处的弹窗即为第一弹窗的一例。

在第一弹窗首次出现时，还可以请求日历app的读写权限的授权，这样当这个游戏app中其他H5活动后续有提醒需求再出现第一弹窗的时候就不需要重复授权了。

S603、用户在每天的指定时间段内都会受到日历的通知栏提醒。

此处的通知栏即为第二弹窗的一例。

S604、用户点击日历提醒事项中的深度链接跳转到第一应用的该H5活动页面。

图7是本申请实施例的一种通过日历提醒进入活动页面的执行过程的示意图。图7可以看成是步骤S304的一个示例。

S701、用户点击日历提醒事项中的deeplink。

S702、跳转到日历中转页。

S703、在日历中转页判断deeplink对应的app是否已经安装在电子设备上，当判断结果为是，转为执行步骤S704，当判断结果为否，转为执行步骤S705。

S704、跳转到对应app的H5活动页。

S705、在日历中转页中提示用户安装对应app。

图8是本申请实施例的一种活动日历提醒的执行过程的示意图。图8可以看成是图3所示方法的一个示例。

如图8所示，界面801为一个app的H5活动页面（第一页面的一个示例）的显示。此处以签到活动为例。界面801中包括签到结果的显示，以及是否订阅活动的指示“签到提醒订阅通知”的控件A（第一控件的一个示例）。假设用户在界面801中点击了控件A就会出现一个弹窗B（第一弹窗的一个示例），在弹窗B中指示用户是否开启提醒，如界面802所示。假设用户在界面802中点击了“取消”控件，就是不创建日历提醒，结束流程，继续显示界面801所示状态。假设用户在界面802中点击了“确认”控件，就是要创建日历提醒，继续流程，如果不是首次在这个app上订阅活动（包括订阅过其他H5活动），就会直接跳转到界面804所示，在界面804中以轻提示的方式告诉用户订阅成功了。在界面804中“签到提醒订阅通知”的控件A呈现被选中的状态，而且日历提醒事项已经创建好了，但应理解，这一系列过程都是系统后台自动完成，不需要用户执行操作。

假设在界面802中点击了“确认”控件后，说明要创建日历提醒了，然后系统检测到这是首次在这个app上订阅活动，那就还需要获取日历应用的读写权限的授权，才能够达到自动创建日历提醒事项的结果。此时就会先跳转到界面803所示，在界面803中包括一个弹窗（第二弹窗的一个示例），指示用户是否允许访问日历app。假设用户在界面803中点击了“允许”（确认授权控件的一例），就可以获取到读写权限了，那么系统后台继续执行本申请方案的相关步骤，然后得到界面804所示的创建成功的提示。假设用户在界面803中点击了“不允许”（不授权控件的一例），就可以获取到读写权限了，那么结束流程，取消创建，得到界面805所示的取消创建的提示，在界面805中控件A不改变状态。

应理解，在本申请实施例的方案中，启动日历应用和创建日历提醒事项都是后台自动完成的，不需要用户手动输入任何参数。提醒时间、提醒事项、deeplink这些都是从服务器直接拿到的数据，不需要用户手动参与。如果是非首次订阅，用户只需要两次点击，也就是界面801中对控件A的点击和在界面802中对“确认”控件的点击，之后直到日历提醒事项创建好都不需要再手动输入了。

当创建好了之后，用户如果想看详情，可以点击日历应用的图标启动日历应用，然后查看创建结果，但如果用户不想看详情也就不需要去验证。

创建好之后，在每天到了提醒时间时，就会显示日历通知栏（第三弹窗或第四弹窗的一例），如界面806所示。在界面806中包括一个日历通知栏，提示用户是否再次参与这个H5活动。

在一种情况下，假设用户点击了界面806通知栏的主干内容部分，说明用户需要参加活动，就可以直接跳转至界面808所示的情况，在界面808中显示的直接就是该app的H5活动页面。在这种情况下，日历通知栏是第三弹窗的一例。点击弹窗就能直接跳转。

在另一种情况下，假设用户点击了界面806通知栏的主干内容部分，会打开日历应用的该日历提醒事项的页面，也就是这个H5活动的中转页，如界面807所示。当用户在界面807中点击了deeplink才会跳转到界面808所示的情况。这种方式增加了日历中转页，也就是界面807所示的界面，只有用户进一步在中转页点击了链接才跳转。

界面806中的日历通知栏中还可以包括取消提醒等选择的控件，方便用户不打开应用的情况下就可以按照意愿操作。

在界面804创建好日历提醒事项之后，假设用户想看看创建结果，就可以打开日历应用，看到图9所示情况。图9是本申请实施例的创建好的日历提醒事项的结果示意图。如图9所示，在界面810中已经包含了日历事项，假设用户在界面810点击日历事项，就可以看到界面811所示的情况。在界面811中包括了活动名称、时间区间、提醒的日期还有deeplink这些参数，而且这些参数都是电子设备从服务器请求来的，不需要用户手动输入，简化了繁琐操作。但应理解，界面810和界面811并不需要必须显示，是用户自主选择下是不是在创建完成后查看，创建过程中并不需要执行界面810和界面811的过程。

上文主要结合附图对本申请实施例的方法进行了介绍。应理解，虽然如上所述的各实施例所涉及的流程图中的各个步骤依次显示，但是这些步骤并不是必然按照图中所示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。下面结合附图对本申请实施例的装置进行介绍。

图10是本申请实施例的一种活动日历提醒的装置的示意图。如图10所示，该装置2000包括处理单元2001和创建单元2002。该装置2000可以是集成在手机、平板电脑、笔记本电脑等电子设备中。

该装置2000能够用于执行上文任意一种活动日历提醒的方法。例如，处理单元2001可用于执行步骤S301、S302和S304，创建单元2002可用于执行步骤S303。又例如，该装置2000还可以用于执行图5至图7所示各个步骤。该装置2000还可以用于执行图3中电子设备A执行的步骤，也就是说，该装置2000可以是集成在图3中的电子设备A中。该装置2000还可以用于执行图4中H5、游戏app和日历app执行的步骤，以及接收用户的操作和进行响应。该装置2000还可以用于执行图8和图9所示过程。

在一种实现方式中，装置2000还可以包括存储单元，用于存储相关数据。该存储单元可以是集成在上述任意一个单元中，也可以是独立于上述所有单元之外的单元。

图11是本申请实施例的一种电子设备的硬件结构的示意图。如图11所示，电子设备900可以包括处理器910，外部存储器接口920，内部存储器921，通用串行总线（universalserial bus，USB）接口930，充电管理模块940，电源管理模块941，电池942，天线1，天线2，移动通信模块950，无线通信模块960，音频模块970，扬声器970A，受话器970B，麦克风970C，耳机接口970D，传感器模块980，按键990，马达991，指示器992，摄像头993，显示屏994，以及用户标识模块（subscriber identification module，SIM）卡接口995等。其中，传感器模块980可以包括压力传感器980A，陀螺仪传感器980B，气压传感980C，磁传感器980D，加速度传感器980E，距离传感器980F，接近光传感器980G，指纹传感器980H，温度传感器980J，触摸传感器980K，环境光传感器980L，骨传导传感器980M等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备900的具体限定。在本申请另一些实施例中，电子设备900可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

示例性地，图11所示的处理器910可以包括一个或多个处理单元，例如：处理器910可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processing unit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是电子设备900的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器910中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器910中的存储器为高速缓冲存储器。该存储器可以保存处理器910刚用过或循环使用的指令或数据。如果处理器910需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器910的等待时间，因而提高了系统的效率。

在一些实施例中，MIPI接口可以被用于连接处理器910与显示屏994，摄像头993等外围器件。MIPI接口包括摄像头串行接口（camera serial interface，CSI），显示屏串行接口（display serial interface，DSI）等。处理器910和显示屏994通过DSI接口通信，实现电子设备900的显示功能。

在一些实施例中，GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。GPIO接口可以用于连接处理器910与摄像头993，显示屏994，无线通信模块960，音频模块970，传感器模块980等。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。

可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备900的结构限定。在本申请另一些实施例中，电子设备900也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

电子设备900通过GPU，显示屏994，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏994和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器910可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏994用于显示图像，视频等。显示屏994包括显示面板。在一些实施例中，电子设备900可以包括1个或N个显示屏994，N为大于1的正整数。

内部存储器921可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器910通过运行存储在内部存储器921的指令，从而执行电子设备900的各种功能应用以及数据处理。内部存储器921可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序（比如声音播放功能，图像播放功能等）等。存储数据区可存储电子设备900使用过程中所创建的数据（比如音频数据，电话本等）等。此外，内部存储器921可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器（universal flash storage，UFS）等。

压力传感器980A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器980A可以设置于显示屏994。压力传感器980A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器980A，电极之间的电容改变。电子设备900根据电容的变化确定压力的强度。当有触摸操作作用于显示屏994，电子设备900根据压力传感器980A检测所述触摸操作强度。电子设备900也可以根据压力传感器980A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如，当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。

触摸传感器980K，也称“触控面板”。触摸传感器980K可以设置于显示屏994，由触摸传感器980K与显示屏994组成触摸屏，也称“触控屏”。触摸传感器980K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏994提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器980K也可以设置于电子设备900的表面，与显示屏994所处的位置不同。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种电子设备，该电子设备包括：一个或多个处理器、存储器以及存储在所述存储器中并可在所述一个或多个处理器上运行的计算机程序，所述一个或多个处理器执行所述计算机程序时使得所述电子设备可实现上述任意方法中的步骤。本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被电子设备执行时可实现上述各个方法实施例中的步骤。

所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/电子设备的任何实体或装置、记录介质、计算机存储器、只读存储器（read-only memory，ROM）、随机存取存储器（random access memory，RAM）、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机程序，当计算机程序被电子设备执行时可实现上述各个方法实施例中的步骤。所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (13)

1.一种活动日历提醒的方法，其特征在于，包括：

在电子设备上运行第一应用，并显示所述第一应用的第一页面，所述第一页面为目标活动的互动页面；

响应于用户对所述第一页面中的第一控件的第一操作，显示第一弹窗；所述第一控件用于指示是否参与目标活动，所述第一操作用于表示参与目标活动，所述第一弹窗中包括用于指示是否创建日历提醒的第二控件；

响应于用户对所述第一弹窗中所述第二控件的第二操作，启动日历应用，并创建日历提醒事项；所述日历提醒事项中包括目标活动对应的提醒时间和所述第一页面的深度链接deeplink；所述第二操作用于表示创建日历提醒事项；

在每次到达所述提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在所述电子设备上启动所述第一应用，并基于所述深度链接再次加载所述第一页面。

2.根据权利要求1所述的方法，其特征在于，所述响应于用户对所述第一弹窗中所述第二控件的第二操作，启动日历应用，并创建日历提醒事项，包括：

在创建所述日历提醒事项之前，通过桥接器JSbridge从H5前端服务器接收第一文件，并从所述第一文件中得到所述提醒时间和所述深度链接；

在创建所述日历提醒事项时，将所述深度链接和所述提醒时间写入所述日历提醒事项。

3.根据权利要求2所述的方法，其特征在于，所述在创建所述日历提醒事项之前，通过桥接器JSbridge从H5前端服务器接收第一文件，并从所述第一文件中得到所述提醒时间和所述深度链接，包括：

在所述第二操作的触发下，向所述H5前端服务器发送数据请求，并通过所述H5前端服务器向所述第一应用的营销中心服务器转发所述数据请求；所述数据请求包括所述提醒时间和所述深度链接；所述提醒时间包括目标活动日期的开始日期和结束日期，以及目标活动日期中每天内的起始时间和结束时间；所述数据请求还包括以下至少一项：活动标识ID和是否参与目标活动的标识；

通过JSbridge从H5前端服务器接收所述第一文件，所述第一文件是所述营销中心服务器在接收到所述数据请求后，根据所述数据请求发送给所述H5前端服务器的；所述第一文件中包括所述数据请求对应的目标数据，所述目标数据包括所述提醒时间和所述深度链接，所述目标数据还包括活动ID和/或是否参与目标活动的标识。

4.根据权利要求2所述的方法，其特征在于，所述响应于用户对所述第一弹窗中所述第二控件的第二操作，启动日历应用，并创建日历提醒事项，包括：

获取所述日历应用的读写权限；

在获取到所述日历应用的读写权限并且接收到所述第一文件后，启动所述日历应用并创建所述日历提醒事项。

5.根据权利要求4所述的方法，其特征在于，所述获取所述日历应用的读写权限，包括：

在所述电子设备的屏幕上显示第二弹窗，所述第二弹窗中包括授权所述日历应用的读写权限的确认授权控件；

响应于用户对确认授权控件的点击操作，得到所述日历应用的读写权限。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述在每次到达所述提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在所述电子设备上启动所述第一应用，并基于所述深度链接再次加载所述第一页面，包括：

在每次到达所述提醒时间时，在所述电子设备上显示第三弹窗，所述第三弹窗用于提醒用户是否再次参与目标活动；

响应于用户对所述第三弹窗的点击操作，启动所述第一应用，并基于所述深度链接加载出所述第一页面进行显示，对所述第三弹窗的点击操作即为所述再次参与目标活动的确认操作。

7.根据权利要求1至5中任一项所述的方法，其特征在于，所述在每次到达所述提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在所述电子设备上启动所述第一应用，并基于所述深度链接再次加载所述第一页面，包括：

在每次到达所述提醒时间时，在所述电子设备上显示第四弹窗，所述第四弹窗用于提醒用户是否再次参与目标活动；

响应于用户对所述第四弹窗的点击操作，启动所述日历应用，并显示所述日历提醒事项；

响应于用户对所述日历提醒事项中的所述深度链接的点击操作，启动所述第一应用，并加载出所述第一页面进行显示，对所述第四弹窗的点击操作和对所述深度链接的点击操作的组合即为所述再次参与目标活动的确认操作。

8.根据权利要求1至5中任一项所述的方法，其特征在于，所述在每次到达所述提醒时间时，响应于用户输入的再次参与目标活动的确认操作，在所述电子设备上启动所述第一应用，并基于所述深度链接再次加载所述第一页面，包括：

检测所述电子设备中是否安装有所述第一应用；

当检测到所述第一应用已安装时，启动所述第一应用，并基于所述深度链接跳转至所述第一页面；或者，

当检测到所述第一应用没有安装时，显示第五弹窗，所述第五弹窗用于指示用户是否安装所述第一应用。

9.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：

响应于用户对所述第一控件的第三操作，不显示所述第一弹窗，所述第三操作用于表示不参与目标活动。

10.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：

响应于用户对所述第二控件的第四操作，不启动所述日历应用，所述第四操作用于表示不创建日历提醒事项。

11.根据权利要求5所述的方法，其特征在于，所述第二弹窗中还包括不允许授权所述日历应用的读写权限的取消授权控件，所述方法还包括：

响应于用户对所述取消授权控件的点击操作，取消所述日历应用的读写权限的获取。

12.一种电子设备，包括存储器、一个或多个处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述一个或多个处理器执行所述计算机程序时使得所述电子设备实现如权利要求1至11中任一项所述的方法。

13.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被电子设备执行时实现如权利要求1至11中任一项所述的方法。