Wątek przeniesiony 2020-09-27 23:26 z Mobilne przez somekind.

Rynek pracy dla devów Android, jesień 2020

1

Persystencja:
Roomy, Gson mapping, SQL, SQL light, Realm, objectbox, shared preferences, file storage - jak wrzucicie wzorzec repozytorium to jeden piec co tam pod spodem jest. Wtedy baza danych jest szczegółem implementacyjnym. Oczywiście dochodzi do tego wydajność np Room będzie szybszy w filtrowaniu elementów niż czytanie jsona przez gsona. Warto tutaj zrobić oszacowanie jak nasze dane będą rosły - jeśli będziemy potrzebować szybkiego filtrowania po ~relacjach np jakieś dane medyczne albo sportowe to room dzień dobry. Ja np w poprzedniej aplikacji napisałem cały lokalny storage w uwaga plikach json które były zapisywane przez gsona. Dlaczego tak? bo znałem skalę jak to będzie rosło, tych plików było max 100 po kilka kilo. 0 Filtrowania tylko key-value. Nie było tam sensu dodawać rooma. Oczywiście samo dodaniei rooma było też dość proste - napisałoby się wtedy kolejne repozytorium + coś ponad tym (pewnie serwis albo use case) który robiłby migrację do nowego rozwiązania.

Dzięki temu można było odroczyć podjęcie decyzji jaka baza danych powinna być użyta. Miałem rozmowę z biznesem: hej lubie_programowac, tutaj masz flow, designy apki na trzy miechy do przodu/

1

A ja uważam, że Android stał się opasły. Sam taki Dagger pewnie już dorównuje Springowi pod względem skomplikowania. Powstaje masa bibliotek i wzorców, które mają przykrywać skopane api Androida.

Flutter upraszcza wiele rzeczy, a z kolei wprowadza nowe problemy. Np serializacja/deserializacja jsona. Nie ma odpowiednika gsona i podobnych, trzeba generować masę boileprate i to wynika ze specyfiki języka. Odpowiednik Retrofita jest, ale ułomny i zmusza do serializacji/deserializacji w wątku głównym, co wprowadza lagi w gui.

W większych projektach zarządzanie stanem aplikacji robi się problematyczne, więc wymyślono providera. Potem wymyślono bloc. Znów to samo, pudrowanie kupy. Powtórka z rozrywki.
Nie można prosto tworzyć różnych flavour aplikacji, bo Flutter nic nie wie o flavour z Gradle, nie mówiąc o iOS. Itd, znów jest na co narzekać.

3

Co prawda nie znam się w dziedzinie Androidowej (jestem javowcem), natomiast kilka rzeczy, spośród wymieniłeś, jak np Jenkins czy HTTP / REST to jest 1 dzień "nauki" i trochę (parę miesięcy np) doświadczenia w komercyjnym projekcie. Jeśli ktoś wymaga 1000 technologii, to raczej chodzi mu o kogoś z T-shaped wiedzą, czyli szczegółową wiedzą w jednym zakresie (np język Java / Kotlin) oraz powszechną wiedzą z wielu innych zakresów, czyli np jakiś framework czy biblioteka - wiedzieć po co ona jest, z czym się dobrze integruje, plusy i minusy. Szczegółów implementacyjnych raczej nie trzeba znać (różnie to jednak bywa - zależy też od firmy i poziomu stanowiska - junior czy senior).

Dlatego np sensowny Bootcamp od zera do java developera powinien zaczynać od 3 miesięcy samej javy - żeby dobrze poznać core, rdzeń tego wokół czego inne technologie będą się kręcić, a nie od razu Java + Spring Boot + Hibernate + REST API

2

Nie rozumiem problemu - identyczny jest dla typowego backendowca czy gościa od frontów. Jak dla kogoś za dużo to ciepła i niewymagająca posada w maku czeka

3

Dobrze płacą za dobre umiejętności także to raczej pozytywny aspekt niż negatywny, że jest czego się uczyć i co udoskonalać :)

2

Chyba nie jest tak do końca. Próg wejścia jest rzeczywiście wyższy, ale wymogi na mid i seniora są niższe. Kiedy ja byłem juniorem to każdy mid był android+druga platforma. Jeden senior i team leader ogarniali 3 platformy. Teraz na seniora nie trzeba znać JNI, a co dopiero drugą platformę.

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