Mac應用程序編程指南(一)

注:原文引用Mac開發官方文檔,鑒于Mac開發文檔較少,本人主要做一下梳理,同時記錄學習過程。


Mac應用環境

(1)設計易于使用的環境

使用Cocoa為OS X編寫應用程序。

*用戶不必手動保存工作。Cocoa中的文檔模型提供了保存用戶基于文件的文檔而無需用戶交互的支持;請參閱文檔架構免費提供許多功能

*應用程序應在登錄時恢復用戶的工作環境。Cocoa提供對歸檔當前狀態的應用程序界面的支持(包括未保存文檔的狀態),并在啟動時恢復該狀態;請參閱用戶界面保存

*應用程序應該支持自動終止,以便用戶永遠不必退出。自動終止意味著當用戶關閉應用程序的窗口時,應用程序似乎退出,但實際上只是靜靜地移動到背景上。優點在于隨著應用程序簡單地回到前臺,隨后的啟動幾乎是即時的。請參閱自動和突然終止應用程序改善用戶體驗

*您應該考慮通過實施用戶界面的全屏版本為用戶提供身臨其境的全屏體驗。全屏體驗消除了外界的分心,并允許用戶關注其內容;請參閱實施全屏體驗

*支持觸控板手勢,在您的應用程序中進行適當的操作。手勢為常見任務提供簡單的快捷方式,可用于補充現有的控件和菜單命令。OS X通過正常的事件處理機制提供對您的應用程序報告手勢的自動支持;參見可可事件處理指南

*考慮最小化或消除用戶與原始文件系統的交互。通過打開和保存面板將整個文件系統公開給用戶,通過iPhoto和iTunes的方式,一些應用程序可以通過專門為應用程序內容設計的簡化瀏覽器中呈現用戶內容,從而提供更好的用戶體驗。OS X使用一個定義明確的文件系統結構,可以輕松放置和查找文件,并包含許多訪問這些文件的技術;請參閱文件系統

*對于支持自定義文檔類型的應用程序,請提供Quick Look插件,以便用戶可以從您的應用程序外部查看文檔;請參閱快速編程指南

*應用程序應該支持OS X用戶體驗的基本功能,使應用程序優雅直觀,例如直接操作和拖放。用戶應該保持控制,收到一致的反饋,并且能夠探索,因為該應用程序是寬容的動作;請參閱macOS人機接口指南

所有上述功能都可以由Cocoa支持。


(2)運行環境的低級細節

*并發和線程

每個進程都以單個執行線程開始,并可根據需要創建更多的線程。雖然可以創建直接使用POSIX和其他更高級別的接口線程,最好是間接創建它們使用塊對象GCD操作對象,通過Cocoa并發技術NSOperation類。

GCD和操作對象是簡化或消除通常與線程編程相關的許多問題(如同步和鎖定)的原始線程的替代方法。具體來說,它們定義了一個異步編程模型,其中只指定要執行的工作和要執行的順序。系統然后處理在當前硬件上盡可能有效地安排必要的線程和執行任務所需的繁瑣工作。不應該使用GCD或操作進行需要時間敏感數據處理(例如音頻或視頻播放)的工作,但您可以將其用于大多數其他類型的任務。

有關使用GCD和操作對象在應用程序中實現并發性的更多信息,請參閱并發編程指南

*文件系統

Finder不會將整個文件系統暴露給用戶,而是隱藏普通用戶不需要使用的任何文件和目錄,例如低級UNIX目錄的內容。應用程序仍然可以訪問他們具有有效權限的任何文件和目錄,無論它們是否被Finder隱藏。

創建應用程序時,您應該了解并遵循與OS X文件系統關聯的約定。知道放置文件的位置以及如何從文件系統中獲取信息可確保更好的用戶體驗。文件系統中的每個文件都有其位置,應用程序需要知道將它們創建的文件放在哪里。通過App Store分發應用程序,這尤其重要。

列出了應用程序通常進行交互的目錄。

Applications directory

應用程序的安裝目錄。但是,全局應用程序目錄的路徑是/Applications每個用戶目錄可能包含一個包含用戶特定應用程序的本地應用程序目錄。不需要直接使用此路徑。要訪問應用程序包中的資源,使用NSBundle對象。

Home directory

應用程序的配置決定了應用程序看到的主目錄的位置:對于在OS X v10.7及更高版本的沙箱中運行的應用程序,主目錄是應用程序的容器目錄。有關容器目錄的更多信息,請參閱鑰匙串

對于在沙箱外運行的應用程序(包括在10.7之前運行的OS X版本的應用程序),主目錄是/Users包含用戶文件的用戶特定子目錄。要檢索到主目錄的路徑,請使用該NSHomeDirectory功能。

Library directory

Library目錄是用于存儲私人應用程序相關數據和首選項的頂級目錄。有幾個Library目錄分散在整個系統中,但是您應該始終使用位于當前主目錄內的Library目錄。

不要將文件直接存儲在Library目錄的頂層。相反,將它們存儲在此表中描述的特定子目錄之一中。

在OS X v10.7及更高版本中,Finder默認隱藏用戶主文件夾中的Library目錄。因此,不應該將該文件存儲在您希望用戶訪問的目錄中。

要獲取此目錄的NSLibraryDirectory路徑,請使用NSUserDomainMask域的搜索路徑密鑰。

Application Support directory

應用程序支持目錄是您的應用程序存儲支持應用程序的任何類型的文件,但該應用程序不需要運行的文件,例如文檔模板或配置文件。文件應該是特定于應用程序的,但不應該存儲用戶數據。該目錄位于Library目錄下。

不要將文件存儲在此目錄的頂層:始終將它們放在為您的應用程序或公司命名的子目錄中。

如果資源適用于系統上的所有用戶,例如文檔模板,請將其放入/Library/Application Support。要獲取此目錄的NSApplicationSupportDirectory路徑,請使用NSLocalDomainMask域的搜索路徑密鑰。如果資源是用戶特定的,例如工作區配置文件,請將它們放在當前用戶的~/Library/Application Support目錄中。要獲取此目錄的NSApplicationSupportDirectory路徑,請使用NSUserDomainMask域的搜索路徑密鑰。

Caches directory

緩存目錄是存儲緩存文件和其他臨時數據的位置,您的應用程序可以根據需要重新創建。該目錄位于Library目錄下。

不要將文件存儲在此目錄的頂層:始終將它們放在為您的應用程序或公司命名的子目錄中。您的應用程序負責在不再需要時清除緩存數據文件。系統不會從此目錄中刪除文件。

要獲取此目錄的NSCachesDirectory路徑,請使用NSUserDomainMask域的搜索路徑密鑰。

Movies directory

電影目錄包含用戶的視頻文件。要獲取此目錄的NSMoviesDirectory路徑,請使用NSUserDomainMask域的搜索路徑密鑰。

Music directory

音樂目錄包含用戶的音樂和音頻文件。要獲取此目錄的NSMusicDirectory路徑,請使用NSUserDomainMask域的搜索路徑密鑰。

Pictures directory

圖片目錄包含用戶的圖像和照片。要獲取此目錄的NSPicturesDirectory路徑,請使用NSUserDomainMask域的搜索路徑密鑰。

Temporary directory

臨時目錄是您存儲不需要在應用程序啟動之間持續存儲的文件的位置。您通常將此目錄用于臨時文件或與應用程序持久數據無關的其他類型的短命名數據文件。該目錄通常從用戶隱藏

您的應用程序應盡快從此目錄中刪除文件。在系統啟動時,系統還可以從該目錄中清除滯留文件。

要獲取此目錄的路徑,請使用該NSTemporaryDirectory功能。

清單1-1顯示了如何檢索Application Support目錄的基本路徑,然后向其附加一個自定義應用程序目錄的示例。

