Tworzenie Aplikacji Mobilnych – 3 możliwości: HTML5, natywna, czy hybryda?

Tworząc aplikację mobilną musimy odpowiedzieć na wiele pytań: co ma robić?, jak ma wyglądać?, jak użytkownik ma się w niej poruszać, itp. itd.? Wśród tych pytań są również te związane z technologią. Teoretycznie wszystko niby jest proste Android to Java, iOS to Objective-C. Niestety kilka lat temu powstała idea aplikacji mobilnych opartych o HTML5. Trzeba przyznać, że trochę ta idea namieszała w porządku i nie da się koło tej opcji przejść obojętnie. Powiem więcej, trzeba przeanalizować i przekalkulować, czy jest sens wykorzystać to, co daje nam ta możliwość.

Aplikacja Mobilna: HTML5 czy natywna?


Niniejszy post jest częścią serii postów pod tytułem: Jak stworzyć aplikację mobilną? Jeżeli zainteresowała Cię ta tematyka, to zachęcam do przeczytania pozostałych artykułów powiązanych z tworzeniem aplikacji mobilnych.


Podsumowując, aplikacje mobilne możemy wykonać na 3 sposoby. Może to być aplikacja:

  1. HTML5
  2. Natywna
  3. Hybrydowa

Aplikacja HTML5

W przypadku Aplikacji HTML5, cała aplikacja jest oparta o technologie webowe: HTML5, CSS, jakiś framework JavaScriptowy. Całość wsadzona jest w natywny kontener pozwalający na dystrybucję w AppStore czy GooglePlay. W przypadku takiego projektu potrzebujemy specjalistów, którzy mają dowiadczenie w technologiach webowych, nie koniecznie potrzebujemy specjalistów od aplikacji mobilnych, przy założeniu, że projekt UI i UX został wykonany poporawnie z uwzględnieniem specyfiki urządzeń mobilnych. O aplikacjach HTML5 pisałem już jakiś czas temu w tym poście. Przytaczając zalety takiego rozwiązania, wybór takiego podejścia ułatwia nam:

  • w przypadku prostych aplikacji ponosimy dużo mniejszy nakład pracy na stworzenie aplikacji działającej pod iOS’em oraz Android’em
  • pewne rzeczy związane z implementacją widoków prościej jest zrobić w HTML niż natywnie
  • w razie czego można ten kod HTML wykorzystać do stworzenia aplikacji webowej uruchamianej na zwykłym komputerze (MacBook, PC)

A oto wady tego rozwiązania o których również już kiedyś wspomniałem:

  • brak bezpośredniej integracji ze sprzętem: system plików, aparat, kamera, akcelerometr, baza danych, itp
  • brak możliwości optymalizacji aplikacji poprzez zrównoleglenie pewnych operacji na wątkach
  • dużo mniejsza wydajność, co skutkuje znacznie słabszym useability, wolniejszym działaniem aplikacji, problemami z pamięcią, itp.
  • różnice w szybkości aplikacji (gdy przyjmiemy, że aplikacjia na iOS to 100%, ta sama aplikacja na podobnej platformie sprzętowej na Android będzie działała z szybkością 50%)
  • zwiększony nakład pracy, by otrzymać pewne “efekty” które w technologiach natywnych mamy do dyspozycji “od ręki”
  • i wiele, wiele innych

Poza tym, z całą odpowiedzialnością mogę powiedzieć, że UX aplikacji HTML jest w większości przypadków co najmniej średni. Wykorzystanie animacji w przejściach między ekranami działa co najmniej średnio. Tym gorzej im słabszy sprzęt jest używany do uruchomienia aplikacji. Nawet na dobrym sprzęcie gołym okiem widać różnicę. Wystarczy spojrzeć na ciekawą aplikację Nozbe, którą oceniałem i której właśnie problemy z interfejsem wytykałem. Nie wszystkich takie rzeczy drażnią, nie wszyscy takie rzeczy widzą, ale nie da się ukryć, że jeśli chcemy wydobyć 100% z urządzenia i dać użytkownikowi 100% jakości, to nie ma miejsca na kompromis i trzeba sięgnąć po opcję nr 2.

Cały czas używam terminu aplikacje HTML5. Jednak pragnę uściślić, że takie aplikacje nie składają się jedynie z elementów wykonanych z HTML5. Oprócz tego do gry wchodzą CSS oraz JavaScript i cała gama frameworków. Do tych najpopularniejszych należą:

Aplikacja Natywna

Aplikacja Natywna zbudowana jest w całości tylko i wyłącznie z natywnych komponentów, w przypadku iOS napisana jest w Objective-C z wykorzystaniem iOS SDK, w przypadku Androida wykorzustyjemy Javę i Android SDK. Do wykonania aplikacji natywnych potrzebujemy ludzi z doświadczeniem w natywnych technologiach, ale też zaznajomionych z SDK konkretnej platformy, czyli specjalistów w swojej dziedzinie.

