本发明涉及计算机软件领域，尤其涉及一种家校互动方法。
背景技术：
中小学生的学校教育牵动着千万家长的心，学生在学校的学习及生活情况是否能够实时的通知家长显得尤为重要。因此，急需开发一款产品能够满足家长实时的参与到孩子的学习过程中，并且能够了解孩子在学校的表现，纠正孩子的不良嗜好，家长与教师能够互动，教师家长可以根据学生的特点开启不同的教育模式，培养学生的个性。现有技术中的家校互动方法不能实现家长客户端和服务器中学生信息的绑定功能，这样教师不容易将家长和学生对号入座，造成教师管理上的困难。
技术实现要素：
有鉴于此，本发明实施例提供了一种家校互动的方法，解决了现有技术中家长客户端和服务器中学生信息不能绑定的问题。
本发明实施例的一种家校互动方法，应用于一种基于XMPP协议开发的家校互动系统，所述系统包括服务器和多个客户端，其中所述服务器与所述多个客户端通过互联网连接，其特征在于，所述多个客户端中的每个支持多个用户类型，当所述多个用户类型中的第一用户类型的用户通过一个客户端向服务器注册时，所述方法包括：
向所述服务器发送第一注册信息，其中所述第一注册信息包括第二用户类型的用户账号；
判断在已存储的用户账号中是否存在所述第二用户类型的用户账号；若是，则向所述服务器发送第二注册信息，其中所述第二注册信息包括所述第二用户类型的用户账号、第一用户类型的用户账号以及第一用户类型的用户密码；
存储所述第二注册信息，其中，将所述第一用户类型的用户账号与所述第二用户类型的用户账号关联存储。
进一步地，当所述多个用户类型中的任一个用户类型的用户通过一个客户端登陆所述服务器时，所述方法进一步包括：
向所述服务器发送第一登陆信息，其中所述第一登陆信息包括：当前用户类型的用户账号和用户密码；
判断已存储的用户账号和用户密码中是否存在所述第一登陆信息中的用户账号和用户密码；
若是，则向所述服务器发送包括当前用户类型的第二登陆信息；
判断所述第二登陆信息中的用户类型是否与所述第一登陆信息中的用户账号相匹配；
若相匹配，则当前用户类型的用户登陆成功。
进一步地，所述第一注册信息和/或第二注册信息中包括默认解析标签，其中所述默认解析标签包括如下字段：
消息标记，用来唯一标记本次通信信息；
目的地标记，用来标记本次通信信息的目的服务器；
发送者标记，用来标记本次通信信息的来源客户端；和
反馈标记，用来标记是否需要服务器返回结果。
进一步地，所述发送者标记的格式为：用户名++服务器名+/+客户端标记。
进一步地，所述第一用户类型为家长，所述第二用户类型为学生。
进一步地，所述多个用户类型进一步包括：教师。
进一步地，所述方法进一步包括：根据所述客户端当前所登陆的用户类型为所述客户端分配权限。
进一步地，当一客户端当前所登陆的用户类型为教师时，为该客户端所分配的权限包括：创建支持多个客户端交互通信的讨论组；其中，
将所述讨论组内的通信权限设置为：用户类型为教师的客户端和用户类型为学生的客户端之间可以发送和接受信息，或
将所述讨论组内的通信权限设置为：用户类型为教师的客户端和用户类型为家长的客户端之间可以发送和接受信息。
进一步地，所述多个客户端包括：第一客户端和第二客户端，当所述第一客户端向所述第二客户端发送文件时，所述方法进一步包括：
所述第一客户端向所述服务器查询所述第二客户端是否在线；
若所述服务器返回所述第二客户端在线；则所述第一客户端通过所述服务器获取所述第二客户端的IP；所述第一客户端向所述第二客户端发送传输文件命令以及所述第一客户端的IP；所述第二客户端打开文件监听接口并通知所述第一客户端；所述第一客户端向所述第二客户端发送文件包；所述第二客户端接收完毕，向所述第一客户端发送接受成功；所述第一客户端关闭发送文件接口；
若所述服务器返回所述第二户端不在线；则所述第一客户端向所述服务器发送离线文件申请，所述离线文件申请包括所述第二客户端的用户名；所述服务器向所述第一客户端发送所述服务器的IP并打开文件接收端口；所述第一客户端向所述服务器发送文件包；所述服务器接收完毕，向所述第一客户端发送接受成功；所述第一客户端关闭发送文件接口；所述第二客户端上线；所述服务器向所述第二客户端发送消息，提示所述第二客户端有未接受的文件以及所述服务器的IP和所述第一客户端的信息；所述第二客户端打开所述接收文件端口并通知所述服务器；所述服务器向所述第二客户端发送文件包；所述第二客户端接收完毕，向所述服务器发送接受成功；所述服务器关闭所述发送文件接口。
进一步地，所述方法进一步包括：
当所述用户类型为学生的客户端登陆成功后，所述服务器向所述用户类型为学生的客户端发送未读信息列表；
判断所述未读信息列表中的未读信息是否被读取；
当一个所述未读信息已被读取时，所述用户类型为学生的客户端向所述服务器发送已读信息；
所述服务器收到所述已读信息，标记与该已读信息相对应的未读信息为已读。
本发明实施例提供的一种家校互动方法，可实现第一用户类型的用户在注册后与第二用户类型的用户账号之间绑定。这样在家校互动的场景中，可将第一用户类型设置为家长，第二用户类型设置为学生。通过这种形式，可以将用户类型为家长的客户端和用户类型为学生的客户端进行绑定。这样，教师可以将家长和学生对号入座，管理起来十分方便，而且家长也可以更有针对性的参与到互动教学过程中，可实现更灵活的家校互动方式。
附图说明
图1为本发明一实施例所提供的家校互动方法中注册方法的流程图。
图2为本发明一实施例所提供的家校互动方法所基于的家校互动系统的结构示意图。
图3为本发明一实施例所提供的家校互动方法中注册方法的原理示意图。
图4为本发明一实施例所提供的家校互动方法中登陆方法的流程图。
图5本发明一实施例所提供的家校互动方法中登陆方法的原理示意图。
图6为本发明一实施例所提供的家校互动方法中发送文件方法的流程图。
图7为本发明一实施例所提供的家校互动方法中阅后通知方法的流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本发明一实施例所提供的家校互动方法中注册方法的流程图。如图1所示，该家校互动方法应用于一种基于XMPP协议开发的家校互动系统，该系统包括服务器和多个客户端，其中服务器与多个客户端通过互联网连接，多个客户端中的每个支持多个用户类型，当多个用户类型中的第一用户类型的用户通过一个客户端向服务器注册时，该方法包括：
步骤S101：向服务器发送第一注册信息，其中第一注册信息包括第二用户类型的用户账号。在后续的注册过程中，该第二用户类型的用户账号将与当前第一用户类型的用户账号关联存储，以实现该第一用户类型的用户和第二用户类型的用户之间的绑定。
步骤S102：判断在已存储的用户账号中是否存在第二用户类型的用户账号。之所以进行该判断是为了确认服务器的数据库中是否存在该要实现绑定的第二用户类型的用户账号，以防止第一用户类型的用户绑定错误。若是，执行步骤S103，若否执行步骤S105。
其中，已存储的用户账号可为已经过注册的用户账号，或无需注册直接录入的用户账号，这些已存储的用户账号可能分别对应不同的用户类型。例如，在家校互动的应用场景中，教师和学生的用户账号可被直接录入服务器的数据库，只有家长需要通过客户端实现与相应学生的关联注册。已存储的用户账号可以是存储在服务器的数据库中，也可以存储在客户端本地，本发明对此并不做限定。
步骤S103：向服务器发送第二注册信息，其中第二注册信息包括第二用户类型的用户账号、第一用户类型的用户账号以及第一用户类型的用户密码。此时所发送的第一用户类型的用户账号和用户密码将作为该第一用户类型的用户后续登陆时进行身份验证的凭证。
步骤S104：存储第二注册信息，其中将第一用户类型的用户账号与第二用户类型的用户账号关联存储。
步骤S105：客户端停留在注册界面，并弹出“第二用户类型的用户账号不正确”。具体到家校互动的场景中，当家长通过客户端输入了错误的学生账号时，则客户端提示“所输入的学生账号有误”，此时绑定失败。
由此便实现了第一用户类型的用户和第二用户类型的用户的绑定。在注册后的登陆过程中，只要该第一用户类型的用户登陆成功，即可查询到与该第一用户类型的用户相对应的第二用户类型的用户账号。这样在家校互动的场景中，可将第一用户类型设置为家长，第二用户类型设置为学生。通过这种形式，可以将用户类型为家长的客户端和服务器中用户类型为学生的客户端通过学生的用户账号进行绑定。这样，教师可以将家长和学生对号入座，家校管理起来十分方便，而且家长也可以更有针对性的参与到互动教学过程中，可实现更灵活的家校互动方式。
图2为本发明一实施例所提供的家校互动方法所基于的家校互动系统的结构示意图。如图2所示，该家校互动系统基于XMPP协议开发实现，具体包括基于openfire实现的服务器、基于mysql实现的数据库，以及4个客户端。该4个客户端分别为WINDOWSPC端、ANDROID端、手机IOS端以及WINDOWSPHONE端。其中，具备有线网络接口的客户端可使用宽带网络接入服务器，手机客户端可使用无线网或GPRS信号接入服务器。不同的客户端与服务器之间的通信可以通过smack通信实现。
图3为本发明一实施例所提供的家校互动方法中注册方法的原理示意图。在图3所示的实施例中，第一用户类型为家长，第二用户类型为学生。此外，客户端还可支持教师用户类型。当家长想要通过客户端向服务器注册时，需要首先通过客户端向服务器发送包括所要绑定的学生的学号以及内容为“注册”的事件类型的第一注册信息，当服务器在数据库中查找到该学生学号后，服务器返回内容为success的反馈信息，此时客户端再次发送包含学生学号、家长用户名、家长密码以及家长的其他个人信息(例如电话、邮箱等)，当服务器完成了家长用户名和学生学号的关联存储后，则再次返回success的反馈信息，至此该家长则完成了与学生的绑定注册。
在本发明一实施例中，为了方便客户端与服务器之间的通信，上述的第一注册信息和/或第二注册信息中可包括默认解析标签，其中默认解析标签可包括如下字段：
消息标记，用来唯一标记本次通信信息；
目的地标记，用来标记本次通信信息的目的服务器；
发送者标记，用来标记本次通信信息的来源客户端；和
反馈标记，用来标记是否需要服务器返回结果。
例如，可在ANDROID系统的asmack.jar包中添加如下协议以实现家长与服务器之间关于第一注册信息的交互。该协议基于XMPP协议通过xml语言实现，具体如下：
用户类型为家长的客户端向服务器所发送的包含第一注册信息的协议可为：
<iqid＝\"Qx6fC-12\"to＝\"hurry-pc\"type＝\"get\"from＝\"xjyhurry-pc/Smack\">#这里的iq即为默认解析标签，所包含的字段如下：id对应消息标记，本次通信信息的编号为Qx6fC-12；to对应目的地标记，本次通信信息的目的服务器名称为hurry-pc；type对应反馈标记，get表示要取得服务器的反馈结果；from对应发送者标记，具体格式为“用户名++服务器名+/+客户端标记”，即来源客户端的用户名为xjy，客户端的标记为Smack#
<registerxmlns＝\"combanc:im:register\">#combanc:im:register为监听服务器是否收到本次通信信息的监听命令，如果服务器返回的结果是success，则证明服务器已经收到了本次通信信息#
<students>
<id>4404126</id>
</students>#4404126即为要注册的与家长账号相关联的学生学号#
<eventtype>注册验证</eventtype>#从客户端传过来的字符串“注册验证”，用做与服务器返回的字符串相对应#
</register>
</iq>
服务器收到包含上述第一注册信息后返回的协议如下：
<iqid＝\"Qx6fC-13\"type＝\"result\"to＝\"xjyhurry-pc/Smack\"from＝\"hurry-pc\">
<registerxmlns＝\"combanc:im:register\">#服务器返回的协议也包括该默认解析标签，具体内容不再赘述#
<result>success</result>#服务器已查找到学生账号，返回的内容为success的反馈结果#
<eventtype>注册验证</eventtype>#将从客户端传过来的字符串原值返回#
</register>
</iq>
以上的<register></register>，<students></students>，<id></id>等标签的具体形式均可由开发者自定义，本发明对此不做限定。
本领域技术人员可以理解，注册方法流程还可以通过其他的协议形式来编写，只要能够在家长注册时实现家长的用户账号和学生学号的绑定即可，本发明对注册方法流程所用协议的具体形式不做限定。
图4为本发明一实施例所提供的家校互动方法中登陆方法的流程图。当多个用户类型中的任一个用户类型的用户通过一个客户端登陆时，该家校互动方法进一步包括：
步骤S401：向所述服务器发送第一登陆信息，其中所述第一登陆信息包括：当前用户类型的用户账号和用户密码。例如，在具体的家校互动场景中，为任一个用户类型可为学生、家长和老师。虽然用户类型不同，但登陆方法是相同的。
步骤S402：判断已存储的用户账号和用户密码中是否存在所述登陆信息中的用户账号和用户密码；若已存在，执行步骤S404，若不存在，执行步骤S403。
步骤S403：客户端停留在登陆界面，弹出“用户账号或密码错误”。这样可以防止不法分子盗用任一个用户类型的用户账号，同时也可以防止任一个用户类型的用户误登陆。
步骤S404:向所述服务器发送包括当前用户类型的第二登陆信息。例如，当前用户类型为家长时，第二登陆信息中就应包含内容为“家长”的用户类型信息。
步骤S405：判断所述第二登陆信息中的用户类型是否与所述第一登陆信息中的用户账号相匹配；若相匹配，当前用户类型的用户登陆成功，若不匹配，执行步骤S406。
步骤S406：客户端跳转到登陆界面，弹出“用户类型匹配失败”。
通过执行上述判断步骤S405，可以进一步验证当前用户账号与所输入的用户类型是否一致。例如，学生在第一登陆信息中所输入的用户账号(学生学号)和用户密码后，在第二登陆信息中输入的用户类型却为教师，则会被判断为不相匹配，此时登陆失败。这样可以防止当前登陆用户因选错用户类型而使得权限的限制或滥用。例如，学生选择老师的用户类型而胡乱发号施令，或者老师选择了学生的用户类型限制了权限的使用。
图5本发明一实施例所提供的家校互动方法中登陆方法的原理示意图。如图5所示，该登陆方法所给予的家校互动系统与图3所示的相同。其中客户端所支持的用户类型包括家长、学生和教师三种。其中任何一种用户类型的用户要登陆到服务器时，首先通过第一登陆输入用户名(用户账号)和密码(用户密码)，服务器验证通过该用户名和密码后返回内容为success的反馈结果给客户端，客户端再通过第二次登陆输入用户名和相应的用户类型，服务器验证所输入的用户名与用户类型一致时再次返回内容为success的反馈结果给客户端，至此当前用户登陆成功。
在本发明一实施例中，还可根据客户端当前所登陆的用户类型为该客户端分配权限。通过这种方式可实现对不同用户类型的用户之间的通信进行权限管理，以实现更灵活的家校互动方式。
在本发明一实施例中，当一客户端当前所登陆的用户类型为教师时，为该客户端所分配的权限包括：创建支持多个客户端交互通信的讨论组。讨论组只能由教师建立，这样教师可以对建立的讨论组进行控制。例如，教师可在上课期间关闭讨论组功能，同时还可以对讨论组内的人员进行正确引导，以将关注点放在学生在学校或家中的学习中。
讨论组中所包括的客户端不同，所实现的交互范围也不同。例如，可将讨论组内的通信权限设置为：用户类型为教师的客户端和用户类型为学生的客户端之间可以发送和接受信息。通过这种方式可以建立仅可教师和学生加入的班级课内讨论组。再例如，还可将所述讨论组内的通信权限设置为：用户类型为教师的客户端和用户类型为家长的客户端之间可以发送和接受信息。通过这种方式可以建立仅可教师和家长加入的班级课外讨论组。通过根据用户类型建立讨论组进行分组通信的方式，教师可以分别和学生以及家长进行沟通，避免在教学过程中出现不必要的尴尬。
用户类型为教师的客户端在创建讨论组之后，还可以设置或修改讨论组的讨论组名和密码，使用户类型为家长或学生的客户端加入或退出讨论组。在本发明另一实施例中，用户类型为家长或学生的客户端在登陆之后，通过搜索讨论组名加入讨论组；或，用户类型为家长或学生的客户端退出讨论组。
这样，教师可具有创建讨论组、设置或修改组名和密码、增加或删除用户的权利，学生和家长仅仅具有加入讨论组和退出讨论组的权利。
图6为本发明一实施例所提供的家校互动方法中发送文件方法的流程图。如图6所示，多个客户端包括：第一客户端和第二客户端，以第一个客户端向第二客户端发送文件为例，步骤如下：
步骤S601：第一客户端向服务器查询第二客户端是否在线；若服务器返回第二客户端在线，执行步骤S602；若服务器返回第二客户端不在线，执行步骤S604；
步骤S602：第一客户端通过服务器获取第二客户端的IP；第一客户端向第二客户端发送传输文件命令以及第一客户端的IP；
步骤S603:第二客户端打开文件监听接口并通知第一客户端；第一客户端向第二客户端发送文件包；第二客户端接收完毕，向第一客户端发送接受成功；第一客户端关闭发送文件接口；
步骤S604:第一客户端向服务器发送离线文件申请，离线文件申请包括第二客户端的用户名；服务器向第一客户端发送服务器的IP并打开文件接收端口；第一客户端向服务器发送文件包；服务器接收完毕，向第一客户端发送接受成功；第一客户端关闭发送文件接口；
步骤S605:第二客户端上线；服务器向第二客户端发送消息，提示第二客户端有未接受的文件以及服务器的IP和第一客户端的信息；第二客户端打开接收文件端口并通知服务器；服务器向第二客户端发送文件包；第二客户端接收完毕，向服务器发送接受成功；服务器关闭发送文件接口。
在本发明一实施例中，第一客户端可为教师，第二客户端可为学生或家长。通过这种方式，不管学生或家长是否在线，都可以保证教师所发送的文件能够被发送到。在本发明另一实施例中，学生或家长也可向教师发送文件。发送文件的内容可为语言、视频和图片等。本发明对发送文件的用户类型以及发送文件的内容不做限定。
图7为本发明一实施例所提供的家校互动方法中阅后通知方法的流程图。如图7所示，该家校互动方法进一步包括：
步骤S701：当用户类型为学生的客户端登陆成功后，服务器向用户类型为学生的客户端发送未读信息列表。其中，未读信息可为教师发送的作业信息、一些生活小贴士或明天需要预习的课程等等。
步骤S702：判断未读信息列表中的未读信息是否被读取；如果一个未读信息已被读取，执行步骤S703，如果未被读取，执行步骤S705。
步骤S703：用户类型为学生的客户端向服务器发送已读信息。
步骤S704：服务器收到已读信息，标记与该已读信息相对应的未读信息为已读。这样该用户类型为学生的客户端下一次登陆成功后则不再向其发送该未读信息，以此避免信息重复发送，避免造成学生收到很多条信息而不知哪条已经读取了哪条并未读取。
步骤S705：当一未读信息未被读取时，则用户类型为学生的客户端下一次登陆时，服务器要在数据库中查找未读信息，并将未读信息列表发送给用户类型为学生的客户端。如此循环往复，只要改未读信息处于未读状态，该学生每次登陆成功后都会收到该未读信息。
通过这种方式，学生可以对老师所布置的作业和所下答的通知进行监听，以免造成漏读信息的情况。
上述实施例只为说明本发明的技术构思及特点，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换等，均应包含在本发明的保护范围之内。