坑1:关于UITextField限定长度.
需求很简单.就是限定一个UITextField的字符长度在n个中文之内(中英文均有可能).
首先,需求中有中英文的要求,那么如何计算长度呢,很简单:
lengthOfBytesUsingEncoding
1个中文长度等于3个英文长度.在UITextField的代理里面直接搞定它.
- (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string{
NSString *strWhenChanged = [textField.text stringByReplacingCharactersInRange:range withString:string];
return [strWhenChanged lengthOfBytesUsingEncoding:NSUTF8StringEncoding] <= 9;
}
似乎好了,测试一下,好像不那么对劲,当字数满了以后,无法删除了.
ok,继续改进
- (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string{
if ([string isEqualToString:@""]){
return YES;
}
NSString *strWhenChanged = [textField.text stringByReplacingCharactersInRange:range withString:string];
return [strWhenChanged lengthOfBytesUsingEncoding:NSUTF8StringEncoding] <= 9;
}
好了,可以删除了.到了规定字符数以后也无法继续输入.可是,问题又来了,全拼键盘的联想仍然能用.
妈蛋,我们关了它
textfiled.autocorrectionType = UITextAutocorrectionTypeNo;
啊,好像没用...还是可以联想.而且有个特别严重的问题,点击联想的文字,代理并不会触发!
替换成通知好了,我们使用通知:
UITextFieldTextDidChangeNotification
在使用一个屌屌的属性:
markedTextRange
就可以啦.
不过还有一个问题,如果规定n个字符,如果超过n个字符是截断呢还是干脆就置空?截断似乎要好很多.
我们需要做一个递归的截断方法:
extension String{
func limitLengthByUTF8(limitedLenght: Int) -> String{
if self.lengthOfBytesUsingEncoding(NSUTF8StringEncoding) <= limitedLenght{
return self
}
else{
let limitedStr = self.substringToIndex(advance(self.endIndex, -1))
return limitedStr.limitLengthByUTF8(limitedLenght)
}
}
}
最终是这样的:
[[NSNotificationCenter defaultCenter] addObserverForName:UITextFieldTextDidChangeNotification object:nil queue:nil usingBlock:^(NSNotification *note) {
UITextField *field = (UITextField *)note.object;
if(field.markedTextRange){
return;
}
field.text = [field.text limitLengthByUTF8:45];
}];
坑在哪里?
流着眼泪的说,我用的是第三方输入法(百度).测试的时候,这个点根本没出任何问题.第三方输入法有自己的toolbar,联想的时候并不会造成代理不响应的情况.
切记切记,一定在开发中要使用原生的输入法进行测试啊.
坑2:坑爹的联系人
又出问题了!怎么问题这么多!
有一个需求是读取联系人列表,然后进行各项操作,诸如分类(A-Z),筛选之类的.在分类的时候,使用CFStringTransform获取联系人拼音首字母,的确会有一些资源消耗.
在普通情况下,一两百个联系人的时候,并没有明显的卡顿,所以当时也没有做异步的操作.
可是,在测试的时候,居然出现了非常明显的卡顿,这...
遇上bug,首先修改为异步,dispatch_async走起.
然后查询为何会卡顿.
通过查询,不可思议的一幕来了:200来个联系人,居然有3000多个电话号码!
无法理解,无法理解,继续抓虫!
通过打印,发现了如下的情况,在系统电话本中如图所示:
原来,这就是安全卫士类的软件(360等)拦截骚扰电话的数据库.
那么怎么来的呢?很有可能是从其他地方导入.
目前没有特别好的办法处理,不知道大家有没有好的方案?
我暂时只想到2种:
是找寻此种号码的规律,将其忽略.不过因为样本不足,此种方法未被采纳.有360,还有百度,还有腾讯,未来还有xxx卫士啊.
当单个联系人中超过n个号码的话,就判定该联系人为非正常联系人.n根据情况设定.当然这种方法有错杀的风险.
的确有可能有人会把公司当做一个联系人,所有的同事的联系方式都建立在该公司(联系人)下.不过这种方式蛮蠢的,毕竟无法搜索...
