原文同步发布在:devhy.com/33-xcode11-…
一年一适配,今年又来了。
今年整体上问题不大,我司的App 没有出现编译报错问题。
首先,用 Xcode10 编译的 App 在 iOS 13 上使用甚至几乎完美😀
然而,用 Xcode11 编译的 App 再在 iOS 13 上跑,就有些问题了😂
具体碰到的问题如下:
modal新样式
iOS 13 多了一个新的枚举类型 UIModalPresentationAutomatic
,且是modalPresentationStyle
的默认值。
UIModalPresentationAutomatic
实际是表现是在 <iOS 13 的设备上被映射成UIModalPresentationFullScreen
,在 >=iOS 13的设备上被映射成UIModalPresentationPageSheet
。
我这边的设计师表示,新样式不错,可以不用改😆。
不过, PageSheet
与 FullScreen
对比 有个需要注意的地方,控制器的生命周期有点区别:
以 控制器A
、控制器B
举例:
控制器A
present控制器B
控制器A
不会调用viewWillDisappear
以及viewDidDisappear
控制器B
dismiss 时
控制器A
不会调用viewWillAppear
以及viewDidAppear
那么如果有些业务逻辑会在控制器A
的生命周期里做的话,就需要考虑其他方式实现,或者改回UIModalPresentationFullScreen
如果需要改成原本全屏的样式,可以处理Controller:
- 初始化时设置
modalPresentationStyle
值 - 跳转修改
modalPresentationStyle
值 - 覆盖
modalPresentationStyle
的get方法
扩展 看上面gif,用户是可以通过手势下拉关闭被present出来的控制器的,那如果我需要禁止他下来要怎么实现呢?
可以参考 disabling_pulling_down_a_sheet 的Demo
设置presentationController.delegate
代理对象,实现 UIAdaptivePresentationControllerDelegate
协议方法
@interface XXViewController () <UIAdaptivePresentationControllerDelegate>
@property (nonatomic, assign) BOOL allowBack;
@end
@implementation XXViewController
- (void)viewDidLoad {
[super viewDidLoad];
// ...
// 如果vc被navigation套了一层就要取navigation的presentationController
self.navigationController.presentationController.delegate = self;
}
// 使用UIAdaptivePresentationControllerDelegate 协议方法控制能否下拉dismiss
// 或者不实现这个协议,设置self.modalInPresentation(YES-不允许下拉关闭,NO-可以下拉关闭)
- (BOOL)presentationControllerShouldDismiss:(UIPresentationController *)presentationController {
return self.allowBack;
}
// 如果 self.modalInPresentation=YES 或者
// 上面协议方法return NO,用户再下拉就会在这收到回调
- (void)presentationControllerDidAttemptToDismiss:(UIPresentationController *)presentationController {
// 如果self.allowBack == NO,会回调到这里
// 可以在这里做一些事情然后再考虑让 self.allowBack=YES 或
// 则让 self.modalInPresentation=NO 即可让页面可以下拉返回
}
@end
textfield.leftview
如下方式,直接给 textfield.leftView
赋值一个 UILabel
对象,他的宽高会被 sizeToFit
,而不是创建时的值。
// left view label
UILabel *phoneLabel = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 63, 50)];
phoneLabel.text = @"手机号";
phoneLabel.font = [UIFont systemFontOfSize:16];
// set textfield left view
self.textfieldName.leftView = phoneLabel;
如所看到,实际 leftview 的width为59,height为19:
通过监听 leftView
的 frame
变化,发现是 layoutSubview
之后变化的。
最终还是给UILabel多套了一个UIView来解决
// label
UILabel *phoneLabel = [[UILabel alloc] init];
phoneLabel.text = @"手机号";
phoneLabel.font = [UIFont systemFontOfSize:16];
[phoneLabel sizeToFit];
phoneLabel.centerY = 50/2.f;
// left view
UIView *leftView = [[UIView alloc] initWithFrame:(CGRect){0, 0, 63, 50}];
[leftView addSubview:phoneLabel];
// set textfield left view
self.textfieldName.leftView = leftView;
KVC访问私有属性Crash
打开有UISearchBar
的页面发现Crash了,看到控制台输出提示:
// 获取_searchField
UITextField *sField = [self.searchbar valueForKey:@"_searchField"];
// crash log
*** Terminating app due to uncaught exception 'NSGenericException', reason:
'Access to UISearchBar's _searchField ivar is prohibited.
This is an application bug'
看起来是禁止访问私有属性了。
用 Xcode 10 编译的 App 在 iOS 13 上能正常使用,那么就是 Xcode 11 做了限制访问私有属性的一些处理了。
偶然发现 iOS 13 中增加了UISearchTextField
类,且暴露了searchTextField
。
// UISearchTextField.h
UIKIT_CLASS_AVAILABLE_IOS_ONLY(13.0)
@interface UISearchTextField : UITextField
// ...
@end
@interface UISearchBar (UITokenSearch)
@property (nonatomic, readonly) UISearchTextField *searchTextField;
@end
但是仅在 iOS 13 以上系统支持,还是暂时用遍历view的方式去做了😂
navigationBar:shouldPopItem:
点击导航栏返回的时候Crash了,控制台输出提示:
Теrmіnаtіng арр due to uncaught exception' NSInternalInconsistencyException' ,
reason : ' Override of -navigationBar : shouldPopItem: returned YES after
manually popping a view controller ( navigat ionController=<MHCRNavgationController : 0x106039400>) '
因为我们工程里,基本上所有的 Controller
是继承基类 BaseViewController
并实现- (BOOL)naviBack:
方法,用于实现在用户点击返回和策划返回时,一些不能返回的特殊处理。
其根本原理是通过实现 UINavgationBar
的代理方法 - (BOOL)navigationBar:shouldPopItem:
来做的控制:
- (BOOL)navigationBar:(UINavigationBar *)navigationBar
shouldPopItem:(UINavigationItem *)item {
// 默认可以返回
BOOL canGoBack = YES;
// BaseViewController定义协议方法判断能否能点击返回上一层
UIViewController *vc = self.viewControllers.lastObject;
if ([vc isKindOfClass:BaseViewController.class]) {
canGoBack = [(BaseViewController *)vc naviBack:nil];
}
if (canGoBack) {
[self popViewControllerAnimated:YES];
}
return canGoBack;
}
但是我实现的时候有 Return YES
啊!想了想,试着 注释 了[self popViewControllerAnimated:YES]
,发现没有崩溃了。
但是在iOS 12上,会发现控制器没有回到上一层,如图,只有navbar回到上一层了:
好吧,那只能判断一下版本解决这个问题了,修改方式:
- (BOOL)navigationBar:(UINavigationBar *)navigationBar
shouldPopItem:(UINavigationItem *)item {
// 判断 iOS 版本低于13
BOOL bellow13 = !@available(iOS 13.0, *);
// 默认可以返回
BOOL canGoBack = YES;
// BaseViewController定义协议方法判断能否能点击返回上一层
UIViewController *vc = self.viewControllers.lastObject;
if ([vc isKindOfClass:BaseViewController.class]) {
canGoBack = [(BaseViewController *)vc naviBack:nil];
}
if (canGoBack && bellow13) {
// 如果低于13且可以返回,就执行popViewController
[self popViewControllerAnimated:YES];
}
return canGoBack;
}
夜间模式
WWDC 19 直播的时候看到夜间模式,老实说挺开心的,直到我用 Xcode 11 开始做适配,妈耶!x N
注意:使用 Xcode 10 编译的 App 依然是日间模式,不会产生效果!!!
初步扫了一下出现的问题如下图,大致情况是:没有设置背景色的系统控件会被设置成黑色,部分控件是tintColor没设置的话也会被改。
由于Assets里的Color配置是 iOS 12 以上才能使用的,所以如果没有做全局主题色设计且需要支持 iOS 12 以下设备,改起来会比较恶心。
对此现象,找设计师沟通。设计师表示,暂时没有精力做夜间模式规划。
设计师问:能否强制只日间模式?
答:能。配置方式有两种,单页面配置
和 全局配置
。
-
单页配置
将需要配置的
UIViewControler
对象的overrideUserInterfaceStyle
属性设置成UIUserInterfaceStyleLight
或者UIUserInterfaceStyleDark
以强制是某个页面显示为浅/深色模式
-
全局配置
在工程的
Info.plist
的中,增加/修改UIUserInterfaceStyle
为UIUserInterfaceStyleLight
或UIUserInterfaceStyleDark
。
2019.07.26 补充: 早上刚好看到知识小集发了篇 适配 Dark Mode 的文章,看了下挺好的,推荐阅读。
Pod私有库校验报错找不到simulator
推 Cocoapods 私有库校验的时候,收到一个报错:
- ERROR | [iOS] unknown: Encountered an unknown error (Could not find aiossimulator
(valid values: ). Ensure that Xcode -> Window -> Devices has at least
oneiossimulator listed or otherwise add one.) during validation.
直觉告诉我是 cocoapods 的问题,去其 github 仓库的 issues 搜了一下,没有搜到 xcode 11 相关的,然后去 google 了一下,看到了这个问题:
cocoapods-cant-find-simulators-pod-repo-push-fails
里面有一条
After installing Xcode 11, pod lib lint is broken again because of fourflusher - The "availability" key from
xcrun simctl list -j
is now a boolean "isAvailable"
但是这个fourflusher的路径我找不到,可能自己的ruby环境不太一样,那么gem会不会支持反查一个工具的位置呢?
通过 gem help
看了下使用说明,发现可以用gem help commands
查找所有gem的指令。
其中就有一个which
指令,描述上说是用来找库文件位置的。
# 使用gem which来查找位置
gem which fourflusher
果然出现了:
/Users/HY/.rvm/gems/ruby-2.4.1/gems/fourflusher-2.2.0/lib/fourflusher.rb
对应的知道 fourflusher
的位置,那么接下来就可以修改了。
- 前往
/Users/HY/.rvm/gems/ruby-2.4.1/gems/fourflusher-2.2.0/lib/fourflusher/
- 打开文件
find.rb
- 查找
device['availability'] == '(available)'
- 增加一个判断
device['isAvailable'] == true
即可
修改结果如图即可: