Free Press

Platforma Cocoa jest obecnie reprezentowana przez cztery oddzielne smaki, lub pod-platformy, z macOS, iOS/iPadOS, watchOS i tvOS SDKs. Każdy SDK składa się z indywidualnych bibliotek, zwykle określanych jako „Frameworks”.

Po stronie Objective-C każdy framework jest pakietem z rozszerzeniem .framework, który zawiera zarówno pliki binarne (.dylib, co jest porównywalne z .dll w systemie Windows), jak i pliki nagłówkowe Objective-C. Dla Elements, każdy framework w SDK jest reprezentowany przez plik .fx, który agreguje wszystkie metadane z nagłówków, aby ułatwić i przyspieszyć ich konsumpcję przez kompilator Elements.

Elements jest dostarczany z wstępnie utworzonymi plikami .fx dla wszystkich frameworków w standardowych pakietach SDK Apple, które są dostarczane z najnowszymi wersjami czterech pakietów SDK (jak również dla wybranych starszych wersji).

Pełną listę wszystkich frameworków można znaleźć na poniższych listach. Zobaczysz, że wiele z tych frameworków jest współdzielonych przez niektóre lub nawet wszystkie SDK, zapewniając ogromną bibliotekę klas, które pozwalają pisać kod, który może być skompilowany i współdzielony między wszystkimi pod-platformami, podczas gdy każdy SDK zapewnia również znaczną liczbę frameworków, które są specyficzne dla danej platformy.

• Wszystkie frameworki SDK macOS
• Wszystkie frameworki SDK iOS
• Wszystkie frameworki SDK tvOS
• Wszystkie frameworki SDK watchOS
• Wszystkie frameworki Mac Catalyst

Przyjrzyjmy się niektórym z tych frameworków bardziej szczegółowo.

Foundation

Prawdopodobnie najbardziej krytycznym frameworkiem dla każdej aplikacji Cocoa jest framework Foundation, ponieważ – jak sama nazwa wskazuje – dostarcza on wiele klas fundamentalnych, które tworzą aplikację na Objective-C runtime. Obejmuje to większość standardowych klas z prefiksami NS* (poza klasami GUI, o których więcej poniżej), od prostych i podstawowych typów, takich jak NSString, NSArray i podobnych, do klas, które zapewniają dostęp do podstawowych usług systemu operacyjnego, takich jak NSFileManager dla dostępu do dysku, NSNotificationCenter do pracy z powiadomieniami, NSURL* klasy do pracy z żądaniami sieciowymi i wiele innych.

Czytaj więcej na temat Foundation.fx. Jest on dostępny na wszystkich podplatformach Cocoa.

User Interfaces: AppKit vs. UIKit vs. WatchKit.

Podobieństwa między SDK iOS, watchOS, tvOS i macOS rozwiewają się, gdy wkraczamy w sferę rozwoju interfejsu użytkownika – i nie bez powodu, ponieważ UI dla aplikacji na tych platformach jest diametralnie różne. Z tego powodu SDK udostępniają trzy bardzo różne frameworki:

AppKit jest zawarty tylko w macOS SDK i zapewnia wszystkie klasy i elementy sterujące potrzebne do tworzenia aplikacji na Maca. Ze względu na starsze wersje większość tych klas ma wspólny prefiks nazewnictwa z Foundation i zaczyna się od NS*, a klasy, z którymi będziesz pracować, obejmują NSWindow, NSButton, NSTableView i tym podobne.

UIKit jest frameworkiem, którego zarówno iOS, jak i tvOS używają do dostarczania swoich interfejsów użytkownika, a jego klasy zaczynają się od prefiksu UI*. Wiele koncepcji jest współdzielonych przez AppKit i UIKit, ale klasy są różne &mdash niektóre bardziej niż inne. Na przykład, oba frameworki mają klasy reprezentujące kolor (NSColor i UIColor, odpowiednio), które działają bardzo podobnie, podczas gdy inne koncepcje są dość unikalne dla UIKit, takie jak użycie predefiniowanych kontrolerów, takich jak UINavigationController i UITabBarController. UIKit ma również różnice (niektóre drobne, niektóre bardzo znaczące) między iOS i tvOS.

WatchKit, w końcu, jest używany przez watchOS do budowania UI dla Apple Watch w zakresie aplikacji, spojrzeń i powiadomień. (Istnieje również ClockKit do budowania komplikacji twarzy zegarka.) WatchKit używa innego i bardziej prostego podejścia do projektowania UI niż UIKit.

Różne frameworki zmuszają programistę do ponownego przemyślenia i zaprojektowania ich aplikacji UI od podstaw, ale to dobrze, ponieważ paradygmaty UI na każdej platformie są zasadniczo różne, z UIKit jest w dużej mierze napędzany przez dotyk (zarówno bezpośredni, jak i za pośrednictwem Siri Remote na Apple TV) i AppKit jest używany do bardziej tradycyjnej interakcji w stylu mysz + klawiatura.

