戲畫地雷: [ios]xcode 無痛開發之路 (xcode操作/ project setting欄位介紹 / coredata / ui layout / 編譯 / 打包ipa / 上傳至itunes connect )

藉由本篇，來對筆者在兩個月內密集遇到的ios開發問題做一個記錄。方便之後查找，也希望能夠幫到其他人。

第一步：認識*.xcproj。其實這只是一個目錄(從命令列才看得出來。要使用finder觀看的話要在檔案上面按滑鼠右鍵，選擇「觀看包裝內容」... apple quality)。其內容如下：

*. xcworkspace ：記錄著此project的xcode的設定，也是一個目錄... 內容不研究。
*.pbxproj：記錄著此project的所有設定。像是compile流程相關，檔案包含，檔案路徑相關資料。要注意的是，同時有兩人以上編輯同一個檔案，加入同樣的檔案，出來的結果會不一樣。因此在多人開發的環境，建議在pbxproj有檔案變動的時候，只由一人commit，其他人pull update之後再由一個人做add/更改自己的檔案的動作，然後commit，直到全部做完。

第二步：認識project setting。筆者認為是整個iosapp開發流程裡面最重要的步驟。因為只要一踏出xcode的自動保護之外，編譯錯誤隨之而來，而且還不一定會提示該怎麼解。

總之先點選project，讓xcode顯示設定。

文字編輯的方法：把游標移動到條目上面，在條目上面滑鼠點一下左鍵，可以編輯整條文字。條目之間xcode是以半形空格分開(也因此強烈不建議路徑/檔名等等命名有空格)。編輯完畢要讓設定值有效，建議按一下Enter鍵。有時候直接移動編輯的游標至其他條目，會被當做是cancel，而不一定會套用新的設定值。滑鼠點兩下的話會打開編輯框，條目的增減使用編輯框左下角所顯示的「+」「-」符號操作。

圖上的1：要操作project的設定的時候，必須點選此地方才會顯示設定。同時這個區域也是xcode的project檔案列表。xcode的檔案列表跟實際的檔案目錄結構不一定會同步，沒有列在這裡的檔案，xcode就不知道它的存在。另外，除了資源類的檔案之外，建議使用黃色的「Grouping」資料夾，不要使用藍色的路徑資料夾。就如圖上所顯示的xcode預設的設計。

雖然藍色的路徑資料夾會自動的增減檔案，但是不易分辨檔案的編譯列表跟打包列表的增減會不易判斷。在「Grouping」資料夾刪檔，檔案可以選擇保留，不會消失，而編譯列表跟打包列表會自動除名該檔案。

拖拉檔案進入這個列表的時候，會出現對話框選擇target，請仔細選擇。沒勾選到的target在編譯時就不會含入此檔案。(可以之後按照檔案類型，自行在後面提到的「Build phase」區加入)
圖上的2：若是此紅框的區域沒有出現，請先點選「2」左側的藍色icon，此區域就會出現。
圖上的3：切換設定值分類的地方。
圖上的4：build scheme。指定目前build/run的設定值。左半部可以切換target setting(下面會提到)，右半部用來切換執行的硬體。執行的硬體分成三類：
・實機(把iphone接上macbook之後就會出現在選項內)，
・「General Device」(製作app的專用選項。發現Products->Archive被設成灰色無法輸出app檔案的時候，應該是build scheme沒有被改為「General Device」)，
・各種simulator device。
另外要提的是，把游標停留在左半部，按滑鼠右鍵，可以選擇「edit scheme」，裡面可以調整build scheme為debug mode還是release mode。有助於debug 只有release mode會遇到的問題。筆者第一次用到這功能，是在debug release mode之後發現假如有使用compiler的optimization，會導致block宣告回傳null...暫定方案是關閉compiler的optimization，目前還沒找到正式的解決方案。
圖上的5：顯示當時在「2」區域所指定的檔案或是檔案內的可視元件的相關設定。像是程式碼檔案的話就會顯示「Target Membership」，語系檔案的話就會顯示可以勾選Localization的設定，layout相關的話就可以指定class name，layout參數等等。

圖上的2：project setting 跟target setting的不同：
project只有一個，裡面放置的是project共通的設定。target setting可以有很多組。可以把它當成用同一套程式碼產生不同的app。

project setting，主要的調整參數以Tab分成兩區(圖上的數字「3」的區域)：

Info區：

Deployment target：直接選擇最新版。目前(ios11.2)的時代也不支援ios7以下的版本了。
Localizations：可以增減此project支援的語言。是xcode一個不易理解的部分。目前只知道以下的規則：
・各種資源檔(除了project相關檔案/程式碼(.m/.h等等)/lib跟framework/datamodel/xcassets以外的檔案)都可以被Localization。
・Localize過的檔案，在finders裡面看到的會是在「xxxx.lproj」資料夾內。xcode內部的擺放運作方式：「以該檔案的路徑，建立一個「xxx.lproj」目錄，然後移動該檔案進去該資料夾」。

