W tym odcinku omawiam kluczowe technologie i pojęcia związane ze światem tworzenia aplikacji mobilnych.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 29. Alfabet Kiciora – edycja mobilna. To już chyba pewna tradycja, że połowę odcinków temu, a dokładnie w odcinku 15, poprowadziłem pierwszą edycję Alfabetu Kiciora, w której opowiadałem o technologiach webowych używanych do tworzenia aplikacji działających w przeglądarce, ale też wprowadziłem kilka podstawowym pojęć takich, można powiedzieć, wspólnych dla różnych ujęć technologicznych i teraz postanowiłem przejść do omówienia popularnych technologii mobilnych do tworzenia aplikacji – właśnie mobilnych. Także zachęcam, jeżeli jeszcze tego nie zrobiłaś, nie zrobiłeś do zapoznania się z odcinkiem 15, bo odnajdziesz w nim właśnie kilka takich podstawowych pojęć jak język programowania czy biblioteka, co pozwoli ci uzupełnić takie ogólne słownictwo, można powiedzieć, ale też myślę, że warto posłuchać z uwagi właśnie na technologie webowe, zwłaszcza że my tutaj w tym odcinku też poruszymy sobie poniekąd kwestie aplikacji webowych w bardzo, no, niewielkim, ale jednak ważnym zakresie.

No to zaczynamy, może niekoniecznie w kolejności alfabetycznej, choć zaczniemy od litery „A”, natomiast to wymienianie liter alfabetu ma dla mnie taką formę pretekstu do omówienia pewnych istotnych pojęć, bytów, koncepcji i jest to tylko taka konwencja.

Zaczynamy więc od litery „A” jak Android, czyli jeden z dwóch najpopularniejszych mobilnych systemów operacyjnych. Zaletą Androida, choć jednocześnie bolączką dla deweloperów, była zawsze ogromna różnorodność urządzeń, na które powstawały aplikacje. Pamiętam jak już ładne kilka lat po takim powstaniu, popularyzacji, kiedy zaczęliśmy tworzyć aplikacje mobilne w Makimo modeli IPhone’ów, na które można było wygenerować aplikacje było powiedzmy, że kilkanaście. Dokładnej wartości nie pamiętam, ale to był taki rząd wielkości, natomiast w przypadku Androidów, kiedy chciało się wdrożyć aplikację o analogicznym zakresie funkcjonalnym, w analogicznej równoważnej wersji Androida w grę wchodziło kilka tysięcy modeli urządzeń i to było już całkiem sporo lat temu. Trudno więc nie dziwić się, że programiści Androida, jeżeli tworzą aplikacje przeznaczone na taki ogólny rynek, a nie pod konkretne urządzenia, no są w trochę gorszej pozycji. Obecnie według różnych badań ma między 70 a 72% popularności na rynku smartfonów i bywa używany w przeróżnych urządzeniach, nie tylko na smartfonach czy choćby w samochodach, gdzie tak naprawdę po prostu zwykły Android jest używany w trybie auto. Natomiast można go znaleźć zwłaszcza w urządzeniach zamkniętych produkowanych przez firmy, gdzie ten Android jako otwarty system bywa używany jako podstawa to tworzenia dalszych systemów operacyjnych czy nawet w bardziej zaawansowanych urządzeniach IoT. Zaleta Androida, czyli jego taka uniwersalność to niestety też właśnie przekleństwo, bo zdarza się, że działa na urządzeniach bardzo tanich o niskiej wydajności co utrudnia stworzenie aplikacji, bo nawet jeżeli stworzymy fajnie działającą aplikację i ona będzie dobrze działać na popularnych, mocnych urządzeniach to potem okaże się, że ktoś zainstaluje ją sobie na bardzo kiepskim urządzeniu no, ale takim, które na przykład obsługuje nową wersję Androida mimo wszystko. No ale stwierdzi ta osoba, że ta aplikacja działa za wolno, nie do końca poprawnie, wystawi negatywną ocenę i co z tego, że aplikacja nie była zoptymalizowana pod takie urządzenia, niestety będzie to dla nas problem.

Skoro był Android to teraz „I” jak iOS. Trochę to może źle brzmi, bo przecież nazwę czytamy tak po angielsku, no ale cóż. Jest to główny konkurent i posiadacz niemal całego pozostałego udziału w rynku. W zasadzie jakieś inne systemy operacyjne to sumarycznie mniej niż 1 %, natomiast, no, mogłoby się wydawać, że czemu tak ważny jest iOS, skoro ma udział w rynku ponad 3 razy mniejszy. Jeżeli nie wiadomo o co chodzi to chodzi o pieniądze a tutaj nie da się ukryć, że użytkownicy IPhone’ów choć mniej liczni jakby nie patrzeć generują więcej przychodu dla sklepu z aplikacjami App Store niż ma to miejsce w przypadku Google Play. Także co z tego, że użytkowników jest mniej, skoro lepiej płacą. To ja bym powiedział, że wręcz bardzo dobrze, bo w końcu im mniej użytkowników tym potencjalnie mniejsze ryzyko, że będą marudzić. Chociaż no o tym można by dyskutować, bo z kolei płacący użytkownicy mogą być bardziej skorzy do dyskusji. To co jeszcze ważne od strony technicznej to to, że no wiadomo, że urządzenia z iOS-em produkuje tylko Apple. Mamy ograniczoną liczbę IPhone’ów, IPad’ów. Ona co prawda rośnie z czasem, ale wciąż nie musimy obsługiwać wszystkich IPhone’ów począwszy od tego pierwszego z 2007 r. No, z biegiem czasu kolejne IPhone’y jakby wypadają z gry, więc jest to, nie da się ukryć, dość korzystna sytuacja dla deweloperów. Warto tutaj wspomnieć, że publikowanie aplikacji w App Store jest no bardziej rygorystycznie traktowane niż w Google Play. Te aplikacje przechodzą taki manualny, ludzki proces kontroli. Warto o tym pamiętać, bo często tworząc aplikacje nie myśli się o wdrożeniu a ono też potrafi zająć sporo czasu.

Jesteśmy po omówieniu już obu głównych systemów operacyjnych, więc teraz przejdziemy do litery „N” jak aplikacja natywna. Aplikacje natywne to takie aplikacje, które, nie da się ukryć, że i Apple i Google chyba najbardziej chciałyby abyśmy tworzyli. Są to aplikacje pisane w technologiach dedykowanych tym platformom, czyli jest to taki najbardziej natywny, naturalny sposób tworzenia aplikacji dla iOS-a i dla Androida. Niestety technologie te są dość rozbieżne. Można by się nawet zdziwić, że skoro to są podobne urządzenia to technologie powinny być podobne i oczywiście one koncepcyjnie są podobne, ale technologie, w których je tworzymy, języki programowania, biblioteki są po prostu inne. Także nie da się na przykład z reguły, oczywiście są wyjątki, ale bardzo często programiści, którzy specjalizują się, powiedzmy, w iOS-ie – developmencie na iOS niekoniecznie są w stanie pisać aplikacje na Androida. Z drugiej strony mimo tej niewątpliwie wady, czyli tego, że ten proces trzeba przeprowadzać dla obu platform niezależnie takie aplikacje mają najszersze możliwości i no wydaje się, że można pokusić się o stwierdzenie, że będą działać też najbardziej wydajnie. Jeżeli piszemy jakąś wysokowydajną aplikację przetwarzającą dane to faktycznie wybór technologii natywnej ma sens.

Była literka „N” to teraz przechodzimy do „H” jak aplikacja hybrydowa. Aplikacje hybrydowe to o wiele bardziej szerokie pojęcie, takie parasolowe, obejmujące bardzo różne technologie, ale mające jeden wspólny cel: umożliwić napisanie jednej aplikacji do uruchomienia na obu mobilnych platformach, a w niektórych przypadkach także w ogóle na wielu innych platformach, na przykład na komputerach stacjonarnych. W historii aplikacji mobilnych było takich technologii no bardzo dużo, bo był, pamiętam, jedna z naszych pierwszych aplikacji mobilnych Appcelerator Titanium, był PhoneGap nazwany później Cordovą. Były też bardziej dojrzałe technologie, o których powiem osobno. I tutaj podstawową różnicą jest to czy te aplikacje hybrydowe są tworzone w stylu aplikacji webowych, gdzie wprost można skorzystać z doświadczenia, wiedzy programistów, programistek Front-end z zakresu aplikacji webowych (tutaj mogę odesłać właśnie ponownie do odcinka 15.), czy nie; czy jest to alternatywne podejście? Aplikacje mobilne w postaci webowej mają sporo zalet właśnie pod tym kątem – pod kątem takiej w zasadzie pełnej kompatybilności z aplikacjami webowymi. No pomijam oczywiście nowe funkcje, które smartfony mają, a takie zwykłe aplikacje webowe nie, ale też z kolei właśnie wsparcie pewnych natywnych mechanizmów obsługi kamery, GPS, akcelerometru, innych takich dodatkowych modułów bywają najtrudniejsze i też no najwięcej problemów z tym bywa. Z kolei tradycyjne aplikacje hybrydowe, czyli takie nieoparte o technologie webowe, front-endowe są gdzieś pośrodku, czyli można powiedzieć gdybyśmy mieli to tak sobie powiedzieć to aplikacje natywne są najbliższe platformom, potem mamy aplikacje hybrydowe takie tradycyjne, o których sobie powiemy i aplikacje mobilne, webowe, czyli takie najbliższe tradycyjnym aplikacjom webowym.

