基于安卓系统的智慧公益平台研究与实现

2022-01-24侯金昌闫曙曙

通化师范学院学报 2022年2期

钟娟，侯金昌，闫曙曙

近年来，公益志愿活动在社区活动中的地位和作用日益彰显［1］，越来越多的人愿意投身于公益志愿活动，但是统一便捷的平台却无处可寻，平台的缺乏消减了人们的积极性，增加了需要得到帮助的人的等待时间.智慧公益平台主要是面向社区居民，打破线下公益的局限性，突破时间和空间的限制，传播社会正能量.平台可以成为志愿者的聚集地，对志愿者来说，平台不仅能够及时寻找到志愿活动，快速高效地为人民服务，也能够与其他志愿者进行沟通交流，激发公益热情.对被服务对象来说，既可以及时在平台发布志愿招募，快速解决难题，又能够在平台上向志愿者表达谢意.

据调查，同类型的App屈指可数，目前主要有“公益中国”和“米公益”这两款App，“公益中国”面向的群体较少，“米公益”的模式过于单一.相比于这两个平台，本文设计的平台更加开放，面向的公益群体更加广泛，不仅面向组织还面向个人；另外爱心小窝模块的卡通人物形象相比于刻板单一的流程更加深入人心，能够极大地提高用户的积极性；平台的模式富有多样性，可以进行签到、募捐等功能.

1 系统整体设计

1.1 整体框架

智慧公益平台整体的架构采用Android+SpringBoot［2］+Mysql［3］，构架图见图1，在后台采用MVC架构［4］，耦合性比较低，并且视图层和业务层分离，开发和维护都比较方便，业务逻辑比较清晰，SpringBoot［5-6］和SpringMVC［7］相比较配置更加方便，仅需要几行代码就可以快速配置；在安卓端，开发使用的是谷歌提供的原生安卓框架，其中包含了丰富的类库，也支持开源类库的直接调用，如百度地图、OkHttp［8］、站长付等，完全满足开发需求.

图1 架构图

1.2 数据库的设计

根据需求分析，系统中出现了7类对象，分别为：用户、说说、任务、虚拟儿童、募捐活动、商品以及收件人，对这些对象进行抽象建模［8］，每个模型应该具备的属性如下：

①用户（用户id、账户、用户名、密码、爱心币、邮箱、地址、头像、登录状态、支付码）；

②说说（说说id、作者id、发布时间、标题、详情、图片描述）；

③任务（任务id、标题、详情、图片描述、任务地址、经度、纬度、悬赏、召集人数总量、召集人数剩余量、发布时间、执行时间、结束时间、结束与否、类型、签到码、发布者id）；

④虚拟儿童（虚拟儿童id、智力、体力、见识、领主id）；

⑤募捐活动（活动id、发起者id、标题、详情、募捐对象图片、发布时间、结束时间、所需物资名、当前所需物资数量、所需物资总量、收件人id）；

⑥商品（商品id、价格、库存、图片、商品名、商品描述、商家id、入库时间）；

⑦收件人（收件人id、手机号、姓名、省、市、县、详细地址）.

实体表结构设计：

①用户表.用户表包含了志愿者、商家和组织三种角色，每一种角色的共同属性都被抽象在用户表中，其不同的属性由用户行为表现出来，可以看到，用户的id是自增的，每次注册一个新用户获得一个独一无二的user_id，将其设置为主键也是为了能够唯一标识该用户.isLogin的添加是为了记录用户的登录状态，防止出现同一用户并发操作的情况，标志在线状态也能够提高用户账户的安全性，表的详细结构如表1所示.

表1 用户表

②身边公益说说表.类似QQ空间里的说说，作者和说说之间是1∶N关系，根据3NF［9］规范，要给每一个说说打上作者标签，设置author_id为外键，指向用户表中的主键user_id，并为说说设置BTREE索引；此外，为了满足用户发布多张图片的需求，将多个图片地址通过逗号隔开，大大降低了存储成本，表的详细结构如表2所示.

表2 身边公益说说表