要注意的是，自行照此規則去做(建立資料夾跟擺檔案進去)，xcode是認不得的。建議的操作流程：用finder/命令列把檔案copy到project下面想擺放的目錄，然後拖進xcode視窗左方的檔案列表裡面的想要擺放的目錄(上圖的「1」區)，在xcode的project的檔案列表內按左鍵點選該檔案，再到xcode視窗右側選擇想要進行Localizations的語言。
・勾選「Use Base Internationalization」的話，「Development Language」的語言目錄不會出現在project的檔案資料夾，而會以「Base.lproj」代替。
・同一個檔案用在多個語言，xcode的做法是自動複製成為多個檔案。所以改動其中一個語言的檔案內容，其他語言的檔案並不會被更動。
・如何修復沒有Localizations的project(會發生在把Localizations的所有語言都砍掉的狀態，這時想要建立Localization會因為列表內無檔案而無法建立。apple quality...)：在project的根目錄裡面建立一個「Base.lproj」目錄，然後放一個可以被Localize的檔案進去，然後到Localizations下面勾選「Use Base Internationalization」，這時就可以看到列表內有檔案。
・NSLocalizedString()若是該語言裡面沒有該字串的替代字，並不會使用「Development Language」(Base)的替代字，請注意。

Build Settings區：這邊建議全部不要動。因為Target也有一樣的Build Settings，而且設定值會是以Target的為優先。

設定完project的整體設定之後，接下來點選TARGETS裡面的project name，來設定target setting。要新增target，圖上的2區的下方有「+」「-」符號可以操作。

設定的項目非常多。本篇只談筆者遇到有做調整的地方。這樣就寫不完啦...

General區：

Display Name：app在系統桌面上所顯示的名稱。若是給空值的話，xcode會自動用灰色補上 Info.plist 裡面所給定的「Bundle Name」的值。
Bundle Identifier：app的辨別id。會影響到app儲存在系統裡面的路徑。只能使用英文字(有分大小寫)，數字，「-」，「.」。官方建議以reverse domain name的格式命名。像是「com.yourcompany.yourappname」。跟android的app相同的是，在app store上架之後就不能改。
Version：app的版本編號。只能使用數字跟「.」，建議以「(主版號).(副版號).(小修改編號)」三個數字的方式編寫。例如「1.0.1」。上架之後，版號數字在上架的時候只能增不能減。
Build: 必須為數字。通常是定義為編譯次數，不過xcode不會自動累加... 此數值在上架的時候只能增不能減。
Automatically manage Signing：也是ios一個很麻煩的地方。
要讓連接到mac book的iphone可以debug app，必須先到 apple developer 註冊帳號，建立「iOS Certificates」(必須使用osx系統裡面的key chain access app去要求apple的server給出CSR，然後把CSR上傳到apple developer，從apple developer下載證書，再安裝到keychain access裡面)，註冊app，註冊iphone(測試機必須註冊)，建立provisioning profile(這步完成之後，Automatically manage Signing就會正確運作)。
Team：「Automatically manage Signing」設定完成之後這邊就有選項可以選，或是可以線上從apple developer，或是在不使用「Automatically manage Signing」的狀態，import從apple developer下載來的provisioning profile。
Deployment target：直接選擇最新版。目前(ios11.2)的時代也不支援ios7以下的版本了。
Devices：可以選擇「iphone」「ipad」「universal」。選擇預設値「universal」即可。
Main interface：指定app在顯示完launchscreen之後，首先呈現的xib/storyboard file。這個參數會根據main.m裡面的delegate的導入方式而有不同的處理方法。假如習慣完全用程式碼處理，可以不設定此欄位，直接在delegate裡面去讀取想要呈現的xib/storyboard file。
Device Orientation：指定此app支援的螢幕旋轉方向。
App Icons Source：指定app在系統桌面上顯示的icon。必須在project裡面擁有「*.xcassets」的檔案，並在裡面增加「AppIcon」，下拉選單才會有選項可選。「*.xcassets」路徑的增加方法：在project的列表內，點選要增加檔案的目錄，按滑鼠右鍵選擇「Add file」，跳出來的視窗選擇「Asset Catalog」。
然後在該Asset Catalog裡面點選新增檔案，再選擇「App Icon」，然後依照指定大小拖拉檔案進去。請一定要用選取的方式新增「App Icon」，新增非「App Icon」的image，不會出現在下拉選單裡面。
注意：AppIcon若是「Devices」的設定為「Universal」，必須加上ipad支援的格式的圖。沒有的話，在上傳到itunes connect的時候就會出錯。若是原本的AppIcon沒有勾選ipad的話，滑鼠點選AppIcon之後到視窗右邊欄選擇最右邊的icon，出現的選項裡面就會有ipad可以勾選。
Launch images source：指定app起動的時候首先顯示的圖檔。筆者不建議使用。因為使用這方法，必須在「Asset Catalog」裡面新增「launch image」。還必須因應各種不同的螢幕size跟螢幕轉向，裁切xcode指定長寬的圖，非常惱人而且佔空間。
Launch Screen File：指定app起動的時候首先顯示的storyboard/xib檔名。不需要指定副檔名，iOS起動app的時候會自己找.storyboard或是.xib。
這是替代「Launch images source」的方法。好處是可以藉由storyboard提供的auto layout功能，達成只要提供一個啟動頁的layout就可以解決所有機型的問題。
Embedded Binaries：指定app在輸出的時候，需要跟app一起打包的libraries跟framework。iOS內建的lib跟framework以外的都需要加進來。
若是不知道該加哪些的話，可以先不加，在app 的linking階段出現找不到function的時候再一個個加進去修正，或是在debug的時候發現xcode console出現「dyld: Library not loaded」的時候再加也是可以。

