Cocoa-plattformen finns nu i fyra separata varianter, eller underplattformar, med SDK:erna för macOS, iOS/iPadOS, watchOS och tvOS. Varje SDK består av enskilda bibliotek som vanligtvis kallas ”ramverk”.

På Objective-C-sidan är varje ramverk ett paket med tillägget .framework som innehåller både binära (.dylib, vilket kan jämföras med .dll på Windows) och Objective-C-huvudfiler. För Elements representeras varje ramverk i SDK:n av en .fx-fil som aggregerar all metadata från rubrikerna för att göra dem enklare och snabbare för Elements-kompilatorn att konsumera.

Elements levereras med förskapade .fx-filer för alla ramverk i Apples standard-SDK:er som levereras med de senaste versionerna av de fyra SDK:erna (samt för utvalda äldre versioner).

Den fullständiga listan över alla ramverk hittar du i listorna nedan. Du kommer att se att många av ramverken delas av vissa eller till och med alla SDK:er, vilket ger ett stort bibliotek av klasser som gör att du kan skriva kod som kan kompileras för och delas mellan alla underplattformar, medan varje SDK också ger ett stort antal ramverk som är plattformsspecifika.

  • Alla ramverk för macOS SDK
  • Alla ramverk för iOS SDK
  • Alla ramverk för tvOS SDK
  • Alla ramverk för watchOS SDK
  • Alla ramverk för Mac Catalyst

Nedan ska vi titta närmare på några av dessa ramverk.

Foundation

Det antagligen mest kritiska ramverket för en Cocoa-app är Foundation-ramverket, eftersom det – som namnet antyder – tillhandahåller en stor del av de grundklasser som utgör ett program på Objective-C-körtiden. Detta inkluderar de flesta standardklasser med NS*-prefix (bortsett från GUI-klasser, mer om det nedan), från enkla och viktiga typer som NSString, NSArray och liknande, till klasser som ger tillgång till centrala OS-tjänster, till exempel NSFileManager för diskåtkomst, NSNotificationCenter för att arbeta med meddelanden, NSURL*-klasser för att arbeta med nätverksförfrågningar, och många många många fler.

Läs mer på om Foundation.fx. Den är tillgänglig på alla Cocoa-subplattformar.

Användargränssnitt: AppKit vs UIKit vs WatchKit.

Likheterna mellan iOS-, watchOS-, tvOS- och macOS-SDK:erna försvinner när vi kommer in på området för utveckling av användargränssnitt – och det på goda grunder, eftersom användargränssnittet för tillämpningar på dessa plattformar är mycket olika. Av denna anledning tillhandahåller SDK:erna tre mycket olika ramverk:

AppKit ingår endast i macOS SDK och tillhandahåller alla klasser och kontroller som du behöver för att skapa Mac-applikationer. Av äldre skäl delar de flesta av dessa klasser ett gemensamt namnprefix med Foundation och börjar med NS*, och de klasser du kommer att arbeta med inkluderar NSWindow, NSButton, NSTableView och liknande.

UIKit är det ramverk som både iOS och tvOS använder för att tillhandahålla sina användargränssnitt, och dess klasser börjar med ett UI* prefix. Många koncept delas av AppKit och UIKit, men klasserna är olika &mdash vissa mer än andra. Till exempel har båda ramverken en klass för att representera färg (NSColor respektive UIColor) som fungerar mycket lika, medan andra koncept är ganska unika för UIKit, t.ex. användningen av fördefinierade styrenheter som UINavigationController och UITabBarController. UIKit har också skillnader (vissa mindre, andra mycket stora) mellan iOS och tvOS.

WatchKit, slutligen, används av watchOS för att bygga användargränssnitt för Apple Watch när det gäller appar, glances och notiser. (Det finns också ClockKit för att bygga komplikationer för urtavlor.) WatchKit använder ett annat och enklare tillvägagångssätt för UI-design än UIKit.

De olika ramverken tvingar utvecklaren att tänka om och designa sitt applikations-UI från grunden, men det är bra, eftersom UI-paradigmen på varje plattform är fundamentalt olika, där UIKit till stor del styrs av beröring (både direkt och via Siri Remote på Apple TV) och AppKit används för mer traditionell interaktion i stil med mus och tangentbord.

Men många av koncepten bakom ramverken är likartade, och du kommer att märka att om du lär dig att skapa program på det ena kommer du i många fall lätt att överföra dem till det andra. Till exempel använder alla tre ramverken Model-View-Controller-paradigmet för att separera det faktiska användargränssnittet från den ”controller”-klass som styr det. Detta blir uppenbart så fort du börjar skapa ditt första användargränssnitt, för i stället för att implementera din egen Window- eller View-klass (på grund av att iOS har ett enda fönster tänker UIKit-applikationer mest i termer av vyer, inte fönster) i kod som du skulle göra i .NET eller Delphi, implementerar du en Window (eller View) ”Controller”.