清單1-1獲取Application Support目錄的路徑

NSFileManager * fileManager = [NSFileManager defaultManager];

NSURL * appSupportDir = nil;

NSArray * urls = [fileManager URLsForDirectory:NSApplicationSupportDirectory inDomains:NSUserDomainMask];

if([paths count]> 0){

appSupportDir = [[url objectAtIndex:0] URLByAppendingPathComponent:@“com.example.MyApp”];

}

有關如何訪問公知系統目錄中的文件的更多信息,請參閱“文件系統編程指南”

與文件系統交互

*區分大小寫

HFS +文件系統是不區分大小寫的,但也可以區分大小寫。因此,在代碼中指定文件名和目錄時,最好假定區分大小寫。

*路徑建設

使用NSURLNSString類的方法構造路徑。NSURL由于能夠指定本地文件系統中的路徑,而是指定網絡資源的路徑,因此該類優先于路徑構建。

*文件屬性

可以使用類的getResourceValue:forKey:error:方法檢索許多與文件相關的屬性NSURL。您還可以使用NSFileManager對象來檢索許多與文件相關的屬性。

*文件權限

使用訪問控制列表(ACL)和BSD權限管理文件權限。系統盡可能使用ACL來指定文件和目錄的精確權限,但是當沒有指定ACL時,它會回退到使用BSD權限。

默認情況下,您的應用程序創建的任何文件都由當前用戶擁有并提供適當的權限。因此,您的應用程序應始終能夠讀寫明確創建的文件。此外,應用程序的沙箱可能允許它在特定情況下訪問其他文件。有關沙箱的更多信息,請參閱應用程序沙箱和XPC

*跟蹤文件更改

無法使用文件協調界面的應用程序(請參閱使用其他進程協調文件訪問)跟蹤文件和目錄的更改可以改用FSEvents API。該API提供了一個用于跟蹤文件系統交互的下級界面,并且在OS X v10.5及更高版本中可用。

有關如何使用FSEvents API的信息,請參閱“文件系統事件編程指南”


安全

OS X中的安全技術可幫助您保護由應用程序創建或管理的敏感數據,并幫助最大限度地減少惡意代碼成功攻擊造成的損失。這些技術會影響您的應用程序與系統資源和文件系統的交互。

應用程序沙箱XPC

您可以按照安全編碼指南中推薦的做法來保護您的應用免受惡意軟件的攻擊。但攻擊者只需要在您的防御中找到一個洞,或者與您鏈接的任何框架和庫中找到一個孔,以獲得對應用程序的所有權限的控制。

如果惡意代碼利用您的應用程式,App Sandbox可以防止被盜,損壞或已刪除的用戶數據的最后一道防線。App Sandbox還可以最大限度地減少編碼錯誤造成的損害。其戰略有兩個方面:

應用程序沙箱可讓您描述應用程序如何與系統進行交互。系統然后授予您的應用程序所需的訪問權限,以完成其工作,而不再需要。為了讓您的應用程序提供最高級別的損壞遏制,最佳做法是盡可能采用最嚴格的沙箱。

應用程序沙箱允許用戶通過打開和保存對話框,拖放和其他熟悉的用戶交互方式透明地授予您的應用程序附加訪問權限。

您可以通過在Xcode中設置權限來描述您的應用程序與系統的交互。的權利是一個鍵值對,在定義屬性列表文件,賦予特定的功能或安全許可的目標。例如,有權利密鑰表示您的應用程序需要訪問攝像機,網絡和用戶數據,如地址簿。有關OS X中可用的所有權利的詳細信息,請參閱授權密鑰參考

當您采用App Sandbox時,該系統提供了一個特殊的目錄供您的應用程序使用,并且只能由您的應用程序稱為容器。您的應用程序對容器進行了無限制的讀/寫訪問。POSIX層上方的所有OS X路徑查找API都相對于容器而不是用戶的主目錄。其他沙盒應用程序無法訪問您的應用程序的容器,如代碼簽名中進一步描述。