但是有一些第三方的library不能加。像是Fabric跟Crashlytics...加了之後在release app的export階段會出現錯誤「Found an unexpected Mach-O header code: 0x72613c21」。推測是framework裡面有含入一些app相關的設定檔(像是 Info.plist之類的)。
Linked Frameworks and Libraries：指定此target會用到的Frameworks and Libraries。要使用ios內建的Frameworks and Libraries，必須使用此選項的「＋」號才會出現列表，也才能找到想用的東西並加入target裡面linking兼使用。

Build Settings區：
參考圖：

Valid Architectures：編譯的cpu架構。需要自己加的選項有「arm64」(iphone5以後)，「x86_64」(iphone模擬器)，「armv7」(watchos)。概念：iphone的cpu已經全部都是64bit，即為「arm64」。ios app的開發平台(macbook)的模擬器(simulator)，cpu架構是macbook用的cpu：x86_64，因此想在iphone跟xcode的模擬器都可以執行app，「arm64」跟「x86_64」是必須加進去的。有使用到第三方，非原始碼的lib或是framework，也要注意該lib有沒有包含需要的cpu架構。確認的方法：「lipo -info [library name]」
Build Active Architectures only：是不是只編譯目前所指定的硬體(上圖的「4」號區域裡面可以選擇)裡面所記載的cpu架構。建議啟用。
因為xcode要是在後面會談到的設定「Embedded binaries」裡面有放lib，在做app的release的時候會check lib的bitcode，xcode要求「Embedded binaries」的lib，只能包含「該裝置支援的架構的程式碼」。若是在simulator上面開發，之後要release的時候，要是需要導入的library不支援動態載入，必須以「Embedded binaries」的方式含入的話，可能要做framework search path的切換。
Supported Platforms: 選項有「macOS」「iOS」「tvOS」「watchOS」。根據app的目標使用平台選擇。
Complier for C/C++/Objective-C ：選擇預設值「Defalut Compiler(Apple LLVM 9.0)」。
Debug information format：設定為預設值「DWARF with dSYM file」
Enable Bitcode：iOS9之後的新功能，建議啟用。以apple的習慣，說不定不久之後會要求強制啟用。使用的library或是framework不支援bitcode的話，opensource的lib可以自己編譯成帶有bitcode。付費的lib，直接要求lib的提供者support吧。
Other Linker Flags：建議加上「-ObjC -v」。「-ObjC」的作用是將所有的.obj都產生object-c class。有用到第三方Framework/lib的話必須加上此選項，才能使用selector的語法來call c的function，否則只能用C的傳統function call的方法。「-v」可以讓linker輸出比較多資料，方便判斷編譯錯誤的原因。
Info-plist file：為重要參數。指定「Info.plist」的檔案路徑(不一定等於project內的路徑)。所有的target都必須要有一個「Info.plist」檔案。可以針對不同的target，準備不同的plist檔案因應不同需求。因為預設的檔案名稱為「Info.plist」，在多個.plist同時存在的project，一般建議的命名方式為「<target name>-Info.plist」。
Product Bundle Identifier：跟General 區的「Bundle Identifier」相同。修改的時候會相互影響，可以當成是同一個參數。
Product Name：預設會以「$(TARGET_NAME)」做為參考值。
Framework Search Paths：指定需打包進app的Framework的檔案搜尋路徑。不過因為第三方的framework在做release的時候，.a檔案必需只有該app的對象的硬體的cpu 架構，例如給iphone/ipad的就只能有arm64，不能包含x86_64(但是debug階段想要同時在simulator跟測試硬體上跑，卻又要兩種都有)，結果還是得在不同
Header Search Paths：指定Header檔案的搜尋路徑。一般用在導入library的時候，該lib所附帶的header檔。有指定路徑的話，沒加到project file list的header檔案也可以被搜尋到而不會出現compile error。
Library Search Paths：指定lib檔案(通常附檔名為「.a」)的搜尋路徑。有指定路徑的話，沒加到project file list的lib檔案也可以被搜尋到，而不會出現compile error。
Optimization Level：建議設定為None。debug一定要設為None，否則中斷點可能會不正常動作。release也建議設定為None，因為前面有提到，遇過一個跟最佳化有關的問題：假如有使用compiler的optimization，會導致block宣告回傳null...暫定方案是關閉compiler的optimization，目前還沒找到正式的解決方案。
Prefix Header：指定在各個檔案編譯的時候一定會含入的檔案名稱(不需在程式碼檔案內指定)。像是把大量的constant放在一個檔案裡面指定的時候，將該檔案指定為Prefix Header，就不需要在每一個程式碼檔案裡面import它。
Obj-C Automatic Reference Counting(ARC)：基本上目前的第三方開源lib大部分已經使用ARC方式開發，建議project不要使用之前的MRC的方式開發。強制使用MRC不只得自己控制release的方式，對於ARC的程式碼，跑起來可能會出現無法預期的問題，也只會徒增自己麻煩。