Minusem tego podejścia jest konieczność pisania każdej z natywnych wersji oddzielnie na każdą platformę. W związku z czym, koszta takiego projektu przynajmniej teoretycznie będą większe niż w przypadku Aplikacji HTML5 i Aplikacji Hybrydowej. Piszę „przynajmniej teoretycznie”, gdyż różnie z tym bywa. Czasem wykonanie pewnych modułów aplikacji hybrydowej lub HTML5 zajmie tyle samo lub nawet więcej czasu niż oddzielnie napisanie go natywnie na wybrane platformy. Często trzeba się solidnie nagimnastykować, żeby w HTML5 i hybrydzie osiągnąć odpowiednią wydajność, podczas gdy w przypadku natywnych aplikacji z definicji mamy możliwość wykorzystania maksimum sprzętu, bez żadnych dodatkowych narzutów.

Do zalet aplikacji natywnych należą zdecydowanie zniesienie ograniczeń dla programisty do minimum. Jedyne co nas ogranicza to dana platforma sprzętowa i softwarowa. Mamy przez odpowiednie komponenty SDK dostęp do sprzętu (kamera, akcelerometr, system plików). Dzięki temu możemy w naszej aplikacji wykorzystać maksimum danego urządzenia. Dodatkowo działamy na maksymalnej wydajności. Nie ma pośrednika w postaci parsera i interpretera JavaScriptu. Skompilowany kod wykonywany jest przez procesor w maksymalnej prędkości. (Nie wchodzę tutaj już w detale tj. narzut wirtualnej maszyny Javy czy też Objective-C Runtime, bo niżej niż to już nie zejdziemy). Dostępne bazy danych (przeważnie SQLite) są wspierane przez towarzyszące im Frameworki (iOS – CoreData; Android – jest trochę ORMów, np OrmLite), co znacznie ułatwia budowanie skomplikowanych aplikacji.

Aplikacja Hybrydowa

 

Aplikacja Hybrydowa łączy wady i zalety obu powyższych rozwiązań. Aby wykonać taką aplikację, potrzebujemy ludzi z wiedzą zarówno z technologii webowych jak i natywnych. Nie jest prosto znaleźć specjalistę od iOS, który świetnie zna iOS SDK i Objective-C a jednocześnie rozumie i umie technologie webowe, zwłaszcza frameworki JavaScriptowe. To samo dotyczy Androida. Dobry Javoviec nie koniecznie chce i lubi pisać w JavaScript. Oczywiste jest, że nie wszyscy programiści muszą znać się na wszystkim, czasem wystarczy nam 1 osoba która jest w stanie zintegrować iOS i HTML5 i druga odpowiedzialna za integrację Javy z HTML5. Jeśli mamy wielkie szczęście, to w zespole będziemy mieć magika znającego w praktyce iOS, Javę i technologie HTML5, jednak nie ma się co oszukiwać i takich ekspertów nie spotykamy na co dzień.

Aplikacja Hybrydowa może czerpać korzyści z aplikacji HTML5: tam gdzie to możliwe można zrobić jeden element aplikacji raz na wiele platform, a tam gdzie potrzebujemy dużej wydajności lub współpracy ze sprzętem, możemy użyć natywnych komponentów i wykonać połączenie między nimi a komponentami HTML5. Z mojego doświadczenia mogę powiedzieć, że aplikacje hybrydowe stają się co raz bardziej popularne w obszarze B2B. Firmy nie chcę przeinwestować i czasem są gotowe pójść na kompromisy i na przykład kosztem świetnego UX, zrobić aplikację taniej, ale z nieco słabszym interfejsem i doświadczeniem użytkownika. Powiedzmy sobie szczerze: pracownicy mają do wykonania jakieś konkretne zadania i wg niektórych firm interfejs ich aplikacji nie musi zachwycać i zwalać z nóg, a przynajmniej nie jest to najwyższy priorytet.

Z wydajnością hybrydy wiążę się też pewna prawidłowość: z aplikacjami i urządzeniami z jakimi ja miałem kontakt, wynika, że wydajność tej samej aplikacji na urządzeniu platformy iOS jest kilkukrotnie większa niż na platformie Android. Jest to temat skomplikowany. Częściowo wynika ze specyfiki budżetowych urządzeń z Androidem (tańsze i wolniejsze podzespoły), częściowo z wersji samego Androida (np brak wsparcia sprzętowego przy renderowaniu widoku w HTML), z wydajności samego kontenera webowego, który uruchamia kod części HTMLowej, czy też z dodatkowych narzutów, niezbędnych do działania wirtualnej maszyny Javy vs Objective-C Runtime.

Zapraszam do lektury artykułu Sencha Touch – hybrydowe aplikacje mobilne, w którym staram się pokazać możliwości potężnego frameworka, który na pewno warto rozważyć jako warstwę HTML5 aplikacji hybrydowej.

Podsumowanie

Podsumowując: Jak widać powyżej wybór jednej z tych 3 opcji niesie ze sobą dosyć konkretne skutki. Trzeba się solidnie zastanowić i przekalkulować: finanse, ale też ryzyka związane z każdą z tych opcji. Nie ma jednoznacznej odpowiedzi, że zawsze warto pisać hybrydę, albo że zawsze tylko natywne. Często wybierając jedną opcję poświęcamy coś kosztem czegoś innego: niższy koszt projektu w zamian za nieco słabszy interfejs. Każda sytuacja jest inna i każdy ma inne preferencje czy też wymagania, a także inny budżet. Jedno jest pewne, każdy może wybrać coś dla siebie.

Dodaj komentarz