Mobilne technologie

Cześć,

od ponad roku pracuję jako programista C/C++ (systemy wbudowane), za chwilę bronię inżyniera - projekt również napisany w C++. Będę miał teraz chwilę czasu i chciałbym spróbować swoich sił w aplikacjach mobilnych i w tym kierunku poszerzać swoją wiedzę. Technologii w których można pisać aplikacje mobilne jest bardzo wiele i właśnie stąd rodzi się pytanie - którą wybrać i dlaczego?

Technologie, które znam lub o nich słyszałem to:

• Java/Kotlin - aplikacje na platformę Android (miałem styczność na studiach kilka prostych projektów)
• Swift/Objective C - aplikacje na platformę iOS (nigdy nie miałem styczności)
• Xammarin - słyszałem, kiedyś coś próbowałem wydaje się być sensowne z racji uruchomienia na Androidzie oraz iOS
• Flutter - nowa technologia, wydaje się sensowna, sama siebie rysuje więc uruchamia się również na Androidzie i iOS.
• React native - nie wiele o tym wiem ale wiem, że uruchamia się również na obu platformach

Java i Kotlin oraz Swift/Objective C jakoś najmniej do mnie przemawiają z racji ograniczenia w uruchamianiu tylko na jednej platformie. Mimo, że uważam, że Jave znam dobrze lub nawet bardzo dobrze, jakoś bardziej ciągnie mnie w pozostałe trzy. Jak wspomniałem, najbardziej i najlepiej znam C++ oraz Javę, którą technologię z powyższych (lub innych) polecalibyście mi na start, od zera i dlaczego oraz czy macie może jakieś sprawdzone materiały odnośnie ich (jeśli tak to można podlinkować).

Dzięki za odpowiedzi i wszystkiego dobrego w nowym roku :)

Jak słusznie zauważyłeś, niewątpliwą zaletą trzech ostatnich pozycji jest to, że można stworzyć aplikację na kilka platform, zamiast celować w jedną i ograniczać jej użytek tylko do jednej.

Najprawdopodobniej najlepszym wyborem będzie dla Ciebie Xamarin, gdzie użyjesz języka C#, a tuż za nim może plasować się Flutter z językiem Dart – obie mają sporo wspólnego z językiem Java, o którym – jak wspomniałeś – masz doświadczenie i dobrze znasz, więc pomoże Ci to szybciej rozpocząć proces tworzenia konkretniejszych aplikacji.

W zasadzie technologie, które wymieniłeś to główne technologie na rynku mobilnym. Można niby jeszcze pod to podpiąć PWA, ale to raczej web. Są też rzeczy w stylu Ionic czy Native Script, ale można je pominąć, bo to ogromna nisza i jeśli nie masz doświadczenia w technologiach, na których one bazują, i nie potrzebujesz sam zbudować aplikacji mobilnej, korzystając już z umiejętności które masz.

Jeżeli chodzi o wybór technologii to zależy czemu chcesz się zająć mobilkami. Jeżeli szukasz pod kątem pracy to w zasadzie aplikacje natywne czyli Java/Kotlin i Swift/Obj-C. Są też oferty na Xamarina, RN i Fluttera, ale zdecydowanie mniej. Najwięcej z tych trzech jest na RN. Z kolei jeśli szukasz pod kątem zainteresowań, to widać, że interesują Cię rozwiązania hybrydowe. Co człowiek to opinia, więc podam swoją.

• Xamarin - Nie miałem styczności jeżeli chodzi o samo pisanie aplikacji. Xamarin dzieli się na Native i Forms. Z aplikacji, które widziałem, to działał najgorzej ze wszsystkich hybrydowych rozwiązań. Z Native non stop były jakieś problemy przy budowaniu projektu i wiadomości wyrzucane przez kompilator albo IDE były mało pomocne. Czasem trzeba było robić jakieś akrobacje w stylu czyszczenie pamięci podręcznej aplikacji przed ponownym jej zainstalowanie. Ogólnie biednie to działało. Podejrzewam, że kwestia braku umiejętności programistów, ale też do pewnej granicy, bo np. Forms nie ma w ogóle wsparcie dla przetrwania śmerci procesu. Dla mnie to od razu skreśla framework, żeby traktować go poważnie przy pisaniu aplikacji. Pewnie @Ktos może bardziej się na ten temat wypowiedzieć, bo chyba ma styczność z Xamarinem.

