当产品搞了一堆弹窗的需要后,如各自提示、引导,然后发现这样不好,需要进行排序显示,也就是显示一个之后再显示下一个,这事就落到开发手上。这些弹窗有各种不同类型,并且每种弹窗可能有取消(好的),或者还有确定(来进入下一弹窗),也就是说整个业务完成之后才算消失。
每个弹窗显示的内容是根据服务端下发的数据来配置。下发的方式有 HTTP (一次性下发所有需要显示的弹窗数据)或 Socket (分开下发各个弹窗数据,也就是说下发的先后顺序可能不同)。
场景描述完了,用我的真实需求来说明:弹窗分别有心愿审核结果(A)、心愿填写(B)、心愿分享引导(C)。A有两种状态,审核通过(A1,只有确定,点击则消失)和审核拒绝(A2,有取消和确定,取消点击则消失,确定则进入下个流程),在 A2 时点击确定则显示 B,然后可以进行心愿的修改,也可以取消来结束,当上面流程结束后显示 C,以上都需要先判断是否有 A、B、C 可供显示,有就显示,无则跳过。下面是简单的顺序图,任意节点没有则跳过,直接到下一个。
A
/ \
A1 A2
\ \
C B
/
C
接着聊聊排序显示的实现:
一、
最初的解决方案是想简单暴力点,因为细看上面的需求,其实就是两层。要记录的就是 A 是否出现,是否点击显示 B,然后是否显示显示 C 。前面说的如果是 Socket 下发 A 和 C 时,暂不考虑 C 在 A 前面的情况(其实后续实现 FIFO 就可以不理会),因为目前需求是 A 肯定在 C 前面。
通过 bShowWishResult 记录是否显示 A,而接着是显示 B 则等 B 消失时把 bShowWishResult = NO,不然则 A 消失时置 NO,此时再通过 shareGuideDic 判断是否显示 C。当 A 和 C 同时下发,C 先判断 bShowWishResult,为 NO 才显示,不然先记录 shareGuideDic 再等待。代码实现如下:
// 是否显示心愿结果 A 中
@property (nonatomic) BOOL bShowWishResult;
// 心愿分享引导 C 的数据
@property (nonatomic, strong) NSDictionary *shareGuideDic;
- (void)doConnectSocket:(NSDictionary *)dic {
if (type == A) {
self.bShowWishResult = YES;
[self p_showWishResultView:dic];
}
else if (type == C) {
if (self.bShowWishResult == YES) {
self.shareGuideDic = dic;
}
else {
[self p_showShareGuideView:dic];
}
}
}
// 显示 A 页面
- (void)p_showWishResultView:(NSDictionary *)dic {
...
// 显示完消失,通过 delegate 或者 block 来调用 p_nextView 显示 C
self.bShowWishResult = NO;
[self p_nextView];
}
// 显示 C 页面
- (void)p_showShareGuideView:(NSDictionary *)dic {
// 显示完消失,通过 delegate 或者 block 来调用,来清空记录
self.shareGuideDic = nil;
}
- (void)p_nextView {
// 有 C 的数据则显示 C 页面
if (self.shareGuideDic != nil) {
[self p_showShareGuideView:self.shareGuideDic];
}
}
不论是 A 之后直接到 C, 还是 A 到 B,再到 C,都得通过 delegate 或者 block 到主 VC 来调用 [self p_nextView]; 来显示下个弹窗。这里有个问题是每个页面的都需要这种消失的回调。而类似 A1,本来就是个简单的提醒弹窗,此时就不得不也添加回调。这样等于增加了总的代码量,主 VC 也增加处理。所以后面会讨论是否使用 监听 来减低这种耦合。
二、
当完成第一版的时候,已经满足了需求。可是再细想下,会发现其实这样做并不通用,也就是说再增加一个类似A或者C的弹窗时候,需要再增加 property 的字典等逻辑。而这种排序显示让人想到了堆(heap),FIFO。所以使用堆的数据结构来保存这种顺序的话,然后再拿出来显示。
需要增加:项目中 Socket 过来的数据是要判断同一场次的,就是推 type 为 A 的gameId 需要和 type 为 B 的 gameId 要一致。gameId 是在进场的 HTTP 或者初始的 Socket 路由得到的,我们额外保存当前 gameId 就可以。
现在我们使用 heap 管理类,将同个 gameId 的弹窗数据一一添加到对应 key-value 数组中。这样就不用因为多个弹窗再添加类似第一版的 bShowWishResult 和 shareGuideDic,现在直接通过 QHHeapManager 的 queueDicValue 来管理。代码如下:
#define QHHeapTypeKey @"type"
#define QHHeapDicKey @"dic"
typedef enum : NSUInteger {
QHHeapTypeWish,
QHHeapTypeShare
} QHHeapType;
@interface QHHeapManager()
@property (nonatomic, strong) NSMutableDictionary *queueDicValue;
@end
@implementation QHHeapManager
- (NSArray *)hasNext:(NSSting *)gameId {
NSArray *value = self.queueDicValue[gameId];
if (value != nil && value.count > 0) {
return [value copy];
}
return nil;
}
- (void)addQueue:(NSSting *)gameId value:(nonnull id)data {
NSArray *value = self.queueDicValue[gameId];
if (value != nil) {
NSMutableArray *newValue = [NSMutableArray arrayWithArray:value];
[newValue addObject:[data copy]];
[self.queueDicValue setObject:newValue forKey:gameId];
}
else {
[self.queueDicValue setObject:@[[data copy]] forKey:gameId];
}
}
- (void)goNext:(NSSting *)gameId {
NSArray *value = self.queueDicValue[gameId];
if (value != nil && value.count > 0) {
NSMutableArray *newValue = [NSMutableArray arrayWithArray:value];
[newValue removeObjectAtIndex:0];
[self.queueDicValue setObject:newValue forKey:gameId];
if (newValue.count > 0) {
// 下一个
[self.delegate nextQueue:[newValue firstObject]];
}
}
}
@end
调用方式,及回调逻辑代码:
// A
[self.heapManager addQueue:@"123" value:@{QHHeapTypeKey: @QHHeapTypeWish, QHHeapDicKey: dic}];
// B
[self.heapManager addQueue:@"123" value:@{QHHeapTypeKey: @QHHeapTypeShare, QHHeapDicKey: dic}];
// 完成 A 之后,调用
[self.heapManager goNext:@"123"];
// delegate
- (void)nextQueue:(id)value {
NSDictionary *dic = ((NSDictionary *) alue);
if ([dic[QHHeapTypeKey] integerValue] == QHHeapTypeShare) {
[self p_showShareGuideView:dic[QHHeapDicKey]];
}
}
三、
说到这里可以看出 QHHeapManager 的 API 只支持用于 gameId,或者类似 gameId 的 key。但是注意他们不能一起使用,除非使用特殊字符区分,必须唯一。而 delegate 的 - (void)nextQueue:(id)value; 也需要区分大类,再区分小类。因此需要修改上面的 delegate 的API。最终我通过增加枚举来维护不同的字段,这样也方便查看目前使用的排序种类,避免重复。而下面的完整版也增加了上面提到的 NSNotificationCenter 来解耦,让 A1 无须多写 delegate,只需在页面消失添加 Notif 的 post。代码如下:
[[NSNotificationCenter defaultCenter] postNotificationName:GONEXT_LUACYQUEUE_NOTIFICATIONNAME object:@(QHQueueTypeEnter)];
QHHeapManager 的完整代码如下:
// 通知
#define GONEXT_LUACYQUEUE_NOTIFICATIONNAME @"GONEXTLUACYQUEUENOTIFICATIONNAME"
// 增加大类
typedef enum : NSUInteger {
QHQueueTypeFinal,
QHQueueTypeEnter
} QHQueueType;
typedef enum : NSUInteger {
QHHeapTypeWish,
QHHeapTypeShare
} QHHeapType;
#define QHHeapTypeKey @"type"
#define QHHeapDicKey @"dic"
// 大类的 key
#define QHHeapOtherKey @"otherKey"
#define QHQueueValue @"queueValue"
@interface QHHeapManager()
@property (nonatomic, strong) NSMutableDictionary *queueDicValue;
@end
@implementation QHHeapManager
- (void)dealloc {
[[NSNotificationCenter defaultCenter] removeObserver:self name:GONEXT_LUACYQUEUE_NOTIFICATIONNAME object:nil];
_queueDicValue = nil;
}
- (instancetype)init {
self = [super init];
if (self) {
[self p_setup];
}
return self;
}
- (void)p_setup {
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(goLuckyQueueNextAction:) name:GONEXT_LUACYQUEUE_NOTIFICATIONNAME object:nil];
}
- (NSArray *)nextValue:(QHQueueType)type {
NSArray *value = self.queueDicValue[@(type)];
if (value != nil && value.count > 0) {
return [value copy];
}
return nil;
}
- (void)deleteValue:(QHQueueType)type {
[self.queueDicValue removeObjectForKey:@(type)];
}
- (void)addQueue:(QHQueueType)type value:(nonnull id)data {
NSArray *value = self.queueDicValue[@(type)];
if (value != nil) {
NSMutableArray *newValue = [NSMutableArray arrayWithArray:value];
[newValue addObject:[data copy]];
[self.queueDicValue setObject:newValue forKey:@(type)];
}
else {
[self.queueDicValue setObject:@[[data copy]] forKey:@(type)];
}
}
- (void)goNext:(QHQueueType)type dicComplete:(BOOL(^)(QHQueueType type, id value))complete {
if (type == QHQueueTypeFinal ||
type == QHQueueTypeEnter) {
NSArray *value = self.queueDicValue[@(type)];
if (value != nil && value.count > 0) {
NSMutableArray *newValue = [NSMutableArray arrayWithArray:value];
[newValue removeObjectAtIndex:0];
[self.queueDicValue setObject:newValue forKey:@(type)];
if (newValue.count > 0) {
if (complete == nil || complete(type, [newValue firstObject]) == YES) {
if (newValue.count > 0) {
[self.delegate nextQueue:type value:[newValue firstObject]];
}
}
}
}
}
}
- (void)goLuckyQueueNextAction:(NSNotification *)notif {
id type = notif.object;
if (type != nil) {
[self goNext:[type integerValue] dicComplete:nil];
}
}
- (NSMutableDictionary *)queueDicValue {
if (_queueDicValue == nil) {
_queueDicValue = [NSMutableDictionary new];
}
return _queueDicValue;
}
@end
#pragma mark - QHHeapManagerDelegate
- (void)nextQueue:(QHQueueType)type value:(id)value {
if (type == QHQueueTypeFinal) {
NSDictionary *dicValue = value;
if ([dicValue[QHHeapTypeKey] integerValue] == QHHeapTypeShare) {
[self p_showFinalShareGuideView];
}
}
else if (type == QHQueueTypeEnter) {
NSDictionary *dicValue = value;
if ([dicValue[QHHeapTypeKey] integerValue] == QHHeapTypeWish) {
[self p_wishAction];
}
}
}
注意上面有个 goNext 函数的增加了 block,用于对已保存的字典数据进行再比较,来判断是否继续 goNext。如下:
- (void)goNext:(QHQueueType)type dicComplete:(BOOL(^)(QHQueueType type, id value))complete;
总结:
目前的解决方案是使用字典,大类作为key,内容及小类使用数组。其实就是利用数组的堆结构,add 和 firstObject,从而达到 FIFO,顺序获取需要显示的弹窗类型及数据等。而增加的通知,它虽然能减耦,但是当多个类都创建 QHHeapManager 时,都会监听这个通知,而通过类型判断可以避免触发对应逻辑(这也是为什么每个顺序都得添加一个大类的枚举),但是这种通知是消耗资源的。所以页面的逻辑还是得以回调为主,通知为辅。