Sytuacja kobiet w IT w 2024 roku
14.01.20218 min
Łukasz Dudziński

Łukasz DudzińskiStrefaKodera.pl

Technologie do budowy wieloplatformowych aplikacji mobilnych

Sprawdź, jakich technologii możesz użyć, budując wieloplatformową aplikację mobilną oraz poznaj zalety i wady poszczególnych rozwiązań.

Technologie do budowy wieloplatformowych aplikacji mobilnych

Na wstępie chciałbym gorąco przywitać się, ze wszystkimi czytelnikami portalu Bulldogjob. Ja nazywam się Łukasz Dudziński i jestem autorem bloga programistycznego Strefa Kodera. Jest to moje zajęcie, które rozwijam „po godzinach”. W pełnym wymiarze zajmuję się tworzeniem multiplatformowych aplikacji mobilnych z wykorzystaniem technologii Xamarin. Jeśli nie lubisz Microsoftu, to mam nadzieję, że nie uciekniesz czym prędzej, omijając niniejszy artykuł.

Nie będę tutaj bawił się w ewangelistę tej korporacji i wymieniał całej litanii przeróżnych zalet środowiska .NET oraz C#. Celem tego materiału będzie przedstawienie Ci kilku fajnych technologii, wykorzystywanych do budowy wieloplatformowych aplikacji mobilnych. Jedną z nich jest wywołany do tablicy Xamarin, ale to nie wszystko, na rynku są też inne ciekawe narzędzia. Zalicza się do nich Flutter, React Native czy PWA (ang. Progressive Web App).

Wybór jest naprawdę spory. Nie zmienia to faktu, że obecnie rzadko kiedy słyszę o aplikacjach hybrydowych, budowanych raz i działających jednakowo pod systemem Android oraz iOS. Tak naprawdę w komercyjnych zastosowaniach, wykorzystuje się na szeroką skalę głównie aplikacje budowane natywnie. Jeśli jednak dobrze się rozejrzysz, to oczywiście znajdziesz duże projekty, prowadzone przez jeszcze większe firmy, a budowane właśnie na podstawie idei „napisz raz, uruchom gdziekolwiek” (ang. write once, run anywhere).

Co prawda wspomniane zdanie odnosiło się bardziej do koncepcji forsowanej przez Sun Microsystems w kontekście promocji Javy, ale tutaj również idealnie pasuje. Jeden kod, jedna aplikacja i wiele systemów operacyjnych. To naprawdę ma sens, ale jak to zwykle bywa, diabeł tkwi w szczegółach. Nie zawsze sprawdza się to idealnie. Jeśli przykładowo potrzebujesz aplikacji, która w pierwszej kolejności ma ładnie wyglądać, to raczej szedłbym tutaj w rozwiązania natywne. Pamiętaj, że wybór technologii to jedna z najważniejszych decyzji, jaką podejmujesz na starcie projektu. Dlatego też zawsze polecam zrobić kilka mini aplikacji POC (ang. proof of concept), aby na „żywym organizmie” sprawdzić, jak to wszystko działa, a przede wszystkim czy od strony technicznej jesteś w stanie podołać założeniom projektowym.

Na koniec mam jeszcze jedną prośbę do Ciebie. Nie traktuj tego artykułu i zawartych w nim opinii jako te jedyne właściwe. To, co tutaj piszę, to w dużej mierze moje subiektywne zdanie, które jest aktualne na moment tworzenia niniejszego materiału. Jak każdy, mogę się mylić, więc jeśli pod wpływem moich opinii zdecydujesz się na jedno z prezentowanych tutaj rozwiązań, to mam nadzieję, że przed ostatecznym podjęciem decyzji dokładnie wszystko przemyślisz. Dowieźć projekt do końca będziesz musiał Ty, a nie ja. Ja swoje aplikacje dostarczam zgodnie z założeniami :)

Xamarin

