Budowanie architektury wtyczki za pomocą Adobe AIR

Question

Zastanawiam się nad wyborem środowiska Adobe AIR jako technologii implementacji po stronie klienta dla nadchodzącego projektu. (Poprzednim wyborem były C# i WPF, ale ostatnio byłem pod wielkim wrażeniem Flash/Flex/AIR.)

Ale jedną z najważniejszych cech mojego produktu będzie jego architektura wtyczek, pozwalająca twórcom stron trzecich na rozszerzyć funkcjonalność i GUI w interesujący sposób.

Wiem, jak zaprojektować architekturę w języku C#: Program ładujący dodatki wyliczy wszystkie zestawy w lokalnym katalogu "app/plugins /". Dla każdego zestawu wylicza wszystkie klasy, szukając implementacji interfejsu "IPluginFactory". Dla każdej wtyczki stworzonej przez fabrykę, poprosiłbym o jej klasy MVC, i zatrzasnę jej elementy GUI (elementy menu, panele, itp.) W odpowiednich slotach w istniejącym układzie GUI.

Chciałbym osiągnąć to samo w środowisku AIR (ładowanie wtyczek z lokalnego systemu plików, a nie z sieci). Po przeczytaniu this article rozumiem, że jest to możliwe i że podstawowa architektura (ładowanie plików SWF do piaskownicy ApplicationDomains itp.) Jest bardzo podobna do sposobu, w jaki robiłbyś to w .NET.

Ale jestem ciekawy tematów.

Jeśli któryś z was wykonał dynamiczne ładowanie klas za pomocą Flash Playera (najlepiej w mieszanych aplikacjach Flash/Flex, a szczególnie w hostach AIR), chciałbym usłyszeć o waszych doświadczeniach związanych z budowaniem frameworka wtyczek i wpadł w trudne sytuacje z Flash Playerem, a także z Flash, Flex i AIR API.

Na przykład, jeśli ktoś zadał mi to samo pytanie, ale z myślą o platformie Java, zdecydowanie powiedziałbym, że JVM nie ma pojęcia "modułów" lub "złożeń". Najwyższym poziomem agregacji jest "klasa", więc tworzenie struktur organizacyjnych w systemie wtyczek do zarządzania dużymi projektami może być trudne. Porozmawiałbym również o problemach z wieloma klasami ładującymi i o tym, jak każdy zachowuje swoje własne oddzielne wystąpienie załadowanej klasy (z własnymi oddzielnymi statycznymi varsami).

---

Oto kilka konkretnych pytań wciąż bez odpowiedzi dla mnie:

1) ActionScript klasa "Loader" można załadować do SWF z ApplicationDomain. Ale co dokładnie zawiera ta aplikacja? Moduły? Klasy? W jaki sposób są reprezentowane komponenty MXML? Jak znaleźć wszystkie klasy implementujące mój interfejs wtyczki?

2) Jeśli masz ładowaną wtyczkę do osobnej aplikacji ApplicationDomain z głównej aplikacji, czy jest znacznie bardziej skomplikowany kod wywołania z tej innej aplikacji? Czy istnieją jakieś istotne ograniczenia dotyczące rodzajów danych, które mogą przechodzić przez warstwę sortowania między aplikacjami? Czy marszowanie jest zbyt drogie?

3) Idealnie, chciałbym rozwinąć większość mojego własnego głównego kodu jako wtyczki (z główną aplikacją jest niewiele więcej niż powłoką ładującą plugin) i użyć architektury wtyczki, aby wciągnąć tę funkcjonalność do aplikacja. Czy to powoduje strach w twoim sercu?

Answer 1

Luca Tettamanti dał dobre odpowiedzi na konkretne pytania już, więc ja po prostu oferują pewne dodatkowe informacje na temat ogólnego przedmiotu:

I zostały wdrożone proste wtyczki API dla aplikacji Flex przy użyciu klasę ModuleManager (i inne rzeczy w pakiecie mx.modules.) Istotą jest to, że wtyczki podklasy od ModuleBase i użyć ModuleManager w aplikacji hosta, aby je załadować. Następnie masz wtyczki implementujące wspólny interfejs (np. IMyAppPlugin) i używają jakiegoś rodzaju facade do reprezentowania i implementacji interfejsu do aplikacji hosta, z której mogą korzystać wtyczki (np. MyAppFacade implements IMyAppFacade.) Po każdorazowym załadowaniu wtyczek, wstrzyknij to odniesienie do fasady w im.

Temat "Modular applications overview" w pomocy Flex 3 ma kilka dobrych informacji Oto fragment (podrozdziale „Domeny Module” omawia domen aplikacji w kontekście modułów.):

„Domyślnie moduł jest ładowany do domeny podrzędnej bieżącej domeny aplikacji . Można określić inną domenę aplikacji, korzystając z właściwości applicationDomain klasy ModuleLoader. "

Temat "Using the ApplicationDomain class" przechodzi w bardziej szczegółowo na temat domen aplikacji, i powinno się ją przeczytać, jeśli nie masz.

Answer 2

1. ApplicationDomain jest bardziej podobny do nazw, to definicje klasy grupy i umieścić je w hierarchii: domena może mieć bezpośredni dostęp do symboli we własnej domenie lub w domenie nadrzędnej, ale nie w dziecko lub rodzeństwo domeny (lub lepiej: nie może tego zrobić bezpośrednio - musi przejść przez obiekt applicationDomain, zadając definicję danej klasy); podczas ładowania zewnętrznego pliku SWF można zdecydować, , gdzie, aby wstawić nowe symbole: domena podrzędna (domyślnie), nowa domena dołączona do systemu (przy użyciu wartości null), domena , domena dołączona gdzie indziej (jawnie przechodząca rodzic nowej domeny). Zauważ, że nowe symbole nigdy nie nadpiszeją symboli w bieżącej domenie, ale ta sama nazwa może istnieć w wielu domenach.
   Niestety nie można wyliczyć klas w danej domenie (cóż, przynajmniej nie wiem, jak to zrobić), ale powszechnym rozwiązaniem jest wymaganie (jak w "Interfejsie wtyczki") obecności studni - znaną fabrykę w każdym swf, która zwróci albo definicję (klasę) wtyczki, albo samą wtyczkę.
2. Po prostu uzyskałeś odniesienie do obiektu w jakiś sposób (fabryka), to jest po prostu kolejny obiekt. Nie ma tunelowania: domena to tylko logiczna partycjonowanie przestrzeni nazw (jest to rozgałęzienie drzewa domeny systemowej).
3. Nie :) Ale ostrzegaj: może łatwo zmienić się w piekło dla GC, gdzie nieużywane domeny nie mogą zostać rozładowane z powodu odniesień rozpowszechnianych w innej domenie. Proponuję przyjrzeć się wielordzeniowemu szkieletowi PureMVC, ewentualnie z rurami, aby zapewnić ścisłą separację wtyczek.

Przy okazji, Flash Player jest także pojęciem domeny bezpieczeństwa, ale tak naprawdę nigdy go nie dotknąłem, więc nie wiem, jakie są tu możliwości.

Answer 3

Odpowiadając na oświadczenie dotyczące Java jako możliwego architektury plug-in:

Okazuje się, Java został wykorzystany do opracowania plug-in Systems Architecture przez wiele lat. Jeśli chodzi o stronę klienta, ramy zarządzania modułem Equinox OSGi są prawdopodobnie najlepiej znane. W pewnym momencie Eclipse IDE refaktoryzował swoją architekturę wtyczek na platformie Equinox OSGi. Eclipse IDE jest prawdopodobnie jednym z najbardziej udanych systemów architektury wtyczek po stronie klienta, które zostały opracowane - z punktu widzenia historycznej długowieczności, a także z szerokiej bazy użytkowników i społeczności twórców wtyczek. Oferują również swoją architekturę wtyczek jako fundamentalną platformę do projektowania dowolnych aplikacji klienckich - Eclipse RCP.

Po prostu musiałem to wtrącić, ponieważ chociaż Java była pozycjonowana jako prawdopodobnie bardzo słaby wybór do tego, to w rzeczywistości jest znacznie bardziej skuteczna niż jakikolwiek inny język/środowisko uruchomieniowe w dostarczaniu działających systemów tego rodzaju - szczególnie vs. C# .NET, który, oczywiście, ma dobry wrodzony obiekt dla modułów. Jest trochę ironiczny, ale masz go.

Co do Adobe AIR, jestem deweloperem zarządzającym projektem, który jest opracowywany w środowisku AIR. W naszym przypadku nasza rozbudowa modułu zawsze będzie dostarczana z serwera WWW, a nie z lokalnego katalogu. Taśma ma

<mx:Module/>

znacznika tworzenia moduły, które mogą być ładowane w czasie wykonywania dyskretnie.

Niestety, frustracja ze środowiskiem AIR polega na tym, że nie ma żadnych interfejsów API klas do uruchamiania innych aplikacji. Możesz załadować adres URL, aby załadować coś w domyślnej przeglądarce użytkownika, ale nie możesz uruchomić, powiedzmy, Excela. Zarówno Java, jak i C# mają interfejsy API do uruchamiania innych aplikacji jako procesów zewnętrznych.

Answer 4

Czy próbowałeś wczytać podaplikacje?
Istnieje dobra dokumentacja do robienia tego w środowisku AIR i odniosłem sukces w ciągu kilku godzin. Jednak ta sama implementacja jest inna w programie Flex z powodu naruszenia środowiska piaskownicy między podaplikacją a główną aplikacją. Spędziłem tygodnie waląc głową w ścianę.