iOS注意:由于不是用戶文檔,OS X容器與iOS容器不同,iOS容器在用戶文檔中是唯一的位置。作為用戶文檔的唯一本地位置,iOS容器通常被稱為應用程序的Documents目錄。

此外,iOS容器還包含該應用程序本身。這在OS X中不是這樣。

iCloud注意:如iCloud Storage所述,Apple的iCloud技術也使用名稱“container”。iCloud容器和App Sandbox容器之間沒有功能連接。

您的沙盒應用程序可以通過以下三種方式訪問??其容器外的路徑:

在用戶的特定方向

您可以使用特定文件系統位置的權限(如Movies文件夾)配置應用程序

當路徑在某些目錄中是世界可讀的時

與用戶進行交互以擴展沙箱的OS X安全技術稱為Powerbox。Powerbox沒有API。例如,當您使用NSOpenPanelNSSavePanel類時,或用戶在應用程序中拖放時,您的應用程序會透明地使用Powerbox。

一些應用程序操作更有可能成為惡意利用的目標。示例是對通過網絡接收的數據的解析以及視頻幀的解碼。通過使用XPC,您可以通過將這些潛在危險的活動分成自己的地址空間來提高App Sandbox提供的損害容限的有效性。

XPC是通過啟用特權分離來補充App Sandbox的OS X進程間通信技術。特權分隔反過來是一種開發策略,您可以根據每個部分需要的系統資源訪問將應用程序分割成多個。您創建的組件被稱為XPC服務。有關采用XPC的詳細信息,請參閱“守護進程和服務編程指南”

有關App Sandbox及其使用方法的完整說明,請參閱“應用程序沙箱設計指南”

代碼簽名

OS X采用稱為代碼簽名的安全技術,允許您證明您的應用程序確實由您創建。應用程式代碼簽署后,系統可以偵測到應用程式的任何變更 - 無論是意外引起變更,還是惡意代碼。各種安全技術,包括App Sandbox和家長控制,都取決于代碼簽名。

在大多數情況下,您可以依賴Xcode的自動代碼簽名,這只需要在項目的構建設置中指定代碼簽名身份。在Mac的“工具流程指南”中的代碼簽名應用程序中描述了采取的步驟。如果您需要將代碼簽名合并到自動構建系統中,或者將應用程序與第三方框架相鏈接,請參閱代碼簽名指南中所述的步驟。

當您采用App Sandbox時,您必須對您的應用程序進行編碼。這是因為授權(包括啟用App Sandbox的特權)內置于應用程式的代碼簽名中。

OS X強制應用程序的容器和應用程序的代碼簽名之間的關系。這個重要的安全功能確保沒有其他沙盒應用可以訪問您的容器。該機制的工作原理如下:系統創建一個應用程序的容器后,每次啟動具有相同軟件包ID的應用程序時,系統會檢查應用程序的代碼簽名是否與容器預期的代碼簽名相匹配。如果系統檢測到不匹配,則會阻止該應用啟動。

代碼簽名的應用程序中沙箱的情況下一個完整的解釋,閱讀的深度應用程序沙箱中的應用沙盒設計指南

鑰匙扣

鑰匙串是用于存儲用戶密碼和其他秘密的安全加密容器。它旨在幫助用戶管理他們的多個登錄,每個登錄具有自己的ID和密碼。您應該始終使用鑰匙串來存儲應用程序的敏感憑據。

有關鑰匙串的更多信息,請參閱鑰匙串服務編程指南中的鑰匙串服務概念

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,825評論 6 546
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,814評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,980評論 0 384
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 64,064評論 1 319
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,779評論 6 414
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 56,109評論 1 330
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,099評論 3 450
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,287評論 0 291
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,799評論 1 338
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,515評論 3 361
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,750評論 1 375
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,221評論 5 365
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,933評論 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,327評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,667評論 1 296
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,492評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,703評論 2 380

推薦閱讀更多精彩內容