Na pierwszy ogień, wziąłem Xamarina. Jest to technologia, w której pracuję na co dzień, więc najłatwiej też mi napisać co nieco na ten temat. Jak już pewnie się domyślasz, to narzędzie rozwijane przez firmę Microsoft, aczkolwiek nie ona była jego twórcą. Działa na podstawie technologii .NET, a cały kod piszemy w języku C#. Do budowy interfejsu użytkownika obecnie wykorzystujemy XAML (aczkolwiek są też inne sposoby na rozwiązanie tego elementu), ale to w najbliższym czasie może się zmienić. Jeśli wszystko pójdzie pomyślnie, UI będzie tworzony w całości programistycznie. Jest to koncepcja analogiczna, do tego, do czego zmierzają twórcy systemów Android oraz iOS. Tak nawiasem pisząc, miałem nawet jakiś czas temu okazję zabawy ze Swift UI i muszę powiedzieć, że naprawdę fajnie się to zapowiada. Zobaczymy, co z tego wyjdzie w przyszłości, ale na razie zejdźmy na ziemię.

Xamarin umożliwia budowę aplikacji międzyplatformowych poprzez współdzielenie kodu pomiędzy różne systemy operacyjne. Jest kilka koncepcji na osiągnięcie takiego założenia: NET Standard Libraries, Shared Projects oraz Portable Class Libraries — to akurat rozwiązanie „przestarzałe”, więc nie rekomenduję jego wykorzystania. Nie będę tutaj dokładnie opisywał, na czym one polegają. Jeśli chcesz poznać szczegóły, to odsyłam do stosownej dokumentacji technicznej.

To, co mi osobiście podoba się w Xamarin, to natywne wsparcie dla wzorca architektonicznego MVVM (ang. Model-View-ViewModel). Moim skromnym zdaniem jest to jedna z najlepszych koncepcji architektonicznych, jaką można wykorzystać w budowie większości aplikacji mobilnych. Podział na model, widok oraz warstwę pośrednią (ang. ViewModel) pozwala programiście w bardzo prosty sposób dostosować się do zasady separacji problemów (ang. separation of concerns). To z kolei wpływa na łatwy podział prac oraz późniejsze tworzenie testów.

Aplikacje budowane z wykorzystaniem Xamarin, finalnie kompilowane są do wersji natywnych pod każdy z obsługiwanych systemów operacyjnych. Ich dystrybucja, działanie oraz wygląd interfejsu użytkownika są takie sam jak dla oprogramowania budowanego w sposób tradycyjny. Wszystkie różnice związane z wyborem tej technologii są odczuwane jedynie na poziomie programistycznym i nie mają końcowego wpływu na odbiór produktu przez użytkowników.

Jeśli na co dzień pracujesz w środowisku .NET, to myślę, że warto zainteresować się tym rozwiązaniem. Przy wykorzystaniu jednego ekosystemu, możesz zbudować aplikację mobilną pod system iOS, Android oraz UWP (ang. Universal Windows Platform), web serwis oraz aplikację internetową. Cały komplet może w prosty sposób działać wspólnie, a Twój klient dzięki temu, oszczędzi wiele czasu i pieniędzy.

Progressive Web App

Progresywne aplikacje internetowe to stosunkowo świeża koncepcja promowana przez wiele dużych firm ze świata IT, w tym Google. Polega ona na budowie stron internetowych imitujących swoim zachowaniem natywne aplikacje mobilne. Nazwa „Progressive Web App” w całości odzwierciedla zamysł jej twórców. Polega ona na budowie zwykłej strony internetowej z wykorzystaniem „starych” sprawdzonych rozwiązań.

