Aplikacje mobilne - porównanie technologii

Aplikacje mobilne - porównanie technologii

Załóżmy, że stoi przed nami zadanie wykonania aplikacji mobilnej. Klient nalega oczywiście, żeby zrobić to szybko, dobrze i tanio. Jak podejdziemy do tematu? Na rynku dostępnych mamy wiele narzędzi, które można wykorzystać w tym celu. Które wybrać? Oczywiście „to zależy” 🙂

Strona techniczna

Dostępne na rynku narzędzia można podzielić na trzy główne generacje.

1
Źródło – http://www.slideshare.net/Xamarin/xamarin-vs-hybrid-html-making-the-right-mobile-platform-choice-for-the-enterprise

1. Generacja pierwsza (aplikacje natywne)

Czyli aplikacje wykonane w specyficznym dla platformy języku. Dla Androida w Javie, dla iOS w Objective-C lub Swift, a dla Windows Phone w C#.

Zalety

– w pełni natywny UX, czyli aplikacje wyglądają i zachowują się w 100% tak jak powinny na danej platformie,

– wysoka wydajność aplikacji,

– niskie zużycie zasobów (nie mamy tutaj żadnych narzutów powodowanych przez dodatkowe narzędzia),

– w prosty sposób jesteśmy w stanie dostać się do hardware’u tzn. wykorzystać kamerę, żyroskop itd.,

nie uzależniamy się od dodatkowych zewnętrznych rozwiązań, których wsparcie może zostać zaniechane,

– jesteśmy w stanie szybko reagować na aktualizacje oprogramowania danej platformy mobilnej ze względu na brak pośredników,

ogromne community, które powstały wokół każdej z platform. Oznacza to mnóstwo dostępnych w Internecie rozwiązań, z których korzystamy na co dzień w pracy.

Wady

– Minusy to brak ujednoliconego środowiska programistycznego. Ile platform tyle języków programowania. Często sprowadza się to do dwóch osobnych teamów programistów z umiejętnościami związanymi z daną platformą.

– Brak możliwości współdzielenia kodu pomiędzy platformami. Oznacza to, że pewną część tej samej pracy będzie trzeba wykonać tyle razy na ile platform chcemy dostarczyć aplikację. Najczęściej dotyczy to części backendowej, czyli integracji z serwerem czy przetwarzania danych.

2. Generacja druga (aplikacje cross-platformowe, hybrydowe, HTML’owe)

Aplikacje mobilne tworzone za pomocą HTMLa i JavaScriptu. Mamy dostępnych wiele rozwiązań, które umożliwiają nam robić takie cuda. Najbardziej popularne to PhoneGap i Cordova. Z raz napisanego kodu w HTML i JavaScript generujemy aplikacje na wszystkie systemy. Możemy wrzucić je do sklepów i instalować jak normalne aplikacje natywne. Różnica jest jednak taka, że uruchamiane są one w tzw. web view, co na pierwszy rzut oka może być niezauważalne, jednak niesie to za sobą pewne konsekwencje.

Zalety

z raz napisanego kodu dostajemy aplikacje na wszystkie platformy mobilne (faktycznie ilość kodu, który piszemy raz może sięgać ponad 90%, dochodząc niemalże do 100%),

