前言:
iOS開發(fā)中,一般情況下我們希望后臺服務(wù)器都返回字符串給我們(我們直接使用NSString *)類型的變量來接收....
但是,后臺boy們,總是喜歡肆意返回各種類型的數(shù)據(jù).曾經(jīng)我和后臺協(xié)商過多次,希望他們?nèi)坑米址祷?可是他們說,有的數(shù)據(jù)他們不好轉(zhuǎn)換為字符串類型.于是返回的數(shù)據(jù)都是各種類型.那么下面的梗來了...
- 后臺返回數(shù)值型數(shù)據(jù)給我們,而我們不清楚數(shù)據(jù)類型時,使用NSString來接收
例如后臺返回的json數(shù)據(jù)是
data:{
peopleNum:12345
price:200
}
其中peopleNum和price均是數(shù)值型,我們現(xiàn)在來解析他們(先假設(shè)有2個label用來顯示這2個數(shù)據(jù))
NSString *peopleNum=dict[@"peopleNum"];
NSString *price=dict[@"price"];
self.labPeopleNum.text=peopleNum;
self.labPrice.text=price;
你會發(fā)現(xiàn),程序執(zhí)行到self.labPeopleNum.text=peopleNum; 這行代碼的時候,崩潰了...并報下面的錯誤
reason: '-[__NSCFNumber rangeOfCharacterFromSet:]: unrecognized selector sent to instance
我們簡要分析下這個錯誤發(fā)生的原因:
這個錯誤是說...NSNumber類型的變量沒有rangeOfCharacterFromSet這個方法的定義....
那么我們仔細(xì)查看發(fā)現(xiàn): rangeOfCharacterFromSet這個方法是NSString的方法...
回過頭來,我們在賦值peopleNum給labPeopleNum.text的時候,其實底層就做了一次這個rangeOfCharacterFromSet方法,造成了崩潰...
總結(jié):深究此處的原因是什么呢?? 那就是因為后臺返回的peopleNum數(shù)據(jù)是數(shù)值型數(shù)據(jù),不是字符串.....到我們客戶端以后呢,我們會把數(shù)值型數(shù)據(jù)轉(zhuǎn)換為NSNumber類型的數(shù)據(jù)...因而應(yīng)該修改下上面的代碼,把接收到的peopleNum轉(zhuǎn)換為NSString類型即可:
NSNumer *peopleNum=dict[@"peopleNum"];
NSNumer *price=dict[@"price"];
self.labPeopleNum.text=[NSString stringWithFormat:@"%@",peopleNum];
self.labPrice.text=[NSString stringWithFormat:@"%@", price];
2.后臺大牛們,還經(jīng)常喜歡返回NULL數(shù)據(jù)給我們,然后造成崩潰.不知道大家有沒有深受其害哈....處理這個問題的方法比較多了,
<1>如果你是用AFNetWorking的話,可以看下下面:
/**
Whether to remove keys with `NSNull` values from response JSON. Defaults to `NO`.
*/
@property (nonatomic, assign) BOOL removesKeysWithNullValues;
那么我們只要把這個removesKeysWithNullValues=YES.這樣的話,后臺返回的JSON數(shù)據(jù)中空的鍵值對,將會被自動刪除,可以避免我們對這些空值做操作,造成崩潰問題
<2>還有一種就是gitHub上比較流行的NullSafe了,不過我還沒用過這個哈..
3.還想說個比較深入的問題,不知道廣大iOS開發(fā)者,你們現(xiàn)在的"上拉下拉刷新"使用的是什么樣的機(jī)制...如果你公司使用的是"page-limit策略",那么就恭喜你中獎了(可能你公司的測試會來找你的麻煩)...
有的人,我上拉加載數(shù)據(jù)的時候,page++,然后訪問服務(wù)器拿新的limit條數(shù)據(jù),這沒有什么問題啊??
其實這個問題呢,和我們客戶端沒什么大的關(guān)系,這個算是后臺在考慮列表問題上的不全面不仔細(xì)的問題...
下面來分析下這么做會遇到什么問題呢:
當(dāng)我們在顯示完page=1的時候,我們正準(zhǔn)備上拉加載更多的時候,此時服務(wù)器數(shù)據(jù)庫中在這前10條數(shù)據(jù)中新插入了一條數(shù)據(jù)...此時我們上拉加載更多,你會發(fā)現(xiàn)出現(xiàn)了2個數(shù)據(jù)一樣的Cell.
總結(jié):其實這里就是 采用"page-limit"策略造成的問題了,因為服務(wù)端臨時有新的數(shù)據(jù)插入,導(dǎo)致數(shù)據(jù)增多,我們page++的時候,正好把前page的第limit數(shù)據(jù)擠到page+1上了..造成了數(shù)據(jù)重復(fù)顯示
那么怎么解決這個問題呢??
其實服務(wù)端應(yīng)該采用"id++"的策略來解決這個問題,就是每次從一個id開始,往后請求"limit條"數(shù)據(jù)回來...
PS:每天一篇文章,記錄iOS開發(fā)的點點滴滴,喜歡我的文章,就點擊"關(guān)注我"吧...