Andra ämnen på den här dokumentsajten, t.ex. artikeln Working with XIB Files, diskuterar de här koncepten mer i detalj.

Läs mer om AppKit.fx, UIKit.fx och WatchKit.fx.

Notera: Det finns en Cocoa.framework (och en matchande Cocoa.fx) i macOS SDK. Detta ramverk är bara ett paket av Foundation och AppKit. Det ska inte förväxlas med vår allmänna användning av termen ”Cocoa” för att hänvisa till hela plattformen.

Mer specifika UI-ramar

Båda SDK:erna innehåller ytterligare ramar som bygger på AppKit och UIKit för att ge tillgång till mer avancerade eller specifika UI-element.

Till exempel:

  • Den SDK för macOS, iOS och watchOS innehåller MapKit, som tillhandahåller klasser för att integrera Apple Maps i ditt program, både för att visa kartor och för att arbeta med geografiska data. (MapKit har också ett nära samarbete med CoreLocation, som behandlas nedan.)
  • Både iOS och macOS innehåller det nya ramverket Social som gör att ditt program kan visa användargränssnitt för delning av innehåll på Twitter, Facebook, Sina Weibo och andra sociala nätverk.
  • iOS innehåller ramverket MessageUI för att interagera med e-post och låta användaren skicka e-post direkt från ditt program.
  • SpriteKit, som är nytt i både iOS 7.0 och OS X 10.9, och SceneKit (nytt i OS X 10.9 och även i iOS från och med version 8.0) gör det enklare att skapa bra användargränssnitt för spel.

Systemtjänster

Det finns också ett gäng ramverk som låter din applikation interagera med systemtjänster, t.ex.:

  • StoreKit för att hantera köp i appen för iOS- och Mac App Store-appar.
  • Säkerhet för att få tillgång till systemets nyckelkedja, lagra och hämta lösenord och certifikat osv.
  • CoreLocation för att arbeta med GPS (och Wifi-baserade lokaliseringstjänster).
  • CoreAudio och CoreVideo för att arbeta med och spela upp ljud- och videomedia.
  • Addressbook och EventKit för att arbeta med användarnas kontakter och kalendrar (tillsammans med EventKitUI på iOS).
  • GameKit för att integrera dina spel med Game Center.

(allt delat mellan alla plattformar) med mera.

Frameworks på lägre nivå

Om du vill gå längre än bara AppKit/UIKit för din utveckling av användargränssnittet tillhandahåller båda SDK:erna också ramverk som låter dig få smutsigare händer och arbeta med användargränssnittet på lägre nivåer.

  • CoreGraphics är grunden för all grafikrendering i de centrala ramverken för användargränssnittet, och du kan och kommer att arbeta med det när du skapar dina egna anpassade kontroller.
  • QuartzCore innehåller ”CoreAnimation”, biblioteket som ger sofistikerad men ändå enkel åtkomst till att lägga till animationer i dina program – ett måste för alla moderna iOS- och Mac-appar.
  • GLKit låter dig lägga till OpenGL-baserade element i dina UIKit/AppKit-applikationer, medan ramverken på lägre nivå OpenGL (macOS) och OpenGLES (iOS och tvOS) ger dig full tillgång till de råa OpenGL API:erna.

rtl.fx, libToffee.fx, libSwift.fx

Förutom de centrala SDK-ramverken tillhandahåller Elements tre ytterligare .fx filer som är avgörande för dess funktion.

  • rtl.fx är ännu mer grundläggande än ramverket Foundation och innehåller alla API:er på låg nivå i C-stil som utgör kärnan i UNIX-systemet i macOS, iOS, watchOS och tvOS; den innehåller också bibliotek som Grand Central Dispatch och CommonCrypto. I huvudsak representerar rtl.fx de flesta av rubrikerna i /usr/include.
  • libToffee.fx innehåller hjälptyper som är avgörande för själva Elements-kompilatorn. Den innehåller till exempel internt stöd för Future Types, generiska NSArray<T> och NSDictionary<T> typer, LINQ-stöd med mera.
  • libSwift.fx innehåller ytterligare typer och funktioner som är specifika för Swift-språket.

Varje Cocoa-program kommer automatiskt att referera till rtl.fx, oavsett om den är explicit listad i referenserna eller inte. Referenser till libToffee.fx och libSwift.fx är frivilliga; kompilatorn kommer att varna/felförklara om funktioner används som kräver en referens till libToffee.fx eller libSwift.fx och de inte är refererade.

Lämna ett svar

Din e-postadress kommer inte publiceras.