③任务表.任务表内容较多，其中task_id是任务的唯一标识，title是任务标题，detail是任务内容，img是任务描述图片，address是任务地点，need是任务目前所需人数，start_time是发布时间，exe_time是任务执行时间，author_id指向发布任务的作者，lantitude是任务地点的经度，longitude是任务地点的纬度，is_finished标识任务是否结束，1表示结束，0表示未结束，end_time表示任务截止时间，end_timeexe_time为任务时长，coin表示任务悬赏，sum表示任务一共需要人数，sum-need为已经报名的人数，type是任务类型，有互助、慰问、咨询三种，code表示签到码.属性很多，但都很必要，例如经纬度（lantitude和logitude），把任务的地点精确到经纬度，能够极大方便用户查看地图寻找目的地，也为设置打卡范围提供了数据加持，表的详细结构如表3所示.

表3 任务表

④虚拟儿童表.此表是为了让志愿者培养自己的虚拟儿童，记录虚拟儿童的成长，简单地将属性分为智力、体力和见识，表的详细结构如表4所示.

表4 虚拟儿童表

⑤募捐活动表.募捐活动表中的属性也有很多，属性命名应见名知意，表中的consignee_id外键指向consignee表中的同名主键，将募捐活动的收件人详细化，方便商家发货.另外，系统将所有的时间都设置成datetime类型，是为了数据的正确性，防止用户误操作出现错误数据，datetime默认的时间格式是“年-月-日时：分：秒”，符合国人习惯.表的详细结构如表5所示.

表5 募捐活动表

⑥商品表.此表中的user_id与post表中的author_id异曲同工，只是指向的用户角色是商家，此处count仅代表当前动态变化的库存，表的详细结构如表6所示.

表6 商品表

⑦收件人表.此表是为了记录收件人的详细信息，方便募捐发起者和商家进行物流运输，详细记录了收件人所在的省、市、县和具体地址，并添加了收件人姓名和手机号码.表的详细结构如表7所示.

表7 收件人表

在数据库设计过程中，为了满足程序的功能，必须把实体与实体之间的关系以表的形式呈现出来［8-9］，实体之间的关系按照数量可以分为三种，1∶1、1∶N和N∶N，有一些1∶1、1∶N关系，无需中间表，如作者和说说的1∶N关系，任务发布者和任务的1∶N关系，商家和商品的1∶N关系，募捐发起者和募捐活动的1∶N关系，用户和虚拟儿童之间的1∶1关系，下面主要介绍N∶N关系，其他关系不再赘述.

根据需求分析，首先对这些关系进行抽象建模，这些关系应该具备的属性如下：

①用户-说说表（用户id、说说id、评论内容、是否点赞）；

②用户-任务表（用户id、任务id、是否签到、领取时间）；

③募捐活动-商品-用户表（募捐活动id、商品id、用户id、交易时间、交易金额、是否确认收货）.

注：有下划线的属性表示主键［10］.

关系表结构设计如下：

①用户和说说之间的N∶N关系表.此表是为了将用户和说说联系起来，一个用户可以给多个说说点赞评论，一个说说也可以被多个用户点赞评论，故设计一个中间表，以user_id和post_id为双主键，并作为外键分别指向user表和post表，comment表示用户对说说的评论，若未评论则为null，zan表示用户对说说的点赞次数，0表示未点赞.表的详细结构如表8所示.

表8 用户和说说之间的N∶N关系表

②用户和任务之间的N∶N关系表.此表是为了将志愿者用户和任务联系起来，一个用户可以领取多个任务，一个任务也可以召集多个用户，故设计一个中间表，以user_id和task_id为双主键，并且作为外键分别指向user表和task表，is_finished表示用户是否已经完成任务，1表示已经签到成功，0表示尚未签到成功.表的详细结构如表9所示.

表9 用户和任务之间的N∶N关系表

③募捐活动、商品、用户之间的N∶N关系表.此表是为了将用户参与募捐活动并购买商品的行为记录下来，由于用户只有在参与募捐活动的时候才能够购买商品，所以donation_id、goods_id、user_id均为主键，并作为外键分别指向donation表、goods表、user表，为了让用户可以在不同时间多次参与同一个募捐活动，所以笔者又增加了一个主键——build_time，goods_count表示用户该次捐赠的物资数量.

④money表示此次捐赠所消费的爱心币数量.is_finished表示该次捐赠是否成功，当且仅当物资签收时才会置1.事实上，donation_user_goods既是一个订单表，也是一个捐赠表.表的详细结构如表10所示.

表10 募捐活动、商品、用户之间的N∶N关系表

2 平台实现关键技术

2.1 SpringBoot框架

SpringBoot的出现降低了Web后台开发的门槛，解决了SpringMVC配置复杂的问题，让开发者可以轻松设计事务.SpringBoot继承了Spring的优秀特性，能较好地解决版本冲突的问题.

2.2 OkHttp框架

OkHttp是一个高效轻量的异步请求框架，用于替代谷歌的HttpClient，不需要开发人员通过各种格式转换获取请求结果，而是直接获取Response对象，使用起来简单方便，有透明的Gzip压缩，响应延迟很小.

2.3 Meterial Design

Meterial Design中有许多实用方便的小组件.Material Design一个最明显的标志是身边公益模块中运用到的用来发布说说的悬浮球FAB，这个小球通常添加与背景色具有反差的颜色，非常的醒目，常驻在屏幕的右下角.在平台界面中，Meterial Design的顶部应用栏中通常是用来显示用户当前所在界面的功能.卡片式设计的应用也很多，卡片不仅具有阴影、圆角等让界面变得美观的设计，还能放置头像、图标、标题和各种媒体元素.

3 系统功能和实现

3.1 登录注册

登录注册是每个应用都必不可少的模块，登录注册模块已得到广泛应用，因此其发展较为成熟，设计起来并不困难.登录设计就是根据用户提供的账户和密码信息查询user数据库，若存在该用户，就将登录成功信息返回给客户端，否则将拒绝登录信息返回给前端.注册设计就是根据用户提供的账户密码等个人信息，首先查询该用户是否已经存在，若用户已经存在，则拒绝注册，否则，将用户个人信息插入到user表中，最后将操作结果返回给前端.值得注意的是注册过程中使用正则表达式和Bmob短信服务，用来验证用户手机号的真实性和有效性.对应的用户登录与注册实现效果图如图2所示.

图2 登录注册效果图

3.2 爱心小窝

此模块设计的难点在于场景的设计和模型的建立，为了激励用户积极地参与到活动中并获得完成任务的成就感，给软件创建了虚拟爱心币，用来进行任务的奖励和实品的兑换，在爱心小窝模块设置了卡通人物和虚拟背景，虚拟人物的设定就是现实中需要帮助的人，用户可以利用完成任务获得的爱心币对虚拟卡通人物的智力、体力、见识等进行补充，平台会将这些数据转化成线下相应的实物捐赠.对应的实现效果图如图3所示.

图3 爱心小窝模块效果图

3.3 任务模块

任务模块是本平台最具特色的一个模块，主要有发布任务，查看发布任务签到码，领取任务和打卡签到.用例图［11］如图4所示，本模块将主要介绍任务发布地点推荐和打卡签到的两层限制.

图4 任务模块用例图

在任务发布过程中，任务地址不能只是用户编辑的地址，更不能直接获取当前地址，而是首先通过百度地图的定位功能获取用户当前所在位置，然后再根据关键字在当前位置进行周边搜索，将搜索到的结果作为选项展示给用户，按照用户的选择将地址、经纬度作为任务的一部分提交到后台.这一过程需要借助第三方平台，这里选择了用户量巨大、定位精确、功能强大的百度地图作为第三方平台.

本平台的任务模块中使用了百度地图的定位和周边关键字搜索功能.定位方法需要用到BDLocationClient类，创建一个该类，对象就相当于开启了一个地图客户端，对该对象设置监听便可以时刻监视位置变化，在监听位置的回调方法中能够获取用户设备当前的经纬度.周边关键词检索用到的方法主要是SuggestionSearch类的RequestSuggestion方法，该方法的形参为SuggestionSearchOption对象.通过前面获取到的经纬度、关键字可以创建该Option对象，并执行RequestSuggestion方法，搜索成功后将推荐地址数据回调，就可看到所有包含键入关键词的地点名称，用户选择正确的地点名称并提交任务信息，就可以将完整的任务信息存储到后台数据库.