Teraz omówię dwie litery pod rząd, bo i oba te pojęcia są bardzo ze sobą zbliżone; mianowicie J, czy „dżej”, jak Java, „K” jak Kotlin to dwie technologie, które są zbliżone w alfabecie, natomiast są one używane do pisania aplikacji natywnych dla systemu Android. Na czym polega różnica? Java była używana jako pierwsza. Jest językiem pod kątem właśnie Androida starszym. Teraz już zdecydowanie częściej pisze się w Kotlinie. Javę możecie kojarzyć oczywiście z przeróżnych zastosowań; z aplikacji webowych, z aplikacji desktopowych. Jest to jeden z najpopularniejszych języków programowania. Kiedyś zresztą była też Java na stare telefony komórkowe, te przed erą smartfonów – Java Micro Edition. Pamiętam ją dobrze, bo na jej temat pisałem pierwszą książkę, natomiast później tak się złożyło, że Google postanowił użyć tego języka, aby tworzyć aplikacje natywne. Z czasem pojawił się Kotlin, który jest znacznie przyjemniejszy w użyciu według znanych mi opinii programistów no i nie da się ukryć, że jeżeli chcesz stworzyć aplikację mobilną natywną dla Androida to warto zainteresować się Kotlinem. Java to tylko jeżeli masz jakąś aplikację legacy, odziedziczoną no i po prostu trzeba coś w niej zrobić to wtedy ewentualnie no można temat kontynuować w Javie, ale to nie jest raczej preferencja deweloperów.

Były dwie litery dla Androida, to teraz dwie litery ze świata iOS, czyli „O” jak Objective-C i „S” jak Swift i tutaj sytuacja bardzo analogiczna; tworzenie aplikacji mobilnych zaczęło się od języka Objective-C, a teraz już od wielu lat używa się Swifta. Różnica może jest taka, że w przeciwieństwie do Javy Objective-C jest językiem bardzo niszowym, w zasadzie głównie związanym z platformą Mac, iOS, tak, z firmą Apple. Nie jest to język zbyt przyjemny, to tak z własnego doświadczenia powiem, no w sumie Java też nie jest, ale Objective-C do tego z językiem może nie tyle trudnym co takim, na który trudno się przestawić.

Teraz przechodzimy już do świata technologii hybrydowych, a więc „F” jak Flutter. Flutter to technologia autorstwa Google, natomiast działa nie tylko na Androidzie, jest też wersja dla iOS-a i co ważne, że to podkreślić – we Flutterze jest możliwe tworzenie interfejsów zgodnych z wytycznymi zasadami, które są określone dla obu systemów operacyjnych osobno, takie tzw. guidelines. Jest to jedna z najpopularniejszych obecnie platform do tworzenia aplikacji mobilnych, cross-platformowych, czyli właśnie hybrydowych i obecnie jest to też jeden z głównych wyborów, jeżeli nie chcę się robić takiej aplikacji hybrydowej webowej. Co warto podkreślić to taka może bardziej techniczna sprawa, ale Flutter w pełni zajmuje się wyświetlaniem swojego interfejsu użytkownika. Ważne jest to o tyle, że to daje bardzo, bardzo taką dużą wydajność przy zachowaniu jednocześnie kompatybilności z obydwoma platformami, a to była często bolączka takich technologii hybrydowych. Z drugiej strony warto wspomnieć, że we Flutterze aplikacje pisze się w języku Dart, który nie jest jakoś specjalnie trudnym, ale też nie jest to na przykład język tak bardzo popularny jak Java.

Jeżeli o Flutterze mowa to trzeba powiedzieć o chyba głównej konkurencji teraz, czyli „R” jak React Native. Technologia siłą rzeczy zbliżona do też znanej technologii frontowej React chociaż może to nie jest oczywiste, bo przecież Java i JavaScript to absolutnie nie to samo. React został opracowany przez Facebooka do tworzenia aplikacji webowych po stronie Front-endu no i wersja React Native jest taką technologią do tworzenia aplikacji właśnie mobilnych, hybrydowych. Przy czym warto podkreślić, że nie jest to tak, że programista Reacta automatycznie będzie w stanie tworzyć aplikacje w React Native. Oczywiście przekwalifikowanie się nie jest zbyt trudne, ale jednak nie jest to po prostu pstryknięcie palcem i rozpoczęcie pisania aplikacji w nowej technologii. Nie da się ukryć, że z drugiej strony też, nie popadajmy w skrajność, tak naprawdę dowolni programiści Front-endowi szybciej raczej odnajdą się właśnie w React Native niż na przykład we Flutterze. Odnotujmy też, że React Native jest technologią starszą, stąd też jeszcze 4-5 lat temu no to to był taki główny wybór przy aplikacjach hybrydowych, natomiast obecnie z uwagi na nieco gorszą wydajność związaną z bardziej złożoną metodą komunikacji z systemem operacyjnym, bo React Native, krótko mówiąc, wprowadza większy poziom skomplikowania w tej komunikacji niż Flutter, a także przez przekonanie się wielu deweloperów do Fluttera to wszystko powoduje, że React Native traci na popularności.