Jednym wyjątkiem, który odróżnia taką witrynę od innych, jest wdrożenie mechanizmu service worker. W momencie, w którym użytkownik po raz pierwszy, odwiedza stronę internetową, zbudowaną zgodnie z wytycznymi PWA, zachodzą następujące akcje:

  • wszystkie elementy statyczne warstwy aplikacji — odpowiednik interfejsu użytkownika — zapisywane są w pamięci cache urządzenia. W efekcie mamy do nich dostęp bez konieczności ponownego łączenia się z internetem. Ten punkt to de facto imitacja procesu instalacji natywnej aplikacji mobilnej,
  • użytkownik otrzymuje komunikat z informacją o możliwości zapisania ikony skrótu do odwiedzanej witryny, tak aby dostęp do niej był identyczny jak dla „zwykłej” aplikacji mobilnej.


Po wykonaniu powyższych kroków, aby ponownie odwiedzić daną witrynę internetową, możemy posłużyć się stworzonym wcześniej skrótem, a do poprawnego działania, nie potrzebujemy łączności z zewnętrzną siecią.

Oczywiście rozwiązanie to ma swoje wady. Budujemy tutaj stronę internetową, a nie aplikację mobilną. Nie możemy więc skorzystać z szeregu różnych funkcji, jakie dają nam rozwiązania natywne oraz cross-platformowe. Przykładowo, na moment, w którym piszę te słowa, PWA nie zapewnia wsparcia dla obsługi zadań wywoływanych w tle. Nasze oprogramowanie może więc wykonywać jakieś czynności, ale tylko do momentu, w którym urządzenie nie zostanie uśpione bądź użytkownik nie uruchomi innej aplikacji.

Nie wszystko jednak jest na straconej pozycji. Nasza witryna napisana zgodnie z zasadami PWA może między innymi wysyłać powiadomienia push czy też obsługiwać nadajnik GPS. Dla większości projektów taka funkcjonalność będzie wystarczająca.

Jeśli zainteresował Cię ten temat i chcesz poznać więcej szczegółów związanych z tworzeniem witryn internetowych zgodnie z zasadami PWA, to odsyłam do dokumentacji. Ciekawy opis możliwości tego narzędzia, znajdziesz na łamach serwisów prowadzonych przez Google.

React Native

Facebook to nie tylko portal społecznościowy. To również całkiem spora firma technologiczna, która może pochwalić się opracowaniem wielu ciekawych rozwiązań technicznych. Jednym z takich projektów jest React Native, otwarty framework mobilny, wykorzystywany do budowy wieloplatformowych aplikacji, działających pod systemami takimi jak: Android, iOS czy UWP.

Tutaj podobnie jak w przypadku PWA, tworzymy oprogramowanie z wykorzystaniem technologii internetowych. Cały kod powstaje w JavaScript i jak można się domyślać, minusem tego rozwiązania będzie ograniczone wsparcie dla API obsługiwanych systemów operacyjnych. Co prawda, dotyczy to tylko niewielkiej grupy specyficznych funkcjonalności, ale zawsze istnieje szansa, że akurat to Ty trafisz na taki problem.

W odróżnieniu od PWA, kod napisany w React Native kompilowany jest do natywnych paczek, osobno dla każdego systemu mobilnego. Finalnie oprogramowanie wygląda analogicznie do tego napisanego w technologiach natywnych. Warto również podkreślić, że mamy tutaj możliwość wykonywania zadań w tle.

Więcej na temat React Native, nie będę tutaj pisał. Jeszcze nie miałem okazji pracować komercyjnie z tym frameworkiem, więc nie chcę bawić się w „eksperta”. Może masz jakieś większe doświadczenie? To chętnie poczytam na ten temat w komentarzach.

Na koniec podrzucam link do pełnej dokumentacji technicznej.

Flutter

Ostatnie rozwiązanie, o jakim chciałem napisać to Flutter. Jest on rozwijany przez firmę Google i umożliwia budowanie wieloplatformowych aplikacji natywnych. Różnice? Pod maską, kryje się zupełnie inne podejście niż w przypadku PWA czy React Native. Cały UI rysowany jest na bazie elementu ‘Canvas’. Nie mamy żadnego mapowania na natywne kontrolki interfejsu użytkownika. Wszystko jest tworzone tak, aby wspólnie stwarzało jednolity UX identyczny z tym w klasycznie tworzonych aplikacjach.

