-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
一个比较难受的需求 #28
Comments
你怎么处理的? |
因为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 unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHVRVOZATSGHDWYRWONKHTUMCFOVANCNFSM4IPBDJUQ>.
|
最近看大佬的文章,倍感启发。这个框架是我看到最优雅的网络封装了,对于这个框架还没完全掌握,有两个疑问想请教下大佬:
|
这个框架请求的本质就是调用APIManager对象的loadData方法。 对于这两种请求场景来说,调度器不需要关心到底是什么APIManager,他只要拿到实例调用loadData方法就好了,调度器也不需要关心参数从哪里来,因为都是走的paramSource。 对于链式请求来说,发起下一次请求的时机可以是在业务里,也就是业务实现calback delegate的地方。也可以是在自己的APIManager里,因为APIManager提供了interceptor,interceptor提供了一个APIManager的完整生命周期。所以如果是业务场景的链式调度需求,那就写在业务代码中。如果是固定的链式调用需求,那就写在APIManager自己的interceptor里。 前面提到了调度器,由于调度器的本质就是调用一个对象的固定方法,所以实现调度器是一个很简单的事情。但是不同的业务需求又影响调度器的实现,所以这个框架里并不提供调度器的实现,你可以自行实现,不难的。 对于第二个问题,一个业务要调用6个接口创建6个APIManager,正是因为这么做了,所以你才能用上面的方式解决问题。如果是集约型调度,所有API都走一个地方,你就很难针对每个不同的APIManager做生命周期的不同处理了。 |
有这样一个需求,App 大量的请求需要依赖一个 ticket。
对这个 ticket 的设计是 30 分钟时效,要客户端自己做时间戳判断,过期就要先请求 ticket,再发本来的请求。
这样我无论如何都想不到比较优雅的方法在底层处理,不知大神有没有想法。
The text was updated successfully, but these errors were encountered: