Jak działa Codename One?

Question

Poszukuję alternatyw dla rozwoju wielu platform mobilnych i znalazłem Codename One, która używa języka Java jako lingua franca, zamiast HTML/CSS/JS lub języków skryptowych.

Czego nie mogłem znaleźć, to jak to działa. Czy łączy JVM z aplikacją dla iOS i Win7 i używa Dalvik w systemie Android? Czy tłumaczy kod źródłowy na natywny i czy mamy dostęp do tego kodu źródłowego? Czy jest jeszcze inna magia, skoro obiecują "bez kompromisów"? Jakie ograniczenia powinienem znać podczas kodowania agnostycznego środowiska Java?

Prewencyjne uderzenie: to jest pytanie o Codename One, , a nie o tym, którą powinienem wybrać między różnymi platformami lub czy powinienem wybrać język macierzysty, czy też powinienem wejść do sieci.

Answer 1

Codename One wykorzystuje podejście oparte na SaaS, więc może (i prawdopodobnie będzie) zmienić się w przyszłości w celu dostosowania ulepszonych architektur. Zauważ, że Codename One zapewnia także opcję build offline, co oznacza, że ​​korporacje, które mają zasady zabraniające takich architektur chmur, nadal mogą używać Codename One z dodatkowym obciążeniem/złożonością.

Obecnie na Androidzie standardowy kod Java jest wykonywany tak jak jest. Składnia Java 8 jest tłumaczona za pomocą retrolambdy na wszystkie platformy, gdy jest używana. Dzięki temu może być kompatybilny ze wszystkimi wersjami Androida, a także z innymi portami.

Na iOS Codename One zbudowany & open source ParparVM, który jest bardzo konserwatywną maszyną wirtualną. ParparVM ma współbieżny (nie blokujący) GC i jest napisany w całości w języku Java/C. Oznacza to, że projekt xcode jest generowany i kompilowany na serwerach budowania, dzięki czemu działa tak, jakby ręcznie natywna aplikacja, a tym samym "przyszły dowód" zmian wprowadzonych przez Apple. Na przykład. przy ostatnich 64-bitowych i bitcode zmianach w kompilacjach iOS, ParparVM nie potrzebował żadnych modyfikacji, aby dostosować się do tych zmian.

W przeszłości nazwa kodowa One używał XMLVM do generowania natywnego kodu w bardzo podobny sposób, ale rozwiązanie XMLVM było zbyt ogólne dla potrzeb Codename One.

Kompilacje iOS są kompilowane i podpisywane na komputerach Mac w chmurze za pomocą xcode (oficjalne narzędzie do budowania Apple). Dzięki temu są one zgodne z bieżącymi/przyszłymi zmianami wprowadzonymi przez firmę Apple i umożliwiają programistom korzystanie z systemu Windows/Linux podczas kierowania na system iOS. Możesz przeczytać więcej na temat kompatybilności ParparVM z iOS here.

W przeszłości nazwa kodowa One obsługiwała system Windows Phone przy użyciu translatora C# opartego na XMLVM, ale nie było to idealne podejście. Zauważ, że backend XMLVM, który tłumaczy się na C#, bardzo różni się od tego, który był poprzednio używany do tłumaczenia na iOS. Nazwa kodowa One wybrana na discontinue that old backend, ponieważ nie była tak silna jak nowy backend UWP i nie pasuje do celów Microsoftu idących dalej i skupiających się na UWP (Universal Windows Platform).

Dla komputerów stacjonarnych i urządzeń przenośnych dla systemu Windows Nazwa kodowa 1 używa iKVM do target UWP (Universal Windows Platform) i otworzyła źródła zmian oryginalnego kodu iKVM w wersji Codename One github repository.

Uwaga, UWP buduje są wykonywane w systemie Windows 10 maszyn w chmurze, umożliwiając tym samym programistom korzystać z Mac/Linux lub starszych wersjach systemu Windows podczas tworzenia okna rodzime aplikacje ...

JavaScript budować cele, które są dostępne na subskrybenci na poziomie korporacyjnym używają TeaVM do statycznego tłumaczenia. TeaVM zapewnia wsparcie dla wątków za pomocą JavaScriptu poprzez przerywanie aplikacji w dość skomplikowany sposób.Do obsługi złożonego interfejsu użytkownika Codename One wykorzystuje interfejs API HTML5 Canvas, który pozwala na całkowitą elastyczność w budowaniu aplikacji.

W przypadku kompilacji komputerowych Nazwa kodowa One używa javafxpackager, ponieważ zarówno komputery Mac, jak i komputery z systemem Windows są dostępne w chmurze, specyficzny dla platformy charakter javafxpackager nie stanowi problemu.

Cechą wyróżniającą Codename One jest podejście do interfejsu użytkownika, w którym wykorzystuje "lekką architekturę", aby interfejs działał bezproblemowo na wszystkich platformach i był rozwijany niemal w całości w języku Java. Jest on wzbogacony o możliwość umieszczenia widżetów "wagi ciężkiej" na miejscu wśród "jasnych". Możesz dowiedzieć się więcej na ten temat w tym blog post. Zauważ, że w tej chwili peering is undergoing some improvements, a teraz obsługuje bardziej skomplikowane zastosowania, takie jak warstw.

