網頁

顯示具有 iOS 標籤的文章。 顯示所有文章
顯示具有 iOS 標籤的文章。 顯示所有文章

2021年11月4日 星期四

舊案一直出現 Error: objc_msgSend Calls Too many arguments to function call, expected 0, have 4

 一個很舊的案子去年改過最近重啟加新需求,去年沒事今年卻出現"Too many arguments to function call, expected 0, have 4"的Error,看了看是objc_msgSend這個造成,但看define: "objc_msgSend(id _Nullable self, SEL _Nonnull op, ...)"也看不出來有4個,3個應該也行吧,Google了下Too many arguments to function call, expected 0, have 3中提到https://github.com/th-in-gs/THObserversAndBinders/blob/master/THObserversAndBinders/THObserver.m,根本跟有幾個參數無關,第一個先將"Apple Clang-Preprocessing"中的"Enable Strict Checking of objc_msgSend Calls"改成NO,然後在用到objc_msgSend前面要加參數的型態,如

objc_msgSend(target, action, selectedDate, origin)
改成 => ((void(*)(id, SEL, NSDate*, id))objc_msgSend)(target, action, selectedDate, origin)

這樣就能解決這error了


參考網址:

objc_msgSend()報錯Too many arguments to function call ,expected 0,have2

Too many arguments to function call, expected 0, have 3

2020年9月6日 星期日

解決UITableView的Grouped型態的Section間會有空隙

為了讓Section不會一直停留在最上方,將UITableView的style改成UITableViewStyleGrouped。但卻發現第二個section和第一個seciont的最後一個元素隔一大段空白,查半天看到的StackOver都沒有但打勾確認,不過實際測了下Space Between Sections in UITableview的解決,如下面程式碼就能解決了,其實不能回傳0是要注意的,就直接給個比0大的值就好

- (CGFloat)tableView:(UITableView *)tableView heightForFooterInSection:(NSInteger)section{
    return 0.00001f;
}


參考網址:

Space Between Sections in UITableview

2020年9月4日 星期五

iOS上架遇到出口合資訊這怪問題

上傳iOS app後,點選建置版本後,跳出回應"出口合規資訊"這樣的問題,查半天看半天大家都選否,也不是很清楚,APP TestFlight缺少出口合規資訊是寫了這是很久前的規定"很久很久之前美國政府不允許採用高強度加密的套件,必須改成弱強度的加密方式",蘋果提交版本後顯示”缺少出口合規證明“的解決辦法這邊倒是有特別寫個解法,最後選了否......再看看狀況吧


參考網址:

https://www.ptt.cc/bbs/MacDev/M.1513654588.A.92C.html

APP TestFlight缺少出口合規資訊

蘋果提交版本後顯示”缺少出口合規證明“的解決辦法

解決"ERROR ITMS-90339: "This bundle is invalid. The Info.plist contains an invalid key 'UIApplicationExitsOnSuspend' in bundle"

 上架上傳app時遇到個Error,"ERROR ITMS-90339: "This bundle is invalid. The Info.plist contains an invalid key 'UIApplicationExitsOnSuspend' in bundle XXX [XXX.app]""


看半天,看到UIApplicationExitsOnSuspend key issue. How do I fix it?有寫,對著info.plist按右鍵,點選"Show Raw Keys/Values",倒是真的出現UIApplicationExitsOnSuspend,將它拿掉就可以過了

參考網址:

UIApplicationExitsOnSuspend key issue. How do I fix it?


2020年8月14日 星期五

Xcode舊專案改用Automatic Sign發生〞Set the provisioning profile value to "Automatic" in the build settings editor, or switch to manual signing in the Signing & Capabilities editor.〞 Error

平時都是用手動指定憑證發布app,但剛好有舊案可以使用自動的,就改成自動,結果一直發生"Set the provisioning profile value to "Automatic" in the build settings editor, or switch to manual signing in the Signing & Capabilities editor.",查半天,看到升级Xcode 10后遇到的问题提到清空User defined中的PROVISIONING_PROFILE,Target及Project設定都要改。

改完後,最好是Automatically manage signing的勾選取消再勾回,選Team,重開XCode。

參考網址:

升级Xcode 10后遇到的问题

