在IOS的App开发中,传值是必不可少的.
常用的传值方法:
1:正向传值,也就是直接赋值
2:单例传值,其实也就是共享单利对象的数据
3:block传值
4:代理传值
5:通知传值
今天想要跟大家分享就是通知传值的那些坑
上面介绍的传值方式123,都用一个共同的特点,就是两个对象之间存在一定关系.一般可以直接获取到进行,赋值,设置代理,给block赋值等操作.这样就可以在合适的时间点进行赋值操作,实现传值的目的.
方法4可以实现一些毫无关联的对象之间共享数据,因为单例在内存中只存在一个.这样任何时候,都可以去访问单例,获取数据.但单例传值并不具有及时性.有时候并不能满足我们的需求.
通知传值,最大的优点就是可以实现毫无关联的对象之间获取到数据.
列举一个项目中可能会遇到的一个问题,在支付宝支付的支付中
[[AlipaySDK defaultService] payOrder:orderString fromScheme:AppScheme callback:^(NSDictionary *resultDic) {
NSLog(@"收到回调结果:%@",resultDic);
}];
其中在callBack中会收到支付宝的回调,此时可以进行操作用来判断用户支付是否成功.但是最新的支付宝SDK中,对callback回调做了解释,只有手机中没有安装支付宝客户端的用户,通过h5界面的支付宝进行操作时,才会在callback中收到支付信息的回调.
那么对于安装了支付宝客户端的应用程序,应用程序会通过openurl传递参数的方式调起支付宝,支付宝在支付结束以后会回调给客户端支付结果,
- (BOOL)application:(UIApplication *)application
openURL:(NSURL *)url
sourceApplication:(NSString *)sourceApplication
annotation:(id)annotation {
}
应用程序会走这里,附带从支付宝客户端传递过来的参数.
此时如何将参数传递给发生支付的ViewController是一大问题.如果用通知传值,一定是再合适不过了.可以在这里,发送一个通知,将传递的信息发送给注册了通知的对象实现传递消息.
通知的使用中,我们通常都会在dealloc里面写,从通知中心去移除self
但程序真的一定会走dealloc函数吗?
对于新手程序员,将常遇到的问题就是block里面对self的循环引用(这个下章会详细解释)
如果当前控制器在退出的时候,不走dealloc函数,可想而知,当前控制前还在内存中存在,并且没有从通知中心移除.程序员也不容易发现这些问题.那么在下次支付的时候,通过回调,会有两个对象都收到了通知的消息,程序就可能会有意外的情况情况发生.
这就是为什么通知并不是特别好用的原因
