Wątek przeniesiony 2020-05-25 10:40 z Kariera przez cerrato.

Mobile Developer- przyszłość branży

Odpowiedz Nowy wątek
2020-05-24 19:27

Rejestracja: 1 rok temu

Ostatnio: 1 godzina temu

0

Cześć piszę dzisiaj z pytaniem: jak według was będzie wyglądała przyszłość mobile developerów? Chodzi mi o ilość ofert na rynku i zarobki w porównaniu do ludzi piszących w innych technologiach z podobnym doświadczeniem.

Wiem, że często będą to wasze subiektywne opinie, ale chciałbym wiedzieć jak Wy widzicie przyszłość tej gałęzi, w jakim kierunku zmierza (czy może zostanie zastąpiona), jaki stack technologiczny będzie na topie etc.

Miłego :)

Pozostało 580 znaków

2020-05-25 10:48

Rejestracja: 1 rok temu

Ostatnio: 2 minuty temu

Lokalizacja: Silesia

0
cerrato napisał(a):

Ogólnie flutter będzie sobie żył i będzie w nim praca, ale native zawsze będzie lepszy

To trochę jak kilka(naście) lat temu twierdzenie, że lepiej pisać w samym WinAPI, bo wszystkie biblioteki, frameworki, MFC czy inne Delphi generują nadmiarowy kod, który tylko zamula i spowalnia. Może do pewnych specyficznych działań rzeczywiście native nie ma konkurencji, ale w większości przypadków takie rozwiązania w stylu Fluttera czy RN dają rade całkowicie dobrze.

Jak to mówili? Write once, run anywhere?


To jest trochę inna sytuacja, bo o ile kojarzę, to Flutter tworzy apki natywne, nie ma żadnych mostków czy translacji. Jedynie UI może być niespójne w pełni z danym ekosystemem. - cerrato 2020-05-25 10:54
Czyli Write once, compile anywhere? - KamilAdam 2020-05-25 10:55
Dokladnie, Flutter komplikuje się do kodu maszynowego, z kolei RN gada z natywnymi komponentami przez JS Bridge, ale można też np. robiąc animacje działać bezpośrednio na natywnym wątku - don_draper 2020-05-25 11:05

Pozostało 580 znaków

2020-05-25 10:52

Rejestracja: 7 lat temu

Ostatnio: 1 dzień temu

1

Moim zdaniem Apple ubije konkurencję crossplatformową jeżeli będzie zbyt poważna, nie będzie chciał oddać deweloperów Google'owi. Fuschia to temat mocno niepewny i może zostać jeszcze ubite przez Google. Przez najbliższe 3 lata nic się raczej nie zmieni :P

Pozostało 580 znaków

2020-05-25 10:54

Rejestracja: 1 rok temu

Ostatnio: 1 miesiąc temu

1

@cerrato:
Tylko tu piszesz o strachu przed ewolucją z tym WinAPI.

Tutaj nie ma ewolucji w robieniu software'u tylko masz równoległy projekt który stara się konkurować z innym (Flutter vs Native). Przypominam że piszę w kontekście iOS'a - Na Androidzie się nie znam.

Native nie jest tak jak WinAPI przestarzałe i toporne. Tworzenie UI wymagało odświeżenia i je otrzymało - w SwiftUI piszesz tak samo szybko i przyjemne jak we Flutterze. Moim głównym argumentem w tej dyskusji jest długofalowy support i możliwość rozwoju w projektu.

Aplikacje natywne są płynniejsze i dostają wszystkie bajery od Apple'a (np. nowy sposób prezentacji widoków modalnych. Od razu na flutterze widać że tego nie ma.)

@don_draper
Z apkami hybrydowymi masz wartość biznesową do pewnego momentu. Jak projekt jest już bardzo skomplikowany i masz mnóstwo kodu do obsługi androidowych i iosowych funkcjonalności za jakąś abstrakcją to sprawa się często wtedy rypie i szybciej i taniej byłoby utrzymywać dwie apki natywne.

edytowany 2x, ostatnio: ktw_diver, 2020-05-25 10:55

Pozostało 580 znaków

2020-05-25 11:09
Moderator Kariera

Rejestracja: 2 lata temu

Ostatnio: 1 minuta temu

Lokalizacja: Poznań

0

Aplikacje natywne są płynniejsze i dostają wszystkie bajery od Apple'a (np. nowy sposób prezentacji widoków modalnych. Od razu na flutterze widać że tego nie ma.)

Ale czy przeciętny user na to zwróci uwagę? Może zauważy, że apka zachowuje się troszkę inaczej, ale co z tego? Będzie miał jakieś przyciski do wciskania, jakieś pola z tekstem i nawet jak będą się zachowywać trochę odmiennie, żadna tragedia się nie stanie, aplikacja będzie w pełni funkcjonalna i działająca. Tak samo jak np. w Windowsach (nowszych) aplikacja może dodać swoje polecenia do kliknięcia prawym klawiszem na przycisku na pasku zadań (np. "nowe okno" w przypadku przeglądarki internetowej - jak widać na poniższym obrazku). Niektóre aplikacje z tego korzystają, inne nie - ale nie przeszkadza to w niczym szczególnym. Podobne jest z mobilkami - to, że nie będzie w 100% zgodne z najnowszym UI nie jest dużym problemem.

