Rynek pracy dla Mobile Dev

0

Witajcie,
niedawno rozpoczęłam swoją pierwszą pracę w IT jako tester. Zastanawiam się nad dalszą ścieżką kariery - testowanie automatyczne w Javie czy aplikacje mobilne na Androida. Zdziwiła mnie bardzo mała ilość ofert pracy ala mobile developerów. Z czego to wynika biorąc pod uwagę tak wielką popularność urządzeń mobilnych ?
Będę bardzo wdzięczna za wszystkie opinie w tym temacie.

0

Bo zazwyczaj potrzeba tylko kilku developerow nawet w dużych firmach i na fajne stanowiska biorą w większości po znajomosci/poleceniu.

0

Może źle patrzysz? Sam android w dzisiejszych czasach to trochę za mało :-P Szybsza pętla zwrotna jest w przypadku react native, a w dodatku produkujesz kod pod androida i iosa.

0

Co masz na myśli mówiąc pętla zwrotna?

0
nohtyp napisał(a):

Szybsza pętla zwrotna jest w przypadku react native, a w dodatku produkujesz kod pod androida i iosa.

Wtedy, biorąc pod uwagę to że jeśli zainstalujesz 100 przypadkowo wybranych aplikacji ze sklepu, może 2-3 będą używały React Native, a reszta nie, pojawia się pytanie: dlaczego na rynku pracy jest większe zapotrzebowanie na coś rzadziej używanego, a mniejsze na coś częściej używanego?

0

Żeby nie było to jeszcze nie programuje mobilnie, ale tematem się interesuje i przymierzam do pisania własnych projektów.

W wolnej chwili czytałem książkę react native i tam był tekst, że jak masz js to nie musisz w kółko rekompilować kodu co zmianę. Ja bym poszedł o krok dalej tzn repl oriented programming na przykładzie ClojureScript. Ta technika umożliwia rzeźbić program (i aktualizować go) w trakcie gdy ten program po prostu sobie dziala - to przypomina pracę na żywym ograniźmie :-P Przykład: To jest coś więcej niż zwykłe odświeżanie - bo proces aplikacji pamięta stan jaki był przed zmianą. Poza tym możesz do procesu podpiąć się z poziomu konsoli i poprzez zwykłe wywoływanie funkcji zmieniać stan w jakim znajduje się ten proces.

Poza tym bazowanie na javascriptach ma plus w przypadku wydawania oprogramowania. Bo jakbyś miał wszystko kompilowane, to każda zmiana jaka chcesz wypuścić musialaby przejść przez audyt sklepów google i apple (a to przecież trwa). Natomiast jak masz większość kodu w js to wystarczy, że zaciągasz sobie z serwera js i całość nie wymaga rekompilacji i tym samym dodatkowych audytów.

0

Top 100 aplikacji ze sklepu Androida jest robionych przez teamy kilkudziesięciu programistów Androida. To są duże aplikacje składające się z wielu modułów, gdzie każdy mógłby być oddzielną aplikacją. Uber czy Spotify mają ponad 100 programistów Androida. Z drugiej strony jest wiele startupów bez kasy lub firm które chcą być obecne w sklepie Google po taniości i mają tylko 1-3 androidowców.

W Polsce niestety są to niemal wyłącznie małe teamy. Z ciekawości kto z was pracuje w większym teamie Android? Ilu was jest?

0

@Darck: Pracowałem w różnych teamach: od 1 osobowych (czy jedna osoba to team?) przez 2, 3, 5. W firmie były i teamy 8 osobowe. Wszystkie cyfry dotyczą tylko programistów androida. Te najmniejsze to praca dla startupów, największe to projekt dla firmy w Niemczech gdzie deadline był nie do ruszenia i trzeba było zrównoleglić pracę - 3 miesiące na aplikację od 0 do wydania. Druga piątka to praca dla jednego z największych dostawców VOD na świecie. Team był podzielny na zadania np. jeden robił moduł dla ~dzieci drugi dodawał nowe typy a trzeci przymierzał się do dodania chromecasta. Oczywiście trzeba było wszystko jeszcze koordynować. Ten team 8 osobowy to też dla VOD - sprawa podobna jak poprzednio tylko tutaj zadanie polegało na połączeniu kilku różnych aplikacji w jedną a następnie zrobić ~whitelabel. Oczywiście ciągłe utrzymanie, wydawanie kolejnych wersji...

@nohtyp: [...] jak masz js to nie musisz w kółko rekompilować kodu co zmianę. Niby tak ale moja aplikacja nad którą teraz pracuje clean build zajmuje ~1min ( to jest dużo, mam sporo kodu c++ / ndk). Budowanie przyrostowe zajmuje ~6s - najwięcej czasu zajmuje upload aplikacji na urządzenie. Na androidzie jest niby Instant Run który powinien robić to samo ale niestety nie jest on dopracowany. Prawdę powiedziawszy aplikacji na androida nie powinno się pisać i testować na urządzeniu. Wychodzę z założenia że prawie cały process pisania kodu powinien odbywać się lokalnie poprzez pisanie testów i logiki biznesowej. Oczywiście jest trochę zabawy z wywołaniami czysto androidowymi ale tutaj też z grubsza można obejść się bez uruchomienia na urządzeniu.

Bo jakbyś miał wszystko kompilowane, to każda zmiana jaka chcesz wypuścić musiałaby przejść przez audyt sklepów google i apple (a to przecież trwa) Po pierwsze nie wiem czy aplikacja która wstrzykuje / omija audyt nie będzie automatycznie usunięta z marketu. Po drugie takie rozwiązanie też można uzyskać w aplikacjach natywnych ( kotlin / swift). W jednym z poprzednich projektów w aplikacji fitnessowej gdzie trackowaniem aktywności było około 70% funkcjonalności nowe typy aktywności były pobierane z serwera. Tzn mówiąc ogólnie - mieliśmy szablonowy widok w androidzie i zależnie od konfiguracji różne mini ekrany były wstrzykiwane.

//Edit:
Interesujący artykuł związany z crossplatformowymi rozwiązaniami: https://medium.com/pixplicity/why-we-are-not-cross-platform-developers-fd7ef70e976d

0

Nawet jeśli jeszcze rozwiązania wieloplatformowe nie działają tak jakbyśmy tego chcieli, to jest to tylko kwestią czasu aż ktoś takie wymyśli które nie ma większości wad. Jak tam z Googlowym Flutter? https://flutter.io Coś nie zdobywa rynku przebojem. Jakie są jego wady, bo o zaletach słyszałem coś?

0

@Darck Na mobiconfie w sierpniu tego roku opowiadał gość o zaletach Fluttera, w sumie żadnych wad nie powiedział. Pierwsze pytania jakie padły, to kiedy będzie oficjalne wsparcie dla WebView i map, szybka odpowiedź była, że to jeszcze dynamicznie rozwijająca się platforma. Domyślam się, że przy poważnym projekcie powychodziłoby sporo jeszcze jakiś braków.

1

Pracuję w mobile dev i osobiście uważam, że będzie odwrotnie. Rynek nauczy się, że rozwiązania cross-platform są do wszystkiego, czyli do niczego i w końcu przestaną takie powstawać. To wszystko fajnie wygląda na prezentacjach i tutorialach, ale wbrew temu co wielu myśli mobile development nie ogranicza się do trywialnego "klepania" frontendu. Zawszę wychodzą braki takich rozwiązań, nawet w średnio dużych projektach.
Jednak uważam, że cross-platform zachowa swoją niszę prostych apek-wizytówek, przy których korzyści z ich używania przewyższają - ogromne w innych przypadkach - koszty.

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