Na koniec, jeśli chodzi o technologie hybrydowe pozwolę sobie przypomnieć technologię Xamarin, ale to będzie Xamarin jak „X”, bo tak to się czyta po angielsku, to technologia, którą co do zasady możemy porównać do Fluttera i React Native, natomiast nie da się ukryć, że jest to jeszcze starsza technologia i już chyba swoje najlepsze, najbardziej świetne dni ma za sobą. To co może skłonić do jej wyboru to oczywiście fakt, że już mamy jakąś aplikację istniejącą w Xamarinie i przede wszystkim to, że jesteśmy zaangażowani w platformę Microsoft i technologie z nią związane, np. platformę .Net. Także no, jeżeli nie jesteś powiązany z Microsoftem lub jeżeli nie masz jakichś po prostu aplikacji do utrzymania w Xamarinie to radziłbym się zastanowić przed wyborem tej technologii. Oczywiście też zachęcam do dyskusji, bo znam jednocześnie wielu programistów, projektów zrobionych w Xamarinie całkiem skutecznych, natomiast odnotowuje też po prostu obecność pewnych trendów na rynku.

Na koniec przejdziemy do ponownie litery „I”. Tym razem jak Ionic, ponieważ związana jest to technologia z hybrydowymi aplikacjami webowymi, bo jeżeli chcemy stworzyć aplikację, która będzie de facto taką stroną, aplikacją webową od strony frontowej, opakowaną jako aplikacja do publikowania na sklepie to możemy stworzyć dowolny, dowolną architekturę Front-endową. Możemy sobie po prostu napisać prostą stronę, natomiast zdecydowanie lepiej jest korzystać z takiej kompleksowej technologii, która no jest jednak przygotowana pod takie zastosowanie i tutaj właśnie Ionic, czyli taka platforma właśnie do tworzenia aplikacji mobilnych webowych, która z jednej strony potrafi skorzystać z możliwości tych frameworków Front-endowych takie jak Angular, React czy Vue, a  z drugiej za pomocą jeszcze dodatkowej technologii Capacitor może być właśnie opakowana w aplikacje natywną sprawia że jesteśmy bardzo łatwo w stanie, bardzo szybko stworzyć aplikację webową do uruchomienia jako aplikację mobilną. Sam to testowałem niedawno i bardzo szybko taki proces przebiega.

I tak już naprawdę na koniec – nie byłyby to odcinek kompletny gdybyśmy nie wspomnieli o „P” jak Progressive Web Apps, czyli PWA; progresywne aplikacje webowe. Tutaj wydawałoby się, że wręcz z samej nazwy wynika to, że to w ogóle nie jest aplikacja mobilna. Natomiast to jest technologia, która wykracza poza którąkolwiek z platform i jest to pewien standard tworzenia aplikacji na podstawie aplikacji webowych, które mogą być instalowane na komputerach czy na smartfonach, tabletach użytkowników co daje pewne dodatkowe możliwości, np. wysyłanie powiadomień, też obsługę niektórych możliwości urządzenia. Co ważne – nie musimy wtedy takich aplikacji wrzucać na sklepy co ma swoje może wady, bo no nie są one wtedy tak widoczne na sklepie, ale z drugiej strony ma też zalety, bo np. jeżeli chcemy coś sprzedawać, jakieś dobra cyfrowe, nie musimy wtedy potrącać prowizji, a przynajmniej to jest coś co cały czas podlega pewnym obserwacjom i proszę pamiętać, że ta sytuacja może się zmienić. Natomiast póki co no można na przykład sprzedać swoje usługi w formie aplikacji PWA i no tutaj raczej żadna prowizja dla Apple czy dla Google nie powinna mieć miejsca.

Na tym kończymy ten odcinek. Mam nadzieję, że twoja wiedza na temat świata aplikacji mobilnych i technologii z nimi związanych się poszerzyła i będzie ci łatwiej odnaleźć się przy kolejnych rozmowach, dyskusjach na temat na przykład tworzenia aplikacji mobilnych, a jeżeli masz jakieś szczegółowe pytania, chciałbyś, chciałabyś dowiedzieć się nieco więcej na temat takiego procesu tworzenia takich aplikacji czy to hybrydowych czy natywnych, to po prostu napisz do mnie, chętnie porozmawiam i podzielę się bardziej szczegółowymi doświadczeniami.

Na dziś to już wszystko, dziękuję za uwagę, kłaniam się nisko i do usłyszenia.

KONIEC