Frameworki crossplatform – jak stworzyć aplikację na iOS i Androida jednocześnie?

15 grudnia 2018 9 minut czytania

Witajcie ponownie — dzisiaj dowiecie się, co to są frameworki crossplatform i po co ktokolwiek miałby ich używać. Nie chcę ukrywać, że nigdy nie byłem zwolennikiem takiego podejścia do tworzenia aplikacji, ale przy tym artykule postaram się odłożyć moje osobiste przekonania na bok i podać jak najwięcej suchych danych. Nie ma co przedłużać, zapraszam do konkretów!

Powstanie pomysłu

Jeśli używaliście przez dłuższy czas iOSa i Androida, to pewnie zauważyliście, że większość aplikacji wygląda identycznie na obu platformach. Czasami występują jakieś drobne różnice w interfejsie użytkownika, jednak zasada działania pozostaje taka sama. Chcąc stworzyć aplikacje w tradycyjny sposób, potrzebujemy dwóch zespołów programistów, po jednym na każdą platformę. Dodatkowo część kodu będzie zdublowana (oczywiście pod względem logicznym, ponieważ składnie Javy i Swifta mocno się różnią). Już na pierwszy rzut oka widać tutaj sporo miejsca na oszczędności. W pewnym momencie ktoś stwierdził, że zamiast pisać dwóch kompletnie osobnych porcji kodu, możemy napisać tylko jedną i skompilować ją osobno na iOS oraz Android. Dzięki takiemu podejściu moglibyśmy oszczędzić naprawdę sporo pieniędzy.

Błędy w założeniach

Zaletą oraz jednocześnie wadą takiego podejścia jest jego atrakcyjność pod względem marketingowym. Pomyśl sam, czyż nie wolałbyś napisać czegoś raz, tak żeby działało na obu platformach? Klient, słysząc takie coś, będzie zachwycony — dla niego oznacza to oszczędność 50% środków przeznaczonych na implementacje aplikacji. Jednak w rzeczywistości nie wygląda to tak kolorowo. O ile w prostych aplikacjach, posiadających kilka ekranów takie założenie jest bliskie prawdy, o tyle w tych bardziej skomplikowanych sprawy mają się nieco inaczej.

Czytając różne raporty dotyczące gotowych aplikacji stworzonych jako hybryda, można założyć, że stworzenie dwóch aplikacji w tej technologii zajmie 150% czasu wymaganego na stworzenie jednej aplikacji (na jedną platformę). Widać, że mimo wszystko jest oszczędność, jednak już nie tak duża jakby mogło się wydawać początkowo. Dodatkowo trzeba zaznaczyć, że często musimy korzystać z wiedzy dotyczącej konkretnej platformy. Tak więc nadal musimy posiadać w zespole ludzi doświadczonych w pisaniu na obie platformy. Możemy jedynie lekko zredukować ich ilość.

Różne podejścia

Frameworków crossplatform jest sporo — na końcu artykułu wymienię najważniejsze. Teraz chciałbym przedstawić trzy podejścia do tego tematu. Na potrzeby tego akapitu musisz wiedzieć, że wyróżniamy podział aplikacji na dwie warstwy. Pierwszą jest interfejs użytkownika, o którym już szerzej wspominaliśmy — jest to wszystko to, co widzi użytkownik po włączeniu naszej aplikacji: obrazki, przyciski i tak dalej. Drugą warstwą jest natomiast logika biznesowa, czyli wszystko to, co się dzieje pod spodem. Logiką biznesową jest na przykład to, że po kliknięciu przycisku „Zaloguj” wykonujemy zapytanie na serwer i logujemy użytkownika.

Jeśli to mamy wyjaśnione, to możemy wyróżnić najpopularniejsze podejścia do tematu aplikacji hybrydowych:

Współdzielenie samej logiki biznesowej — dzięki takiemu podejściu mamy pewność, że logika biznesowa na obydwu platformach będzie jednakowa. Z drugiej jednak strony mamy wolną rękę, jeśli chodzi o tworzenie interfejsu użytkownika. Możemy zrobić interfejs dostosowany zarówno do telefonów z iOS, jak i Androidem. Jednak jeśli chcemy mieć jednakowy wygląd na obu platformach, będziemy musieli pisać dwa razy to samo.
Współdzielenie logiki biznesowej oraz interfejsu użytkownika — to podejście jest podobne do tego wyżej, z tą różnicą, że również widoki są definiowane raz dla obu platform. Zaletą jest to, że nie musimy implementować dwa razy tego samego widoku, jednak nie możemy go również dostosować osobno pod każdą z platform (chociaż niektóre frameworki dopuszczają takie coś).
Współdzielenie interfejsu użytkownika — to podejście jest coraz rzadziej spotykane. Dawniej było bardziej popularne, jednak było implementowane w koszmarny sposób. Interfejs użytkownika był definiowany jako strona internetowa i wyświetlany w aplikacji na każdej z platform. Takie rozwiązanie było bardzo ciężkie i powodowało sporo błędów oraz potencjalnych niebezpieczeństw.

Jakie są zalety?

Tak jak wspominałem wyżej, największą zaletą jest niedublowanie logiki biznesowej. Mamy mniej miejsc na popełnienie błędów. Dodatkowo w przypadku zmiany wymagań klienta, wystarczy, że dokonamy zmiany w jednym miejscu i zaktualizujemy jednocześnie kod dla dwóch platform. Jest to ogromna oszczędność zasobów ludzkich oraz pieniędzy.

