红包功能的开发总结
两天内对项目中的红包展示逻辑及UI做了大调,总结下其中的经验以及发现的编程中的问题:
先说下问题:
多余时间消耗的原因以及解决方案:
两天时间中,除去编码、调试以及优化外,其中有三处耗时的地方可以优化
1,前期的交互逻辑模糊。
在没有准确明确各个页面如何跳转,每个页面跳转携带什么数据,页面展示需要请求什么数据,回调会传递会什么数据前,匆忙编码,导致过程中逻辑大量修改。
2,没有准备好测试工具。
调试中,多次错过仅此一次的测试机会,导致在特有条件下没有捕获流程,状态信息。
现在的红包测试依赖于真实的付费,以及多账号之间的切换。测试过程复杂耗时。
在只针对于逻辑、UI的调整,不涉及接口的情况下,应对各个状态的model进行持久化存储,便于调试时随意选择要展示的状态。
3,程序中细节可以记录,调整。
比如case的排序,常查看的方法所在行数。在大量代码的文件中查找方法、刚刚的代码位置也是比较麻烦的。
还要熟练配合快捷键以及多tab的切换。
tab页 排列方式:
从左到右依次是小控件 封装View 控制器 配置页
快捷键:
搜索 “iOS开发快捷键,看这一篇就足够了” 比较全
红包展示逻辑(从点击红包开始):
1,准备红包展示需要的基础数据,红包类型,红包状态
- 基础数据存在于点击控件中,头像,名称,祝福语等
- 红包类型存在于点击控件中 ,一般也在基础数据中,比如随机红包,平均红包,名片红包等
- 红包状态需要临时获取,这样才能取到最新的状态,包括:可以抢,已抢,被他人抢完了,已过期 只有这四个
2,展示红包
- 普通红包的展示仅仅需要基础数据,类型和状态
- 名片红包在基础数据外,还需要单独获取名片的信息(名片的信息需要通过红包ID 获取)这里的逻辑是,先展示View的整体,对内部view的数据临时获取,这样可以提高外层view的展示速度。
3,回调的处理,代理的方式要优于block
- 设置代理不需要在协议类中,但是block一般要在view的添加类中,否则需要类之间的调用传递消息。
- block不宜多层嵌套,这样逻辑代码糅合在一起不易理解。
- delegate中一个方法处理一个逻辑更清晰。多协议比多block更容易维护。
4, 抢红包动作的处理。
- 最终抢红包结果基于状态,因此触发抢红包动作时,需要请求最新状态,根据最新状态进行展示
- 对于名片红包,抢之前需要判断自己的名片信息,如果没有名片还需要编辑,有完整信息后才可以获取红包,交换名片。
发红包规则(对微信的学习,并做了调整) :
优先级:
个数,单个红包区间,金额
单个红包在0.01~200之间
三种提示语:
一次最多发100个红包(个数提示)
单个红包金额不可超过200元(金额提示)
单次支付总额不可超过20000元(金额提示)
输入限制
1,金额
不得大于99999
不得 0X、0.X. 、.X
2,个数
不得先输入0
不得大于999
合规性判断
1,编辑金额时:
无个数{
金额 不得大于20000
}
有个数{
优先判断个数的合规
if(个数不合规){// 个数的优先级要高于金额
提示个数错误
}else{
单个金额 不得大于200 or 小于 0.01 合规性判断针对金额
}
}
2,编辑个数时:
if(个数 <= 100){
无金额{
}else{
// 有金额
单个金额 不得大于200 or 小于 0.01 合规性判断针对金额
}
}else{
// 个数 大于 100
提示个数的 超过100
}
对于合规性判断的处理是比较复杂的,在逻辑没有梳理清楚后会出现很多问题并且不宜维护
于是我设计了另一种报错的策略,保持权重最大的错误:
给每个错误设置权重,保持权重最大的错误,在所有逻辑判断完成后,统一进行提示。
该策略逻辑清晰,最终输出统一,容易控制。
测试代码稍后上传github: 红包封装