Lekki komponent jest napisany w całości w języku Java, dzięki czemu programiści mogą dokładnie wyświetlić podgląd aplikacji w symulatorze GUI &.

Nazwa kodowa Jedna osiąga wysoką wydajność, korzystając z natywnych interfejsów API gier większości platform, np. OpenGL ES na iOS.

Podstawowymi technologiami kryjącymi się za Codename One są wszystkie otwarte źródła, w tym większość materiałów opracowanych przez samą Codename One, np. ParparVM, ale także full library, platform ports, designer tool, device skins itd. Możesz dowiedzieć się więcej o korzystaniu ze źródeł kodowych One here.

FYI Shai Almog, autor tej odpowiedzi, jest dyrektorem generalnym Codename One.

Answer 2

Nazwa kodowa jednego przyjęła bardzo zrównoważone podejście do przenoszenia. Chciałbym dodać pragmatyczny komentarz.

Od strony interfejsu użytkownika, CN1 maluje cały swój interfejs na płótnie dostarczanym przez platformę. Próbuje naśladować wygląd i styl platformy macierzystej, jeśli ją wybierzesz, ale odniosła tyle samo sukcesów, co Swing z jej "natywnym wyglądem i stylem platformy", ponieważ rodzima platforma ciągle się zmienia, a "rodzimy l & f" zawsze jest za i w większości przypadków nie czuje się dobrze.

Ale jeśli wybierzesz niezależny od platformy wygląd i styl (który jest dzisiaj rodzajem trendu), nie jesteś ograniczony zestawem domyślnych zestawów kodowych Codenameone w żaden sposób: jest to tak samo jak Swing z wieloplatformowym wyglądem i czuć ("Metal" itp.). Co jest dobre.

Od strony językowej: na iOS jest to Java skompilowana do C, która jest następnie powiązana z ręcznie napisanym Objective-C, i nie łączy VM, tylko warstwy przenośności. Najważniejsze w tym przypadku jest to, że java jest kompilowany do C, a nie do Objective-C, co czyni go szybszym od idiomatycznego kodu Objective-C, ponieważ wykonuje wirtualne lub, częściej, bezpośrednie wywołania metod zamiast powolnego wywoływania komunikatów w Objective C. Co jest dobre.

Może również wydawać się nieco szybsze na Androida, ponieważ podczas korzystania z Dalvik/Art nie korzysta z natywnego interfejsu Android, który jest nieporęczny w porównaniu do CN1. Może to przyspieszyć tworzenie dynamicznego interfejsu użytkownika w czasie wykonywania, co jest dobre.

Jednym z najmocniejszych punktów podejścia CN1 jest jego emulator (zaimplementowany na płótnie JavaFX), którego używasz do tworzenia oprogramowania. Emulator korzysta z tego samego kodu UI i przenośnościowych interfejsów API, co na platformach mobilnych i pozwala używać IDE do debugowania. Ponownie uruchamia się ponownie, a cykl edycji-kompilacji jest bardzo trwały w porównaniu do Androida. Co jest dobre.

Drugi bardzo silny punkt (główny!) jest otwartym charakterem ich biblioteki UI, całego kodu natywnego i tłumacza kodu bajtowego na język C. Jeśli poświęcisz trochę więcej czasu, możesz uniknąć budowania portów Android/iOS w swoich farmach i rozwiązać problem z ich konkretną wersją produktu (ale nie z całkiem wielu usług o wartości dodanej, które oferują, a nie open source!). W zależności od sytuacji może to (lub nie!) Być całkiem dobre dla ciebie!

Słaby punkt Codenameone to mniej idealna dojrzałość, co oznacza, że ​​można łatwo strzelać sobie w stopę przy użyciu podstawowych składników interfejsu użytkownika, jeśli używa się ich w sposób, w jaki nie były przeznaczone do użycia. Oznacza to również, że jego warstwa przenośności java nie jest wystarczająco duża (i ma w sobie dziury), aby pokryć potrzeby wszystkich, a być może będziesz musiał użyć natywnego w niektórych miejscach i przenosić inne czyste biblioteki java.

Również obecny stan wydajności grafiki jest nieoptymalny; jeśli dostaniesz garść tekstu na ekranie, z łatwością stracisz 16 ms czasu na płynną animację/odświeżenie limitu czasu, można to obejść przez podwójne buforowanie, ale ma również swoje ograniczenia. Na szczęście istnieje jeszcze miejsce na optymalizację wdrożenia na obu głównych platformach, mam nadzieję, że poprawią to.

Ogólnie rzecz biorąc kodonitor ma dobrą niszę jako platformę międzyplatformową dla kilku klas aplikacji; możesz również znaleźć wartość w swoich usługach.