Info區：
內容等同於「Info.plist」。在build setting區的「Info-plist file」設定檔案「Info.plist」之後，切到這個區域的時候就會自動帶入「Info.plist」的內容。大部分的設定値，跟General區的類似名稱的項目有關。

新增條目：把滑鼠游標放在已存在的條目上面，條目的右邊會出現「＋」「-」符號。點選「＋」就會新增條目，點選「-」就會刪除該條目。
Bundle Name：對應的xml tag為「CFBundleName」。若是要套用General Tag提過的「Display Name」的設定值的話，可設定為「${PRODUCT_NAME}」。想根據不同語言而有不同的顯示名稱的話，必須將Info.plist給多國語言化才行。
Bundle identifier：若是Info.plist 要套用General的設定值的話，參數為「$(PRODUCT_BUNDLE_IDENTIFIER)」
Main storyboard file base name：等同於General區的「Main interface」裡面的設定。修改文字的話，兩邊的値會互相影響。
Launch screen interface file base name：等同於General區的「Launch Screen File」的設定。一樣不需要指定副檔名。
Bundle version string. short：等同於General區的「Version」的設定。修改文字的話，兩邊的値會互相影響。
Localization native development region：預設值是：「$(DEVELOPMENT_LANGUAGE)」，但是「$(DEVELOPMENT_LANGUAGE)」要修改，從xcode的ui操作相當麻煩。一般的建議方法是關閉xcode，到.xcodeproj裡面直接修改.pbxproj的「developmentRegion」。

Build Phases區：

Compile Sources：需要編譯的程式碼。只有放在這裡的程式碼檔案才會被編譯。
只擺.m就好，不要擺.h(header檔)。

執行project file list的檔案新增與刪除的動作，會提示該檔案要加到哪個target內。在此時有勾選或是加入project file list之後有點選該檔案並操作該檔案的「Target Membership」(這選項在視窗右側)的話，xcode也同時會在這個列表增刪檔案。不過因為這個列表可以手動操作，在編譯的時候遇到缺function，可以來這個列表確認檔案是不是有放進來。
此選項也可以一次大量增加需要編譯的檔案，因為要增加編譯程式碼的檔案，只有這個選項的「＋」所跳出的列表框可以多選檔案。而且這個列表不會列出重複檔案，可以防止因為檔案重複加入此列表而產生的linker錯誤：Duplicate symbol。同樣的，發現Duplicate symbol，直接來這個設定找看看有沒有重複定義同一檔案。
Link Binary with Libraries：這個列表的內容會跟General區的「Linked Frameworks and Libraries」相同。對其中一個列表做修改，結果也會相互影響。全新的project，一開始沒有任何的Framework加入的狀態，會看不到這個設定區。
Copy Bundle Resources：所有app相關的資源檔案(Info.plist / Assets / 圖檔 / strings / raw file / xib / storyboard / ssl證書等等) 都要加在這裡。沒加入的話，在執行階段就會拿不到檔案...
Embed Frameworks：這個列表的內容會跟General區的「Embedded Binaries」相同。對其中一個列表做修改，結果也會相互影響。全新的project，一開始沒有任何的Framework加入的狀態，會看不到這個設定區。

「Link Binary with Libraries」跟「Embed Frameworks」的差異：目前還沒有研究透徹。只知道「Link Binary with Libraries」加入之後，在compile階段才不會找不到function。使用ios內建的framework，只要加入「Link Binary with Libraries」就好。
第三方的framework，建議除了加入「Link Binary with Libraries」，也要加入「Embed Frameworks」。這樣app的執行階段才不會發生動態載入找不到檔案的問題。(錯誤訊息：dyld: Library not loaded:Reason: image not found)

備註：一小部分參照用的參數命名
    $(TARGET_NAME)：就是target name。
    $(PRODUCT_NAME)：Build Setting區的「Product Name」。
    $(PRODUCT_BUNDLE_IDENTIFIER) ：Build Setting區的「Product Bundle Identifier」
    $(EXECUTABLE_NAME)：執行檔名。
    $(DEVELOPMENT_LANGUAGE)：app的預設語言。
    $(CONTENTS_FOLDER_PATH) : 一個以Build Setting區的「Product Name」為參考值的參數。會自動加上「.app」做尾修飾。
    $(PRODUCT_NAME:c99extidentifier) ：一個以Product Name為參考值的參數。會在Productname前面加上底線符號修飾。
    $(PROJECT_DIR) ：project的根目錄。常用在指定檔案path相關的設定。
$(SRCROOT)：程式碼的根目錄。在xcode的環境下，內容等同於$(PROJECT_DIR)。
    $(inherited)：在Target setting裡面繼承Project setting同欄位的內容。

到這裡，算是把project的設定都走完一遍了。
開發相關：

