Kto kiedykolwiek próbował napisać aplikację na smartphone przy pomocy domyślnych narzędzi, dostarczanych przez producenta, ten wie, że wymaga to dość obszernej wiedzy nie tylko programistycznej. Kluczowe jest zrozumienie samej platformy, na którą dedykowana jest aplikacja. Kruczków i sztuczek jest cała masa i bardzo łatwo wpaść w jakąś pułapkę. Po kilku/kilkunastu miesiącach obcowania w takim środowisku wszystko staje się przystępne, a "jedynym" wyzwaniem jest nadążanie za coraz to nowszymi ulepszeniami, dodatkowymi API.

Problem pojawia się, gdy programista zaznajomiony z konkretną platformą staje przed zadaniem napisania "tego samego" na inną platformę. Wtedy jego wiedza może się okazać co najmniej niewystarczająca, a niekiedy nawet może przeszkadzać w poznawaniu nowego.

Z pomocą przychodzą narzędzia tworzone przez podmioty trzecie, których misją jest ujednolicenie procesu wytwarzania oprogramowania niezależnie od platformy. Do tego celu tworzą specjalny software, które przetwarzają kod aplikacji w taki sposób, aby było możliwe uruchomienie go na różnych platformach.

Proces ten w skrócie wygląda następująco: kod napisany w języku, który abstrahuje od platformy docelowej jest kompilowany do języka, który jest wspierany przez tę platformę, następnie jest obudowywany warstwą narzędzi, które są niezbędne, aby ten kod na niej działał i ostatecznie budowany jest plik wynikowy przy użyciu natywnych narzędzi dostarczanych przez producenta danej platformy.

Język, który jest zazwyczaj do tego celu używany to JavaScript (a raczej ECMAScript). Ponieważ JS używany jest także przy budowie aplikacji webowych (SPA, PWA), stał się on niezwykle popularny i można powiedzieć, że przeżywa swój renesans.

Osobiście spotkałem się z następującymi frameworkami, jest ich znacznie więcej:

• ReactNative - narzędzia rozszerzające ReactJS, framework dostarczany przez Facebook;
• Xamarin - rozbudowany zbiór narzędzi, producent Microsoft;
• Ionic - framework, którego podstawą jest framework AngularJS;
• Appcelerator Titanium - Framework wraz z narzędziami do budowy aplikacji hybrydowych;

Nasuwa się pytanie: skoro budowa aplikacji na wiele platform jest możliwa, to dlaczego ich producenci się jakoś nie porozumieją i nie stworzą narzędzi wspólnych? Odpowiedź mogłaby brzmieć: ponieważ konkurują ze sobą. A poza tym, ze względu na złożoność jednej platformy, obsługa obu jednocześnie, zarówno po stronie producenta jak i programisty, który później miałby tworzyć taką aplikację wydaje się aż nazbyt skomplikowanym zagadnieniem.

Ponadto aplikacje hybrydowe nie są pozbawione wad. O ile stworzenie relatywnie łatwej aplikacji jest bezproblemowe, tak w przypadku, gdy zachodzi potrzeba użycia specyficznych API, które dana platforma dostarcza, narzędzia hybrydowe mogą nie podołać. Powodem jest ich ograniczoność- producent hybrydowego rozwiązania najpewniej nie dostarczy API do wszystkich zakamarków platformy. Ten problem można obejść np. za pomocą tworzenia bibliotek do frameworka, który stworzy interface dla hybrydowego API i połączy je z API natywnym. Czasami jest to ekonomicznie sensowne, niekiedy jednak problematyczność rozwiązania nokautuje hybrydowe podejście.

Rzeczą pomijaną przez twórców rozwiązań hybrydowych jest prędkość działania aplikacji. Hybrydy nigdy nie będą tak szybkie jak natywne rozwiązania, jednak w większości przypadków ich wydajność jest zadowalająca. Gry, które wymagają skrajnej wydajności nie są najlepszymi projektami, które można oprzeć na tych narzędziach.

Czy kiedykolwiek spotkałaś/spotkałeś się z hybrydami? Masz o nich jakieś zdanie? Podziel się w komentarzu!