POIT #052: Jak zostać Android developerem?

Witam w pięćdziesiątym drugim odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to jak zostać Android developerem.

Dziś moim gościem jest Mateusz Dziubeksenior Android developer, który uwielbia zdobywać nową wiedzę i umiejętności oraz nimi się dzielić z młodszymi programistami na blogu Coders Bible. Pracował przy wielu dużych projektach.Twórca Boardly – aplikacji dla fanów planszówek.

W tym odcinku opowiemy o następujących kwestiach i umiejętnościach z roadmapy junior Android developera:

  • czy na rynku pracy jest coraz więcej Android developerów?
  • czy Android developerem może zostać ktoś bez doświadczenia w programowaniu?
  • jaki jest najlepszy sposób nauki tej specjalizacji?
  • czy inwestować swój czas w Javę czy Kotlina?
  • jakie podstawowe narzędzia i technologie trzeba poznać?
  • jakie zagadnienia z warstwy wizualnej są istotne do poznania?
  • a jakie z warstwy logiki i przetwarzania w tle?
  • co trzeba wiedzieć w temacie zapisywania danych lokalnie na telefonie?
  • co z architektury kodu jest istotne na początku?
  • co powinno się poznać z zakresu testowania aplikacji?
  • w którym kierunku zmierza programowania na Androida?

Subskrypcja podcastu:

Linki:

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 52. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o tym, jak zostać Android deweloperem. Czyli jakie umiejętności powinien posiąść Android developer, rozpoczynający swoją karierę w 2019-2020 roku. Przypominam, że w poprzednim odcinku poruszyłem temat rekrutacji i kultury pracy w dziale IT, w dużej korporacji. 

Wszystkie linki oraz transkrypcje dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/52. Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane podcasty będę to robił z sukcesem. Ja się nazywam Krzysztof Kempiński i życzę ci miłego słuchania, odpalamy.

Mój dzisiejszy gość to Senior Android developer, który uwielbia zdobywać nową wiedzę i oraz nimi się dzielić z młodszymi programistami na blogu Coders Bible. Pracował przy wielu dużych projektach, twórca Broadly – aplikacji dla fanów planszówek. Mój dzisiejszy gość to Mateusz Dziubek. 

 

Cześć Mateusz, bardzo mi miło cię gościć w Podcaście.

Cześć Krzysztof Miło mi być gościem Twojego podcastu.

Jasne, przyjemność po mojej stronie. Tak jak powiedziałem na początku, Mateusz to Senior Android developer. Ja w odcinku piątym tego podcastu, to już było trochę czasu temu, półtora roku temu jak sobie przed chwilą sprawdziłem, rozmawiałem i właśnie poruszałem różne kwestie związane z Androidem, czy czy tak naprawdę z programowaniem na tą platformę. Natomiast półtora roku to oczywiście taki czas kiedy sporo się zmieniło, doszło sporo nowych rzeczy, sporo rzeczy już pewnie się nie używa, warto jest tą wiedzę sobie odświeżyć. A po takiej fajnej rozmowie którą miałem z Mateuszem, postanowiliśmy, że dobrze byłoby pokazać osobom, które dopiero myślą o zostaniu Android Deweloperem, jakie umiejętności, jaką wiedzę trzeba posiąść na początku, żeby skutecznie działać jako Android developer w 2019/2020, bo już niedaleko końca roku. Stąd ten odcinek jest taką road mapą dla juniorów, dla osób które rozpoczynają swoją przygodę z Android Deweloperem. Road Mapa, która ma za zadanie pokazać w co warto inwestować swój czas, jakie umiejętności zdobyć, żeby można było się nazwać powiedzmy takim solidnym Junior deweloperem. To po tym trochę przydługim wstępie myślę, że możemy zaczynać. No i na początku moje standardowe pytanie skierowane do ciebie Mateusz, czy słuchasz podcastów, Jeśli tak to jakich najczęściej?

Tak słucham podcastów. Jakby sposób przyswajania wiedzy przeze mnie, jako sposób przez słuchawki, jest to coś, co odkryłem dość niedawno i wydaje mi się to jednym z lepszych sposobów dowiadywania się nowych i ciekawych informacji. Nie słucham podcastów, aż tak często jak bym chciał, stricte technicznych. Wolę po prostu po pracy usiąść sobie i posłuchać czegoś związanego wiesz, z takimi kwestiami miękkimi, których używamy w pracy na co dzień jako programiści. Wiesz, lubię słuchać o biznesie, trochę o historiach innych ludzi, o ciekawych projektach, o takich psychologiczno komunikacyjnych. Wiesz, bardzo lubię taki podcast, który nazywa się Smart Passive Income – to jest podcast Pata Flynna, który jest dość znanym kolesiem w takiej blogosferze szeroko pojętej, bardzo dobrze uczy dywersyfikować swój przychód i udziela naprawdę świetnych rad. I trochę dzięki niemu zacząłem się trochę bardziej udzielać na swoim blogu Coders Bible. Takim klasykiem też w Polsce myślę, że wiele osób też nie związanych z IT, słucha Michała Szafrańskiego. On ma podcast “Więcej niż oszczędzanie pieniędzy” – też bardzo lubię ten jego styl przekazywania tej wiedzy, który jest bardzo konkretny. Z takich krótkich rzeczy, bo wiesz jakby podcastów, jest mnóstwo, informacji jest mnóstwo do przyswojenia, ale według mnie więcej trzeba robić niż słuchać, więc ostatnio odkryłem taki fajny podcast od Harvard Business Review, nazywa się IT icast – wiesz, takich 10-15 minut j idealne na to, żeby słuchać jak jedziesz do pracy, jakiejś idei fajnej, czyli zaprasza jakiegoś autora jakiejś książki, która została wydana i po prostu rozmawiaj przez 10 minut o czymś, co jest jakby dla niego ważne. Często fajny początek jakiegoś większego tematu, na temat wiesz, głębszego researchu. To są takie główne podcasty wokół, których oscyluje. No i oczywiście masa audiobooków, które uwielbiam. [śmiech].

Też się tym zaraziłem. Fajne jest to co powiedziałeś, że starasz się słuchać nie tylko technicznych rzeczy, bo takie poszerzanie horyzontów myślę, że nawet przekłada się na to, że jako programiści jesteśmy po prostu skuteczniejsi, mamy jakieś szersze pole, więc jestem jak najbardziej fanem takiego podejścia. Okej, a powiedz jak to się stało, że zostałeś Android deweloperem, jakie masz doświadczenie, co cię skłoniło, żeby właśnie w tym kierunku pokierować swoją karierą.

A, jasne. Jakby moja kariera nie była taka dość oczywista, nie studiowałem informatyki, więc trochę przez przypadek znalazłem się w świecie IT. Studiowałem automatykę i robotykę na wydziale mechanicznym, na Polibudzie w Krakowie, więc było tam dużo rzeczy związanych z pompami, tokarkami, frezarkami i gdzieś tam po drugim roku zdałem sobie sprawę, że nie do końca mnie to kręci. I najciekawszą rzeczą, którą zawsze omawialiśmy była elektronika, więc ta elektronika gdzieś tam się zawsze przewijała. Potem gdzieś się przewinął Phyton, taka moja naprawdę podstawowa znajomość Pythona. Parę dni poświęciłem na to, żeby w ogóle zobaczyć na czym polega programowanie. No i zacząłem się uczyć C, przez zajęcia, które mieliśmy z mikrokontrolerów na uczelni, bo to było ciągle połączone z elektroniką. No i oczywiście te zajęcia były prowadzone w tragiczny sposób, programowaliśmy na na kartkach z tego co pamiętam. Według mnie to jest bardzo słaby sposób uczenia się programowania, więc w końcu wziąłem sprawy w swoje ręce i chciałem zaprogramować coś, co jest niby mikrokontrolerem, ma jakieś czujniki, ma pewną moc obliczeniową, ale nie chciałem, żeby to było tak prymitywne, jak mikrokontroler, więc pomyślałem, że w sumie takie urządzenie ma w kieszeni – jest to smartfon, więc zacząłem się bawić się jakoś tam czujnikami i zacząłem bawić się w końcu czymś bardziej skomplikowanym, jak jakieś widoki, no i tak zostało mi w końcu, że zacząłem tworzyć aplikacje na Androida, które nawet nie są związane stricte z czujnikami, więc odszedłem od tego mojego zafascynowania samym hardware. Bardzo to polubiłem dlatego, że jeśli chodzi o Androida, to jest wizualne ,możesz napisać po 2-3 dniach aplikację, którą twój kolega, twoja koleżanka mogą zobaczyć, przy czym jest to na przykład do backendu, gdzie tam zmiany są bardziej subtelne i robią jakby świetne rzeczy back-end owcy, ale ciężko je zauważyć prawda? Ciężko je zauważyć komuś, kto nie jest związany z informatyką.

Jasne.

Pytałeś o moje doświadczenia też, bo to też jest bardzo bardzo różne. Ja pracowałem nad wieloma różnymi aplikacjami, tak jak mówiłeś – jakiś rok temu stworzyłem własną aplikację, pierwszą, która miała chyba jakieś 3000 użytkowników, co i tak jest dużym sukcesem biorąc pod uwagę niszę, którą sobie wybrałem czyli, świat gier planszowych. Była to Apka, która służyła do łączenia ze sobą graczy planszówek w Polsce, całkiem fajnie sobie radziła. Ja zaczynałem od trzymiesięcznego bezpłatnego stażu, gdzie na tym stażu zadanie, które dostałem jako pierwsze to przepisywanie jakiś stringów na litewski, łotewski, bułgarski, więc jakby zaczynałem jako taki typowy stażysta albo praktykant, potem zaczynały się bardzo fajne aplikacje, bo pamiętam, że trafiłem do jednego projektu, gdzie robiliśmy jakąś aplikację dołączenia kościołów w Teksasie. Potem przechodziłem do kolejnych firm, gdzie robiłem jedną z bardziej popularnych aplikacji pogodowych w Szwecji i współpracowałem właśnie ze Szwedami, z Norwegami, mieliśmy też współpracę częściowo z Bangladeszem, gdzie tworzyliśmy taką dość popularną apkę – e-commerce. I naprawdę moje doświadczenie zahacza też trochę od Bluetooth, bo pracowałem też w firmie gdzie, pracowaliśmy nad bardzo ciekawym projektem, który był ogromnym hitem sprzedażowym, ma chyba kilkadziesiąt milionów dolarów finansowania i to jest pompa laktacyjna, pompa laktacyjna sterowana przez Bluetooth, która jest niesamowicie pięknie zaprojektowana i ma piękną aplikacje do tego i okazało się, że ta aplikacja to był taki killer, który łączył to wszystko i dzięki temu inwestorzy i konsumenci po prostu na to lecieli i to było bardzo fajne. A w tej chwili pracuję nad aplikacją Boardly, która jest taką aplikacją społecznościową, która ma około 6 milionów użytkowników teraz, więc to są problemy już trochę innej skali, które są bardzo dużym wyzwaniem, ale bardzo się cieszę, nigdy nie miałem tylu użytkowników do utrzymania w aplikacji, więc to jest coś, nad czym pracuję teraz.

Fajnie, naprawdę sporo takich różnorodnych doświadczeń masz za sobą. Ja jakiś czas, kilka lat temu też miałem taki epizod, takie zachłyśnięcie programowaniem na aplikacjach mobilnych, to był co prawda u mnie iOS, ale też to co mnie przyciągnęło i to co mnie przekonało, to właśnie ta wizualność tego, że bardzo szybko, nawet na własnym telefonie można zobaczyć taki efekt, to jest zupełnie coś innego, niż taka wirtualna strona internetowa, także doskonale wiem o czym mówisz.

 

Wiesz to jest też trochę w ten sposób, u mnie to było trochę w ten sposób, że moi znajomi – Każdy mój znajomy miał Androida i wydaje mi się, że częściowo dlatego jestem Android Deweloperem, że gdyby wszyscy wokół mnie mieli iOS, no to jakby po co miałbym tworzyć apkę dla moich znajomych, żeby pochwalić się, że coś umiem, jakby nikt nie mógłby jej odpalić, więc wydaje mi się, że trochę zostałem Androidem, dlatego, że na początku studiów nie było mnie stać na iOS po prostu, ale ciągle cieszę się, bo myślę, że zebrałem coś co, koniec końców podoba mi się bardziej i cały ten system podoba mi się bardziej niż ten od Apple.

Według mnie całościowy programista powinien umieć rozwiązywać techniczne problemy przy pomocy języków programowania

 

Powiedziałeś, że wszyscy twoi znajomi mieli właśnie Androida i to też może po części pokrywa się z tym, co ja obserwuję na różnych job boardach, w różnych miejscach, gdzie są ogłoszenia o pracę skierowane właśnie do deweloperów. Obserwuję to że, rośnie ich liczba, rośnie ilość w ogóle Android deweloperów mam wrażenie na rynku. Myślisz że to jest perspektywiczna specjalizacja?

 

Wiesz ciężko spekulować. Ja też zrobiłem taki research na temat tego jak to wygląda, osobiście mogę mówić tylko z własnego doświadczenia, że sam na brak pracy i perspektyw nigdy nie mogłem narzekać, ale wiem, że jest nas dużo Juniorów, więc wydaje mi się że taką ogólną radą, którą mogę dać to żeby po prostu starać się być inżynierem oprogramowania. Bardziej niż jakby konkretnie Android Deweloperem. Mam tutaj na myśli, że według mnie taki całościowy programista, taki pełny programista, powinien po prostu umieć rozwiązywać techniczne przy pomocy języków programowania i gdy rynek wskazuje na to że, technologia umiera, to powinien umieć się przebranżowić. Wydaje mi się, że to jest coś, w którym kierunku…jeżeli jakiś Junior, który nas teraz słucha myśli sobie, że nauczy się dzisiaj tworzyć aplikacje mobilne i będzie tworzył aplikacje mobilne, albo przynajmniej będzie tworzył w ten sam sposób za 5-10 lat, to w jest dużym błędzie. To wszystko zmienia się tak niesamowicie, że ja już w ciągu swojej kilkuletniej kariery, żeby tworzyć aplikacje na Androida, już musiałem się uczyć dwóch języków programowania, więc to bardzo bardzo się zmienia i to jest to jest właśnie ekscytujące według mnie. Jeśli mamy już mówić o konkretach, jest taki raport przygotowany przez stronę indeed.com – to jest jeden z takich bardziej popularnych boardów chyba w Stanach, ale też ogólnie na świecie, gdzie po prostu wrzuca się ogłoszenia o pracę. I czytałem tam, że w ostatnim roku od maja 2018, do maja 2019, ludzie szukali mniej pracy na Androida, ale było więcej ogłoszeń o pracę na Androida, Co oznacza że jest mniejsze zainteresowanie na Androida, ale jest więcej ofert pracy. To było chyba o 26% było mniej wyszukiwań, a o 10% więcej ofert pracy. Co oznacza, że biorąc pod uwagę tylko ten raport, który bazuje na dość dużej próbce, mamy mniejszą konkurencję i mamy po prostu mniejszą konkurencję, mamy po prostu więcej ofert, a mniej ludzi zainteresowanych, co jest też dość ciekawym fenomenem.

 

Ciekawe, to jesteś fajna myśl, którą poruszyłeś, że warto być takim deweloperem, który powiedzmy potrafi rozwiązywać problemy, bo to jest najistotniejsze, a technologia musi iść zawsze za tym problemem, ale jest generalnie czymś wtórnym, czego się można nauczyć. To się pokrywa z tym co ja często dostaję – pytania od słuchaczy właśnie takich początkujących, którzy zastanawiają się jaki język wybrać, albo w którym kierunku tą swoją karierę na początku pokierować. I raczej staram się tłumaczyć, że to na początku naprawdę nie ma znaczenia, bo najprawdopodobniej wiele razy tą technologię po prostu zmienią. Ważne jest to, żeby zrozumieć pewne prawidła, które się powtarzają, są wspólne dla większości różnych technologii, ale to w związku z tym mam…

 

Język programowania to jest po prostu narzędzie, które jest narzędziem dobrego inżyniera oprogramowania. I to czy robimy w tej chwili coś na Androida, czy za parę lat będziemy robić coś, co jest wiesz, jednoczesne na Androida i na iOS, czyli mam to tutaj na myśli takie Cross platformowe podejście typu Flutter, ja z chęcią się tego nauczę, jeżeli faktycznie rynek będzie na to gotowy.

 

Jasne. To idąc jakby tą ścieżką, mam do ciebie też pytanie, czy Android deweloperem może zostać ktoś, kto jeszcze powiedzmy nie programuje, wiesz zupełnie Świeżak, czy osoba, która nie ma jakiś doświadczeń z programowaniem webowym, dysk topowym, która powiedzmy chcę dopiero wejść na ten rynek. Czy myślisz, że w ogóle programowanie na takiej powiedzmy właśnie platformie mobilnej, to jest dobry Punkt startowy?

Oczywiście że tak. Ja uważam, że do nauki programowania nie trzeba być jakimś niesamowitym mózgiem z matematyki, czy z fizyki, nie potrzeba nawet studiów. Uważam, że jeśli chodzi o Android Development, próg wejścia jest dość niski. Uważam też, że jest bardzo wdzięczne programowanie na Androida na początku, też na inne systemy mobilne dlatego, że tak jak już wspomnieliśmy wcześniej, kodzisz sobie coś i po dwóch trzech dniach po prostu widzisz efekt wizualny, możesz się tym pochwalić. Wydaje mi się, że to jest bardzo, bardzo motywujący element. Szczególnie dla kogoś, kto uczy się na początku czegoś, szczególnie programowania, które potrafi być czasami upierdliwe, ale koniec końców nie jest niczym ciężkim. Moim zdaniem po prostu wymaga odrobinę systematyczności.

 

