在OC开发中,导航控制器是一个非常常见的控件,而且在不少使用时候,我们需要自定义导航条NavigationBar。但是这个做法可能带来一些小麻烦,下面是我遇到的问题以及解决方案的思维过程。
在苹果内部,返回功能的实现自带了一个边缘的滑动返回功能。但是一旦使用我们自定义的NavigationBar,子控制器这个功能便会消失。如果我们既要用到自定义,又要保留滑动返回功能,那我们首先要分析消失的原因,再来寻找解决方案。
![](https://images2015.cnblogs.com/blog/1061766/201611/1061766-20161111201638452-1069123558.png)
既然替换NavigationBar会导致滑动返回功能的消失,那我们基本可以确定,在NavigationBar当中会有某些属性某些方法实现了这个功能。那么需要进一步考虑系统做了哪些事,哪些会导致滑动功能失效。
由于滑动功能肯定需要手势,我们可以先从手势进行分析。又因为滑动返回手势是iOS7.0以后推出的,而且添加手势是添加到UINavigationController的view上,那我们直接点进去搜索关键字“gesture”
![](https://images2015.cnblogs.com/blog/1061766/201611/1061766-20161111201722249-1414271192.png)
出现有且只有一个符合我们条件的属性。那我们可以大胆推测滑动返回功能跟interactivePopGestureRecognizer有关系,所以直接打印它的值来观察。
![](https://images2015.cnblogs.com/blog/1061766/201611/1061766-20161111201737983-1052868010.png)
刚好它的值中有个与屏幕边缘的手势相关,进一步验证我们的猜想。那么就可以用最简单粗暴的方法来确认,直接“干掉”该方法,如果功能失效,那肯定与它相关,那我们可以考虑尝试代理,通过interactivePopGestureRecognizer让滑动返回功能失效。
首先让控制器成为interactivePopGestureRecognizer的代理,在代理方法中把识别手势方法的返回值改为NO,不出所料,滑动功能无法实现。
![](https://images2015.cnblogs.com/blog/1061766/201611/1061766-20161111201943655-1798079304.png)
为了确认该属性本来就存在着代理,顺便把代理属性的值也打印出来。
![](https://images2015.cnblogs.com/blog/1061766/201611/1061766-20161111201828858-189406553.png)
这也可以证明了猜想的正确性。那么下一步就是考虑如何在使用自定义导航条(NavigationBar)的基础上,使滑动功能继续实现。
首先尝试直接把代理属性清空,不让它继续控制屏幕滑动,确实实现了自定义NavigationBar后继续滑动的返回功能。但明显也会带来bug,造成导航控制器view也可以滑动,而且滑动后造成了界面的假死,所以不能把代理设置为nil。那我们继续使用控制器作为代理,考虑通过控制手势在根控制器上不能滑动来修复该bug。
![](https://images2015.cnblogs.com/blog/1061766/201611/1061766-20161111201954264-1742111986.png)
在手势控制时加入判断,如果该控制器为根控制器,那么手势将不会触发,如果为子控制器,能够正常使用。最终达到项目要求,在使用自定义NavigationBar的前提下实现原有的滑动返回功能。