Free Press

Cocoa-platformen er nu repræsenteret af fire separate varianter eller underplatforme med macOS, iOS/iPadOS, watchOS og tvOS SDK’erne. Hvert SDK består af individuelle biblioteker, der normalt kaldes “Frameworks”.

På Objective-C-siden er hvert framework et bundle med udvidelsen .framework, der indeholder både binære (.dylib, som kan sammenlignes med .dll på Windows) og Objective-C-headerfiler. For Elements er hvert framework i SDK’et repræsenteret af en .fx-fil, der samler alle metadata fra headerne for at gøre dem nemmere og hurtigere at forbruge for Elements-kompileren.

Elements leveres med på forhånd oprettede .fx-filer for alle frameworks i Apples standard SDK’er, der leveres med de nyeste versioner af de fire SDK’er (samt for udvalgte ældre versioner).

Du kan finde en komplet liste over alle frameworks i listerne nedenfor. Du vil se, at mange af rammerne er fælles for nogle eller endda alle SDK’er, hvilket giver et stort bibliotek af klasser, som gør det muligt at skrive kode, der kan kompileres til og deles mellem alle underplatforme, mens hvert SDK også indeholder et betydeligt antal rammer, der er platformsspecifikke.

• Alle macOS SDK Frameworks
• Alle iOS SDK Frameworks
• Alle tvOS SDK Frameworks
• Alle watchOS SDK Frameworks
• Alle Mac Catalyst Frameworks

Lad os se nærmere på nogle af disse frameworks.

Foundation

Den nok mest kritiske ramme for enhver Cocoa-app er Foundation-rammen, fordi den – som navnet antyder – leverer en stor del af de fundamentsklasser, der udgør et program på Objective-C-køretiden. Dette omfatter de fleste af standardklasserne med NS*-præfikser (bortset fra GUI-klasser, mere om det nedenfor), fra enkle og essentielle typer som NSString, NSArray og lignende til klasser, der giver adgang til centrale OS-tjenester, f.eks. NSFileManager til diskadgang, NSNotificationCenter til at arbejde med notifikationer, NSURL*-klasser til at arbejde med netværksanmodninger og mange mange flere.

Læs mere på om Foundation.fx. Den er tilgængelig på alle Cocoa-subplatforme.

Brugergrænseflader: AppKit vs. UIKit vs. WatchKit.

Lighederne mellem iOS-, watchOS-, tvOS- og macOS-SDK’erne forsvinder, når vi kommer ind på området for udvikling af brugergrænseflader – og det er med god grund, da brugergrænsefladen for programmer på disse platforme er meget forskellig. Derfor indeholder SDK’erne tre meget forskellige frameworks:

AppKit er kun inkluderet i macOS SDK’et og indeholder alle de klasser og kontroller, du har brug for til at oprette Mac-programmer. Af legacy-grunde deler de fleste af disse klasser et fælles navngivningspræfiks med Foundation og starter med NS*, og de klasser, du vil arbejde med, omfatter NSWindow, NSButton, NSTableView og lignende.

UIKit er det framework, som både iOS og tvOS bruger til at levere deres brugergrænseflader, og dets klasser starter med et UI* præfiks. Mange koncepter er fælles for AppKit og UIKit, men klasserne er forskellige &mdash nogle mere end andre. F.eks. har begge frameworks en klasse til at repræsentere farve (henholdsvis NSColor og UIColor), der fungerer meget ens, mens andre koncepter er ret unikke for UIKit, f.eks. brugen af foruddefinerede controllere som UINavigationController og UITabBarController. UIKit har også forskelle (nogle mindre, andre meget betydelige) mellem iOS og tvOS.

WatchKit, endelig, bruges af watchOS til at opbygge brugergrænseflader til Apple Watch med hensyn til apps, glances og notifikationer. (Der er også ClockKit til opbygning af komplikationer på urskiven.) WatchKit bruger en anden og mere enkel tilgang til UI-design end UIKit.

De forskellige frameworks tvinger udvikleren til at gentænke og designe deres applikations UI fra bunden, men det er en god ting, fordi UI-paradigmerne på hver platform er fundamentalt forskellige, idet UIKit i høj grad er drevet af berøring (både direkte og via Siri Remote på Apple TV), og AppKit bruges til mere traditionel interaktion i stil med mus og tastatur.

Men mange af koncepterne bag rammerne ligner hinanden, og du vil opdage, at hvis du lærer at skabe programmer på det ene, vil det i mange tilfælde let kunne overføres til det andet. For eksempel omfavner alle tre frameworks Model-View-Controller-paradigmet til at adskille den faktiske brugergrænseflade fra den “controller”-klasse, der styrer den. Dette bliver tydeligt, så snart du begynder at skabe din første brugergrænseflade, for i stedet for at implementere din egen Window- eller View-klasse (på grund af iOS’ enkeltvinduer tænker UIKit-applikationer mest i views og ikke i vinduer) i kode, som du ville gøre i .NET eller Delphi, implementerer du en Window (eller View) ”Controller”.