Zanim przejdziemy do jakiś takich konkretnych technologii, takich twardych umiejętności, które są na co dzień potrzebne deweloperowi, to powiedz proszę jak może wyglądać taka droga wejścia, właśnie do branży, w szczególności właśnie do zostania Android deweloperem. Nie wiem, z jakich źródeł można czerpać wiedzę? Czy trzeba iść na staż, czy może samodzielna nauka wystarcza, jakie tutaj masz przemyślenia w tym temacie?

Jeśli chcesz sprawdzić czy to jest dla Ciebie, to są kursy online. Pamiętajcie, że wiele słabych kursów

 

Wiesz znowu to zależy od człowieka. Ja na przykład ucząc się na błędach zauważyłem, że taka nauka, jaką oferują nam studia, czyli po prostu chodzenie na wykłady, chodzenie na ćwiczenia… cała ta otoczka ze zdobywaniem tytułu, to nie jest optymalny sposób dla mnie na przyjmowanie wiedzy, ale wiem, że są ludzie, którzy uczą się dzięki temu i i osiągają o wiele lepsze wyniki, niż osiągałem ja, więc jeśli to jest sposób – pójście na studia i nauczenie się tam programowania mobilnego, bo są oczywiście kursy na przykład na AGH lub na UJ, na każdej uczelni w Polsce dobrej z mobilnego programowania, to proszę bardzo, to jest jak najbardziej sposób gdzie można się nauczyć. Moim zdaniem o wiele szybszy sposób – chcesz po prostu sprawdzić czy to jest dla ciebie, siebie, no to są po prostu jakieś kursy online. Jest oczywiście mnóstwo słabych kursów online, więc ja też nie mówię, że kursy są z automatu lepsze od uczelni, ale jest mnóstwo świetnych kursów online. Ja jakbym miał wybierać kurs online, żeby sprawdzić to faktycznie Android Development może być być dla mnie, to postawiłbym na praktykę, postawiłbym na kursy, które otwierają się co jakiś czas i mają na przykład – że robisz sobie jakiś projekt i masz jakiś kontakt z grupę, gdzie uczysz się, albo z mentorem. I ja czegoś takiego doświadczyłem ucząc się właśnie takich zagadnień związanych ze sztuczną inteligencją na Udacity. Udacity oferuje kilka płatnych, kilka darmowych programów, które są świetne żeby się nauczyć. Mają świetne wykłady, mają świetne materiały, przede wszystkim ta praktyka połączona z takim mentoringiem lekkim, to jest coś, co bardzo procentuje. No i koniec końców, jakby głównym źródłem tej wiedzy jest dokumentacja, więc wydaje mi się, że jak połączysz to wszystko, to możesz sprawdzić sobie, co jest tak naprawdę dla ciebie, czyli łączysz uczelnie, po uczelni sprawdzasz sobie jakiś kurs, może jeszcze znajdziesz jakiegoś starszego kolegę, który dosyć lepiej ogarnia – to jest taka kwestia mentoringu. No i wiesz, do snu czytasz sobie dokumentację. No i wcześniej, czy później zobaczysz, która wersja jest dla ciebie.

 

Jasne, pewnie. Czyli generalnie otaczasz się powietrzny ze wszystkich możliwych stron danym tematem…

 

Tak, i potem wybierasz, który sposób jest dla ciebie najlepszy.

 

Ok, to może zacznijmy od tych twardych umiejętności, od języka programowania. Kiedyś to była Java, a teraz Kotlin, z tego co obserwuję gdzieś tam z boku, przejął panowanie, poleciłbyś mimo wszystko zaczynanie od Javy? Czy nie wiem, w 2019-2020 nie ma to sensu i warto się skupić tylko na Kotlinie?

 Java wymaga po prostu więcej linijek kodu, żeby coś rozwiązać czy opisać niż Kotlin

 

Wiesz co, myślałem o tym trochę. Ja jestem osobą, która i ogarnia Javę i zaczynała od Javy i też nauczyłem się Kotlina i w tej chwili większość kodu, który pisze – przez większość mam na myśli 95% kodu, który pisze jest w Kotlinie i bardzo się z tego cieszę, ale wydaje mi się, że to jest coś, co już wiesz, jeśli wiesz jak smakuje gorycz, to potrafisz lepiej docenić ten smak słodyczy. I wydaje mi się że Java jest tutaj taką lekką goryczą, a Kotlin potrafi osłodzić ci życie jak piszesz jakieś aplikacje. Głównym argumentem za tym, że Java jest gorsza od Kotlina, jest to, że Java jest bardzo rozwlekła. Co oznacza w skrócie dla juniorów, którzy mogą nas słuchać, którzy wiedzą jak to wygląda, że Java wymaga po prostu więcej linijek kodu, żeby po prostu coś rozwiązać, żeby rozwiązać jakiś krótki problem, żeby coś opisać, niż Kotlin. Czyli na przykład, w Kotlinie można coś zrobić w 3 linijki kodu, w Javie to samo zajęłoby linijek załóżmy 15, albo 20. Tylko, że ja uważam, że ta rozwlekłość jest dość ważna dla kogoś, kto zaczyna dlatego, że dzięki temu możesz widzieć dokładnie co się dzieje krok po kroku, prawda? nie musisz jakby tworzyć skrótów i liczyć na to, że okej, niech się dzieje co się dzieje pod spodem, mnie to nie interesuje, do pewnego momentu to nie powinno Cię obchodzić, na tym polegają te języki programowania, które są wysokopoziomowe, ale Kotlin ulepsza Jave, w sensie Kotlin powoduje, że niektóre wady JavyKotlin nie ma tych wad Javy i po prostu musisz wiedzieć, które wady Javy – Kotlin naprawia moim zdaniem. Jeśli zaczniesz pisać w Javie zobaczysz że masz null pointer exception albo, że przeszkadza ci to, że musisz opisywać coś po raz trzeci w sposób, który zajmuje 30 linijek kodu, to przechodząc potem na Kotlina, zobaczysz jak łatwiej, jak lepiej można coś napisać w tym języku. Najlepiej byłoby moim zdaniem uczyć się Javy i Kotlina jednocześnie. Wydaje mi się, że to jest coś bardzo ciekawego, coś czego nigdy nie było mi dane zrobić, ale wydaje mi się, że to byłoby dość ciekawe doświadczenie. Porównywać sobie jednocześnie ucząc się dwóch języków, ale na pewno rozpoczęcie od Javy i kontynuacja w Kotlin, jest moim zdaniem też dobrym sposobem na to, żeby zrozumieć na czym polega sukces Kotlina i na czym polega jego przewaga nad Javą.

 

Ciekawe. Czyli zalecasz, że gdyby rozpoczęcie jednoczesne z Javą i Kotlinem, z jakimś tam naciskiem mimo wszystko na Kotlina. Czy są jeszcze jakieś narzędzia, albo technologie, które musimy opanować, żeby stworzyć tego przysłowiowego “Hello Worda” na Androida?

 

Gradle to system budowania projektów na Androidzie. Jest to napisane w Groove. 

Jest kilka małych rzeczy, o których wydaje mi się, że powinienem wspomnieć. Jest coś, co nazywa się Gradle. Jest to w dużym skrócie, taki system budowania projektów na Androidzie. Jest to napisane w groove. I wydaje mi się, że nie trzeba wiedzieć jakoś bardzo dużo o tym gradle dlatego, że on działa automatycznie dzięki Android Studio, który ma sobie wbudowane pluginy, które budują nam te projekty, ale żeby nie wystraszyć się tego, że widzimy chwilkę odrobinę inny język programowania, gdy ściągnęliśmy Android Studio i budujemy jakiś projekt, to wydaje mi się, że warto przeczytać przynajmniej pierwszą stronę dokumentacji i zobaczyć na czym w ogóle polega gradle, na czym polega Android gradle plugin, jak na przykład dołączać różne biblioteki do naszego projektu, tak żeby wykorzystywać kod innych. To jest jedna kwestia, ale tak jak mówię – myślę, że nie warto poświęcać na to jakoś bardzo dużo czasu, to jest kwestia bardziej, żeby się nie wystraszyć, jeżeli ktoś zobaczy pliki groove, albo ogólnie gradle w projekcie. XML jest dość ważnym aspektem programowania na Androida. XML jest językiem znaczników, czyli nie jest takim pełnoprawnym językiem, jest takim bardzo bardzo podobnym do HTML. My, Androidzi przede wszystkim używamy XML do tego, żeby tworzyć layouty. Oczywiście jest parę innych zastosowań, ale głównie tworzymy layouty. Czyli jeżeli ktoś odpala aplikacje i widzi na przykład pole tekstowe, jakiś przycisk… no to jakby sam ten layout, samo to co widzimy jest zaprojektowane w XML. To, że tworzymy ten layout jako coś interaktywnego, no to już jest faktycznie zasługa Kotlina i Javy, ale sam ten XML, sam layout, to jest coś co tworzymy osobno. No i na koniec myślę, że Jason to jest też taka podstawa JavaScript Object Notation, dla tych którzy nie wiedzą co to jest. Bardzo prosta rzecz – to jest pewien sposób takiego lekkiego przenoszenia danych pomiędzy platformami, pomimo tego, że ma w sobie nazwę JavaScript, to jest bardzo często używane w różnych technologiach po to, żeby na przykład przenosić dane serwera i wyświetlać je na przykład na telefonie, więc wydaje mi się, że poświęcenie jednego dnia, na takie delikatne obycie się z tymi trzema rzeczami- gradle, XML i Jason na pewno zaprocentuje i gdy otworzymy sobie projekt w Android Studio, to będziemy mniej przerażeni.

 

No dobrze, na początku powiedzieliśmy, że to co ty to powiedziałeś również, że to co Cię gdzieś tam przeciągnęło powiedzmy, do tworzenia aplikacji mobilnych, to jest ta warstwa wizualna. To, że coś widać, to że możemy zaprogramować coś, co w jakiś sposób zmienia swój wygląd. Jakie podstawowe komponenty, zagadnienia według ciebie trzeba znać opanować, żeby z tą warstwą właśnie wizualną móc podziałać na Androidzie?

 

Wydaje mi się, że takie podstawy. Jeśli chodzi o kwestie wizualne, może Activity? Activity to jest klasa od której chciałbym zacząć. Activity to jest klasa, która odpowiada w dużym dużym skrócie za ekran. Wyobraź sobie że otwierasz sobie aplikację, która ma ekran logowania, potem sobie przechodzisz w jakiś główny ekran, który ma jakąś listę, potem sobie możesz przejść w jakiś osobny ekran, który ma na przykład dane o twoim profilu. Każdy z tych ekranów najczęściej – bo jeszcze wspomnę jakie są przypadki, jak to może być podzielone, ale najczęściej jest to implementowane jako osobne Activity. Czyli mamy na przykład login Activity, main Activity, załóżmy profile Activity, i do każdego z tych Activity, które są utworzone w Kotlinie, albo w Javie jest właśnie dopisany jakiś XML. Czyli po prostu takie pliki XML, które, gdzie definiujemy sobie layout, czyli co chcemy wiedzieć na tym widoku. Gdy będziecie przeglądać na przykład dokumentację, związaną właśnie z Activity, albo będziecie uczyć się Activity, to pytanie klasyczne na rozmowie kwalifikacyjnej i coś co, powtarza się potem bardzo często – to to jest Life cycle activity, czyli cykl życia Activity. Czyli przez jakie callbacki wewnątrz Activity przechodzi się podczas interakcji z aplikacją. Co się dzieje gdy włączymy ekran? Co się dzieje gdy wycofany aplikacje na chwilę do backgrounda? Czyli na przykład wyjdziemy z niej, ale ona ciągle będzie działała. To jest coś, na co warto zwrócić szczególną uwagę i do czego warto się przyłożyć, bo wydaje mi się że, nawet mi – jako Seniorowi zdarzają się małe fuck up w tym, w tej kwestii. To jest jedna rzecz – Activity. Czyli duży ekran. Druga rzecz o której chciałem wspomnieć to fragment. I też, fragment też ma swój Life cycle, ma swój cykl życia, czyli znowu mamy fragment jako klasę, która jest częścią ekranu. Czyli możemy mieć Activity, które jest całym ekranem, ale możemy sobie to Activity podzielić na jakieś małe fragmenty. Czyli możemy mieć jakby górną część ekranu i dolną część ekranu. I sam fragment jest osadzony w Activity. Activity jest osadzone ogólnie w całej naszej aplikacji, no i fragment, tak jak mówiłem też ma swój cykl życia, więc tutaj już pojawiają się problemy. Dlatego tak bardzo kładę nacisk na to, żeby zwracać uwagę na cykl życia podczas nauki, bo to jest coraz bardziej skomplikowane, im więcej elementów do siebie dodajemy, mamy wtedy cykl życia, wewnątrz cyklu życia i znowu jedno z najczęściej pojawiających się pytań rekrutacyjnych – czyli cykl życia fragmentu, biorąc pod uwagę, wiesz, jest wewnątrz Activity, więc w skrócie fragment to jest wydzielona porcja, jakby część ekranu, część Activity. Fragmenty stosujemy najczęściej dlatego, żeby jakby stworzyć coś, co jest bardziej, co możemy sobie odłączyć, taki plugin mały. Czyli bierzemy sobie jeden fragment z jednego Activity i wrzucamy do innego Activity. Na fragmentach można to łatwo zrobić. Z Activity może być trochę ciężej, więc w dużym skrócie fragmenty są po to żeby dać nam taką lepszą modularyzację ekranów, żebyśmy mogli przerzucać sobie takie malutkie widoczki na różne Activity, żeby ten widok był jak najbardziej modularny. No i mamy Activity, mamy fragment i tak jak mówiłem – Do każdego z tych bytów, z tych klas jest podłączony jakiś XML. XML, który opisuje nam ten layout, który opisuje nam co my chcemy widzieć. Fragment i Activity tworzy interaktywność z tych layoutów, które są Martwe, ale tak samo layout może zawierać takie rzeczy, jak linearlayout. Linearlayout to jest po prostu layout, który jest taki najprostszy, od którego radzę zacząć, że po prostu wypisujesz sobie w XML kolejne elementy, jakie chcesz tam mieć jakieś tam mieć. Najprostszy to na przykład taki textView. Tekst View to jest taki prosty element, który wrzucasz sobie do XML, no i to jest po prostu zwykły tekst zwykły, taka labelka, jakiś opis możesz tam wrzucić. Edit text to jest kolejna rzecz, którą możesz sobie wrzucić do layoutu, to jest taki input free, czyli po prostu, że masz pasek, gdzie możesz wpisywać jakiś tekst. Też bardzo przydatne, bardzo proste na początek i właśnie od tych, od tych takich prostych rzeczy radzę zacząć. Potem masz button, na przykład button to jest kolejny element, kiedy możesz wrócić sobie do prostego layoutu, gdzie to jest po prostu zwykły przycisk. Image View, też bardzo fajny na sam początek, po prostu jest to malutki widok, gdzie możesz wrzucić jakieś zdjęcie. No i na przykład Progress Bar, czyli jak coś robimy, jak będziemy potem wspominać, o tym że robimy coś w tle, na przykład czekamy aż coś wykona. No to warto pokazać taki ekran ładowania malutki, taki okrąg który się kręci, to jest wbudowane wszystko Androida. Od tych prostych widoków bardzo radzę zacząć. Zbudować coś prostego z Activity, fragmentem, poczuć przede wszystkim Life Cycle,to jest najważniejsze. No i właśnie to co powinien umieć ktoś, kto chce opanować te takie wizualne komponenty na tym poziomie podstawowym.

 

No właśnie rozpocząłeś już to zdanie, że oprócz tego, że mamy warstwę prezentacji, no to aplikacja nasza, najczęściej posiada też jakąś logikę, czyli coś się dzieje w tle, komunikujemy się z jakimś zewnętrznym API, wykonujemy jakieś obliczenia, jakieś jakieś modyfikacje danych i tak dalej. Z Czego na Androidzie mogę skorzystać, aby właśnie tego typu operację móc sobie zakodować?

 

Tak jak mówiłeś, oprócz tego co widzimy, oczywiście musi być też wykonywana jakaś praca w tle i na początek jest oczywiście mnóstwo sposobów, żeby to zrobić. Jeśli chodzi o takie rzeczy, które radzę zgłębić na początku, to serwisy. Serwisy są to takie komponenty Androida, które wykonują jakąś pracę, nawet jeżeli użytkownik nie korzysta z aplikacji. Wykonują ją tle mają, nie mają UI, czyli nie mają tak jak Activity, albo fragment, o którym wspominałem, nie mają XML ,który jest przyczepiony, coś pokazuje. Serwisy wykonują jakąś pracę w tle, coś się dzieje i znowu zaczynamy zgłębiać te serwisy i pojawia się taka czerwona flaga i tutaj też nie warto panikować, tą czerwoną flagą jest to że od Androida 8,i trochę zmieniły się te serwisy. Co oznacza, że nie możemy na przykład używać teraz serwisów w tle. Podam na przykład coś, co ja montowałem do niedawna. Możemy mieć aplikację, która chce zsynchronizować swoje dane z serwerem. Nie chcemy tego robić tak, żeby blokować dla użytkownika ekran, bo to by było bez sensu, chcemy zrobić w tle. Dlatego uruchamiamy serwis, który robi nam synchronizację. Przed Androidem 8 mogliśmy spokojnie ten serwis uruchomić w tle i kompletnie się nie przejmować tym, czy użytkownik wie o tym, czy nie. O tyle, po Androidzie 8, coś co według mnie jest słusznie zrobione, twórcy Androida czyli Google, zobaczył że to bardzo często wpływa na jakość baterii, czyli na długość życia baterii. Bo często są aplikacje, które wykonują niesamowicie ciężką pracę w tle i użytkownik nawet o tym nie wie. Dlatego wprowadzono wiele limitów, jednym z tych limitów jest to, że nie możemy odpalić takich serwisów w tle. Ale to nie znaczy, że serwisy całkowicie umarły. Warto o nich poczytać i warto zastanowić się, jak są one wykorzystywane w tej chwili, mając na uwadze coś, co właśnie nazywa się popularnie Background Execution limit , czyli właśnie na Androida 8.0 jakby wchodzą te limity, które pozwalają nam cieszyć się jeszcze więcej z baterii, więc serwisy – na pewno padnie o to pytanie, wcześniej czy później na jakiejś rozmowie kwalifikacyjnej, przynajmniej wydaje mi się, w tym albo w następnym roku, nie wiadomo co Google wymyśli jeszcze. Druga rzecz, wydaje mi się, że ona jest łatwiejsza i bardziej powszechnie będziecie ją stosować, tworząc jakieś apki proste, ale też bardziej skomplikowane na Androida – retrofit. Retrofit 2 jest to biblioteka ,która została napisana przez między innymi takiego jednego z bogów Androida, czyli Jake Whartona, pewnie będziecie o nim będziecie słyszeć, jak będziecie czytać sobie o różnych rzeczach na Androidzie. Retrofit jest to biblioteka, która służy w dużym skrócie do konsumowania jakiś zewnętrznych API, czyli wyobraźmy sobie, że mamy jakiś serwer, który wystawia nam jakiś endpoint i chcemy zaciągać jakieś dane, na przykład nie wiem, listy użytkowników – chcemy to wyświetlić. To jest tak naprawdę bardzo prosta aplikacja, którą polecam zrobić na początek. Activity, jakiś może fragment i po prostu zasysanie danych i pokazywanie ich na ekranie. I Retrofit właśnie tym się zajmuje. Retrofit dodaje się przez Gradle, tam gdzie dodaje się wszystkie zewnętrzne biblioteki. Gradle to jest ten system budowania, o którym wspominałem, no i Retrofit pozwala nam w taki fajny sposób zaciągnąć to, łatwo możemy tam ogarnąć wątki, żeby nie blokować jakby UI, Retrofit pozwala nam współpracować z API i robić coś ciekawszego, niż jakieś takie widoczki, więc tak jak mówię – serwis i Retrofit na początek, pobawić się tym na pewno to zaprocentuje i i to jest taka fajna podstawa.

Powiedziałeś, że to są takie zupełne podstawy dla osób początkujących. Powiedziałeś co warto znać w tej warstwie wizualnej prezentacji, na czym się skupić jeśli chodzi o logikę. Załóżmy, że mniej więcej już się jakoś w miarę, w tym temacie poruszam. Co dalej mógłbym poznać, albo w jakim kierunku powiedzmy iść, żeby poszerzyć jakoś swoje kompetencje, swoje umiejętności, myśląc o tej warstwie prezentacji jaki byłby następny krok?

Jasne, więc myślę, że dobrym krokiem jest po prostu popatrzenie na to, co fajnego może dojść do XML, jak fajnie, jaki widok, który jest troszeczkę bardziej skomplikowany można dodać do XML. Tak jak mówiłem mamy w XML coś, co nazywaliśmy linear layout. Czyli po prostu layout, który będzie sobie mógł zawierać jeden po drugim, na przykład button, na przykład image View, na przykład tekst, bardzo proste rzeczy. Spróbujmy teraz, jak już będziemy ogarniać trochę lepiej XML znaleźć sobie coś, co nazywa się relative layout. Czyli layout, który już może trochę bardziej, w bardziej skomplikowany sposób manipulować tymi widokami, ustawiać je obok siebie, rozrzucać je po tym ekranie. To wydaje mi się że to będzie fajnym kolejnym krokiem, czyli ten relative layout jest takim kontenerem na inne widoki i wewnątrz tego możemy sobie wrzucić znowu te same rzeczy Image View, Text view, albo jeżeli chcemy pójść dalej, są troszeczkę bardziej skomplikowane widoki, jak na przykład w View pager. View pager to jest widok, który… dobrym przykładem View Pagera to jest ta sekwencja outboardingowa, która jest często widoczna w różnych aplikacjach. Czyli masz na dole takie trzy kropeczki, nie? i po prostu przesuwasz w lewo, albo w prawo palcem, żeby przejść przez ten tutorial. To jest zrobione na View Pagerze najczęściej. Bardzo fajnie można to ogarnąć szczególnie, że można to trochę połączyć z kodem, z adapterami. Myślę, że to jest dość fajne ćwiczenie. Toolbar coś co wydaje się proste, czasami ciężko to dodać. To jest taki klasyczny element, który widać zawsze u góry, który ma nazwę i logo aplikacji, może mieć jakiś Hamburger menu, kolejny poziom na pewno, biorąc pod uwagę poprzednie proste widoczki. Możemy też stworzyć coś co nazywa się Dialogue. Dialogi, które często się wyświetlają, na przykład jakiś błąd, to jest ten taki element, taki prostokącik, który wychodzi za każdym razem kiedy zrobimy coś źle i wychodzi na przykład, wiesz.. czy na pewno chcesz wyjść z aplikacji? możesz kliknąć tak, albo nie, też wymaga troszeczkę bardziej zaawansowanej operacji, ale ciągle wydaje mi się że mieści się w tym średnio zaawansowanym poziomie Juniorstwa. I to jest to jest jeszcze jedna rzecz, o której chciałem też wspomnieć. Jeśli chodzi o poziom średniozaawansowany, bo wydaje mi się, że same widoczki to jedna rzecz, ale trzeba wziąć też pod uwagę że rzeczy, które widzimy nie są tylko i wyłącznie widokami. Dla przykładu – wydaje mi się, że jak już ogarniemy trochę te Activity fragmenty, czy czujemy się pewnie w tym XML, możemy wziąć się za coś, co nazywa się Runtime Permissions. Czyli jeżeli na przykład chcemy wejść w kamerę jeżeli chcemy na przykład zapisać jakiś plik na Androidzie lokalnie, musimy mieć dostęp do pewnych pozwoleń użytkownika. Nie możemy bezpośrednio wejść do kamery użytkownika, użytkownik musi dać nam pozwolenie na to i od Androida 6.0 musi to zrobić w Runtime. W Runtime nie mam na myśli że po prostu podczas użytkowania aplikacji. Wcześniej to się działo przy instalacji, to było dość złe z punktu widzenia użytkownika. Teraz wydaje mi się, że ze względu na to, że te apki mogą być troszeczkę bardziej skomplikowane, więc nie polecam go na początek, ale teraz wydaje mi się, że fajnie byłoby po tym Relative layout, po View Pagerze spróbować na przykład dostać się do kamery i zapytać użytkownika o pozwolenie. Zbudować taki dialog, jak to się wszystko tworzy. Wydaje mi się, że to jest fajny kolejny krok i tutaj jeszcze sobie chyba nikt tych nóg nie połamie, bo jeszcze to nie jest aż tak skomplikowane.

 

To co powiedziałeś, o tych dostępach, to już trochę gdzieś tam powiedzmy wchodzi w logikę aplikacji, trochę trzeba, domyślam się dokodować, do tego dorobić kodu. Czy coś jeszcze powiedzmy z tej warstwy logiki byś radził, żeby rozszerzać swoją wiedzę, w którym kierunku, jakie aspekty warto poznać w dalszym kroku?

 

Ok, a więc to co mówiłem, to była jakby kwestia związana z widokiem dla kogoś średnio zaawansowanego powiedzmy, bo ciągle te permissions, o których mówiłem to jest widok, a View Pager to jest widok Relative layout. Możemy zrobić krok dalej, jeżeli chodzi o Retrofit. Czyli tak jak mówiłam, wcześniej mamy Retrofita, ściągamy jakieś dane i na początku robimy to bardzo prosto, na call backach, to jest jakby domyślny sposób tego, jak powinniśmy to robić. Nie powinniśmy mieć kompleksów, że robimy to w najnudniejszy możliwy sposób. Teraz wydaje mi się, że kolejnym krokiem byłoby fajnie dodać jakiś adapter. Adapter, który na przykład zamieniam to, na przykład na RXJava. To jest coś, co jest bardzo popularne. Większość ofert zawiera w sobie RX Java. RXJava może się wydawać trudna na początek, ale jakby ktoś chciał na przykład jakieś lekkie wprowadzenie do reaktywnego programowania, z którym jest związana RXJava, to to też, na moim blogu jest dość fajny artykuł, który napisałem ostatnio. Wydaje mi się, że można tam zajrzeć i to zobaczyć. RX Java sama w sobie bardzo ułatwia, taką synchroniczną komunikację z serwerem. I na takim podstawowym poziomie nie jest trudna do ogarnięcia, a wydaje mi się że może bardzo zaprocentować, kiedy potem będziemy starać się o pracę. Więc łączymy Retrofit z RXJava, co nie jest tak trudne i potem używamy tej RX Javy, żeby ściągnąć sobie w taki dość fajny sposób te dane, które wcześniej włączyliśmy przez callbacki. Teraz te callbacki wywalamy i używamy RX Javy. Używamy takiego pięknego, reaktywnego, może też funkcyjnego jak ktoś trochę bardziej się postara kodu, więc moim zdaniem, o ile jak wiele osób, jak tylko słyszy coś w stylu RXJava jest przerażona, moim zdaniem już na tym etapie, można spokojnie spróbować czegoś z RX Javy.

RXJava może się wydawać na początek trudna, ale ona ułatwia synchroniczną komunikację z serwerem

 

Ok. Teraz już powiedzmy, kiedy w miarę dobrze tutaj poruszamy się, właśnie w tych technologiach, w tych bibliotekach, o których wspomniałeś i możemy już powoli myśleć o tym, żeby być bardziej zaawansowanym Juniorem, to co warto jeszcze poznać? Jakie narzędzia tutaj sobie przyswoić, żeby jeszcze lepiej się odnajdywać w środowisku Androidowym?

 

Wydaje mi się, że jeśli już ogarniamy na trochę lepszym poziomie, to co robiliśmy w tle, na trochę lepszym poziomie, to co robiliśmy na widoku, no to trzeba trochę podkręcić ten widoczek. Trzeba zrobić coś fajniejszego, trzeba zrobić coś bardziej skomplikowanego, więc mieliśmy coś co nazywało się Linear layout, potem mieliśmy Relative layout. Zróbmy teraz mały refaktoring I zamieńmy to wszystko na Constraint layout, czyli layout, który jest wydaje mi się najbardziej skomplikowany, ale też można z nim robić naprawdę niesamowite rzeczy i zróbmy sobie Constraint layout, zróbmy jakieś widoki, które będą osadzone właśnie na Constraint layout, który wykorzystuje constrainy, to jakby wydaje mi się, w dokumentacji o wiele, wiele fajniej to opisze, niż ja – wizualnie, niż ja teraz przez ten podcast. No i wewnątrz tego layoutu możemy wrzucać sobie rzeczy, które są bardziej zaawansowane, niż prosty Text View, niż tekst, jakiś Edit text. Będziecie czuć, że wypadałoby zrobić coś bardziej skomplikowanego, więc może jakaś lista – Recycler view. Recycler view jest w dużym skrócie listą, trzeba tak naprawdę dodać tam kilka adapterów. W zasadzie 1 adapter, trzeba to połączyć trochę z danymi które możemy zasysać przez Retrofita, przez jakiegoś API, możemy używać RX Javy, ale koniec końców, to jest coś, co wykorzystując… to się nazywa View holder Patent, to jest coś, o co się często pyta na rozmowie kwalifikacyjnej. Tworzy bardzo fajną i dobrze wyglądającą listę. Ja myślę, że powinniśmy tutaj pójść już w tym kierunku, takich bardziej skomplikowanych widoków. Mając tą listę, możemy na przykład filtrować tą listę, więc mamy taki widok który nazywa się Search View. Search view umieszczamy na samej górze, wpisujemy tam jakieś rzeczy, no i nasza lista jest filtrowana. To jak połączyć Search View z Recyclerview, jest mnóstwo sposobów, ale teraz znając już trochę podstawy zarządzania logiką, może niektórzy ambitni wykorzystają RX Jave do tego, co też jest bardzo fajnym sposobem, żeby połączyć Search View z Recycling View, jak to filtrować. No, na pewno te połączenia pomiędzy widokami są fajnym ćwiczeniem, już na tym poziomie, takim Juniora solidnego. Możemy też zajrzeć w style, możemy zajrzeć w tematy. Co oznacza, że żeby jakieś kolory, albo jakieś jakieś formatowanie tego tekstu, jakieś rozmiary czcionek, żeby to wszystko było tak takie samo, żebyśmy nie musieli za każdym razem tworzyć, przepisywać i kopiować 50 linijek Text View, który jest tak fajnie oscylowany, ma jakiś tam rozmiar czcionki. Spróbujmy użyć jakiegoś stylu, jakiegoś stylu, żeby to było wszystko automatycznie za nas robione. Więc kolejna bardziej zaawansowana rzecz związana stricte z widokiem. I wydaje mi się, że takim, ja nie lubię pracować na czymś, co się nazywa customowy widok, czyli tworzenie takich animacji. To jest dość męczące, ale każdy deweloper będzie musiał wcześniej, czy później stworzyć jakąś piękną animację, którą wymyślił designer, wiesz na swoim designowym haju. I to jest niesamowite. Ci ludzie tworzą niesamowite rzeczy, my musimy je kodzić, no i często animacje, jakieś przejścia, jest dużo klas do tego teraz w Androidzie. Wydaje mi się, że można by było teraz, na tym poziomie zaawansowania, na którym mógłby być junior w tej chwili, spokojnie zrobić jakiś fajny widok z jakąś animacją jakieś [00:42:53 niesłyszalny fragment], czyli przechodzenie, takie tranzycje, po prostu pobawić się tym, to jest naprawdę duży plus, jak pójdzie się potem na rozmowę i powie się, że robiło się coś takiego, bo często ja patrzę na takie widoki, które robili ludzie młodsi ode mnie i moje pierwsze pytanie to jest, jak ty to zrobiłeś? Ja po prostu uważam to za jakąś sztuczkę magiczną, bo nie mam pojęcia co się dzieje pod spodem. Dlatego te widoki, tak często robią dość dobre wrażenie. To jest kwestia widoku. Tutaj wydaje mi się, że już każdy będzie mógł troszeczkę bardziej rozwinąć się jeśli chodzi o logikę, oto co się dzieje pod spodem. Ja polecam zajrzeć do Work Manager. Work Manager to jest klasa, która została dość niedawno, dodana do naszego Androida. To jest taka klasa która pozwala nam robić rzeczy w tle. Czyli tak jak wspominałem, serwisy zostały mocno przez Androida 8 przycięte. Przez to, że Google stwierdził, że bateria faktycznie jest trochę za dużo używana przez takie serwisy, które robią coś w tle, te klasy, które robią coś w tle, a użytkownik o tym nie wie. To zostało trochę podcięte, więc dano nam Work Managera, który pozwala nam robić rzeczy w tle, ale na zasadach Google, czyli na zasadach systemu. Czyli nie wszystkie rzeczy będą robione od razu, będą te rzeczy robione w tle, ale tak, żeby użycie baterii było optymalne, więc na pewno to jest pewna alternatywa. Wydaje mi się, że najlepsza w tej chwili i warto sobie zajrzeć do Work Managera i zobaczyć jak teraz możemy tego użyć. A to API, biorąc pod uwagę to co już teraz umiemy jako Junior, który już ogarnął te wszystkie poprzednie tematy, będzie się wydawało dość proste. Kolejny challenge, który możemy sobie dać to coś, co jest dość popularne ostatnio na Kotlinie, czyli rutynę. Czyli tak jak mówiłem, mamy tego Retrofita. Retrofit ściąga nam jakieś dane, na początku robi to w bardzo prosty sposób, przez callbacki. Zaczęliśmy od callbacków. Potem dajemy sobie RX Jave, więc sobie utrudniamy życie sobie. Możemy na samym końcu sobie wrzucić jako rutynę. Rutyny to są takie leciutkie wątki, a tak naprawdę to jest taka konstrukcja w języku Kotlin, która pozwala nam wykonywać pracę w tle, która wygląda jakby była pracą synchroniczna, ale jest ciągle wykonywana w tle, więc możemy sobie dodać kolejny adapter, który łączy nam Retrofita z rutynami i zobaczyć, czy może rutyny odpowiadają nam bardziej, niż RX Java. Naprawdę, gdy rekrutowałem jeszcze rok temu, bardzo lubiłem gadać z ludźmi, którzy potrafią… z juniorami którzy potrafią już formułować na tym poziomie takie swoje opinie, że na przykład rutyny są lepsze od RX Javy dlatego i dlatego, albo RXJava jest lepsza dlatego, że dlatego. Warto sobie wyrobić takie zdanie. Jako rutyny są naprawdę proste do ogarnięcia, a celem rutyn, tak samo jak RX Javy jest ucieczka trochę od callbacku. Jest zrobienie tego, żeby ten kod wyglądał na synchroniczny, ale żeby tylko parę zmian powodowało, że on nie jest synchroniczny. I wydaje mi się że to jest kluczem do zrozumienia tego, po co są rutyny, po co jest RXJava. To jest road mapa na miesiące moim zdaniem. I ona powinna być poparta projektami, ale tutaj też mamy pewne solidne podstawy, takich podstawowych komponentów Androidowskich.

 