2020年3月15日 星期日

Xcode 10.1編譯舊專案出現了'sqlite3_key' is invalid in C99的Error

依然是舊專案的問題,出現了'sqlite3_key' is invalid in C99的Error,查了下看到這篇sqlite3_key is invalid in C99 iOS11,看起來在iOS10是正常的,仔細想了下猜測是compiler版本問題,我的Xcode是10.1,就回到Xcode -> Preferences,點擊Locations,找到Command Line Tools,選Xcode 8.3.1,重開再compiler就OK了

參考網址:
sqlite3_key is invalid in C99 iOS11

升級到Xcode 9.3後出現Expected method to read dictionary element not found on object of type 'id'

開啟多年未開的專案想要compile時一直出現Expected method to read dictionary element not found on object of type 'id<NSFastEnumeration,NSObject>'的錯誤訊息,仔細查看,是PromiseKit這個library在xcode 9.3後會有的問題,查半天都是講用cocoapods升級PromiseKit到1.7.2就OK了,打下pod update後,又出現其他專案的Error,仔細一看發現一個根本不能update的Library,問題最後只能是直接解決這error,反過來想,只好去查看這Framework針對這issue的commit,最後找到Fix build on Xcode 9.3,修改如下



有種怎沒想到這樣改的蠢想法,不過又有種這像是workaround的感覺!!

參考網址:
Objective C- Xcode 9.3 - Expected method to read dictionary element not found on object of type
Fix build on Xcode 9.3

2020年1月3日 星期五

NSDate在2019年12月30日發生年度變成2020年的一年誤差問題

這幾天發生個怪問題,上傳的資料時間居然從2019-12-30變成2020-12-30,每筆資料都一樣,用的是NSDateFormatter這些內建的函式庫,怎麼看都沒問題著實奇怪,Google了下發現iOS NSDate转成时间戳出现一年的误差提到,仔細一看才發現全都是用YYYY這寫法,在ISO週日曆有解釋計算方式,大概可以簡單的去想成1/1那週從週一開始的都會是新的一年,所以還是都用yyyy小寫,除非您是要算成此週為哪一年的會計年度這種需求

參考網址:
iOS NSDate转成时间戳出现一年的误差
ISO週日曆

2018年8月26日 星期日

單純秀文字時,最好是直接使用UILabel,而不要用UITextView

最近想說直接UITextView重覆使用,不能編輯時直接將它偽裝成UILabel,但真正使用時發現,UITextView使用sizeThatFits計算出來的高度,常常莫名的最底下一行會截掉,但換用UILabel時就沒這問題,看起來單純秀文字時,還是使用UILabel比較不會有奇怪狀況發生。

-–-更新-–-
後續發現主要是計算時算出來的是浮點數,但UIView在使用時大多都無條件捨棄小數點,變成就會有少1 pixel的問題

2018年3月15日 星期四

修改app的顯示名稱

開發iOS的APP,依然沒有很全面的看過所有資料,導致有些簡單的動作都做不到,例如:改iOS的名稱,不過這次不是單純的顯示名稱,應該說是iOS app本身的名稱,這在setting中是指Production name,在Build Settings中找到Product Name,一般是寫"${TARGET_NAME}",在這邊就大方的改成你要的名字吧,這樣在企業版上架(一般企業版都會有自己的Store),就可以正確顯示了

2017年12月5日 星期二

UITableView的beginUpdates及endUpdates在iOS 11後行為有變動,造成原本cell的展開不正常

最近案子有個表單是會隨時依使用者的點選變動cell的高度或加入cell,在iOS11出現前都很正常,但最近裝置更新成iOS11後,最後一列的展開會無法出現,但按第二次就正常,非常奇怪,查了半天,看起來在iOS11之前的UITableView的beginUpdates及endUpdates只會讓每個cell的heightForRowAtIndexPath執行一次,但iOS11開始,會執行三次左右,且cellForRowAtIndexPath取得的cell可能為nil,不是每次都如此,最後改使用reloadData就沒有這個問題,但這應該也只是暫時解法,若cell太多或裡頭資料太多,可能造成些效能上的問題

2017年9月29日 星期五

"Values of type 'NSUInteger' should not be used as format arguments; add an explicit cast to 'unsigned long' instead"的處理

在XCode中一直出現"Values of type 'NSUInteger' should not be used as format arguments; add an explicit cast to 'unsigned long' instead",參考String Format Specifiers文件中所提使用"lu 或 lx"卻都沒用,後來看到清理iOS工程中的Warnings其中提到

Values of type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long' instead

在模拟器和真机上,NSInteger是不同的类型定义:
#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
  typedef long NSInteger;
  typedef unsigned long NSUInteger;
#else
  typedef int NSInteger;
  typedef unsigned int NSUInteger;
#endif
在格式化字符串时,使用'%ld'会在真机中报该警告。解决办法:
  • use %zd for signed, %tu for unsigned, and %tx for hex.

(以上出自清理iOS工程中的Warnings)

這才將這討人厭的warning去除 @@

參考網址:
清理iOS工程中的Warnings

2017年9月22日 星期五

更新成XCode 9.0時出現"Conflicting types for 'SecRandomCopyBytes'"

開機後被要求更新XCode APP,想說沒差,結果更新完就出現"Conflicting types for 'SecRandomCopyBytes'",還剛好下午要demo,這下可好,連編譯都Fail,查半天看起來是iOS11後不再支援32Bit,而RNCryptor看起來有相容到10.6,查到Conflicting types error in Xcode 9 #248,看起來可以用底下的code就解決了,不過似乎也是讓他可以compiler

#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000
extern int SecRandomCopyBytes(SecRandomRef rnd, size_t count, void *bytes) __attribute__((weak_import));
#else
extern int SecRandomCopyBytes(SecRandomRef rnd, size_t count, uint8_t *bytes) __attribute__((weak_import));
#endif

參考網址:
Conflicting types error in Xcode 9 #248
ios11 beta error #17
This method(SecRandomCopyBytes) is wrong in Xcode 9 Beta #244

2016年5月5日 星期四

iOS APP要求送審要能支援IPv6

發現iOS要求送審要能支援IPv6 @@

https://developer.apple.com/news/?id=05042016a

2015年2月20日 星期五

iOS開發筆記 - What is ObjC

之前老是在Other linker flags設定-ObjC,總是不大懂為什麼,查了下,在Technical Q&A QA1490 - Building Objective-C static libraries with categories中提到如下:

The -ObjC Linker Flag

Passing the -ObjC option to the linker causes it to load all members of static libraries that implement any Objective-C class or category. This will pickup any category method implementations. But it can make the resulting executable larger, and may pickup unnecessary objects. For this reason it is not on by default.
看起來簡單的解釋是:要載入其他用Objective-C寫的靜態library,要設定這個flag。而這個flag也有造成執行檔肥大的問題。

這倒讓我想到那有可能不用這個設定嗎???

參考網址:
What does the -ObjC linker flag do?
Technical Q&A QA1490 - Building Objective-C static libraries with categories

2014年1月26日 星期日

iOS開發筆記 - iOS6及iOS7的Status bar的Interface問題

在iOS6及iOS7上,最上面的Status bar最大不同就是一個是佔了20px,一個是變成可以使用且讓電池或訊號的影示浮貼在上面。但這就造成一個很大的問題,在iOS6上面看來好好的,到了iOS7上就往上移了20px,在Interface builder上往下調20px,在iOS6上也真的往下調了20px,這真完全不是我要的,而偏偏我沒有用autolayout(說實在是不知道怎使用,跟storyboard一樣難用),找半天發現Interface builder多了底下的調整選項


這部分就是調整兩者間的差距,例如我這邊選的UIImageView的大小是548*320,在iPhone5的iOS6的是正常的,但在iOS7就會整個往上移了20px,所以要像底下這樣設定
Y設20,但iOS 6/7 Deltas的△Y部分要設-20,這樣這UIImageView在這兩個系統中都是在你想要的位置上了。


參考網址:
Supporting iOS 6
iOS 7 is out, but we can't completely forget about iOS 6 just yet.
點我參考Apple的iOS 7 UI轉換指南PDF

2014年1月23日 星期四

iOS開發筆記 -放入舊的SDKs