– używamy bardzo popularnych języków jakim jest HTML i JS (nie musimy dodatkowo znać Javy, C#, Objective-C itd.).

Wady

wydajność takich aplikacji znacznie spada w stosunku do rozwiązań natywnych (jeden z bardziej znanych problemów to długie listy, które podczas przewijania zacinają się),

– dostęp do hardware’u (np. kamery) w pewnym stopniu jest ograniczony. Ogólnie dostęp do hardware z poziomu JS umożliwiają nam komponenty pisane w języku specyficznym dla platformy. Oczywiście istnieje duża ilość gotowych komponentów jednak przy jakiś bardziej zaawansowanych scenariuszach możemy być zmuszeni do napisania takiego komponentu. Po jednym dla każdej platformy,

– problemem jest również UX/UI. Kod piszemy raz na wszystkie platformy to UX również mówiąc w skrócie wychodzi jeden. Nie jest on w pełni dostosowany do danej platformy,

dużo mniejsze community w porównaniu do tych zgromadzonych wokół rozwiązań natywnych,

– uzależniamy się od dodatkowych zewnętrznych dostawców. W przypadku update’u platformy musimy dodatkowo czekać, aż zostanie zupdatowane narzędzie, z którego korzystamy. Po drugie wsparcie takiego narzędzia może wygasnąć, co już się w historii zdarzyło,

– dodatkowa wiedza, którą trzeba przyswoić i która jest specyficzna dla wybranego narzędzia.

3. Generacja trzecia (aplikacje natywne cross-platformowe)

Połączenie najlepszych cech dwóch poprzednich generacji. Mamy dostępne dwa narzędzia – Xamarin oraz React Native. Są to rozwiązania, która mają zapewnić wydajność rozwiązań natywnych, możliwość zrealizowania w 100% natywnego UX, bezproblemowy dostęp do hardware’u oraz możliwość napisania wspólnych fragmentów tylko raz.

Zalety

bardzo dobra wydajność i niskie zużycie zasobów urządzenia (zbliżone do rozwiązań natywnych),

– możliwość dostosowania w 100% natywnego UX/UI,

– wysokie pokrycie (praktycznie 100%) api hardware’u,

– możliwość współdzielenia kodu między aplikacjami na konkretne platformy.

Wady

– jak w przypadku aplikacji pisanych w HTML + JS uzależniamy się od dodatkowych zewnętrznych dostawców,

– mimo wysokiej wydajności i niskiego zużycia zasobów pojawia się pewien narzut względem rozwiązań natywnych. Głównie z powodu dodatkowego poziomu abstrakcji, dzięki któremu jesteśmy w stanie pisać aplikacje w jednym języku (są to jednak narzuty minimalne),

– część kodu, która jest napisana raz i współdzielona jest stosunkowo niewielka w porównaniu do aplikacji pisanych w HTML i JS (z drugiej strony można uznać, że to zaleta, a nie wada),

raczkujące community, więc podobnie jak w aplikacjach generacji drugiej możemy natknąć się na problem, na który będzie ciężko znaleźć rozwiązanie w Internecie.

 

Kiedy decydować się na dane rozwiązanie

1. Natywne – tę opcję warto wybrać kiedy tylko można. Jest ona z pewnością najbardziej pewna – brak pośredników, żadnych narzutów, możliwość natychmiastowej reakcji na aktualizacje. Jesteśmy najbliżej jak się da konkretnej platformy, na którą piszemy. W największym stopniu w porównaniu do innych narzędzi będziemy w stanie doprowadzić aplikację do odpowiedniego wyglądu i zachowania dla danej platformy.

2. Hybrydowe – tutaj jesteśmy w stanie zyskać ogromną ilość czasu i znacznie obniżyć koszty. Warto wykorzystać to wyjście gdy nie zależy nam na w pełni natywnym wyglądzie. Aplikacje przygotowywane na potrzeby eventów, czy krótkoterminowych kampanii mogą być dobrym przykładem.

Warto zaznaczyć, że jest to również bardzo ciekawa opcja dla web developerów. Posiadając umiejętności pisania aplikacji webowych wystarczy dołożyć parę, max paręnaście godzin nauki/pracy i jesteśmy w stanie wyprodukować prostą aplikację, którą można zainstalować na każdym systemie. Jeżeli jednak stoimy przed zadaniem wykonania aplikacji, która ma być stabilnym, dużym projektem rozwijanym w przyszłości to nie jest to do końca dobry wybór.

3. Natywne cross-platformowe – w tym przypadku można mieć najwięcej wątpliwości kiedy warto, a kiedy nie. Dostajemy naprawdę niezłe narzędzia, które służą do budowania „pełnoprawnych” aplikacji natywnych. Nie chodzi tylko o projekty krótkoterminowe. Sam miałem głównie styczność z Xamarinem i mogę powiedzieć, że daje radę. Pewne narzuty i ograniczenia się pojawiają jednak z pewnością dojdziesz do celu. Nie jest na pewno tak, że nie warto się już uczyć Javy do pisania aplikacji na Androida, czy Objective-C/Swift do pisania iOS’a jednak, dla tych, którzy piszą w C#, czy mają cały team C# developerów może się okazać, że przykładowo wspomniany Xamarin jest nie najgorszym wyjściem. Potrafi skrócić czas i koszt wytworzenia, z pewnością ułatwi utrzymanie, a zarazem wytworzona aplikacja nie tracić zbyt dużo na jakości.

Podsumowując

1. Żadne dostępne aktualnie narzędzia umożliwiające pisanie aplikacji cross-platformowych (+ jakieś kolejne nowe, które z pewnością niedługo się pojawią) nie przewyższą zaletami aplikacji natywnych pod kątem technicznym. Nie napiszemy aplikacji lepszej niż natywna używając w/w narzędzi.

2. Obszar, w którym aplikacje cross-platformowe/hybrydowe mogą okazać się lepsze od natywnych to wyłącznie kasa i czas. Mogą pomóc nam zaoszczędzić na kosztach wytworzenia, czy utrzymania aplikacji. Pozwalają wykonać aplikację dużo szybciej i wykorzystując przy tym aktualnie posiadane umiejętności, co zaś dodatkowo w pewnym stopniu może obniżyć koszty. Wszystko, do czego sprowadzają się aplikacje cross-platformowe to obniżenie kosztów i czasu wykonania.

Moja ocena tego jest taka, że najlepiej byłoby pisać wszystko natywnie. O ile tylko mamy na to czas i pieniądze. Nad resztą rozwiązań warto się pochylić, gdy chcemy, bądź jesteśmy zmuszeni ciąć koszty (bo np. budżet się nie spina). Często jednak taka oszczędność może spowodować niższą jakoś aplikacji i uzależnienie się od dodatkowych zewnętrznych dostawców.

  • Jeśli chodzi o aplikacje hybrydowe, to część problemów (m.in. z wydajnością list, czy częściowe dostosowanie do platformy) rozwiązuje Ionic:
    http://ionicframework.com/docs/api/directive/collectionRepeat/

    Można również próbować to połączyć z Crosswalk:
    https://crosswalk-project.org/
    co dodatkowo powinno poprawić wydajność i wyeliminować bardzo irytujące problemy z różnicami w przeglądarkach internetowych na różnych urządzeniam mobilnych (poza gorszą wydajnością niż aplikacji natywnych, to jest to moim zdaniem największy problem aplikacji hybrydowych).

    Zresztą, taki SwipeStox korzysta właśnie z Crosswalka + cordova i nawet im to jakoś wychodzi 🙂

    • Adrian Bystrek

      Super, dzięki za dodatkową porcję wiedzy 🙂