一句话笔记，某段时间内遇到或看到的某个可记录的点。 2016-10-30
- 1、iPhone 左上有显示时是返回 上一个 APP，那么右上角有显示时呢
- 2、UITextField 代理中 textFieldEnd 中几种方式的对比
- 3、多层次封装 View 的感想
1、iPhone 左上有显示时是返回 上一个 APP，那么右上角有显示时呢
这个是使用了 DeepLink 之后跳转出现的一个情况，情景就是从 Notes 里面直接进入App之后的情况，当点击右上角的app.link 之后，下次就不能直接从 Notes 里面直接进来啦，需要长按那个链接，下面会弹出一个弹出框，选择 Open SomeApp 才可以进入的。
2、UITextField 代理中 textFieldEnd 中几种方式的对比
今天在用到 TextField 下面这个代理时遇到了一个问题：
- (BOOL)textFieldShouldEndEditing:(UITextField *)textField {
// Do SomeThing
return YES;
}
问题是，使用了 IQKeyboardManager 的同时，在 UITableView 中的 SubView 中含有一个 UITextField ，最后再收回这个 UITextField 键盘的一瞬间崩了，然后通过排查原因，定在这个代理处，换成下面这个代理就好了：
- (void)textFieldDidEndEditing:(UITextField *)textField {
}
于是去查看下其区别:
- 最直接区别：前者执行顺序在前面，后者执行顺序在后面；
- 其次是：前者可以通过 YES 和 NO，主动控制是否让键盘下移，后者是直接键盘下移的时候调用。
思考： 为什么我在使用上一个时就有问题了？ 目前想到的是，之前那处涉及到了很多方法，其中有一点是外面都可能用了已经执行完了 textFieldShouldEndEditing: ，我还让其继续执行并在里面调用方法 而导致的。此处想的还不是很清晰，到公司后再来细看看里面的崩溃轨迹去。
另外，稍微了解下，iOS10后，苹果又新增加了一个方法：
- (void)textFieldDidEndEditing:(UITextField *)textField reason:(UITextFieldDidEndEditingReason)reason NS_AVAILABLE_IOS(10_0);
// if implemented, called in place of textFieldDidEndEditing:
typedef NS_ENUM(NSInteger, UITextFieldDidEndEditingReason) {
UITextFieldDidEndEditingReasonCommitted,
UITextFieldDidEndEditingReasonCancelled UIKIT_AVAILABLE_TVOS_ONLY(10_0)
} NS_ENUM_AVAILABLE_IOS(10_0);
意味我们在 textFieldDidEndEditing: 中也可以调用它，但目前意义不大，如果只支持 TV的话。（UIKIT_AVAILABLE_TVOS_ONLY(10_0)）
3、多层次封装 View 的感想
最近在做需求，其中涉及到一个复杂界面，不得不将其细分其很多层，然后就做着做着就在想到了几个问题：
- View 的层次，很多时候有必要吗？类似一些跳转是否直接在当前 subView 进行呢？
- 赋值的时候，是直接暴露 subView ，还是直接传 NSString, NSArray, 还是间接传一个 model 呢？
- 返回值的时候，是用 Delegate ,还是用 Block ,甚至说用 NSNotificationCenter 呢？
- 同样一个值，最多传值超过几层呢？三层？ 四层？
我的想法：
3-1、View 的层次，很多时候有必要吗？类似一些跳转是否直接在当前 subView 进行呢？
看情况，复杂的时候有必要，层次明显，整个层次自然也就更清晰。不能为了方便将一坨 subView 房在一块吧；
说到跳转这个问题，我们最近两个项目中，刚好两种不同的处理方式：
- 一种是在 View 中，ViewController 中，ViewModel 中都有跳转
- 一种是都在 ViewController 做统一跳转
前者确实方便了，少传了很多，后者规范了很多，方便查找。
我的想法是：尽量是在 ViewController 中做跳转，但是一些另类的 Link 跳可以区分对待，甚至用一个 Manager 类来管理。
3-2、赋值的时候，是直接暴露 subView ，还是直接传 NSString, NSArray, 还是间接传一个 model 呢？
赋值的时候，我一般通常还是用 Model 的，但是有时候确实麻烦，例如一个 UIButton, 要从外面单一的改变其字体，文字，颜色，选中状态，就会觉的麻烦，用 Model 统一处理也可以但有觉的没必要。
我的想法是，尽量用 Model 传值，类似单一 NSString 也是 OK，用一个 set 方法解决。
3-3、返回值的时候，是用 Delegate ,还是用 Block ,甚至说用 NSNotificationCenter 呢？
现在我们一般用的是 Block 进行的各种回调，但是那个 __weak 和 __strong 很烦, 特别是不能直接通过 Command 找到上一层也麻烦，还得每次用 Command + F 也是习惯了咯，但他真的很方便，少写很多代码相对于 Delegate 来说；
用 Delegate 找寻上一层方法真的方便，就是代码量有点多，这个有时真的不好取舍，但他的代码清晰度没得说。
而 NSNotification 单层传真心没必要， 至少在 View 层次这块来说。当然对整个 App 的统一事件来说，还是得用他。
我的想法：一般还是用 Block , 简单快些，复杂型封装再用 Delegate。
3-4、同样一个值，最多传值超过几层呢？三层？ 四层？
这个看吧，一般超过三层，真心就让维护者头疼了，真心不能让那句： “一个差的程序员养活一大批程序员” 验证....
我的想法：最多三层吧，要不就是换一种形式，要不直接使用单例之类的，像 通知，NSUserDefaults 都比那种四五层的层次好吧
此处，想到是，无论如何尽量使其 保持 低耦合高内聚，但有时由于需要架构或需求原因，有时不能很好做到这点但尽量靠近是必须。换一种说法，就是怎样才能让其他同事维护和修改自己的代码。
同时，也得反思下，怎样的架构才是适合我们项目的需求？
前两天看到一句话，自己总结了下，来一点正能量！
内容是我们 iOS 这块的程序员的划分，可以看下自己所处的水平等级，不一定精确或者说准确，但整体是符合的，认为大致确实是可以反映我们技术水平的。
从工作内容上看：
- 主要做UI
- 主要做网络
- 主要做架构
- 主要做算法
从使用轮子看：
- 找轮子，各种查阅
- 搬迁轮子，各种套用
- 修改轮子，各种适配
- 造好轮子，而且有很多人用的
问问自己是处于那个阶段呢？自己将怎样提高呢？