Obj-C的編譯器已經會自動判斷是不是有重複include header檔案。不過還是要避免兩個.h檔案互相依賴的導入方式，會產生預料之外的狀況。
LaunchScreen使用xib或是storyboard的方式顯示，可以獲得自動layout的好處，不過還是無法以程式碼操作LaunchScreen階段所顯示的View的內容。
class/method宣告方式：
「定義」放在.h的@interface內。修飾放在@interface的大括弧外面。
「實作」放在.m的@implementation內。
都需要用@end結尾。
一個.h可以放多個@interface。
@interface也可以跟method一起放在.m裡面。對於不會跟其他檔案共用的interface，可以用這方法減少.h檔案的數量。
self = java/c++的this.
變數宣告：
全域宣告：跟c一樣為static。
宣告變數的位置的關係：
@interface的大括弧內宣告，scope相當於@protected。
@interface的大括弧外宣告，scope相當於@public。
@implementation內，function定義之外的變數宣告，相當於@private 的static宣告。
在Object-C 2.0，使用「@property」修飾字宣告參數，系統會自動幫你產生setter / getter。在@implementation內也不需要使用「@synthesize」去產生setter / getter。要注意的是，使用「@property」修飾字宣告參數，在interface內部所產生的變數名會在其名稱前加上底線「_」。
要注意的是，這做法是建立在該interfce是繼承自NSObject的前提之下。
範例：
@interface Ball : NSObject {
NSString *name;
}
@property(nonatomic, retain) NSString *name;

在@implementation裡面操作，會發現「self.name」(property預設的getter)跟「self->name」(c的pointer style getter)是不同的變數位置。若是把大括號裡面的宣告移除，使用箭號存取，將只能存取「self->_name」。

另外，setter的用法如下：「self setName:(NSString*)」
訊息運算式「[]」只能存取setter/getter。
點跟箭號運算式可以直接存取物件內部參數。
property的getter還可以使用「[obj valueForKey:@"propertyName"]」的方式執行。
方法(method,function)的宣告：
前置符號為"+"代表為class method(static method)。
宣告方式(在@interface內)：
+ (return type) methodA: (parameter typeA) paramNameA parameterNameB: (parameter typeB) paramNameB
使用方法為「[ClassName methodA: 參數1 parameterNameB: 參數2 (以此類推)]」。
實作的宣告，與interface的宣告相同。
前置符號為"-"代表為object method.
宣告方式(在@interface內)：
- (return type) methodA: (parameter typeA) paramNameA parameterNameB: (parameter typeB) paramNameB

使用方法為「[objName methodA: 參數1 parameterNameB: 參數2 (以此類推)]」。
實作的宣告，與interface的宣告相同。
繼承了NSObject的class的constructor： ClassName *c = [[ClassName alloc]init];。
alloc/init為NSObject的預設function。都可以被override。
NSArray：只能置入繼承NSObject的物件。

layout相關

新增xib檔案的方法：在project上面點滑鼠右鍵，New File->User Interface ->empty view
新增一組.xib/.h/.m的方法：在new file時選擇「Cocoa Touch Class」。
Files Owner：這個xib所代表的class。「不一定」是可視元件。一般的用法是讓viewcontroller可以載入頁面(Files Owner為viewcontroller)，也可以設計一個ui元件套組，這時Files Owner就會是可視元件。
修改完Custom Class請記得打完字之後要按Enter，這樣interface builder才會套用該class。
在interface builder(點選xib/storyboard檔案之後所顯示的介面)指定了view的custom class之後，interface builder右上方的箭頭符號裡面的「Outlets」的數量，是以該custom class的.h裡面定義的「@property (nonatomic, retain) IBOutlet UIclassname *classname」跟繼承的父interface的IBOutlet共同決定。
interface builder在設定Custom class的名稱的時候，要讓系統自動幫你預測class name的話，必須先建好該class的@interface定義。
「拖拉」關聯：設定好Files Owner的custom class之後，Files Owner的outlets區就會出現custom class有宣告IBOutlet的變數。這時就可以把滑鼠停留在變數右邊的圈圈，圈圈會變成「＋」號。然後按著滑鼠左鍵，開始移動滑鼠，就可以「拖拉」，到該變數想存取的ui元件上面放開滑鼠左鍵，就會發現IBOutlet被指定為該ui元件，這樣Files Owner（custom class）才能存取到該元件。
Constraint：讓xcode自動加所有的constraint，通常會導致預料之外的結果。建議ui元件會散佈滿整個畫面的layout(像是登入頁面)，使用相對式constraint的方法：xib的最底層view指定一個固定的長寬，並視需要指定是不是要擴展到填滿superview（方式：加上指定上下左右四周的距離為0的constraint），然後view裡面的各ui元件的位置，使用距離superview的中心點的距離來指定。
畫面下方是可捲動列表的layout，就可以用一般由上而下的layout。

補充：指定相對座標的constraint的加法：先點選要操作的ui元件，增加一個「相對距離」的constraint。 (此例為指定「相對於ui元件下緣」。)
在圖中的「Add new constraints」的正方框的上面的紅色虛線「工」符號的地方用滑鼠點選，「工」符號就會成為實線。然後再點選下方的「Add 1 constraint」。

這時會發現，要是旁邊有兩個以上的ui元件，xcode會以靠最近的元件做為標記對象。
標記對象不是想要的元件的話，就要點選想修改的constraint。
（要更換為另一種constraint的話，就得刪掉該constraint再加另一種，無法直接修改constraint的種類）

