Debata na temat aplikacji mobilnych
Wprowadzenie
Aplikacje mobilne i HTML5 to obecnie dwie najpopularniejsze technologie, które w wielu aspektach się pokrywają. Aplikacje internetowe działają w przeglądarkach mobilnych i mogą być też przekształcane w aplikacje natywne na różnych platformach mobilnych. Dzięki szerokiej gamie obsługiwanych platform i ogromnej mocy przeglądarek mobilnych deweloperzy coraz częściej wybierają HTML5 jako rozwiązanie typu „napisz raz, uruchom wiele razy”. Ale czy to naprawdę ma sens? Nadal istnieją ważne powody, dla których warto tworzyć aplikacje natywne, i wielu programistów wybiera właśnie tę drogę. Ten artykuł to debata na temat aplikacji natywnych i internetowych.
Bogactwo funkcji
Punkt: reklama natywna może więcej
Funkcjonalność mobilną możemy podzielić na 2 wymiary: działanie samej aplikacji i sposób, w jaki jest ona powiązana z ekosystemem urządzenia, np. w przypadku Androida są to funkcje takie jak widżety i powiadomienia. Reklamy natywne sprawdzają się w obu tych aspektach.
Aplikacje natywne mają większe możliwości. Mogą łatwo uzyskać dostęp do zdarzeń przesuwania i wielodotykowych na platformach, które je obsługują. Zazwyczaj reagują na naciśnięcie klawiszy fizycznych, takich jak przycisk wyszukiwania i przyciski głośności na urządzeniach z Androidem. Mogą też korzystać ze sprzętu, np. GPS-u i aparatu. Za zgodą użytkownika niektóre platformy zapewniają nieograniczony dostęp do systemu operacyjnego. Spróbuj sprawdzić poziom baterii za pomocą HTML5.
To jednak nie tylko kwestia działania aplikacji. System operacyjny, taki jak Android, udostępnia aplikacjom różne sposoby interakcji z użytkownikami, a także z innymi aplikacjami. Masz aktywne widżety na stronie głównej. Masz powiadomienia, które wyświetlają się na pasku stanu urządzenia. Masz też intencje, które umożliwiają aplikacji zgłaszanie, że świadczy ogólną usługę, której inne aplikacje mogą od czasu do czasu potrzebować.
Kontrargument: funkcje natywne można rozszerzać, a sieć i tak dogania aplikacje
To prawda, że wiele funkcji w aplikacji jest po prostu niedostępnych dla aplikacji HTML5. Niezależnie od tego, jak dobrze znasz się na technologiach internetowych, jeśli Twoja aplikacja jest zamknięta w piaskownicy bez interfejsu API aparatu, nie będzie w stanie robić zdjęć. Na szczęście nie musisz być w tym środowisku testowym. Jeśli naprawdę potrzebujesz, aby aplikacja internetowa robiła zdjęcia, możesz utworzyć aplikację natywną z osadzonym widokiem WebView, który zapewnia większość interfejsu użytkownika. Tak działa platforma PhoneGap typu open source: wypełnia lukę, udostępniając funkcje natywne jako usługi internetowe, które widok internetowy wywołuje za pomocą standardowego interfejsu API sieci. Gdy tworzysz taką aplikację hybrydową, możesz też korzystać z funkcji platformy, takich jak widżety, powiadomienia i intencje.
Tworzenie aplikacji hybrydowej – natywnej i internetowej – nie jest idealnym rozwiązaniem. Zwiększa to złożoność i dotyczy tylko aplikacji internetowych opakowanych jako aplikacji natywnych, a nie tradycyjnych witryn, do których dostęp uzyskuje się z przeglądarki mobilnej. Ale może nie będzie to konieczne przez długi czas. Standardy internetowe szybko się rozwijają, a nowoczesne przeglądarki mobilne za nimi nadążają. Pamięć offline, geolokalizacja, grafika Canvas oraz odtwarzanie filmów i dźwięku są powszechnie obsługiwane przez nowoczesne smartfony. Obsługa kamery też zaczyna być dostępna – od Androida 3.1 można robić zdjęcia i nagrywać filmy za pomocą standardów internetowych. Najnowsza przeglądarka na iOS obsługuje WebSocket do dwukierunkowego przesyłania strumieniowego, a także wykrywanie orientacji urządzenia.
Ogólnie rzecz biorąc, urządzenia mobilne się rozwijają. Sieć jednak szybko się rozwija. Wśród samych przeglądarek na komputery jest 5 głównych dostawców, którzy rozwijają standardy i dodają funkcje w błyskawicznym tempie. Przeniesienie tych funkcji na urządzenia mobilne nie jest łatwe, ale wiele z nich jest już dostępnych w przeglądarkach mobilnych.
Aplikacje natywne szybko się rozwijają, ale internet dogania je pod tym względem.
Wyniki
Argument: reklamy natywne działają szybciej
Aplikacje natywne nie muszą pokonywać bariery środowiska wykonawczego internetu. Działają one blisko sprzętu i mogą korzystać z funkcji zwiększających wydajność, takich jak akceleracja GPU i wielowątkowość.
Kontrargument: środowiska wykonawcze w internecie są obecnie znacznie szybsze, a większość aplikacji i tak nie potrzebuje takiej szybkości.
Stwierdzenie, że w ostatnich latach internet stał się szybszy, byłoby niedopowiedzeniem. V8, mechanizm JavaScript dostarczany z Chrome, był w momencie wprowadzenia przełomowym rozwiązaniem w zakresie wydajności internetu. Od tego czasu stał się jeszcze szybszy:
Silniki renderowania grafiki również przyspieszyły działanie internetu, a teraz zaczyna się akceleracja sprzętowa. Sprawdź przyspieszenie zapewniane przez płótno z akceleracją sprzętową:
Dodatkowo nowy interfejs Web Workers API umożliwia wielowątkowość, a nowocześni programiści stron internetowych mogą też korzystać z różnych bibliotek zoptymalizowanych pod kątem wydajności i dobrze zbadanych technik optymalizacji wydajności. Większość z nich powstała na potrzeby internetu na komputerach, ale nadal są przydatne na urządzeniach mobilnych.Zwraca się też coraz większą uwagę na urządzenia mobilne. Na przykład guru wydajności Steve Souders ma stronę poświęconą narzędziom do pomiaru wydajności na urządzeniach mobilnych.
Nie wszystkie nowości z komputerów trafiły jeszcze na wszystkie platformy mobilne, ale trendy wskazują, że to tylko kwestia czasu. Warto też pamiętać, że większość aplikacji mobilnych to nie najnowsze gry 3D, ale w zasadzie aplikacje oparte na informacjach: wiadomości, poczta, rozkłady jazdy, sieci społecznościowe itp. Odwiedź kilka witryn na urządzeniu mobilnym, np. Gmail, Amazon czy Twitter, a przekonasz się, że wydajność mobilnej sieci jest więcej niż wystarczająca. Jeśli chodzi o gry, podstawowe są już możliwe do stworzenia za pomocą elementu canvas 2D, a WebGL zaczyna pojawiać się na urządzeniach mobilnych – zobacz Firefox 4. Do czasu, gdy to nastąpi, powstaje coraz więcej platform, które kompilują aplikacje WebGL do aplikacji natywnych, które mogą korzystać z OpenGL, np. ImpactJS.
Środowisko programistyczne
Argument: aplikacje natywne są łatwiejsze w tworzeniu
Aplikacje natywne korzystają z zaawansowanych języków programowania (np. Java, Objective-C, C++), które zostały zaprojektowane z myślą o złożonych aplikacjach i mają sprawdzoną skuteczność. Interfejsy API zostały zaprojektowane od podstaw z myślą o obsłudze danej platformy. Możesz łatwo debugować aplikacje w emulatorach na komputery, które dokładnie odzwierciedlają urządzenie docelowe.
Tworzenie stron internetowych jest szczególnie problematyczne ze względu na ogromną różnorodność przeglądarek i środowisk wykonawczych. Gdy aplikacja jest uruchomiona, nie ma gwarancji, że funkcja X będzie dostępna. A nawet jeśli tak jest, jak przeglądarka to zaimplementuje? Standardy można interpretować na różne sposoby.
Kontrargument: tworzenie aplikacji internetowych jest często łatwiejsze, zwłaszcza jeśli są one przeznaczone na wiele urządzeń.
Zacznijmy od podstawowej technologii. To prawda, że standardy internetowe powstały w czasach, gdy internet był w zasadzie zbiorem dokumentów, a nie aplikacji. JavaScript został stworzony i wdrożony w zaledwie 10 dni. Okazało się jednak, że są one znacznie bardziej przydatne, niż początkowo sądzono. Deweloperzy stron internetowych nauczyli się wykorzystywać ich zalety i ograniczać wady, a obecnie znane są już wzorce projektowania skalowalnych aplikacji. Ponadto standardy nie stoją w miejscu, a projekty takie jak HTML5, CSS3 i EcmaScript Harmony stale ulepszają środowisko programistyczne. To, czy wolisz C++, Javę czy JavaScript, jest kwestią sporną, a także zależy od starszej bazy kodu. JavaScript jest obecnie poważnym konkurentem.
Z drugiej strony, fragmentacja przeglądarek i środowisk wykonawczych oznacza, że wszystkie te środowiska w ogóle istnieją. Tworzysz aplikację na Androida w języku Java, a potem musisz ją w całości przenieść do Objective C, aby obsługiwała iOS. Stwórz aplikację internetową raz, a będzie działać na Androidzie i iOS, nie wspominając o WebOS, BlackBerry, Windows Mobile i … cóż, tak przynajmniej wygląda teoria. W praktyce, jeśli chcesz zapewnić użytkownikom odpowiednie wrażenia, musisz dostosować ustawienia do każdej platformy. Jednak w przypadku większości mobilnych systemów operacyjnych musisz to zrobić też w aplikacji natywnej – istnieją różne wersje i różne urządzenia.
Dobra wiadomość jest taka, że „fragmentacja” zawsze była obecna w internecie i istnieją dobrze znane techniki radzenia sobie z nią. Co najważniejsze, zasada progresywnego ulepszania zachęca deweloperów do kierowania działań w pierwszej kolejności na podstawowe urządzenia i dodawania warstw funkcji specyficznych dla platformy, jeśli są one dostępne. Pomaga w tym również zasada wykrywania funkcji. Obecnie mamy biblioteki, takie jak Modernizr, które obsługują elastyczne projektowanie stron internetowych. Dzięki rozważnemu stosowaniu tych technik możesz zwiększyć zasięg, docierając do zdecydowanej większości urządzeń, w tym starszych telefonów komórkowych, a nawet zegarków i telewizorów, niezależnie od marki i systemu operacyjnego. Podczas Google IO 2011 zaprezentowaliśmy wieloplatformowy interfejs, w którym kierowaliśmy reklamy na różne urządzenia (telefony komórkowe, smartfony, tablety, komputery, telewizory) za pomocą wspólnej bazy kodu logiki i znaczników.
Wygląd i styl
Punkt: reklamy natywne pasują do wyglądu platformy
Jedną z najważniejszych cech każdej platformy jest jej wygląd i sposób działania. Użytkownicy oczekują, że elementy sterujące będą wyświetlane w spójny sposób i będą obsługiwane w ten sam sposób. Istnieją pewne idiomy, które różnią się w zależności od platformy, np. co się stanie, gdy użytkownik wykona „długie przytrzymanie” (przytrzyma element przez kilka sekund)? Platformy mają standardowe rozwiązania w takich przypadkach, a jedna aplikacja HTML5 nie spełni wszystkich tych wymagań.
Ponadto wygląd i styl platformy są koordynowane przez natywną bibliotekę oprogramowania platformy, której widżety zawierają wygląd i styl, jakich oczekują użytkownicy. Wiele oczekiwanych elementów interfejsu użytkownika jest dostępnych „bezpłatnie” dzięki korzystaniu z natywnego zestawu narzędzi.
Kontrargument: internet ma swój własny wygląd i styl, a interfejs internetowy możesz dostosować do platform, które są dla Ciebie najważniejsze.
Jak wyjaśniliśmy w poprzedniej sekcji, w przypadku tworzenia stron internetowych najpierw pisze się podstawową wersję „uniwersalną”, a potem stopniowo ją ulepsza. Ulepszenie jest zwykle oparte na funkcjach, ale możesz je też ulepszyć, kierując reklamy na platformy, które są dla Ciebie najważniejsze. Jest to rodzaj „wykrywania przeglądarki”, który jest czasami źle odbierany przez społeczność internetową, głównie dlatego, że istnieje tak wiele możliwych przeglądarek. Jeśli jednak wyświetlasz 2–3 platformy o bardzo wysokim priorytecie i chcesz włożyć dodatkowy wysiłek, aby konkurować z alternatywnymi platformami natywnymi, może to być dla Ciebie odpowiednie rozwiązanie.
Jeśli chodzi o wersję podstawową, internet ma swój własny wygląd, a nawet każda platforma mobilna ma swój własny „wygląd internetowy” określony przez domyślną przeglądarkę i środowisko wykonawcze internetu. „Wygląd i styl witryny” może być odpowiedni dla Twoich użytkowników, a w rzeczywistości pozwala osiągnąć większą spójność z przeglądaniem na komputerze i innych urządzeniach, z których użytkownik może korzystać. Poza tym istnieje wiele popularnych aplikacji, które nie obsługują natywnego wyglądu i stylu. Dotyczy to zwłaszcza gier (czy Twoja ulubiona gra mobilna jest zgodna z wyglądem i działaniem mobilnego systemu operacyjnego?) i nawet bardziej konwencjonalnych aplikacji. Sprawdź na przykład popularniejsze natywne klienty Twittera na wybranej platformie, a zobaczysz szeroką gamę mechanizmów interfejsu użytkownika.
Widoczność kanału i treści
Argument: aplikacje natywne są łatwiejsze do odkrycia
Mechanizmy dystrybucji aplikacji, takie jak Android Market i Apple App Store, w ostatnich latach zyskały ogromną popularność i są główną siłą napędową całej branży mobilnej. Każdy deweloper może przesłać swoją aplikację natywną na platformę, gdzie użytkownicy mogą ją znaleźć, przeglądając, wyszukując i otrzymując rekomendacje. Co więcej, jeśli dobrze wykonasz swoją pracę, pozytywne oceny i komentarze przekonają użytkowników do kliknięcia najważniejszego przycisku instalacji.
Kontrargument: aplikacje internetowe są łatwiejsze do odkrycia
Internet jest prawdopodobnie najbardziej dostępnym medium, jakie kiedykolwiek powstało. W skromnym adresie URL mamy (przynajmniej w teorii) unikalny identyfikator wszystkiego, co kiedykolwiek zostało opublikowane w internecie, w tym wszelkich aplikacji opublikowanych w standardowych witrynach. Wyszukiwarki ułatwiają odkrywanie tych treści, a inne witryny mogą do nich prowadzić linki, w tym katalogi aplikacji internetowych podobne do platform mobilnych. Każda osoba może udostępniać aplikacje internetowe znajomym, po prostu umieszczając do nich linki w e-mailach i wiadomościach w mediach społecznościowych. Linki można też wysyłać SMS-em. Użytkownicy mobilni będą mogli kliknąć link i uruchomić aplikację w przeglądarce na swoim urządzeniu.
Nie mamy jeszcze takich samych platform, na których użytkownicy mogą oceniać aplikacje i je komentować, ale to się zmienia. Czytaj dalej…
Zarabianie
Punkt: reklamy natywne mogą generować przychody
„6-latek tworzy aplikację w godzinę, sprzedaje milion kopii po 3 dolary za sztukę”. Ten nagłówek pojawia się ostatnio bardzo często, więc nic dziwnego, że deweloperzy, zarówno ci duzi, jak i mali, szukają możliwości zarabiania na platformach mobilnych. Platformy mobilne oferują deweloperom kilka sposobów na bezpośrednie pobieranie opłat za aplikacje. Najprostsza jest płatność jednorazowa, która odblokowuje aplikację na zawsze. Na niektórych platformach dostępne są też mechanizmy płatności w aplikacji i subskrypcji, które są ściśle zintegrowane w spójny i bezpieczny sposób. Te nowsze formy płatności pozwalają deweloperom przekształcić popularną aplikację w długoterminowe źródło przychodów.
Oprócz płatności w aplikacji możesz zarabiać na tradycyjnych modelach internetowych, takich jak reklamy i sponsorowanie.
Kontrargument: zarabianie w internecie było zawsze możliwe, a możliwości w tym zakresie stale rosną
Internet nie byłby motorem nowoczesnego przemysłu, gdyby nie było w nim wielu możliwości zarabiania. Chociaż mechanizmy bezpośredniej płatności za użycie nie rozwinęły się jeszcze w pełni, istnieją różne nisze, w których rozwiązania oparte na subskrypcji, czyli „oprogramowanie jako usługa”, stały się opłacalne. Przykłady to Google Apps, pakiet produktów 37Signals i wersje premium różnych usług poczty e-mail. Płatności bezpośrednie to nie jedyny sposób na zarabianie na aplikacjach internetowych. Obejmuje to reklamy online, linki partnerskie, sponsorowanie, promocję krzyżową innych produktów i usług.
Mimo to deweloper internetowy może przeczytać nagłówki i poczuć lekką zazdrość o zarobki. Nie możesz przesyłać adresów URL do natywnych platform handlowych. Co w takiej sytuacji powinien zrobić deweloper stron internetowych? Tworzysz natywną „aplikację opakowującą” – na każdą platformę, na którą chcesz kierować reklamy, tworzysz pustą aplikację natywną, która zawiera tylko widok internetowy. W widoku internetowym umieszczasz prawdziwą aplikację. Następnie przesyłasz te aplikacje na różne platformy handlowe (i miejmy nadzieję, że zaczniesz zarabiać!). Na głównych platformach handlowych jest obecnie prawdopodobnie setki, a może nawet tysiące aplikacji internetowych. Niektóre z nich są tak sprytnie zasymilowane, że w ogóle nie wiemy, że są aplikacjami internetowymi.
Wadą jest konieczność kompilacji krzyżowej na każdą platformę. W takiej sytuacji może pomóc istniejąca platforma, np. PhoneGap. Jeszcze lepiej, że powstają usługi internetowe takie jak PhoneGap Build i Apparatio. Skieruj te witryny do repozytorium kodu, a otrzymasz aplikację na Androida, aplikację na iOS itp. – gotowe do przesłania do odpowiednich sklepów. Nie musisz instalować na komputerze natywnych pakietów SDK. Do tworzenia tych wszystkich aplikacji natywnych wystarczy edytor kodu i przeglądarka internetowa.
Czy platformy handlowe będą kiedyś obsługiwać aplikacje internetowe bezpośrednio, bez konieczności ich natywnego opakowywania? Nie jest to jeszcze jasne. Wiemy, że w zeszłym roku Google wprowadził Chrome Web Store. Chociaż dotyczy on tylko komputerów, wzbudził zainteresowanie innych dostawców przeglądarek i jest częścią trendu w kierunku katalogów aplikacji internetowych, w tym niektórych prób dotyczących urządzeń mobilnych. Koncepcja sklepu internetowego jest jeszcze w powijakach, ale zapowiada się obiecująco.
Podsumowanie
Chętnie ogłosilibyśmy zwycięzcę, ale na razie nie ma wyraźnego faworyta. Niektóre aplikacje lepiej sprawdzają się jako natywne, a inne jako internetowe. Stos internetowy ma prawdopodobnie większy rozmach, ale pod względem możliwości i jakości wykonania aplikacje natywne też szybko się rozwijają. Dopóki technologie internetowe nie staną się w większości mobilnych systemów operacyjnych rozwiązaniem pierwszego wyboru, aplikacje natywne zawsze będą ważnym czynnikiem.
Jedną z technik wymienionych w tym artykule są aplikacje hybrydowe, które mogą być najlepszym kompromisem dla niektórych deweloperów: widok internetowy tam, gdzie jest to możliwe, i komponenty natywne specyficzne dla platformy tam, gdzie nie jest to możliwe.
Jeśli wybierzesz ścieżkę internetową, pamiętaj o standardach internetowych i zasadzie progresywnego ulepszania. Internet to technologia, która wie, jak docierać do wielu urządzeń i systemów operacyjnych. Niezależnie od tego, czy nazwiesz to „fragmentacją”, czy „różnorodnością”, internet to akceptuje, a programiści mogą korzystać z dotychczasowych rozwiązań.