• Flutter - Rzygam tym jak Google nachalnie promuje Fluttera, śpiewając Kumbaya i zachwycając się jaka to nie jest wspaniała i dojrzała technologia. Uważam, że Flutter jest ok, ale bez przesady. Ma swoje wady, które wyznawcy Fluttera wspaniale igonorują. Jak się robi już bardziej rozbudowane UI, to czasami jest tak, że tylko specyficzna kombinacja kontrolek wygląda tak jakbyśmy chcieli, mimo że inne konfiguracje też powinny osiągnąć zamierzony efekt. Wydajność jest zazwyczaj w porządku, jeśli nie pisze się kaszany w UI, ale apki potrafią zżerać baterię na GPU przez to jak Flutter działa. Dodatkowo wielkość aplikacji jest dramatyczna w porównaniu do aplikacji natywnych, bo z każdą aplikacją Flutterową dostarczany jest za każdym razem silnik do odpalania go. No i moim zdaniem największy minus, to język programowania. Dart jest jednym z najgorszych języków z jakimi miałem styczność. Jakiś zlepek wszystkiego będący potworem Frankensteina, który jest w dodatku wybrakowany. Aha, no i brak wsparcia dla śmierci procesu, to jakiś żart jak w przypadku Xamarina. Natomiast na plus we Flutterze na pewno jest deklaratywne UI. Jeśli ma się trochę oleju w głowie, to dużo łatwiej dbać o separacje odpowiedzialności logiki biznesowej i UI. Hot reload też jest bardzo fajny, bo łatwiej iteracyjnie budować aplikacje (ale czasami można się naciąć, jak nie ma się świadomości jak dokładnie działa hot reload - głównie chodzi o inicjalizację klas i obiektów, ale nie tylko). Dodatkową zaletą jest sposób w jaki obiekty są tworzone, bo można ładnie skorzystać z DI już na warstwie widoku, ale tutaj Dart momentami bardzo przeszkadza, żeby zbudować graf obiektów przejrzysty sposób. No i jeśli chodzi o Darta, to trzeba przyznać Googlowi, że aktywnie nad nim pracują i aktywnie słuchają społeczności, czego chce w języku, więc pomimo moich narzekań jest to aktywny język, z którego może coś będzie.

• RN - Robiłem tylko hobbystycznie, ale z popularnych cross-platformowych rozwiązań podoba mi się najbardziej. Przynajmniej w zamyśle. Tworzymy wspólny model dla UI, który jest tłumaczony na natywne kontrolki i w miarę potrzeby mamy możliwość dostosowywania ich pod nasze wymagania. Ludzie często narzekają na wydajność, ale to raczej wynika z niewiedzy i braku umiejętności. RN potrafi zamulić np. przy starcie, ale generalnie jest stabilnie. Są natomiast problemy z rozwojem RN. Facebook wydaje się być często głuchy na problemy, dokumentacja leży i czuć momentami stagnację pomimo tego, że framework nie jest jeszcze dojrzały.

Zawodowo piszę w większości aplikacje natywne. Miałem też styczność przez rok z Flutterem. W tym przez pół roku z jedną z największych aplikacji w tej technologii. RN, jak wspomniałem, tylko hobbystycznie. Osobiście poleciłbym i tak aplikacje natywne, bo jeszcze żadne rozwiązanie hybrydowe mnie nie przekonało. Pomijając natywne technologie, to pewnie wybrałbym Fluttera, bo najlepiej rokuje. Natomiast jeżeli czujesz, że chciałbyś ciekawe wyzwanie, to możesz zainteresować się Kotlinem, bo jest to język wieloplatformowy i oprócz aplikacji na Androida można też w nim pisać aplikacje na iOS. Jest to rozwiązanie dopiero raczkujące i na pewno będzie z nim obecnie dużo problemów, ale moim zdaniem jest to najrozsądniejsze podejście do aplikacji wieloplatformowych, co widać już na poziomie języka, jeżeli chodzi o wsparcie dla różnych platform.

Możesz też zainteresować się pisaniem aplikacji w C++. Najczęściej pisze się wtedy aplikacje, które zajmują się przetwarzeniem obrazu albo dźwięku - gry, odtwarzacze, streamowanie, komunikacja VoIP, itp.

Michał Sikora napisał(a):

Dodatkowo wielkość aplikacji jest dramatyczna w porównaniu do aplikacji natywnych, bo z każdą aplikacją Flutterową dostarczany jest za każdym razem silnik do odpalania go.