如下圖，「First Item」，意為「操作元件」。點選之後出現的下拉選單，上層為「參考點」，可以設定為「元件的上緣(Top)」，「元件的中線(CenterY)」等等。下方為操作元件的名稱。
「Second Item」，意為「目標元件」。點選之後出現的下拉選單，上層一樣為「參考點」，下方可以選擇對齊的目標元件名稱，也可以選擇對齊superview。
若是有元件名稱重複，建議修改元件名稱。點選元件的名字就可以修改。

在切換完對齊的對象之後，xcode會重新計算以目前元件位置，距離參數會是多少。所以要視需要調整距離參數，調整到想要的位置。

IBAction:
定義ui元件action的連結者使用。xib 的File's owner(custom class)定義IBAction之後，把該IBAction跟xib的widget的event「拖拉連線」。
拖拉方式有兩種：跟IBOutlet一樣的從File's owner的「Received Actions」(Custom class有定義IBAction之後就會出現)拖拉到ui元件上放開，就可以選擇該元件的action列表。
也可以反向從ui元件的Sent Events拖拉到「File's owner」上面。這時會出現的列表只有File's owner有定義的IBAction。

因為IBAction是統一介面，跟android設計不同的是，得在進去function之後才能判斷是哪個元件發送，還有event的內容。

app至少要有一個UIWindow。
app至少要有一個UIViewController。UIViewController下面一定要掛一個view。（也就是xib的File's owner為UIViewController的時候，outlets裡面的「view」要連到xib裡面定義的最底層view。）
navigation contoller，初始拖拉進入lauout區的時候會自動加上一個tableviewcontroller。若是不使用table的話，需要手動刪除，再拖拉一個其他的vc進去。(記得檢查元件連線)

系統相關：

app進入點：檔案通常為main.m。function定義必須為「int main(int, char*)」。
xcode在新建project之後，main.m會是這樣的內容：
int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}
其中的AppDelegate為xcode自動建好的檔案，也需要使用者去做修改，就是繼承UIApplicationDelegate的UI進入點。若是不在Info.plist裡面指定「Main storyboard file base name」，可以在AppDelegate的「didFinishLaunchingWithOptions」的實作裡面，自行對delegate的windows property(也就是self.window)做window的初始化流程。

ios的app，一定要有一個window。在做過self.window = [[UIwindow alloc]init];之後，下一步就是掛上該window的rootViewController(self.window.rootViewController)，之後就是持續的對ViewController做處理，進入一般的ios app開發流程。
其實不以程式碼做window/delegate的初始化也是可以的。有在Info.plist的「Main storyboard file base name」指定storyboard的話，因為storyboard會自動初始化window，所以在storyboard的layout裡面掛上自定義的viewcontroller之後就可以進入一般的開發流程。

若是在Info.plist的「Main storyboard file base name」指定xib檔，雖然系統不會自動初始化self.window，卻可以在xib檔內使用拖拉window object到layout上面的方式初始化window，還可以用拖拉一個Object到layout上面，指定它為「AppDeleagate」，讓main.m的初始程式碼不須指定AppDelegate。
例：先把main.m的初始動作的delegate拿掉：
int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, nil);
    }
}

點選要成為主頁載入使用的xib檔，在xib檔顯示的狀態下，先把File's Owner的Custom class命名為「UIApplication」(請記得打完字之後要按Enter，這樣interface builder才會套用該class)，然後在視窗的右下角列表裡面拖拉一個「Object」到layout顯示區，Custom class命名為「AppDelegate」，然後再拖拉一個「Window」到layout顯示區，然後把files'owner的outlet的delegate跟「AppDelegate」連線，再拖拉一個viewcontroller，Custom class命名為自定義的view controller，再跟「Window」的outlet裡面的「rootViewController」連線。在自定義的viewcontrolle的viewDidLoad下個斷點，執行debug app就會發現自定義的viewcontroller會被執行到，就可以進入一般的開發流程。
通常主頁載入使用的xib不會放任何UI元件。就算是小到只有單頁的app，也會把主頁載入使用的xib當成空頁，把主頁xib的viewcontroller的Custom Class指定為自定義的view controller，把UI元件的layout放在xib+viewcontroller的組合內。

需要換頁的app，主頁xib的viewcontroller 自然是要套上navigation controller，
或是套上tab controller 當做tab式開發的主描述頁。一樣把UI元件的layout放在xib+viewcontroller的組合內。
新增一組xib/vc的方法：在new file時跳出的視窗選擇「Cocoa Touch Class」。
@interface宣告，除了繼承的宣告之外，其他的介面連接「<>」的宣告，也可以到.m裡面才指定。例：

在.h裡面宣告：
@interface AppDelegate : UIResponder <UIApplicationDelegate>
{...}
@end

在.m裡面宣告：
@interface AppDelegate()<ViewControllerADelegate>
@end

這樣的AppDelegate其實繼承了兩個interface：UIApplicationDelegate跟ViewControllerADelegate。

編譯/linking相關問題：