Andre emner på dette dokumentationswebsted, f.eks. artiklen Arbejde med XIB-filer, behandler disse koncepter mere detaljeret.

Læs mere på ca. AppKit.fx, UIKit.fx og WatchKit.fx.

Bemærk: Der findes en Cocoa.framework (og en tilsvarende Cocoa.fx) i macOS SDK. Denne ramme er blot et bundt af Foundation og AppKit. Det skal ikke forveksles med vores generelle brug af udtrykket “Cocoa” til at henvise til hele platformen.

Mere specifikke UI-rammer

Både SDK’er indeholder yderligere rammer, der bygger oven på AppKit og UIKit for at give adgang til mere avancerede eller specifikke UI-elementer.

For eksempel:

• MacOS-, iOS- og watchOS SDK’erne indeholder MapKit, som indeholder klasser til at integrere Apple Maps i dit program, både til at vise kort og til at arbejde med geografiske data. (MapKit arbejder også tæt sammen med CoreLocation, som behandles nedenfor.)
• Både iOS og macOS indeholder det nye Social framework, som gør det muligt for din applikation at vise brugergrænseflader til deling af indhold på Twitter, Facebook, Sina Weibo og andre sociale netværk.
• iOS indeholder MessageUI-rammen til at interagere med e-mail og lade brugeren sende e-mails direkte fra din applikation.
• SpriteKit, der er nyt i både iOS 7.0 og OS X 10.9, og SceneKit (nyt i OS X 10.9 og også i iOS fra version 8.0) gør det nemmere at skabe en fantastisk brugergrænseflade til spil.

Systemtjenester

Der er også en masse frameworks, der lader dit program interagere med systemtjenester, f.eks.:

• StoreKit til håndtering af køb i apps i iOS og Mac App Store-apps.
• Sikkerhed til adgang til systemets nøglekæde, lagring og hentning af adgangskoder og certifikater osv.
• CoreLocation til at arbejde med GPS (og Wifi-baserede lokaliseringstjenester).
• CoreAudio og CoreVideo til at arbejde med og afspille lyd- og videomedier.
• Adressebog og EventKit til at arbejde med brugernes kontakter og kalendere (sammen med EventKitUI på iOS).
• GameKit til at integrere dine spil med Game Center.

(alt sammen delt mellem alle platforme) og meget mere.

Frameworks på lavere niveau

Hvis du ønsker at gå videre end blot AppKit/UIKit til din udvikling af brugergrænsefladen, indeholder begge SDK’er også frameworks, der giver dig mulighed for at få hænderne mere beskidte og arbejde med brugergrænsefladen på lavere niveauer.

• CoreGraphics er grundlaget for al grafikrendering i de centrale UI-rammer, og du kan og vil arbejde med det, når du opretter dine egne brugerdefinerede kontroller.
• QuartzCore indeholder ”CoreAnimation”, biblioteket, der giver sofistikeret og alligevel nem adgang til at tilføje animation til dine programmer – et must for alle moderne iOS- og Mac-apps.
• GLKit giver dig mulighed for at tilføje OpenGL-baserede elementer til dine UIKit/AppKit-programmer, mens OpenGL- (macOS) og OpenGLES- (iOS og tvOS) frameworks på lavere niveau giver dig fuld adgang til de rå OpenGL-API’er.

rtl.fx, libToffee.fx, libSwift.fx

Ud over de centrale SDK-rammer indeholder Elements tre yderligere .fx filer, der er afgørende for dets funktion.

• rtl.fx er endnu mere grundlæggende end Foundation-rammen og indeholder alle de C-stil-API’er på lavt niveau, som udgør det centrale UNIX-system i macOS, iOS, watchOS og tvOS; den indeholder også biblioteker som Grand Central Dispatch og CommonCrypto. I det væsentlige repræsenterer rtl.fx de fleste af overskrifterne i /usr/include.
• libToffee.fx indeholder hjælpetyper, der er afgørende for selve Elements-kompileren. Den indeholder f.eks. intern understøttelse af Future Types, generiske NSArray<T> og NSDictionary<T> typer, LINQ-understøttelse m.m..
• libSwift.fx indeholder yderligere typer og funktioner, der er specifikke for Swift-sproget.

Alle Cocoa-programmer vil automatisk referere til rtl.fx, uanset om den er eksplicit anført i referencerne eller ej. Referencer til libToffee.fx og libSwift.fx er valgfrie; compileren advarer/giver en fejl, hvis der anvendes funktioner, der kræver en reference til libToffee.fx eller libSwift.fx, og de ikke er refereret.