Kolejną zaletą jest oszczędność czasu. Przy standardowych aplikacjach (niewykorzystujących zaawansowanych funkcji systemowych) możemy zaoszczędzić nawet połowę czasu potrzebnej na napisanie jednej z platform. Czyli jeśli na napisanie aplikacji na Androida potrzebujemy 100% i tyle samo na aplikację na iOS, to na obie platformy jednocześnie wystarczy tylko 150%, a nie 200%.

Jakie są wady?

Jeśli chcesz pisać natywne aplikacje, to do Androida musisz użyć języka programowania Java lub Kotlin. Natomiast do iOS języka Swift (dawniej Objective C). Jednak niektóre frameworki wymagają do pisania jeszcze innego języka, tak więc nie wystarczy być programistą którejś z platform, aby móc pisać aplikację w tym frameworku.

Z wprowadzaniem osobnego języka wiąże się jeszcze jedna wada. Załóżmy, że Google wypuszcza jakąś super bibliotekę wymaganą do korzystania z funkcji systemowych. Jako że nie piszemy w Javie, nie możemy tak po prostu użyć tej biblioteki, musimy poczekać, aż wydawca używanego przez nas frameworka przepiszę tę bilbiotekę na odpowiedni język.

Kolejnym minusem jest dostęp do warstwy systemowej. W niektórych frameworkach aplikacja jest uruchomiona w dodatkowej warstwie abstrakcji — w przypadku wystąpienia błędu specyficznego dla systemu, możemy mieć ogromne problemy z odgadnięciem, co właściwie się dzieje i dlaczego nasza aplikacja nie działa.

Jakie frameworki są dostępne na rynku?

Nie chciałbym zagłębiać się za bardzo w szczegóły techniczne dotyczące każdego z frameworków, ponieważ nie każdego mogą one interesować. Mam zamiar opisać tylko podejście do tematu każdego z nich. Chciałbym również podziękować mojemu koledze Tomkowi za zrobienie porównania wszystkich najpopularniejszych frameworków, ponieważ mocno ułatwiło mi to pisanie tego akapitu. Dla zainteresowanych odsyłam do jego artykułu.

Dobra, dość ględzenia, oto obiecana lista:

Xamarin — jest to framework dość stary, o ugruntowanej pozycji na rynku. Używamy w nim języka C#. Oprócz logiki biznesowej możemy również współdzielić część interfejsu użytkownika. Największą wadą jest trudność w używaniu bibliotek systemowych.
Flutter — świeży framework stworzony przez Google. Do tworzenia aplikacji wykorzystujemy język Dart. W przypadku Fluttera współdzielimy zarówno logikę biznesową, jak i interfejs użytkownika (wszystko jest pisane w Darcie). Jeśli stosujemy się do wytycznych Google, nasza aplikacja będzie niesamowicie szybka.
React native — framework stworzony przez Facebooka. Aplikacje piszemy w języku JavaScript. Framework jest przyjazny dla programistów front end, którzy tworzyli już kiedyś w Reactcie. Współdzielimy tutaj zarówno widoki, jak i logikę biznesową. Największym minusem Reacta jest jego wydajność, ponieważ aplikacja cały czas utrzymuje uruchomione środowisko JavaScript, co może powodować spowolnienia przy bardziej wymagających aplikacjach.
Kotlin native — framework stworzony jako dodatek do Kotlina, oficjalnego języka do pisania aplikacji na Androida. Zgodnie z nazwą aplikacje piszemy tutaj w języku Kotlin. W tym frameworku współdzielimy jedynie logikę biznesową, wszystkie rzeczy działające bezpośrednio z systemem musimy napisać w kodach natywnych dla każdej z platform. Największym minusem jest to, że projekt jest obecnie w mocno początkowej fazie, wobec czego zdarzają się pewne błędy.
Unity 3D – jest to framework stworzony na potrzeby tworzenia gier. Piszemy tutaj w języku C#. Z zalet można wymienić wydajność przy renderowaniu grafiki. Framework nie jest zalecany do tworzenia zwykłych aplikacji, niemających nic wspólnego z renderowaniem skomplikowanych grafik.

To już koniec na dziś, dzięki za przeczytanie. Dajcie znać w komentarzach, jeśli korzystaliście z któregoś z frameworków i jakie są wasze odczucia. W sprawie crossplatform nie jestem jakimś wielkim ekspertem, także wszelkie słowa krytyki mile widziane. Widzimy się za tydzień, gdzie dowiecie się, jak obsługujemy kilka języków w jednej aplikacji. Do zobaczenia!

Zapraszam również na największe w Polsce forum dla programistów Android. Jeśli macie pytania odnośnie do kariery programisty — zapraszam do działu Kariera programowanie. Zachęcam również do przejrzenia działu Praca oraz zlecenia dla programistów — być może to właśnie tam znajdziesz swoją pierwszą pracę.

Jeśli potrzebujesz odskoczni od programowania…

…możesz zostać wykładowcą w Coders Lab i uczyć grupy ambitnych osób, które chcą rozpocząć karierę w branży IT. Dzięki temu będziesz mieć realny wpływ na edukację młodego pokolenia programistów. To także doskonały sposób na Twój własny rozwój i zwiększenie motywacji do programowania. Do wyboru masz wiele technologii, a o tym, jakie korzyści płyną z pracy jako wykładowca w Coders Lab, możesz przeczytać tutaj.

Poprzednie odcinki: