本框架实现思路与YTKNetwork和RTNetworking类似,相当于一个简单版,把每一个网络请求封装成对象。使用LXNetwork,你的每一个请求都需要继承LXBaseRequest类,通过覆盖父类的一些方法或者实现相关协议方法来构造指定的网络请求。这个网络库可直接在项目中使用,但是有些功能完成度不是很完美,待完善。
GitHud地址:https://github.com/CoderLXWang/LXNetwork
一、为什么要这样做?
实现思路的图在下面,可以对比着图看下面内容。
直接封装一个简易的HttpTool,里面直接调用AF,返回responseObject直接返回, 这样不行吗, 为什么要弄这么麻烦?
显而易见的优点大概有以下几点:
1,前后隔离AFNetworking,以后如果升级AF或者替换其他框架, 只需要改动直接与AF接触的LXRequestProxy和LXResponse内的代码即可,避免对项目中业务代码产生影响(半小时完成从AF2.6升级AF3.0,重度使用的三方框架一般都要隔离一下)
2,将每个接口抽象成一个类,易于管理,按每个接口的需求构造请求(比如有的接口要缓存,有的接口不要缓存)
3,所有接口调用都经过LXBaseRequest,可以方便的在基类中处理公共逻辑(比如项目全部完成了,突然要用请求参数排序,加盐等方式加密)
缺点:使用麻烦。。。。。
二、思路讲解
包括缓存在内的大体思路即上图,上图中箭头颜色由浅到深即为调用顺序,大概讲解一下
1,首先要把网络请求封装成对象,即图中TestApi(继承于LXBaseRequest),在Viewcontroller中调用接口loadData
2,这时会调用到TestApi的父类LXBaseRequest中的loadData方法, 并从TestApi实现的重写或者协议方法中获取url, 请求类型, 参数等信息, 调用LXRequestProxy中的请求方法
3, LXRequestProxy内部调用AF的GET或其他方法
4, 回调之后并没有直接返回responseObject,而是转换成LXResponse,这样返回的数据经过封装, 相当于从后面也进行了隔离, 比如AF2.x的时候回调block的参数还是^(AFHTTPRequestOperation *operation, id reponseObject)
,AF3.x就变成了^(NSURLSessionDataTask *task, id reponseObject)
,如果不转换一下, 直接返回到控制器,改起来就尴尬了。。。
5,一路回调到TestApi, 再到ViewController
6,走完之后再看一下缓存如何处理,首先,缓存一定分为存和取,
存,在第5步, 一路回调到父类中的successCallApi这一步,将回调数据存起来的(用GET+登录状态或其他+url+参数转换的字符串作为key,这个随意,适合项目即可)。
取,在第2步调用父类LXBaseRequest中的loadData时会先检测该接口对应的数据是否存在, 存在直接返回父类LXBaseRequest中的successCallApi,不存在则正常发出请求
三, 举个栗子
接口如何定义?
FirstTestApi.h
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
#import "LXBaseRequest.h" //要遵守什么协议取决于这个接口需要如何构造, LXBaseRequestDelegate一定要遵守,用于获取url等基本信息 @interface FirstTestApi : LXBaseRequest //调用接口需要的参数,可以从控制器赋值传过来 @property (nonatomic, assign) int tp; /** 是否为读取新数据(对应下拉刷新) */ @property (nonatomic, assign) BOOL isLoadNew; /** 是否为最后一页 */ @property (nonatomic, assign) BOOL isLastPage; /** 可以是转好的数据模型,这里只是示意一下 */ @property (nonatomic, strong) id dataModel; @property (nonatomic, assign) NSUInteger dataLength; @end |
FirstTestApi.m
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 |
#import "FirstTestApi.h" //基本url,可定义成全局变量或者宏, 拼接URL使用 #define BaseUrl @"http://api.zsreader.com/v2/" @implementation FirstTestApi { int page;//记录页码值 int pageSize;//每页条数 NSInteger total;//记录总条数 } //重写init方法是为了设置获取参数和请求头的代理, LXBaseRequestDelegate不用设置是因为已在父类中设置好, 如果只需要最基本的LXBaseRequestDelegate则不需要重写init - (instancetype)init { self = [super init]; if (self) { self.paramSource = self; self.headerSource = self; } return self; } - (LXBaseRequestType)requestType { return LXBaseRequestTypeGet; } //1. 如果是POST请求下面两个方法都不用写 //2. 如果接口需要缓存, 这个可以不写,默认需要 //3. 某些GET接口, 不需要缓存一定要写, 比如需要数据及时变化的 - (BOOL)shouldCache { return YES; } //1. 删除缓存的时候要用来拼接缓存的key, 所以如果使用了缓存, 这个方法最好要写, 简单点就是直接返回requestUrl, 复杂一点的情况, 写各种不同的url的共同部分, 比如一个接口类里面有两个相近的url,@"pub/home/2"和@"pub/found/2", 则可以写@"pub/", 区共同部分,清缓存时都清掉 //2. 不能引用当前类的变量, 直接崩掉, self.的东西都不行 //3. 如果有不同情况, (@"情况1"|@"情况2"), 比如 @"pub/home" 和 @"pub/found" 可以写[NSString stringWithFormat:@"%@(%@|%@)", BaseUrl, @"pub/home", @"pub/found"]; - (NSString *)cacheRegexKey { return [NSString stringWithFormat:@"%@%@", BaseUrl, @"pub/home/2"]; } - (NSString *)requestUrl { return ="crayon-t">NSString *)requestUrl { return 成度不是很完美,待完善。 GitHud地址:https://github.com/CoderLXWang/LXNetwork 一、为什么要这样做? 实现思路的图在下面,可以对比着图看下面内容。 1,前后隔离AFNetworking,以后如果升级AF或者替换其他框架, 只需要改动直接与AF接触的LXRequestProxy和LXResponse内的代码即可,避免对项目中业务代码产生影响(半小时完成从AF2.6升级AF3.0,重度使用的三方框架一般都要隔离一下) 2,将每个接口抽象成一个类,易于管理,按每个接口的需求构造请求(比如有的接口要缓存,有的接口不要缓存) 3,所有接口调用都经过LXBaseRequest,可以方便的在基类中处理公共逻辑(比如项目全部完成了,突然要用请求参数排序,加盐等方式加密) 缺点:使用麻烦。。。。。 二、思路讲解 1,首先要把网络请求封装成对象,即图中TestApi(继承于LXBaseRequest),在Viewcontroller中调用接口loadData 2,这时会调用到TestApi的父类LXBaseRequest中的loadData方法, 并从TestApi实现的重写或者协议方法中获取url, 请求类型, 参数等信息, 调用LXRequestProxy中的请求方法 3, LXRequestProxy内部调用AF的GET或其他方法 4, 回调之后并没有直接返回responseObject,而是转换成LXResponse,这样返回的数据经过封装, 相当于从后面也进行了隔离, 比如AF2.x的时候回调block的参数还是 5,一路回调到TestApi, 再到ViewController 6,走完之后再看一下缓存如何处理,首先,缓存一定分为存和取, 三, 举个栗子 接口如何定义?
FirstTestApi.m
|