Skoro Mateusz już powiedziałeś o tej właśnie warstwie wizualnej, o tym jak możemy z tymi widokami sobie tutaj prace uprzyjemniać, dużo o powiedziałeś też, o tej warstwie logiki, czyli temu wszystkiemu, co tak naprawdę wykonuje się najczęściej pewnie w tle. Jeszcze gdzieś mi tutaj brakuje zapisywania danych. Każda aplikacja mobilna, może nie każda, ale większość przypuszczam, musi coś lokalnie na telefonie zapisywać, jakieś ustawienia, jakieś dane, które są wynikiem działania. Z czego tutaj możemy skorzystać żeby sobie po prostu lokalnie zapisać?

 

Jeśli mamy coś prostego do zapisania, SharedPreferences klasa, która pozwala nam zapisywać proste rzeczy typu, inty, stringi i zapisywać je lokalnie i potem używać z powrotem, nawet jeżeli wyjdziemy z aplikacji, to zapisuje się na dysku, w pamięci naszego telefonu. Przeważnie to jest za mało dlatego, że w naszych prostych aplikacjach możemy tylko używać SharedPreferences, ale już takich aplikacjach, które wymagają czegoś więcej, mamy bardziej skomplikowane zapytania. Myślę, że powinniśmy spojrzeć na klasyk w zapamiętywaniu, klasyk jeżeli chodzi o bazy danych. Kiedyś to było SQLite. SQLite stosowaliśmy jako Android developerzy bardzo dużo na Androidzie, teraz, i to jest coś co radzę teraz juniorom zajrzeć, to jest Room. Room to jest taka świetna nakładka na SQLite, która pozwala tak naprawdę… ułatwia nam pracę z tym SQL, więc dla kogoś, kto nigdy nie korzystał z SQL i przechodzi do Androida i myśli że nie będzie nigdy korzystał z SQL to nie jest do końca prawda. SQL jest ciągle, fajnie dość często wykorzystywany na Androidzie. Ja najczęściej spotykałem się z dość prostym prostymi zapytaniami, więc też nie ma co się załamywać, że to będą jakieś niesamowicie skomplikowane połączenia tych różnych tabelek, nie. SQL trzeba ogarniać, ale Room daje nam świetną nakładkę, żeby sobie dobrze z tym radzić na Androidzie.

 

Ok, to dobrze. Mam wrażenie że znamy już takie komponenty w tym momencie, z których naszą aplikację budować, ale nie zapomnijmy, o tym wszystkim jeszcze, co łączy te wszystkie komponenty, czyli o jakiejś architekturze naszej aplikacji. Jakie zadania zagadnienia według ciebie takie wiesz, związane właśnie z architekturą są niezbędne do poznania na tej początkowej drodze do zostania Android Deweloperem.

 

Tak, ja myślę, że już w tej chwili, gdy już pracujemy kilka miesięcy nad Androidem, robimy te różne rzeczy, no to jako Juniorzy wydaje mi się, że już niektórzy powinni czuć, że może nasz kod jest nie do końca uporządkowany w dobry sposób. I tu właśnie wchodzi architektura, albo wzorce architekturalne, więc no co ja polecam – z tych wzorców architekturalnych mamy model View Presenter, klasyka tak naprawdę, bo tu chciałbym wspomnieć jaki jest cel, który tutaj mamy. Celem jest to, żeby odseparować Androida, odseparować Framework od tego, od naszej logiki, czyli chcemy mieć klasy, które akurat w przypadku model View Presenter nazywa się ta klasa Presenter. Chcemy mieć klasę, chcemy mieć Presentery, które nie mają w sobie zależności Androidowych – to jest celem. Separujemy sobie pewne rzeczy do naszego Frameworka, dzięki temu tworzymy dość fajne zależności pomiędzy różnymi komponentami, mamy widok, który jest tylko Androidowy, mamy Presenter, który ma w sobie logikę prezentacyjną, ale nie ma zależności Androidowych. No i potem możemy mieć jakiś model, który w skrócie odpowiada za tę komunikację pomiędzy serwerem na przykład, albo na przykład pomiędzy bazą danych i tak dalej, czyli stricte taka logika biznesowa, to jest nasz cel. Model View Presenter nam w tym pomaga, model View View model – kolejna z rzecz, to jest wzór architekturalny, który jest dość mocno teraz promowany przez Google. Wydaje mi się, że na pewno wzorzec, do którego warto zajrzeć. Często jest częściej wybierany przez Android Deweloperów niż model View Presenter. Ciężką rzeczą, której można się bardzo wystraszyć na początku w model View View model jest Data Banding. Data Banding jest ciężko się nauczyć na początku, ale wydaje mi się, że mogą być z tego bardzo fajne profity, bo kod Activity, albo kod fragmentu staje się bardzo prosty, więc to jest moja rada – możecie sobie zacząć od model View Presenter, super sposób, żeby zacząć w ogóle rozumieć jak to wszystko podzielić. Model View View model może się wydawać trochę bardziej skomplikowany przez Data Banding, ale też to jest coś, co możecie sami sobie rozkminić, czy faktycznie model View View model jest lepszy od model View presenter dla nas. Bardzo, bardzo na rozmowach kwalifikacyjnych ceni się taką opinię, że model View Presenter jest lepszy dlatego i dlatego, albo nie podobał mi się model View View model, czyli w skrócie MVVM dlatego i dlatego. Jest jeszcze jedna rzecz, o której chciałem wspomnieć – to są wzorce architekturalne, tak naprawdę ciężko mówić, że to jest architektura aplikacji, bo architektura dla mnie przynajmniej, to jest o wiele szersze słowo. Dlatego wydaje mi się, że jeżeli wpiszemy sobie w Google – Clean architecture i klikniemy chyba pierwszy link, czyli ten taki słynny okrąg z warstwami, gdzie mamy w środku entities i tak dalej, i tak dalej To jest coś, w co koniec końców w chcemy celować na Androidzie i na każdym systemie, który projektujemy, więc wydaje mi się, że warto zrozumieć co kryje się za tym co jest w tym artykule związane z Clean architecture jak to się ma do MCP i MVVM, ale na początek MVP zrozumienie tego i dlaczego to robimy, jest bardzo dobrym krokiem.

 

To jeszcze nie zapomnijmy o testowaniu, jak myślisz – Junior Development na Androidzie też powinien się takimi tematami zajmować? Jeśli tak to jakie możliwości narzędzia mamy do wykorzystania?

 

Tak, moim zdaniem juniorzy powinni się interesować testami jednostkowymi i tym, jak automatycznie testować swój kod. Ja na swoim blogu mam też artykuł, o tym co jeszcze dają testy, oprócz tylko przetestowania kodu, więc można tam zajrzeć i zobaczyć co jeszcze dają testy na przykład w przypadku refactoringu to jest też dość duży gain, żeby uniknąć błędów. Po to właśnie robimy architekturę, więc jakby ktoś się zastanawiał po co w ogóle to MVP, MVVM tak to porządkuje kod, ale koniec końców chcemy mieć nasz kod przetestowany, nie możemy osiągać na Androidzie 100% pokrycia kodu testami, ale możemy przetestować takie kluczowe rzeczy, które są dla nas bardzo ważne i dzięki temu robimy architekturę, przez to robimy architekturę potem piszemy dla naszych prezenterów właśnie te testy. Mamy podział na 2 rodzaje testów w Androidzie. Unit testy, na tym właśnie się skupiamy, gdy robimy jakąś architekturę, bo one są szybkie, są odpalane na JVM, możemy sami sobie je puścić na Jenkinsie, ale to jest coś temat na osobny podcast, czyli Continuous Integration. Druga kwestia czyli UY testy, które są odpalane już wtedy z Frameworkiem Androida. Czyli na przykład jakieś automatyczne przechodzenie przez ekran wydaje mi się, że na początek może bardziej skupić się na Unit testach. UY testy tak, powinno się je pisać, jeżeli mamy, 3 godziny to warto te dwie i pół godziny poświęcić na Unit testy, a na przykład 30 minut na UY testy, bo wydaje mi się że Unit testy koniec końców dają nam o wiele więcej i dzięki temu będziemy potrafili lepiej zrozumieć naszą architekturę i dlaczego ją stworzyliśmy, w taki sposób a nie inny, jak ją można udoskonalić.

 