Jeśli zdecydujesz się na zastosowanie tego rozwiązania, nie musisz instalować żadnych specjalistycznych IDE czy innych dodatkowych narzędzi. Wystarczy zwykły edytor, taki jak Visual Studio Code, Sublime czy Notepad. Warto jednak wybrać środowisko takie, które będzie ułatwiało Twoją pracę. Mam tutaj na myśli poprawne podświetlanie kodu czy podpowiadanie składni. Możemy to osiągnąć, wykorzystując wtyczkę o nazwie Flutter. Jest ona wspierana przez Android Studio, IntelliJ (Community lub Ultimate) oraz wywołany już wcześniej do tablicy Visual Studio Code.

Jeśli masz jakieś obawy związane z poznawaniem nowego języka programowana - Flutter wykorzystuje Darta. Nie ma tutaj nic skompilowanego, czego nie byłoby w innych wysokopoziomowych technologiach: Java, C#, C++, JavaScript, Swift i innych. Wszystko jest naprawdę fajnie przemyślane i udokumentowane. Aplikacje kompilowane są do kodu natywnego dla każdego ze wspieranych systemów operacyjnych. To jest bardzo duży plus!

Mam nadzieję, że Cię zainteresowałem. Po szczegóły i przykłady odsyłam do witryny flutter.dev.

Wady i zalety

Pamiętaj, że wybór konkretnej technologii to jedna z ważniejszych decyzji, jakie należy podjąć przed startem nowego projektu. Późniejsze zmiany mogą okazać się problematyczne lub całkowicie niemożliwe. Zanim przejdziesz do kolejnego etapu projektu, zapoznaj się z opiniami dotyczącymi danej technologii - zarówno tymi negatywnymi, jak i pozytywnymi. Przeglądnij dokumentację techniczną, przygotuj kilka POC. Omawiane tutaj narzędzia mają swoje wady i zalety. Część z nich ma też pewne ograniczenia, a to powinno zapalić w Twojej głowie czerwoną lampkę. Być może będą to zupełnie niepotrzebne obawy, ale pamiętaj, że wszystkie decyzje muszą zostać podjęte w pełni świadomie. Ostatnią rzeczą, jaką chcesz, to obudzić się po kilku miesiącach pracy i stwierdzić, że czegoś nie da się zrobić.

Co polecam?

Ze wszystkich prezentowanych tutaj rozwiązań, gdybym miał wybierać, a nie mógłbym skorzystać z Xamarina, zdecydowałbym się pewnie na Fluttera. Kolejne miejsce w moim subiektywnym rankingu należało by do React Native, potem długo nic i PWA. Progressive Web App zajęło ostatnią lokatę w rankingu, głównie dlatego, że technologia ta, obecnie ma szereg ograniczeń funkcjonalnych. Są pewne projekty w których, będzie się ona sprawdzała idealnie, ale raczej w większości nie będzie to dobry wybór. Chętnie jednak podyskutowałbym z Tobą na ten temat. Co o tym myślisz?

Podsumowanie

Na koniec, chciałbym jeszcze dodać, że opisywane tutaj rozwiązania to nie jedyne dostępne możliwości. Wybrałem kilka takich ciekawych narzędzi, które przedstawiłem Ci w kilku zdaniach. To był taki trochę luźniejszy, mało techniczny wpis, ale mam nadzieję, że ciekawy. Być może interesujące byłoby porównanie konkretnych konstrukcji programistycznych? To już temat na osobny artykuł.

Dzięki za poświęcony czas i przeczytanie materiału do końca. Zapraszam do dyskusji i wspólnej wymiany poglądów!

Od redakcji

Łukasz Dudziński ze swoim blogiem StrefaBlogera objął patronatem nasze Badanie społeczności IT 2021 :) Kliknij w link poniżej i weź udział w badaniu!


Badanie społeczności IT 2021

<p>Loading...</p>