Open QIYA0130 opened 5 years ago
有这样一个需求,App 大量的请求需要依赖一个 ticket。 对这个 ticket 的设计是 30 分钟时效,要客户端自己做时间戳判断,过期就要先请求 ticket,再发本来的请求。 这样我无论如何都想不到比较优雅的方法在底层处理,不知大神有没有想法。
你怎么处理的?
因为apimanager的参数是通过pramesource获取的,所以只要paramsource实例还在,这个APImanager的实例就可以保存下来,然后先调用ticket的api,再调用刚刚保存的apimanager的loaddata方法就好了。
发自我的iPhone
在 2021年11月15日,12:41,zzscc @.***> 写道:
有这样一个需求,App 大量的请求需要依赖一个 ticket。 对这个 ticket 的设计是 30 分钟时效,要客户端自己做时间戳判断,过期就要先请求 ticket,再发本来的请求。 这样我无论如何都想不到比较优雅的方法在底层处理,不知大神有没有想法。
你怎么处理的?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/casatwy/CTNetworking/issues/28#issuecomment-968533461, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHVRVOZATSGHDWYRWONKHTUMCFOVANCNFSM4IPBDJUQ.
因为apimanager的参数是通过pramesource获取的,所以只要paramsource实例还在,这个APImanager的实例就可以保存下来,然后先调用ticket的api,再调用刚刚保存的apimanager的loaddata方法就好了。 发自我的iPhone 在 2021年11月15日,12:41,zzscc @.***> 写道: 有这样一个需求,App 大量的请求需要依赖一个 ticket。 对这个 ticket 的设计是 30 分钟时效,要客户端自己做时间戳判断,过期就要先请求 ticket,再发本来的请求。 这样我无论如何都想不到比较优雅的方法在底层处理,不知大神有没有想法。 你怎么处理的? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#28 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHVRVOZATSGHDWYRWONKHTUMCFOVANCNFSM4IPBDJUQ.
最近看大佬的文章,倍感启发。这个框架是我看到最优雅的网络封装了,对于这个框架还没完全掌握,有两个疑问想请教下大佬:
这个框架请求的本质就是调用APIManager对象的loadData方法。 所以批量请求其本质也只是获取APIManager对象数组然后调用这个数组里对象的loadData方法。 链式请求也是在上一个APIManager对象的回调里面调用下一个APIManager对象的loadData方法而已。
对于这两种请求场景来说,调度器不需要关心到底是什么APIManager,他只要拿到实例调用loadData方法就好了,调度器也不需要关心参数从哪里来,因为都是走的paramSource。
对于链式请求来说,发起下一次请求的时机可以是在业务里,也就是业务实现calback delegate的地方。也可以是在自己的APIManager里,因为APIManager提供了interceptor,interceptor提供了一个APIManager的完整生命周期。所以如果是业务场景的链式调度需求,那就写在业务代码中。如果是固定的链式调用需求,那就写在APIManager自己的interceptor里。
前面提到了调度器,由于调度器的本质就是调用一个对象的固定方法,所以实现调度器是一个很简单的事情。但是不同的业务需求又影响调度器的实现,所以这个框架里并不提供调度器的实现,你可以自行实现,不难的。
对于第二个问题,一个业务要调用6个接口创建6个APIManager,正是因为这么做了,所以你才能用上面的方式解决问题。如果是集约型调度,所有API都走一个地方,你就很难针对每个不同的APIManager做生命周期的不同处理了。
有这样一个需求,App 大量的请求需要依赖一个 ticket。
对这个 ticket 的设计是 30 分钟时效,要客户端自己做时间戳判断,过期就要先请求 ticket,再发本来的请求。
这样我无论如何都想不到比较优雅的方法在底层处理,不知大神有没有想法。