screenshot-20200525110943.png


Naczelny forumowy hejter Apple

That game of life is hard to play, I'm gonna lose it anyway
The losing card I'll someday lay, So this is all I have to say

Pozostało 580 znaków

2020-05-25 11:28

Rejestracja: 1 rok temu

Ostatnio: 1 miesiąc temu

2

@cerrato:
Na iOS klienci są przyzwyczajeni do tego że cały system reaguje na dotyk nawet jeżeli czegoś nie da się zrobić. Ciężko jest to wytłumaczyć, ale praktycznie wszystkim na iOS da się ,,bawić'' i system bardzo płynnie reaguje na każdą naszą interakcję. Tu nie chodzi o zachowanie pojedyńczych textfieldów czy tam innych labeli. Jeżeli korzystasz normalnie z Andka to ciężko to będzie wyjaśnić.

Weźmy taki głupi modal o którym wyżej wspominałem. Natywny modal sa się dismissować gestem, można nim jeździć po całym ekranie. Pod spodem wszystko ma bardzo fajny efekt springu z dampingiem i efekt jest taki że ten modal ,,żyje''. Praktycznie każda kontrolka natywna ma coś takiego w sobie co sprawia że cały system jest integralny i spójny. Możesz być pewien że podobnie będzie się zachowywać modal w aplikacjach Telefon czy Ustawienia i że w podobne interakcje możesz wejść z każdą inną aplikacją natywną. Klient uczy się w ten sposób interakcji z systemem. Teraz jak dasz mu aplikację hybrydową w której modala nie może zdismissować takim gestem do którego przywykł, to na pewno się troszeczkę zirytuje. Aplikacje hybrydowe nie potrafią tego replikować dobrze. Na iOS jest to bardzo widoczne, na Androidzie nie bo tam nie przykłada producent aż takiej wagi do UX i płynności wszystkiego.

Największą zaletą aplikacji na iOS jest ich jakość (ludzie są raczej zgodni z tym że na iOS nawet google'owe aplikacje działają i wyglądają lepiej). Przyczyną nie jest tylko proces review u Apple ale właśnie bardzo przemyślane SDK dzięki któremu aplikacje są spójne z resztą systemu.

edytowany 4x, ostatnio: ktw_diver, 2020-05-25 11:35
Kod JS'owy w RN jest zamieniany na apkę z komponentami natywnymi pod spodem (jeżeli dobrze pamiętam) więc jest to faktycznie to samo co w native. Każda hybryda ma swoje problemy, tutaj pisałem głównie w kontekście fluttera ale przyznaję że RN dobrze napisany będzie raczej nie do odróżnienia (bo jest aplikacją natywną, różni się tylko proces developmentu). - ktw_diver 2020-05-25 12:35
Swoją drogą w tych linkach co podesłałeś dobrze widać o czym mówiłem z tymi modalami, że można się nimi bawić :D - ktw_diver 2020-05-25 12:36

Pozostało 580 znaków

2020-05-25 11:36
Moderator Kariera

Rejestracja: 2 lata temu

Ostatnio: 1 minuta temu

Lokalizacja: Poznań

0

Pewnie masz rację. Ja Apple się brzydzę i nie używam ;)

W każdym razie - to, co napisałeś dało mi do zrozumienia, że wszystko zależy od perspektywy, z której się patrzy. Bo są apki dla mas, które muszą być piękne i dopieszczone, ale są tez aplikacje pisane dla konkretnych klientów, np. narzędzie dla handlowca, który może w terenie sprawdzić stany magazynowe, albo rodzic, który będzie miał wgląd w oceny swojego dziecka. I o ile rzeczywiście, w przypadku apki dla mas (np. jakaś aplikacja do monitorowania treningów na siłowni) to użytkownik może się zniechęcić brakiem gadżetów, o których piszesz, to katalog produktów hurtowni motoryzacyjnej, który będzie wykorzystywany przez handlowców oraz klientów, raczej takich rzeczy nie potrzebuje. Mi jest bliżej do drugiego wariantu, w którym ważna jest funkcjonalność i przydatność, a nie dzwonki i gwizdki, ale rozumiem, że inni mogą mieć inne spojrzenie i dla nich taki brak animacji okienka z komunikatem może być problemem.


Naczelny forumowy hejter Apple

That game of life is hard to play, I'm gonna lose it anyway
The losing card I'll someday lay, So this is all I have to say
edytowany 1x, ostatnio: cerrato, 2020-05-25 11:36