Dramat to jest w Xamarinie raczej. Hello world we Flutterze to apk o rozmiarze około 5 MB, chyba że wygenerujesz apk dla wszystkich architektur, czego się zwykle nie robi, a do sklepu i tak powinieneś wrzucić bundle, czyli klient dostanie odpowiednie abi.

P.S. Dart nie jest aż tak zły. Wolę Dart niż JS, chociaż są podobne. Co do RN to jest okropnie niestabilne, aktualizacja wtyczki potrafi rozwalić projekt, a nawet do podstawowych rzeczy potrzebne są wtyczki rozwijane przez społeczność, często miernej jakości. To jest bagno, chyba nic poważniejszego w tym nie pisałeś. Wygląda jak beta, a nie gotowy produkt.

Flutter jest rozwijany aktywnie i z głową i w wielu miejscach uwalnia nas od guana obecnego w natywnym Androidzie, jak cykle życia, fragmenty ich obsługa, widoki i ich api i inne schizy. Chociaż Flutter ma wady, to wiele rzeczy upraszcza, zwłaszcza w zakresie tworzenia bardziej zaawansowanego gui. Nawet tak głupia rzecz, jak dwie linie tekstu na toolbarze w natywnym Androidzie wymaga jakichś dziwacznych kombinacji, dziedziczenia po standardowych klasach i nadpisywania metod, zamiast wstawić 2 textboxy na toolbar i tyle.

A obsługę fragmentów to chyba jakiś psychol wymyślał.

Meini napisał(a):

Dramat to jest w Xamarinie raczej. Hello world we Flutterze to apk o rozmiarze około 5 MB, chyba że wygenerujesz apk dla wszystkich architektur, czego się zwykle nie robi, a do sklepu i tak powinieneś wrzucić bundle, czyli klient dostanie odpowiednie abi.

Jak pisałem, nie korzystałem nigdy z Xamarina, więc nie wiem. Natomiast od 4 MB do 4.5 MB dla każdej aplikacji to moim zdaniem bardzo dużo.

Co do RN to jest okropnie niestabilne, aktualizacja wtyczki potrafi rozwalić projekt, a nawet do podstawowych rzeczy potrzebne są wtyczki rozwijane przez społeczność, często miernej jakości. To jest bagno, chyba nic poważniejszego w tym nie pisałeś. Wygląda jak beta, a nie gotowy produkt.

Zgadzam się co do stabilności. Sam to zaznaczyłem przecież. No i też pisałem, że nic poważnego w RN nie robiłem. Natomiast widziałem efekty poważnych aplikacji napisanych z RN i były dobre. Żeby nie było widziałem też dobrze napisane aplikacje w Xamarinie i Flutterze, ale najmniej problemów widziałem w dobrze napisanych aplikacjach w RN. Natomiast kwestia wtyczek i bibliotek to patalogia taka sama jak wszędzie - Flutter, RN, natywne. Wszędzie jest kupa dennego kodu.

Flutter jest rozwijany aktywnie i z głową i w wielu miejscach uwalnia nas od guana obecnego w natywnym Androidzie, jak cykle życia, fragmenty ich obsługa, widoki i ich api i inne schizy.

Fakt, jest rozwijany aktywnie. Czy z głową, to ciężko mi jeszcze powiedzieć, ale ich podjeście do zgłaszanych problemów jest momentami śmieszne. Zgłaszasz coś, pytają się kilka razy czy naprawili to w jakimś patchu, odpowiadasz że nie, pytają kolejny raz, nie masz już siły odpowiadać a im samym nie chce się sprawdzić i zamykają issue. Albo wersjonowanie Fluttera jest irytujące. Niby korzystają z semantic versioning a potrafią API w stabilnej wersji zmienić przy podbiciu patch zarówno we Flutterze jak i w bibliotekach. Chociaż ten problem wynika bardziej z tego jak ułomny jest Dart z brakiem przeładowywania metod.

Co do reszty, to nie uważam, żeby cykl życia był czymś złym. Aplikacja uruchomiona w środowisku telefonu powinna być go świadoma. Flutter też ma zresztą cykl życia, tylko mniejszy i bardziej ukryty, ale też potrafi momentami zaskoczyć. Ale rozumiem zarzut. Google przez jakieś pierwsze 7 lat w przykładach uczył ludzi pisać kod tak, że wzsystkie klasy praktycznie były zależnego od cyklu życia, więc naturalnie robiła się z tego kaszana. Teraz też to robią, ale jest to mniej lub bardziej zjadliwe à la ViewModel. Fragmenty i ich API zaprojektowane przez upośledzonego konia, to wiedza powszechna, ale też wystarczy nie korzystać z fragmentów i problem znika.