Dobrze, świetnie to jeżeli mamy już aplikację, testy napisane, to pewnie warto byłoby ją opublikować co musimy wiedzieć, albo jakie zagadnienia musimy opanować, żeby ujrzeć swoją aplikację w Google Play?

Dla Google Play jest mnóstwo dokumentacji, tutoriali – jak wrzucić aplikację na sklep czy udostępnić ją innym

To jest dość proste. Dla Google Play jest mnóstwo dokumentacji, mnóstwo tutoriali, jak tą aplikację wrzucić na sklep, jak ją udostępnić innym. Opłata związana z Google Play jest jednorazowa, nie pamiętam ile wynosi, chyba około 100 $, więc to jest coś, z czym musimy się liczyć, ale warto. Warto mieć swoją aplikację opublikowaną, to na pewno daje dużo jeśli chodzi o postrzeganie nas, jako kandydatów do jakiejś pracy. To o czym powinniśmy pamiętać, no to gdy tworzymy jakiś projekt i chcemy go już wypuścić, warto zabezpieczyć ten projekt przez coś czymś co nazywamy obfuskacją, czyli odwrotną kompilacją z naszego kodu. Czyli po prostu warto zabezpieczyć przed tym, żeby ktoś sprawdził co dokładnie mamy w tym kodzie, jak dokładnie używaliśmy różnych klas, co możemy tym ukrywać, jak ta osoba która sprawdza naszą aplikację może użyć tego do złych rzeczy. Dlatego jest coś co nazywa się Progard. Służy do obfuskacji kodu, to jest proces, który nam zaciemnia kod. Wyobraźcie sobie że mamy klasę main activity która, ma w sobie metodę “do something” I nie chcę żeby to “do something” było widoczne dla kogoś, kto potrafi w kilka minut zdekompilować naszą aplikację, więc to co robi progard, to zamienia nam main activity na “a”, zamienia na literkę „a” po prostu, a naszą funkcję “do something” na literkę “b”. I trzyma gdzieś tamten mapping, ale koniec końców nie jest potrzebny do tego, żeby ta aplikacja funkcjonowała dobrze. Oczywiście takie wartości na przykład, jakieś stringi – tego nam nie zamieni na literki a i b, bo to jest coś co na przykład wyświetlamy, ale nazwy klas, to wszystko jest coś, co jest dla nas ludzi ważne jak odczytujemy kod, ale dla maszyny to nie ma znaczenia. I to robi Progard, zaciemnia nam to, utrudnia komuś, kto odwrotnie chce skompilować, po prostu zobaczyć co jest w naszej aplikacji i wykorzystać to do złych rzeczy. Pomaga, pomaga Progard bardzo. Na sam koniec myślę że też fajnie byłoby się zainteresować Dagger 2 to jest coś związane z dependency injection zostawiłem to na sam koniec i tak właśnie przy tej kwestii realisów dlatego, że wiadomo jak wyrealisujemy aplikacje, często, przynajmniej ja tak miałem, że parę dni po tym miałem ochotę coś bardzo z refactorować. Miałem wrażenie, zrobiłem złą robotę w tym i w tym module. Warto sprawdzić sobie jak Dependency Injection, szczególnie jeżeli korzystamy z Daggera 2, to może nam pomóc, to jest oczywiście w połączeniu z testami, w połączeniu z architekturą, to wszystko łączy się w bardzo fajny plus Dagger 2 jest bardzo często częścią rozmów kwalifikacyjnych i mały tip dla ludzi, którzy chcieliby na przykład napisać swoją aplikację z całym takim systemem rejestracji, systemem logowania. Nie trzeba znać backendu, jest coś co nazywa się Fire base. Fire Base to jest Backend Service, co oznacza że w graficzny sposób możemy sobie stworzyć, dzięki Fire basowi taki backend tak naprawdę. Czyli możemy sobie stworzyć jakąś bazę danych, czyli nasz serwer, gdzie będziemy trzymać dane o użytkownikach. Możemy sobie stworzyć tam sposoby logowania, to wszystko po prostu wyklikujemy i łączymy z naszą aplikacją. Powiem wam, że na przykład Broadly, czyli ta moja aplikacja, która ma 3000 chyba użytkowników, to nie jest dużo, ale ciągle utrzymuje się to wszystko na Fire base. Czyli ja nie zakodziłem ani jednej linijki na backendzie, nie znam [00:58:11 niesłyszalny fragment] aż tak dobrze żeby tworzyć backend, po prostu stworzyłem to i wyklikałem samodzielnie, więc to są takie protipy, co robić żeby stworzyć jakąś fajną aplikację. Jak stworzyć aplikację, która właśnie bazuje na Dependency Injection, jak ją ulepszać po wyrealesowaniu. Sam release, bardzo prosty moim zdaniem tylko trzeba trochę zapłacić za dostęp.

 

Fajnie dzięki za te porady. Dobra, Mateusz to tak powoli już zmierzając ku końcowi, zbliża się przełom roku. Myślę, że możemy się trochę pobawić we wróżenie, w którym kierunku według ciebie będzie się ta branża rozwijała? myślę tutaj zarówno od strony technologicznej jak i powiedzmy rynku pracy?

 

To jest ciężkie pytanie, ja nie lubię tak za bardzo spekulować, ale może powiem ci czym ja jestem bardzo zainteresowany, co byłoby dla mnie dość ciekawe. Wydaje mi się, że możemy nieuchronnie zmierzać w kierunku między platformowości, to znaczy React Native zyskuje popularność. Oczywiście myślę, że nigdy nie zastąpi to w 100% takiego natywnego podejścia do aplikacji. Szczególnie że React Native nie jest czymś stworzonym przez Google, które utrzymuje Androida, ale jest jedna rzecz która mnie bardzo interesuje w kontekście w tej Cross platformowości – jest to Flater. Flater to jest Framework stworzony przez Google. Flater to jest framework, który pozwala stworzyć kod jeden raz i duplikować go na iOS i na Androida. I to jest bardzo ciekawe, bo zyskuje na popularności. Wiele rzeczy jest tam ogarnianych w dość fajny sposób, zarówno pod kątem dostępu do natywnych rzeczy na Androidzie jak i jak i samego performansu, który jest dość ważny i był zawsze dużym problemem w przypadku Cross platformowych rozwiązań, więc ja osobiście może przez JavaScript, którego nie do końca przepadam za React Nativem, ale bardzo obserwuję to co się dzieje i bardzo liczę na to, że kiedyś faktycznie stanie się to bardziej.

 

Fajnie Mateusz, bardzo ci dziękuję za rzeczową rozmowę myślał że tą road mapę, którą nakreśliłeś, to będzie co pozwoli Junior Deweloperom, osobom, które dopiero myślą o wejściu do branży i właśnie zostaniem Junior Android Developerem, że to będzie bardzo pomocny materiał, zwłaszcza na ten najbliższy teraz czas, na najbliższy rok, pewnie jeszcze ten rok, bo jeszcze parę tygodni tego roku przed nami. No i co z mojej strony jeszcze raz wielkie dzięki i powiedz gdzie cię można znaleźć w internecie.

 

Przede wszystkim można mnie znaleźć na moim blogu codersbible.com, gdzie pomagam młodszym programistom, udzielam się na wielu grupach na Facebooku, staram się troszeczkę uchylić szerzej te wrota do branży IT. Wspominałem tu o kilku artykułach, które mogą pomóc komuś kto uczy się na Androidzie, czyli na przykład reaktywnego programowania, które potrafi być to programowanie dość ciężkie, wstęp do reaktywnego programowania, który ja napisałem jest takie dość milutkie bym powiedział … no i wspominaliśmy o testowaniu. Dlaczego testowanie jest ważne? No nie tylko to żeby przetestować jakąś prostą logikę, wymieniłem kilka rzeczy na dość fajnym przykładzie, jak to u mnie działało, więc te dwa artykuły są dostępne u mnie na blogu, więc zapraszam na niego – Coders Bible

 

Oczywiście link znajdzie się w notatce z do tego odcinka. Jeszcze raz wielkie dzięki Mateusz do usłyszenia.

 

Dzięki, cześć. I to na tyle, z tego co przygotowałem dla ciebie na dzisiaj. Na rynku pracy widać coraz większe zainteresowanie i potrzebę zatrudnienia Android Deweloperów. Cieszę się, że Mateusz nakreślił road mapę, według której można podążać, żeby zostać Android Deweloperem. To jest ostatni odcinek w 2019 roku. Dziękuję za ten rok i obiecuję, że w 2020 też będzie dużo dobrego ode mnie do posłuchania. Jeśli spodobał ci się ten odcinek, podeślij go komuś, kto zaczyna swoją przygodę z Androidami. Myślę, że może wiele z niego wyciągnąć. Dziękuję. 

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl, ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT,  o tym jak, zostać Android deweloperem. Zapraszam do kolejnego odcinka już za dwa tygodnie.

mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.