Ale wiele koncepcji stojących za tymi frameworkami jest podobnych i przekonasz się, że nauka tworzenia aplikacji na jednym z nich będzie w wielu przypadkach łatwo przekładać się na drugi. Na przykład, wszystkie trzy frameworki wykorzystują paradygmat Model-View-Controller do oddzielenia rzeczywistego UI od klasy „kontrolera”, która go napędza. Staje się to oczywiste w momencie, gdy zaczynasz tworzyć swój pierwszy UI, ponieważ zamiast implementować własną klasę Window lub View (ze względu na jednookienkową naturę iOS, aplikacje UIKit myślą głównie w kategoriach widoków, a nie okien) w kodzie, jak w .NET lub Delphi, implementujesz Okno (lub Widok) ”Kontrolera”.

Inne tematy w tej witrynie docs, takie jak artykuł Praca z plikami XIB, omawiają te koncepcje bardziej szczegółowo.

Czytaj więcej na temat AppKit.fx, UIKit.fx i WatchKit.fx.

Uwaga: A Cocoa.framework (i pasujące Cocoa.fx) istnieje w macOS SDK. Ten framework jest po prostu połączeniem Foundation i AppKit. Nie należy go mylić z naszym ogólnym użyciem terminu „Cocoa” w odniesieniu do całej platformy.

Więcej specyficznych frameworków UI

Oba SDK zawierają dodatkowe frameworki, które bazują na AppKit i UIKit, aby zapewnić dostęp do bardziej zaawansowanych lub specyficznych elementów UI.

Na przykład:

• Karty SDK systemów macOS, iOS i watchOS zawierają MapKit, który udostępnia klasy pozwalające zintegrować Mapy Apple z aplikacją, zarówno w celu wyświetlania map, jak i pracy z danymi geograficznymi. (MapKit ściśle współpracuje również z CoreLocation, o którym poniżej.)
• Zarówno iOS, jak i macOS zawierają nowy framework Social, który pozwala aplikacji pokazać UI do udostępniania treści na Twitterze, Facebooku, Sina Weibo i innych sieciach społecznościowych.
• iOS udostępnia framework MessageUI do interakcji z pocztą elektroniczną i pozwalający użytkownikowi wysyłać e-maile bezpośrednio z aplikacji.
• SpriteKit, nowy zarówno w iOS 7.0, jak i OS X 10.9 oraz SceneKit (nowy w OS X 10.9, a także w iOS od wersji 8.0) ułatwiają tworzenie wspaniałego interfejsu użytkownika w grach.

Usługi systemowe

Istnieje również wiele frameworków, które pozwalają aplikacji współdziałać z usługami systemowymi, takimi jak:

• StoreKit do obsługi zakupów w aplikacji dla iOS i Mac App Store.
• Security do dostępu do łańcucha kluczy systemowych, przechowywania i pobierania haseł i certyfikatów itp.
• CoreLocation do pracy z GPS (i usługami lokalizacyjnymi opartymi na Wifi-).
• CoreAudio i CoreVideo do pracy i odtwarzania mediów audio i wideo.
• Addressbook i EventKit do pracy z Kontaktami i Kalendarzami użytkowników (obok EventKitUI na iOS).
• GameKit do integracji gier z Game Center.

(wszystkie współdzielone między wszystkimi platformami) i więcej.

Szablony niższego poziomu

Jeśli chcesz wyjść poza AppKit/UIKit dla rozwoju interfejsu użytkownika, oba SDK dostarczają również szkielety, które pozwalają Ci brudzić ręce i pracować z UI na niższych poziomach.

• CoreGraphics jest podstawą wszystkich renderowania grafiki w rdzeniu frameworków UI, i można i będzie z nim pracować podczas tworzenia własnych niestandardowych kontrolek.
• QuartzCore zawiera ”CoreAnimation”, bibliotekę, która zapewnia wyrafinowany, ale łatwy dostęp do dodawania animacji do swoich aplikacji – konieczność dla każdej nowoczesnej aplikacji iOS i Mac.
• GLKit pozwala dodawać elementy oparte na OpenGL do aplikacji UIKit/AppKit, podczas gdy niższego poziomu frameworki OpenGL (macOS) i OpenGLES (iOS i tvOS) dają pełny dostęp do surowych interfejsów API OpenGL.

rtl.fx, libToffee.fx, libSwift.fx

Oprócz podstawowych frameworków SDK, Elements dostarcza trzy dodatkowe .fx pliki, które są kluczowe dla jego działania.

• rtl.fx jest jeszcze bardziej fundamentalny niż framework Foundation i zawiera wszystkie niskopoziomowe interfejsy API w stylu C, które tworzą podstawowy system UNIX systemów macOS, iOS, watchOS i tvOS; zawiera również biblioteki takie jak Grand Central Dispatch i CommonCrypto. Zasadniczo, rtl.fx reprezentuje większość nagłówków w /usr/include.
• libToffee.fx zawiera typy pomocników, które są kluczowe dla samego kompilatora Elements. Na przykład zawiera wewnętrzną obsługę typów przyszłych, typów generycznych NSArray<T> i NSDictionary<T>, obsługę LINQ i wiele innych.
• libSwift.fx zapewnia dodatkowe typy i funkcje specyficzne dla języka Swift.

Każda aplikacja Cocoa będzie automatycznie odwoływać się do rtl.fx, niezależnie od tego, czy jest jawnie wymieniona w referencjach, czy nie. Odwołania do libToffee.fx i libSwift.fx są opcjonalne; kompilator będzie ostrzegał/błąd, jeśli używane są funkcje, które wymagają odwołania do libToffee.fx lub libSwift.fx, a nie są do nich odwołane.