为什么要尽量少用通知进行传值

在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函数,可想而知,当前控制前还在内存中存在,并且没有从通知中心移除.程序员也不容易发现这些问题.那么在下次支付的时候,通过回调,会有两个对象都收到了通知的消息,程序就可能会有意外的情况情况发生.

这就是为什么通知并不是特别好用的原因