弄完了PHP的單元測試,回過頭來看看iOS的,下載了最新的xCode 5.0.2(安裝網址)並安裝後,發現整個介面變了,完全是iOS 7的介面。這這這!!!第一個想到的是那SDK 6.0會不會也不在了,開Terminator
$ cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
$ ls -l

果然剩iOS 7.0了,其實是沒太大的差別,以前也一直都這樣,不過這次改變實在太大,加上舊專案都還在用,還是最好有舊的SDK比較放心,查了下資料,可以去下載以前舊的xcode版本或找出舊版xcode,好在我都有備份,將dmg打開,開Terminator,基本上都是放在/Volumes,目錄名稱叫Xcode
$ cd /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/
$ ls

我這邊是看到iPhoneOS6.1.sdk,所以就
$ mkdir /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
$ cp -ri iPhoneOS6.1.sdk/ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk

其他版本也一樣的做法。

How To Support Old iOS SDK’s in Xcode 5文中提到
Update: @rekle points out that it’s possible to get older versions of Xcode from the Downloads area of the Apple Dev Center. Even once Xcode 5 hits the App Store, it should still be possible to get an old SDK version.
有申請開發帳號的人,可以點擊get older versions of Xcode,登入後找以前的版本下載

PS. 建議是在安裝前,先將這目錄下的原SDK都先備份起來,若有同名的,當然是以新的為主

參考網址:
iOS 5 SDK is gone after upgrade to Xcode 4.5
How To Support Old iOS SDK’s in Xcode 5

2013年9月2日 星期一

iOS開發筆記 - int8_t及Byte的小差別

在寫iOS app時,宣告byte陣列使用時(尤其是在網路封包的raw data上),我個人在查資料時,最常見的是int8_t,不過在我實際使用上,卻發現一個小差別,最好還是用Byte,例如:

int8_t aa = (int8_t) 0xe0;
Byte bb = (Byte) 0xe0;


NSlog(@"data: %02x",aa);  --> 顯示:e0
NSlog(@"data: %02x",bb);  --> 顯示:e0

像上述這樣寫,是沒有差別的,使用上是ok的,但如果是接收資料再從NSData轉換過來就有不同了,例如,假設NSData *aa的第一個元素是e0

int8_t *rawData = malloc(sizeof(int8_t) * aa.length);
[aa getBytes:rawData length:aa.length];
NSlog(@"data: %02x", rawData);  --> 顯示:ffffffe0

Byte *rawData = malloc(sizeof(Byte) * aa.length);
[aa getBytes:rawData length:aa.length];
NSlog(@"data: %02x", rawData);  --> 顯示:e0

若要直接操作byte元素,還是最好用Byte會比較不會有不知名的錯誤。

2013年8月19日 星期一

iOS開發筆記 - 取消圖示上的光影

有個需求要取消圖示上半圓的光影,印像是將Prerendered打勾,不知道為什麼一直取消不掉,只好找下資料,看到的方法都一樣,記錄在底下:

1. 先在專案 Target 的 Summary 標籤頁下找到 App Icons項
2. 在 “Prerendered” 打上鉤。
此时在info.plist里会多出一个配置项 "Icon already includes gloss effects"
3. 再找到 “Icon files (iOS 5)” 專案(如果有的話)展開,把裏面的 “Icon already includes gloss effects” 設置成 “YES”

不過仔細用以往的經驗想了下,可能是Resources被cache,只好"Command"+"Shift"+"K",先清一清專案重新編譯,裝置原本裝好的刪掉,再重新裝上去,就ok了

2013年8月14日 星期三

iOS開發筆記 - NSArray及NSDictionary的writeToFile: atomically:存檔失敗,但無Exception

NSArray及NSDictionary有個方便的writeToFile的function可以用,但發現若是裡頭有個元素是NSNull時,存檔會失敗,而且還沒有任何的exception,一般在使用時,是不會想到用NSNull,但我主要是在用AFNetwork時,發現它在解析JSON時,若null的元素會直接設NSNull。

推敲原因,猜測是因為NSNull並沒有實作Archive(實作了也很奇怪),而內定的Class都有,所以若有可能取得的NSArray及NSDictionary之中有元素可能有NSNull,要記得writeToFile前,先將那個元素remove或設成內定Class或能Archive的元素,才能成功儲檔。