Pozostało 580 znaków

2020-05-25 11:39

Rejestracja: 4 miesiące temu

Ostatnio: 2 dni temu

1
ktw_diver napisał(a):

Największą zaletą aplikacji na iOS jest ich jakość (ludzie są raczej zgodni z tym że na iOS nawet google'owe aplikacje działają i wyglądają lepiej).

You make my day.


Z wszelkiego drzewa tego ogrodu możesz spożywać według upodobania - ale z drzewa poznania dobra i zła nie wolno ci jeść, bo gdy z niego spożyjesz, niechybnie umrzesz.

Pozostało 580 znaków

2020-05-25 11:40

Rejestracja: 1 rok temu

Ostatnio: 1 miesiąc temu

0

Jasne. Jest tak jak piszesz - jeżeli aplikacja jest typu enterprise i przeznaczona do umożliwienia komuś pracy to po prostu musi działać i nie wkurzać.

Jednak robiąc apkę natywną (na iOS) ułatwiasz sobie pracę bo klienci są już przyzwyczajeni do poruszania się po innych aplikacjach natywnych (gesty wstecz, force touch, kontrolki i menusy kontekstowe) i nie musisz ich tego w ogóle uczyć. Potrafią sami się poruszać po systemie bardzo szybko bo aplikacja działa tak jak cały iOS i inne aplikacje natywne.

To tak jakby nagle na Andku we flutterze stwierdzili że nie ma przycisku wstecz systemowego tylko musisz klikać strzałkę. Niby nic a by irytowało sporą część ludzi. :)

@cerrato
Też hejciłem Apple ale prawie 6 lat temu mnie pracodawca zmusił żebym na to zaczął kodzić i bardzo mi się teraz podoba. Może dlatego że nie kupuję sprzętu i nie muszę patrzeć na ceny tylko zazwyczaj dostaję :D.

edytowany 1x, ostatnio: ktw_diver, 2020-05-25 11:45
To nie jest kwestia ceny, bo komórki japko kosztują porównywalnie do porządnych flagowców z Andkiem. Po prostu...zresztą mniejsza z tym, nie zaczynajmy offtopu, są już na forum wątki poświęcone nienawiści do tej firmy :D - cerrato 2020-05-25 12:03

Pozostało 580 znaków

2020-05-25 13:20

Rejestracja: 11 miesięcy temu

Ostatnio: 7 godzin temu

1

Ja z kolei nie znam się na Apple, ale znam się trochę na Androidach i na desktopie (Windows). I widzę od kilku lat tendencję do rezygnacji z 100% natywnego wyglądu kontrolek i okien, na rzecz własnego designu, dostosowanego do konkretnego produktu, czy firmy. Na Windows często są to niestandardowe skóry i mało która aplikacja wygląda tak, jak natywne okna Windows, w WPF bardzo łatwo projektuje się niestandardowy wygląd aplikacji. Na Androidzie też jest analogicznie, aplikacje są często tak brandowane, że wygląd wszystkiego jest inny, niż domyślny wygląd kontrolek systemu. Flutter bardzo to ułatwia i tutaj większość firm stawia na identyczny, inny niż systemowy, a spójny pomiędzy platformami wygląd.

Przykład pierwszy z brzegu:
iOS: https://apps.apple.com/pl/app/iko/id597657968?l=pl
Android: https://play.google.com/store/apps/details?id=pl.pkobp.iko

Jak widać, aplikacja nie ma wyglądu natywnego, łącznie z przyciskami, polami edycyjnymi, menu głównym, jak i dialogami. Za to ma dokładnie identyczny wygląd na obu platformach, praktycznie co do piksela.

Taki trend powoduje, że odtworzenie 100% natywnego look and feel traci na znaczeniu tak naprawdę. Ważniejsze staje się osiągnięcie dokładnie takiego samego wyglądu na obu platformach. Flutter mam wrażenie też idzie bardziej w tym kierunku. Tam po prostu wszystko wygląda identycznie na wszystkich platformach, a można też różnicować wygląd, ale ten niby natywny look and feel jest też tylko odtworzony, bo żadna kontrolka nie jest natywna - a tylko odpowiednio ostylowana, żeby wyglądała jak natywna.

edytowany 2x, ostatnio: Meini, 2020-05-25 13:26

Pozostało 580 znaków

2020-05-25 13:25

Rejestracja: 1 rok temu

Ostatnio: 2 minuty temu

Lokalizacja: Silesia

2
Meini napisał(a):

Taki trend powoduje, że odtworzenie 100% natywnego look and feel traci na znaczeniu tak naprawdę. Ważniejsze staje się osiągnięcie dokładnie takiego samego wyglądu na obu platformach. Flutter mam wrażenie też idzie bardziej w tym kierunku.

Czyli nie ważne co jest dobre dla użytkownika (natywne kontroli do których przywykł). Ważne jest co sobie biznes zażyczy


Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0