Wydarzenie Apple - Apple event
Zdarzenia Apple to oparty na komunikatach mechanizm komunikacji międzyprocesowej w systemie Mac OS , który najpierw pojawia się w Systemie 7 i jest obsługiwany od tego czasu przez wszystkie wersje klasycznego systemu Mac OS oraz przez macOS . Zdarzenia Apple opisują zdarzenia „wysokiego poziomu”, takie jak „otwarty dokument” lub „drukuj plik”, podczas gdy wcześniejsze systemy operacyjne obsługiwały znacznie bardziej podstawowe zdarzenia, a mianowicie „kliknięcie” i „naciśnięcie klawisza”. Zdarzenia Apple stanowią podstawę systemu skryptów Mac OS, Open Scripting Architecture (podstawowym językiem takiego języka jest AppleScript ).
Punktem wyjścia jest dynamicznie wpisywany, rozszerzalny format deskryptora zwany AEDesc , który jest po prostu kodem OSType określającym typ danych, wraz z blokiem danych zależnych od typu. Na przykład kod OSType intewskazuje, że dane były czterobajtową liczbą całkowitą ze znakiem w formacie big-endian .
Oprócz predefiniowanych kodów typów dla różnych popularnych typów prostych, istnieją dwa predefiniowane typy deskryptorów strukturalnych: AERecord , który ma typ danych reco(rekord) i AEList z typem list(lista lub tablica). Ich wewnętrzna struktura zawiera rekursywnie zagnieżdżone AEDescs, podczas gdy AERecord również kojarzy każdy element z unikalnym identyfikatorem pola rekordu, którym jest OSType. Menedżer zdarzeń Apple udostępnia wywołania API służące do tworzenia tych struktur, a także wyodrębniania ich zawartości i wysyłania zapytań o typ przechowywanej zawartości.
Apple Event Manager obsługuje również wymuszenie , które konwertuje AEDescs z jednego typu danych na inny. Oprócz standardowych wymuszeń, na przykład między typami całkowitymi i rzeczywistymi, aplikacje mogą instalować własne wywołania zwrotne obsługi wymuszeń , które obsługują konwersje do i z niestandardowych typów danych.
Wydarzenie Jabłko właściwa jest AERecord z pól, które zależały od potrzeb imprezy. Ponadto ma atrybuty (różniące się od pól rekordów, które są obecnie nazywane parametrami zdarzenia) z zestawu wstępnie zdefiniowanego przez Apple Event Manager. Określają one, co ma zrobić zdarzenie (poprzez klasę zdarzenia i identyfikator zdarzenia ), adres docelowy, na który zdarzenie ma zostać wysłane (może to być proces na komputerze lokalnym lub zdalnym) oraz różne inne opcje obsługi to. Zdalne maszyny początkowo musiały być połączone przez AppleTalk , ale Mac OS 9 dodał opcję połączeń przez TCP / IP .
Po wysłaniu zdarzenia Apple do procesu docelowego, proces wysyłania może wybrać otrzymanie odpowiedzi na zdarzenie Apple. Może zawierać różne bity informacji zwróconych od celu na temat przetwarzania pierwotnego zdarzenia, w tym kod błędu wskazujący powodzenie / niepowodzenie, wszelkie informacje wymagane przez pierwotne zdarzenie i / lub inne odpowiednie informacje.
Wydarzenia Apple są podstawą modelu obiektów AppleEvent , który z kolei jest podstawą OSA i AppleScript . Od 2016 roku oficjalna implementacja interfejsu API Apple Event Manager jest dostępna w języku C i jego potomkach, w tym w C ++ . Oficjalne powiązania są również dostarczane dla Objective-C i Swift za pośrednictwem interfejsu API Cocoa . Nieoficjalne powiązania istnieją również dla innych języków (z różnym stopniem ograniczeń), w tym Perl , UserTalk , Ruby i Python .
Model obiektowy
AppleEvent Object Model ( AEOM ) był zestaw protokołów zbudowanych na szczycie AppleEvents przez które aplikacje uruchomione w ramach klasycznego Mac OS i MacOS mógł kontrolować funkcje nawzajem. Aplikacje, które realizowane jakąś część AEOM nazywano skryptów , ponieważ mogą one być kontrolowane poprzez AppleScript . Niestety, obsługa skryptów pozostawała niejednolita i niespójna w całej historii klasycznego systemu Mac OS.
AEOM zapewnił warstwę składniową, w ramach której każda aplikacja mogłaby publikować swoje wewnętrzne obiekty, umożliwiając manipulowanie tymi obiektami w ustandaryzowany sposób. W przeciwieństwie do innych podobnie brzmiących pojęć, takich jak ToolTalk , istniało wyraźne, ortogonalne rozróżnienie między rzeczownikami i czasownikami ; w związku z tym, zamiast udostępniać oddzielne polecenia dla „zamknij dokument” i „zamknij okno”, istnieje pojedynczy czasownik „zamknij”, który może zawierać odniesienia do obiektów „dokument”, „okno” lub dowolnego innego obiektu opublikowanego przez aplikację.
Obiekty, które aplikacja udostępniła dzięki obsłudze AEOM, zostały uporządkowane w hierarchii. Na górze znajdowała się sama aplikacja, do której odwoływała się pusty deskryptor obiektu. Do innych obiektów odwoływano się przez (rekurencyjne) określenie ich obiektu nadrzędnego, wraz z innymi informacjami identyfikującymi go jako dziecko tego rodzica, wszystkie zebrane w AERecord . Iterator została dostarczona przez rodziców, aby wyliczyć swoje dzieci lub dzieci z danej klasy, dzięki czemu aplikacje skierować zestaw elementów. System był ogólnie podobny do Document Object Model używanego w XML , chociaż z pewnymi różnicami we wzorcach dostępu.
Każdy obiekt może mieć elementy i właściwości ; elementami były inne obiekty, które można było tworzyć lub usuwać, podczas gdy właściwości nie mogły być tworzone ani usuwane, ale miały wartości, które można było przesłuchać lub zmienić. Na przykład aplikacja może mieć jeden lub więcej elementów okna reprezentujących okna pokazujące zawartość aktualnie otwartych dokumentów. Okna te mogą mieć właściwości, takie jak tytuł, położenie i rozmiar.
Aplikacja może definiować niestandardowe czasowniki do wykonywania operacji na jej obiektach. AEOM określił również różne standardowe czasowniki, które (jak oczekiwano) aplikacje będą implementować w spójny sposób, takie jak otwieranie, zamykanie, tworzenie elementu, usuwanie, ustawianie danych i pobieranie danych. Każdy czasownik został zdefiniowany jako AppleEvent określonego typu i klasy, wraz z określonymi parametrami określonych typów, które miały być obecne. Na przykład zdarzenie „pobierz dane” było standardowym sposobem uzyskiwania wartości właściwości: wymagało zasadniczo jednego parametru, którym był deskryptor obiektu identyfikujący właściwość, o którą chodziło. Wartość tej właściwości zostanie zwrócona w zdarzeniu odpowiedzi. Zdarzenie „set data” przyjmowało dwa parametry: deskryptor obiektu dla właściwości do ustawienia i nową wartość właściwości; oczekiwano, że zdarzenie odpowiedzi zwróci tylko status sukcesu lub kod błędu niepowodzenia.
Cała architektura AppleEvent identyfikuje rzeczy za pomocą czterobajtowych kodów OSType , starannie unikając rzeczywistych słów lub fraz w języku angielskim (lub jakimkolwiek innym języku). Zamiast tego, korespondencja pomiędzy wewnętrznymi i zewnętrznymi kodami AppleEvent opisach języka naturalnego jest określona przez aete ( AppleEvent Terminologia Extension ) zasobów - na „przedłużenie” będącej do standardowej terminologii wbudowany w samą AppleScript. Aplikacja może udostępniać wiele zasobów „aete” dla wielu języków, zgodnie z oryginalnym wielojęzycznym projektem samego AppleScript
Weźmy na przykład pod uwagę następującą sekwencję AppleScript sterującą fikcyjną aplikacją do rysowania:
tell application "ScriptableDraw"
set background color of window "New Drawing" to background color of window "Old Drawing"
end tell
W rzeczywistości wiąże się to z wysłaniem dwóch AppleEvents do aplikacji docelowej (i odebraniem odpowiadających im odpowiedzi): najpierw wysyłane jest zdarzenie get-data w celu pobrania właściwości koloru tła okna oznaczonego nazwą „Stary rysunek”; następnie wysyłane jest zdarzenie set-data w celu zastosowania wartości zwróconej jako właściwość koloru tła okna o nazwie „Nowy rysunek”.
Ponieważ tego rodzaju wzorzec dostępu był typowy, AppleScript szeroko stosował tellinstrukcję, która przełączała kontekst na nazwany obiekt w sposób podobny do withinstrukcji występującej w języku Visual Basic lub Pascal . Wszystkie polecenia po telldo odpowiedniego end tellbędą wysyłane do obiektu nazwanego w tell, zamiast do obiektu domyślnego, którym była bieżąca aplikacja.
Deskryptory obiektów pozwoliły na identyfikację obiektów na różne sposoby. Najciekawsze było użycie klauzuli where (która została przetłumaczona na terminologię AppleScript jako wyrażenie filtrujące ). Na przykład pakiet AppleScript 1.0 SDK dostarczany z kodem źródłowym przykładowej aplikacji o nazwie Scriptable Text Editor, który reagowałby na skrypty takie jak:
tell application "Scriptable Text Editor"
tell window "Example Document"
set text style of every word whose length > 7 to bold
end tell
end tell
Nawet dzisiaj rzadko można znaleźć tego rodzaju moc w językach skryptowych ogólnego przeznaczenia poza SQL .
Dodanie obsługi AEOM w klasycznym Mac OS było trudnym procesem. Twórcy aplikacji musieli zidentyfikować swoje obiekty i ręcznie napisać kod, aby umożliwić im zajęcie. Zwykle przybierało to postać kodu zwracającego „następny” obiekt określonego typu, umożliwiając AppleScript ich iterację. Ale ponieważ system operacyjny nie zawierał modelu obiektowego, praca ta została całkowicie pozostawiona programistom, z których wielu nie wdrożyło jej. Co dziwne, nawet własny framework aplikacji Apple , MacApp , nie oferował takiego modelu, z wyjątkiem obiektów GUI , o których wiedział, po raz kolejny zmuszając programistę do wykonywania większości pracy związanej ze skryptowaniem obiektów reprezentujących same dane. Głównie z tych powodów obsługa AppleScript nie była zbyt rozpowszechniona.
Firma Apple podjęła próbę rozwiązania tego problemu, wprowadzając różne „zestawy” obiektów, które reprezentowały standardowe obiekty i czasowniki, które miały być obsługiwane przez różne typy aplikacji. Na przykład oczekiwano, że wszystkie aplikacje będą obsługiwać „zestaw podstawowy”, a każdy tekst edycji aplikacji powinien obsługiwać „zestaw tekstowy”. Wybierając odpowiedni zestaw pakietów, deweloper mógłby przynajmniej zmniejszyć nakład pracy związany z planowaniem sposobu wyeksponowania obiektów. Ponieważ jednak obiekty te na ogół nie były częścią samego systemu (z wyjątkiem mocno ograniczonego edytora TextEdit), faktyczną implementację pozostawiono programiście.
Aplikacje opracowane w Cocoa , systemie znanym wcześniej jako OpenStep , oferują bogate środowisko wykonawcze obiektów, do którego można zapytać z dowolnej innej aplikacji. To sprawia, że implementacja AEOM jest znacznie łatwiejsza, radykalnie zmniejszając ilość kodu potrzebnego w przeciętnej aplikacji. Ponadto większość aplikacji Cocoa jest zbudowana głównie z obiektów w standardzie Cocoa, z których wszystkie zostały zaktualizowane, aby zapewnić dość obszerną obsługę skryptów. Dotyczy to nie tylko obiektów GUI, jak w MacApp, ale także obiektów danych w nich zawartych, w tym tekstu, tabel i różnych obiektów list. Plik tekstowy jest używany do mapowania wewnętrznych nazw „podobnych do obiektów” na wersje czytelne dla człowieka. W większości przypadków utworzenie tego jest wszystkim, co jest potrzebne do dodania dość znacznej zdolności skryptowej do większości programów.
Chociaż aplikacje Cocoa nie są oparte na AEOM i często używają subtelnie innych obiektów niż pierwotnie zdefiniowane przez Apple obiekty standardowe, aplikacje Cocoa są generalnie znacznie bardziej skryptowalne niż ich „klasyczne” odpowiedniki - w rzeczywistości rzadko zdarza się znaleźć aplikację Cocoa, której nie można skryptować w pewnym stopniu.
Dalsza lektura
- Cook, William R. (29 września 2006), AppleScript (PDF) , University of Texas at Austin, str. 1–1–1–21, CiteSeerX 10.1.1.76.6993 , doi : 10.1145 / 1238844.1238845 , pobrano 9 maja, 2009. W szczególności zobacz sekcję 2.3 „Wydarzenia Apple” (strony 9–13), chociaż historia i znaczenie wydarzeń Apple są również omówione w innych miejscach dokumentu.