「ld: embedded dylibs/frameworks are only supported on iOS 8.0 and later」：project properties->General -> Deployment Info : change Deployment target to over IOS8
implicit LOGE definition : project properties-> Build Settings -> Apple LLVM X.X - Language -> C Language Dialect : change to "C99"
ib documents for earlier than ios 7 -> 修改所有的xib檔的「build for xxx」，建議設定為「Build target」。
dyld: Library not loaded:Reason: image not found -> add these frameworks into 「project properties-> General -> Embedded binaries」
This app has crashed because it attempted to access privacy-sensitive data without a usage description. -> 有用到contacts等等個人資料。看是要不用個人資料，還是加上app的個人資料使用申請：「NSContactsUsageDescription」
Duplicate symbol -> 把該log行所在的整個linker的log使用滑鼠點擊「more」打開，觀察哪些symbol報告重複。也有可能是因為重複放了同一個.m檔案。到「Build Phase」區的「Compile Sources」檢查看看。

執行階段：

若是使用iphone/ipad等等硬體裝置debug，必須到apple developer console進行裝置認證的動作。先啟動macbook的keychain access(在launchpad的「其他」資料夾) -> 點選螢幕上方的「keychain access」 -> 「憑證輔助程式」->「從憑證授權要求憑證」。user的email address填上itunes帳號的email位置，ca電子郵件不用填，下面的選項選擇「儲存到磁碟」，可勾選的選項不要勾，點選下一步，建立signing request「CertificateSigningRequest. certSigningRequest」檔案。
然後到apple的開發者後台 https://developer.apple.com/ 點選左列表的「cerfificates」的任一項，依照release的需求選擇「iOS App Developement」或是「App Store and Ad Hoc」，上傳前一步做好的CSR，developer console就會建立cerfificates。然後一定要下載到macbook裡面，用滑鼠點擊兩下匯入keychain。注意：匯入keychain要admin權限才能做此事。
另外，以上的動作若是使用自動管理證書的話，做過第一次之後，要是證書過期也會自動更新。
編譯的時候出現「codesign wants to use "login" chain」的話，要輸入登入用的密碼。有時候會出現非常多個一樣的框框，只能乖乖的一次次輸入密碼...
以上的動作，要是按了「否」，會發現之後編譯都不會出現框框，然後就一直失敗在codesign的動作。解決方案是啟動kaychain access (launchpad -> 其他 ->kaychain access)，然後選擇畫面上方的app menubar的「File」->「Lock All Keychains」。然後再Build就會再度出現「codesign wants to use "login" chain」的密碼輸入框了。
apple developer console第二步：建立Identifiers(app的上架資訊)。就算是只拿來硬體debug使用也還是要新增。「App ID Description」填上app的「Bundle Idetifier」。
apple developer console第三步：加入devices，此步驟需要取得手機的UDID。(把手機接在macbook，使用xcode新增simulator的時候就會顯示接在macbook的手機的UDID。)
apple developer console第四步：產生Provisioning Profile。這一步就只有選項，就不截圖了。這步完成之後，xcode選擇自動管理簽名的話就會自動下載簽名的管理機制(Provisioning Profile)，之後xcode會自動處理簽名的流程。
This app has crashed because it attempted to access privacy-sensitive data without a usage description.
-> 有用到contacts等等個人資料。看是要不用，還是在Info.plist裡面加上「NSContactsUsageDescription」。

release階段：

Code Sign error : Command /usr/bin/codesign failed with exit code 1 : 把keychain access裡面所有過期的apple developer下載過的證書全部移除。只能留一組最新的。
provisioning profile doesn't include signing certificate : keychain access的證書幫手裡面的「從認證中心要求簽名」的項目，產生「CertificateSigningRequest. certSigningRequest」並儲存之後，到apple developer產生Certificates之後，必須手動下載然後安裝到keychainaccess。沒做此步驟的話就會出現此錯誤。
Found an unexpected Mach-O header code: 0x72613c21
... Fabric and Crashlytics framework 不可以放在 embedded framework。把這兩個framework放在"linked framework and libraries".
Failed to verify bitcode: release的app只支援iOS的話，不可以包含x86的架構的framerwork或是lib。project-> (select target ) -> Build settings : 拿掉x86 / x64 architecture.
在app thinning的時候出現ipa tool error : 在出現error之前直接按下一步跳過去。

Adhoc測試/上傳至itunes connect：

編譯的第一步：螢幕上方的tool menu選擇「Product」->「Archive」。
上一步的Archive做完之後，會出現一個視窗。選擇右邊的「Distribute App」（舊版xcode的選項是「Export」），出現新的視窗再選擇「Ad Hoc」就可以輸出Adhoc用的.ipa檔案。
itunes connect跟developer console的使用者資料是不同的。雖然帳號是同一個... 加入該服務跟email認證的動作也都要分開執行。
itunes icon改放到xcassets內了。原本指定在Info.plist裡面的CFBundleIcon/ CFBundleIcons等等的設定必須拿掉。
ERROR ITMS-90502: 拔掉iphone跟macbook的連線。 (此為ios版本相容的問題。) 也有可能是apple store上傳有問題(需等apple自己解決)
所有的AppIcon必須是png格式。
編譯期間要是出現「mdwrite wants to use "metadata" chain」，先不管它。過30秒之後應該會跳出「codesign wants to use "access" chain」一樣輸入osx的登入密碼。等到編譯完成之後再關閉「mdwrite wants to use "metadata" chain」的框框。
ITMS-90032: "Invalid Image Path - No image found at the path referenced under key xxxxx ：把所需要的App Icon補完。目前所知道的必須Icon：Iphone App 2x 60pt / App Store IOS 1024pt。有打勾ipad的話就需要ipad格式的。app不支援ipad的話要取消ipad的打勾，才不會一直被itunes抱怨。