Chociaż Flutter ma wady, to wiele rzeczy upraszcza, zwłaszcza w zakresie tworzenia bardziej zaawansowanego gui. Nawet tak głupia rzecz, jak dwie linie tekstu na toolbarze w natywnym Androidzie wymaga jakichś dziwacznych kombinacji, dziedziczenia po standardowych klasach i nadpisywania metod, zamiast wstawić 2 textboxy na toolbar i tyle.

Zgadzam się, że deklaratywne podejście do UI w kodzie ma dużo więcej sensu, daje większą swobodę i trudniej źle zaprojektować kod, co przecież zaznaczyłem. Ale nie rozumiem przykładu z Toolbarem. Znaczy się, rozumiem poniekąd, ale wystarczy stworzyć własny widok i problem znika z głowy. To przecież nie jest ani trochę inne od tego, co byśmy zrobili we Flutterze.

<LinearLayout>
  <TextView/>
  <TextView/>
</LinearLayout>

Panowie, dziękuję za fajne wypowiedzi. Poczekam jeszcze troszkę być może ktoś jeszcze coś dopisze.

Jeżeli chodzi o mój zamiar, dlaczego akurat aplikacje mobilne - nie wiem :) Może ma to coś wspólnego, z tym co teraz robię - jak wspomniałem pracuję w embedded. Sprzęty, które robimy są na rynku już kilkadziesiąt lat, jednak świat pędzi do przodu i być może za kilka lat zostaną pochłonięte przez:
a) Web
b) Aplikacje mobilne

Ja raczej obstawiam to drugie z uwagi na specyfikę sprzętu oraz to, że już teraz są tworzone podobne rozwiązania, tyle że, postawienie Androida wymaga dużo więcej zasobów (procesor, RAM itd.) a co za tym idzie - rośnie cena urządzenia, a więc jest to mało opłacalne no i urządzeń tego typu jest raczej niewiele. Aplikacjami mobilnymi zajmowałem się na studiach (3 projekty) - aplikacje fajne, ale uczenie się w trakcie semestru języka, zasad pisania takich aplikacji no i samego programowania, raczej nie wróży żadnej dobrej i dobrze sprzedającej się aplikacji - tymbardziej, że żaden z nas nigdy nie pisał w mobilnych.

Postanowiłem się tym zainteresować, być może kiedyś przyjdzie mi zmienić pracę, a może i technologię i chyba po prostu chcę spróbować czegoś nowego. Zależy mi na tym, żeby nie był to kombajn, który wymaga godzinnego instalowania wtyczek, IDE, gigabajtów bibliotek, a później 3h konfigurowania i uruchamiania 'Hello worlda' tylko raczej czegoś, co nie wywoła u mnie raka po 30min pisania pierwszej aplikacji.

JS nienawidzę, Darta nie znam - mało mnie przekonuje, a Xamarin raczej odpada z powodu podejścia, które kiedyś miałem (niby dawno, ale niesmak pozostał :P). Java jest OK ale boli brak "przenaszalności" pomiędzy stystemami..

JS nienawidzę, Darta nie znam - mało mnie przekonuje, a Xamarin raczej odpada z powodu podejścia, które kiedyś miałem (niby dawno, ale niesmak pozostał :P). Java jest OK ale boli brak "przenaszalności" pomiędzy stystemami..

Boje się, że w takim wypadku zostanie ci tylko Qt i C++ - ale nie wiem, jak bardzo popularne to jest "w biznesie".

Ktos napisał(a):

JS nienawidzę, Darta nie znam - mało mnie przekonuje, a Xamarin raczej odpada z powodu podejścia, które kiedyś miałem (niby dawno, ale niesmak pozostał :P). Java jest OK ale boli brak "przenaszalności" pomiędzy stystemami..

Boje się, że w takim wypadku zostanie ci tylko Qt i C++ - ale nie wiem, jak bardzo popularne to jest "w biznesie".

Zainteresuję się RN i Flutterem, poprzeglądam jakieś podstawowe tutoriale i zorientuję się czym to się je. Być może, któreś mnie w jakimś stopniu zachęci. Dzięki za odpowiedź.