用户需同时满足两层限制才能打卡成功，第一层限制是在打卡地点范围内，第二层限制是输入正确的签到码.

第一层限制的关键在于获取任务地点经纬度和当前经纬度，并结合地球半径计算出两点距离.距离算法主要依赖于半正矢公式：

其中，LngA、LatA分别是A点经度和纬度，Lng B、LatB分别是B点经度和纬度，x表示两点纬度之差，即x=LatA-LatB，y表示两点经度之差，即y=LngA-LngB，6 378.137为地球赤道半径，单位为千米.计算出两点距离之后便可与签到范围比对，确定用户是否满足范围限制.

第二层限制的关键在于签到码的随机性，任务签到码的设计是为了防止用户作弊，签到码的生成规则是使用java.lang包下的Math.random（）方法［12］，为了减少签到码的重复率，需要以当前时间作为时间种子，让签到码在客户端生成，为了提高签到码的随机性，在不同的手机环境下，同一时刻生成的签到码会有所不同.将用户输入的签到码与任务数据库中签到码进行比对便可获取签到结果.

对应的任务模块的效果图如图5所示，任务模块分为任务广场、发布任务、已领任务三个子模块，任务广场和已领任务均以列表的形式展现出来，点击进去可以查看详情，在发布任务中按照提示进行填写就可以发布新的任务，用户领取的任务在规定时间和范围内进行打卡签到.

图5 任务模块效果图

3.4 身边公益模块

身边公益模块可以查看所有用户的公益动态，并且能对某一动态进行点赞和评论；用户可以自己发表动态，输入标题、内容，也可以添加图片，即可发表自己的动态.身边公益模块主要是对post表和user_post表进行增删改查操作.在实现上日期显示为了使数据库中的日期和客户端上的日期完全一致，在服务器端，上传说说时将说说信息转换成post实体类，在post的日期变量上方加入“＠JsonFormat”注解，这样符合国人的时间格式为“年-月-日时：分：秒”.为了使图片显示实时更新，需要解决服务器的热启动问题.服务器内的图片资源放在resources/static/img目录下，与项目一起打包成war文件在Tomcat上运行，但是每次运行其图片资源就已经固定下来了，如果Tomcat不重启，无论上传了多少图片也无法找到.究其原因，是项目内的文件在运行过程中无法更新.该问题的解决方法为：将img文件夹映射到服务器静态文件夹，采用的映射方法是重写WebMvcConfigurer的addResourcesHandlers方法，方法内代码为registry.addResourceHandler（"/img/**"）.addResourceLocations（"file："+filePath）.模块对应的效果图如图6所示.

3.5 募捐模块

募捐模块也是公益平台中的重中之重，该模块的出现给志愿者提供了强大的行动力，主要功能有查询募捐活动并进行商品搜索、支付和收货确认，时序图见图7.

图7 募捐模块时序图

商品搜索的功能实现主要调用了getGoods-ByName方法，此方法主要使用了"like′%${name}%′"关键字实现模糊搜索.在查询之前要做的就是将name字符进行拆分，逐个调用查询方法，查询完毕之后为了防止商品重复出现，使用Java提供的Map容器［13］，以商品的唯一id作为key，完成对商品对象名称的存储.

支付功能的代码实现遵循设计阶段“三个判断、四个操作”的逻辑.先调用donation-Mapper判断是否需要物资，再调用goodsMapper判断库存是否足够，最后调用donation_goods_userMapper判断余额是否足够，调用的三个判断均满足后，再进行“四个操作”：插入关系数据、更新爱心币数量、减少商品库存、减少募捐所需物资，所有操作通过try-catch进行事务回滚.

募捐模块对应的效果图如图8所示.在募捐广场中，能看到图文并茂的募捐活动，并且标注了一些细节，如所需物资、时间等方便用户快速筛选到自己能够参加的活动，点击其中的一个活动就可以进入募捐活动详情界面，里面有更为详细的活动描述，描述底部有“去选择商品”按钮，点击按钮进入选择商品界面，用户可以左滑或右滑对商品进行选择，最后对选择的商品进行支付即可完成一次募捐活动.