上傳之後會需要一些時間，才會在itunes connect上面看到。然後需要填「出口資訊」，填完之後apple才會發出通知信給「測試人員」。

debug：

EXC_BAD_ACCESS：意指存取到已經被釋放的物件。應該只有在非ARC模式會遇到。現在都是ARC模式開發應該很難遇到。(就算想要回到老路，別人寫的程式碼也早就ARC化了...)
app有用到ssl加密，出現seccertificatecreatewithdata returns null:
必須把.pem格式(檔案內容看起來是文字編碼)轉成der格式(憑證內容為二進位檔格式)。
指令：在macbook的文字指令模式執行「openssl x509 -outform der -in <憑證檔名>.pem -out <憑證檔名>.der 」
如何debug release mode app：使用停止方塊右邊的target select，點選之後裡面有個「Edit scheme」來切換build scheme為release。

CoreData 'This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.' -> 原因可能是同時有兩個thread在同時access。coredata不是thread safe.

Core Data相關：

Entity：把它想成是sql的table。
建議的做法：使用xcode new一個data model, 設定完property，
游標focus住datamodel file，Edit->Create NSManagedObject subclass->產生四個檔案：
[Entity name]+[CoreDataProperties].h
[Entity name]+[CoreDataProperties].m
[Entity name]+[CoreDataClass].h
[Entity name]+[CoreDataClass].m

以程式碼的角度來看，Entity就是「CoreData Class」。
要利用自動產生的CoreData Class，import的起點：
#import "[Entity name]+CoreDataClass.h"
自行alloc/init CoreData Class，在使用該class的setter/getter的時候會出錯。必須使用以下方法初始化CoreData Object：
NSEntityDescription *entityDescription = [NSEntityDescription entityForName:<CoreData Class name> inManagedObjectContext:managedObjectContext];

<CoreData Class name>* coredataClassObject = (<CoreData Class name>*)[[NSManagedObject alloc] initWithEntity:entityDescription insertIntoManagedObjectContext:nil];
「Relationship」：在目前的Entity加上一個欄位，該欄位的內容是另一個Entity。
「Inverse」：要是另一個Entity也有關聯到目前的Entity(也就是兩個Entity互相關聯)，就可以選擇另一個Entity的關聯用欄位。

有設定Relationship的Entity，會自動產生setter「add<Relationship欄位名稱>Object」的function。

假設現在有EntityA跟EntityB相互關聯，EntityA的EntityB關聯欄位名稱為「EntityBs」（此欄位為陣列，可以存入多個EntityB）。EntityB的EntityA關聯欄位名稱為「EntityAs」。

現在有CoredataObject objEntityA跟objEntityB，執行[objEntityA addEntityBObject: objEntityB] ，在objEntityA被insert之後，objEntityB會自動被加入EntityB，Relationship也會自動被建立。(查詢到objEntityA，會發現objEntityA.EntityBs欄位會掛上objEntityB，objEntityB的EntiyAs欄位會掛上objEntityA)。

關聯的截斷跟重建：使用查詢的動作取回objEntityA，執行[objEntityA removeEntityBObject]，然後執行[managedObjectContext save:&error]，objEntityA之後再查詢就不會帶回objEntityB。但是objEntityB依然存在於EntityB(使用查詢EntityB的動作依然可以查到)。一樣的，可以再把objEntityB加回去objEntityA的關聯欄位。
假如所定義的core data entity有跟其他的entity做關聯(Relationship)，在執行「Create NSManagedObject subclass」輸出定義檔之後，會發現無法compile。這是因為輸出的定義檔不會自動#import關聯的entity的header檔案(apple quality...)。
需要自行到「[Entity name]+CoreDataProperties.h」加入「#import "[Relationship Entity name]+CoreDataProperties.h"」
core data debug：建議以simulator來debug，因為可以直接觀察db的資料。
一般的儲存path會使用以下設定：
NSURL *appDocDirectory = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];

NSURL *dbPath = [appDocDirectory URLByAppendingPathComponent:@"db.sqlite"];

所儲存的sql檔案位置「file:///Users/<macbook username>/Library/Developer/CoreSimulator/Devices
/<device id>/data/Containers/Data/Application
/<app id>/Documents/"」
把breakpoint停留在dbPath後面就可以取得。然後找一套osx可用的sqlite browser直接打開db.sqlite檔案即可。

戲畫地雷

2018年3月6日火曜日

[ios]xcode 無痛開發之路 (xcode操作/ project setting欄位介紹 / coredata / ui layout / 編譯 / 打包ipa / 上傳至itunes connect )

0 件のコメント:

コメントを投稿