Jak zostać Android developerem

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ę – 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 Javy… Kotlin 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 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.

Programowanie urządzeń mobilnych. Debugowanie kodu natywnego Java. cz. 9

W poprzedniej części kursu omówiliśmy sposób debugowania aplikacji tworzonych w Cordovie. Pokazaliśmy jak analizować kod JavaScript, HTML i CSS oraz ruch sieciowy, a więc wszystko to, co przeciętny twórca aplikacji Cordovy buduje samodzielnie. Zademonstrowane dotąd narzędzia umożliwiają wgląd w aktualnie wykonywany kod aplikacji i podgląd zmiennych, ale niestety nie rozwiązują wszystkich problemów, z jakimi borykają się programiści korzystający z Cordovy. Nierzadko okazuje się, że problem z błędnym działaniem aplikacji leży w bibliotekach i pluginach Cordovy, stworzonych w natywnym języku danej platformy sprzętowo-programowej. W artykule opisujemy, jak rozwiązywać tego typu trudności poprzez debugowanie Javy - języka natywnego dla platformy Android.

Jak i w poprzednich częściach kursu, koncentrujemy się na Androidzie, przy czym w tym przypadku cała treść artykuły praktycznie nie będzie miała jakiegokolwiek zastosowania do innych systemów operacyjnych. Można by się też zastanowić, jaki sens ma opisywanie debugowania w języku Java, którego czytelnicy mogą wcale nie znać, bo przecież kurs dotyczy Cordovy, a więc skupia się na zupełnie odmiennym JavaScripcie.

W praktyce jednak umiejętność rozpoznania problemu, czy choćby wskazania jego źródła jest bardzo cenna. Narzędzia do debugowania aplikacji androidowych nie są proste w użyciu, ale można za ich pomocą wiele osiągnąć nawet bez znajomości języka Java.

Pozwalają monitorować stan urządzenia mobilnego znacznie "głębiej" niż narzędzia opisane w poprzedniej części kursu, wykrywać procesy zużywające zbyt dużo zasobów, a przede wszystkim określać, które pluginy, w którym momencie powodują problemy.

Szczególnie to ostatnie ma duże znaczenie dla osób piszących programy Cordovy, gdyż w przypadku niepoprawnej pracy urządzenia, pozwala dosyć dokładnie ocenić, w jakich warunkach zachodzi problem i zdecydować o ewentualnej zamianie używanej wtyczki Cordovy na inną. Oczywiście narzędzia do debugowania stanowią też niezbędną pomoc dla wszystkich, którzy chcą samodzielnie tworzyć pluginy Cordovy, ale o tym napiszemy w innej części kursu.

Android Device Monitor

Rysunek 1. Android Device Monitor

Podstawowym narzędziem, jakie będziemy używali w niniejszej części kursu jest Android Device Monitor (rysunek 1) - oprogramowanie instalowane wraz z Android Studio. Jest to środowisko wykonane w oparciu o platformę Eclipse, dzięki czemu jest dosyć przenośne.

Co więcej, moduły używane w Android Device Monitorze mogą być wykorzystywane bezpośrednio w Eclipse, co będzie pomocne dla tych osób, które programują z użyciem tego IDE (Zintegrowanego Środowiska Deweloperskiego).

My jednak skoncentrujemy się na samodzielnej aplikacji w wersji 24.3.4, która została zainstalowana wraz z innymi programami opisanymi dotąd w trakcie kursu.

Program startuje się poleceniem monitor, wpisanym np. w polu "uruchom" systemu Windows. Powoduje ono uruchomienie pliku monitor.bat, znajdującego się w katalogu z narzędziami deweloperskimi Androida. Domyślnie jest to ścieżka c:UsersNazwaUżytkownikaAppDataLocalAndroidsdktoolsmonitor.bat. Plik monitor.bat sprawdza dostępność bibliotek Javy i uruchamia program znajdujący się w podkatalogu zależnym od aktualnej architektury systemu - np. dla 64-bitowego systemu Windows.

Rysunek 2. Pasek narzędziowy Android Device Monitor

Android Device Monitor (ADM) składa się z jednego okna, obsługującego kilka perspektyw. Te znane są z Eclipse i określają sposób podziału głównego okna programu na moduły, realizujące poszczególne funkcje. Podstawowe perspektywy ADM to DDMS, Debug, Hierarchy View, Pixel Perfect, Resource i Tracer for OpenGL ES. Opiszemy w skrócie większość z nich, przy czym dla osób piszących aplikacje w Cordovie, najważniejsza będzie DDMS.

Zanim to zrobimy, warto jeszcze wspomnieć o ogólnej budowie okna ADM. Główne menu nie obejmuje wielu pozycji. Pozwala jedynie na wprowadzenie ustawień środowiska, uruchomienie zewnętrznych programów lub właśnie wybór i konfiguracje perspektyw.

Lista ustawień środowiska jest bardzo długa i pozwala zmienić przede wszystkim sposób prezentacji informacji, ale też wpływa na interfejsy używane do komunikacji ze sprzętem. Niemniej w praktyce, ustawienia domyślne będą wystarczające.

Główny pasek narzędzi programu (rysunek 2) służy do przełączania perspektyw oraz zawiera przyciski ułatwiające uruchomienie androidowego menedżera SDK i menedżera urządzeń wirtualnych.

DDMS

Rysunek 3. Okno w ADM w perspektywie DDMS

Podstawową perspektywą dla osób chcących debugować aplikacje androidowe jest DDMS, czyli Dalvik Debug Monitor Server. Słowo "Dalvik" to nazwa implementacji maszyny wirtualnej Javy, używanej w Androidzie. Dalvik przetwarza kod bajtowy, powstały przez kompilację kodu napisanego w języku Java.

Natomiast biblioteki Cordovy dla Androida, napisane są właśnie w Javie i pozwalają uruchamiać kod napisany w JavaScripcie - przekierowują wywołania JavaScriptowe do odpowiednich komend i bibliotek Javy. W efekcie, z punktu widzenia maszyny wirtualnej, kod JavaScript, HTML i CSS to zasoby, z których korzysta kod aplikacji napisany w Javie i skompilowany do kodu bajtowego.

Natomiast z punktu widzenia programisty tworzącego z użyciem Cordovy, właściwy kod jest napisany w JavaScripcie i odwołuje się do funkcji bibliotecznych, napisanych w Javie. Warto dodać, że w nowych wersjach Androida, tj. od 5.0 wzwyż, środowisko Dalvik zostało zupełnie zastąpione środowiskiem Android RunTime (ART), które nieco inaczej optymalizuje działanie aplikacji pod kątem konkretnego urządzenia, na którym jest ona instalowana. W praktyce jednak korzysta z tych samych plików kodu bajtowego i narzędzie DDMS może być używane do debugowania programów także na nowszym Androidzie.

Rysunek 4. Lista podłączonych urządzeń i uruchomionych na nich procesów

DDMS przekazuje informacje pomiędzy komputerem, a podłączonym, debugowanym urządzeniem androidowym za pośrednictwem mostu ADB (Android Debug Bridge). Działa zarówno z fizycznymi smartfonami i tabletami, jak i z wirtualnymi.

Ważne by na danym urządzeniu włączone było debugowanie przez USB (co opisywaliśmy w poprzedniej części kursu) oraz by testowana aplikacja była skompilowana w wersji przeznaczonej do debugowania. Nie stanowi to żadnego problemu, gdyż domyślnie kompilowane aplikacje w Cordovie są tworzone właśnie w takim trybie.

DDMS pozwala monitorować stan procesora, pamięci i stertę urządzenia. Umożliwia wykonywanie zrzutów ekranu, logowanie zdarzeń i komunikatów wyświetlanych w konsoli systemowej oraz symulowanie zdarzeń związanych ze stanem połączeń sieciowych, rozmowami przychodzącymi SMSami, pozorowaniem lokalizacji itp.

Widok całego okna DDMS pokazano na rysunku 3. Podstawowym elementem jest zakładka Devices, w której wymienione są podłączone urządzenia androidowe (realne i wirtualne) oraz uruchomione na nich aplikacje, które można debugować (rysunek 4).

Rysunek 5. Pasek narzędzi nad listą urządzeń

Jeśli podłączone urządzenie nie jest widoczne na tej liście, to znaczy, że prawdopodobnie wystąpił problem ze sterownikami. Ich instalację opisaliśmy w poprzedniej części kursu. Jeśli wcześniej wszystko wydawało się działać, ale po jakimś czasie przestało - przydatna okazuje się typowa strategia rozwiązywania problemów przez informatyków: należy zrestartować system, a jeśli to nie pomoże, ponownie przeinstalować sterowniki i podłączyć urządzenia na nowo.

Rysunek 6. Wynik pracy narzędzia wykonującego zrzuty ekranu z podłączonych urządzeń. Zrzuty są w pełnej rozdzielczości, w jakiej pracuje dane urządzenie

Poprawnie podłączone i uruchomione urządzenie będzie miało status "Online" oraz podaną wersję zainstalowanego systemu operacyjnego. W przypadku urządzeń emulowanych podawana jest też nazwa wirtualnego sprzętu.

Każdemu z podłączonych urządzeń przypisana jest lista uruchomionych aplikacji, które można debugować. Warto zauważyć, że w przypadku symulatora, lista aplikacji dostępnych do debugowania jest znacznie większa, gdyż obejmuje także standardowe programy systemu Android.

Obok odwrotnej nazwy domenowej każdej z aplikacji podany jest jej numer procesu PID (Process IDentification) i numer portu, wykorzystywanego do debugowania jej. Numery PID są unikalne w ramach danego urządzenia, a numery portów unikalne w ramach całego debugera. Poza tym w tabeli prezentowane są ikonki, symbolizujące operacje wykonywane przez debuger w związku z danym procesem.

Rysunek 7. Podgląd warstw składających się na wyświetlane okno

Fakt, że każda aplikacja ma oddzielny port wynika ze specyficznego sposobu uruchamiania programów w systemie Android. Każdy proces w Androidzie ma bowiem oddzielną maszynę wirtualną, w której pracuje. Każda maszyna natomiast komunikuje się z użyciem innego portu debugera. W efekcie, numery PID są w rzeczywistości numerami procesów maszyn wirtualnych, ale nie ma to większego znaczenia.

W momencie, gdy DDMS jest uruchamiane, łączy się ono z modułem Android Debug Bridge, który pozwala na komunikację z systemem Android. ADB to narzędzie tekstowe, które można obsługiwać i wywoływać ręcznie z linii poleceń. Wystarczy skorzystać z polecenia - znajduje się ono w podkatalogu platform- tools katalogu z narzędziami deweloperskimi Androida.

Jednakże samodzielne, ręczne używanie tej komendy zdecydowanie wykracza poza zakres tego kursu i raczej nie będzie potrzebne osobom tworzącym aplikacje Cordovy. Znacznie wygodniej jest używać graficznego interfejsu DDMS, który po uruchomieniu odpytuje poprzez ADB o numery PID poszczególnych procesów (ich maszyn wirtualnych) na danym urządzeniu i przypisuje im kolejne numery portów, przez które będzie się komunikować.

Podstawowe operacje

Rysunek 8. Narzędzie do zapisywania do pliku informacji o zdarzeniach w ramach aplikacji, zgodnie z ustawionymi filtrami

Nad listą urządzeń i uruchomionych na nich procesów znajduje się belka z przyciskami, przedstawiona na rysunku 5. Niektóre z wywoływanych przez nie poleceń są jednorazowe, a niektóre służą umożliwieniu wyświetlenia informacji w dalej opisywanych elementach DDMS.

Pierwszy z przycisków o kształcie żuka będzie zapewne wyszarzony, gdyż pozwala on na skakanie do odpowiednich miejsc kodu, gdy ten został skompilowany i uruchomiony bezpośrednio ze zintegrowanego środowiska deweloperskiego.

Jeśli ktoś tworzy aplikacje Cordovy z użyciem Eclipse i z odpowiednimi ustawieniami, wtedy będzie mógł skorzystać z tej opcji. Jednakże w przeciwnym wypadku jest ona niedostępna. Kolejne dwa przyciski pomagają zarządzać pamięcią.

Rysunek 9. Narzędzie do śledzenia akcji OpenGL

Pierwszy służy do włączenia śledzenia sterty pamięci danej aplikacji. Drugi (ten z czerwoną strzałką) umożliwia zapis profilu sterty do pliku. Trzeci - kosz - uruchamia mechanizm czyszczenia pamięci po nieużywanych obiektach (Garbage Collector).

Następne dwa przyciski służą kontroli wątków wykonywanych w ramach wybranej aplikacji. Pierwszy włącza monitorowanie wątków, a drugi umożliwia dokładne śledzenie czasu ich wykonywania. Obie te funkcje zostały opisane w dalszej części artykułu.

Przycisk "Stop Process" pozwala natychmiast zakończyć aplikację. Przycisk "Screen Capture" pozwala pobrać zrzut aktualnego ekranu z urządzenia mobilnego i zapisać go (rysunek 6). Przycisk "Dump View Hierarchy for UI Automator" pozwala natomiast analizować elementy interfejsu graficznego (rysunek 7).

Z punktu widzenia programisty tworzącego w Cordovie jest on jednak znacznie mniej przydatny niż w aplikacjach pisanych w natywnym języku. Cała wyświetlana treść jest traktowana jako jedno okno i nie można wnikać w jej szczegóły, jak to było przy debugowaniu kodu HTML, opisywanego w poprzedniej części kursu.

Rysunek 10. Lista akcji OpenGL, śledzona klatka po klatce

Widok ten jest przydatny w aplikacjach Cordovy tylko wtedy, gdy program nie zajmuje całego ekranu, na przykład, gdy na jego górze znajduje się pasek stanu. Wtedy w widoku hierarchii da się rozróżnić te dwa elementy. Ponadto widok pokazuje listę parametrów okna, a w tym m.in. jego rozmiary.

Przycisk "Capture system wide trace using android systrace" pozwala zebrać przez określony czas wszystkie informacje o zdarzeniach zachodzących w urządzeniu mobilnym lub w wybranej aplikacji i zapisać je do pliku (rysunek 8) - można też szczegółowo określić opcje śledzenia. Komenda Start OpenGL Trace (rysunek 9) umożliwia natomiast śledzenie wywołań graficznych OpenGL i przeglądanie zdarzeń z nimi związanych klatka po klatce (rysunek 10).

W końcu, pod strzałką, w rozwijanym menu, oprócz wcześniej wymienionych opcji znajduje się też przycisk resetowania Android Debug Bridge. Powoduje ona rozłączenie wszystkich dotychczasowych połączeń debugera i załadowanie oraz przypisanie im portów na nowo.

Nowości w Cordovie Od czasu powstania 8 części niniejszego kursu wprowadzono kolejne zmiany w platformie Cordova. Przede wszystkim aktualna wersja platformy Cordova i jej bibliotek to 6.0.0. Korzysta ona z modułu plugman 1.1.0 i cordova-js 4.1.3. Podstawowe zmiany obejmują zwiększenie domyślnych wersji bibliotek poszczególnych platform sprzętowych: cordova-android do wersji 5,

cordova-ios do wersji 4,

cordova-windows do wersji 4.3. Platforma cordova-ios w wersji 4.0 wspiera iOS9 i WKWebView oraz wprowadza wiele usprawnień w zakresie wyświetlania stron w internetowych, konfiguracji ikon i ekranu startowego, natomiast opcjonalna i niedawno wprowadzona wersja 5.1 platformy cordova-android obsługuje Androida 6.x.x, czyli Marshmallow. W Cordovie 6.0.0. wprowadzono nową funkcję tworzenia projektów w oparciu o szablony pobierane np. z Internetu (opcja --template). Wycofano natomiast wsparcie dla starego rejestru wtyczek Cordovy - obecnie obsługiwane są tylko te w zasobach npm, git lub ze ścieżek lokalnych. Wprowadzono też ustawienie, sprawiające że domyślnie w trakcie pobierania standardowych wtyczek platforma będzie sięgać po te wersje, które były jej przypisane w trakcie jej utworzenia, nawet jeśli dostępne będą już nowsze aktualizacje. Pobranie nowszej wersji wtyczki będzie wymagało ręcznego wyboru ze strony użytkownika. Wersje platform i wtyczek, przypisanych do Cordovy 6.0.0 są następujące: Cordova Amazon-FireOS: 3.6.3

Cordova Android: 5.1.0

Cordova BlackBerry10: 3.8.0

Cordova Browser: 4.0.0

Cordova FirefoxOS: 3.6.3

Cordova iOS: 4.0.1

Cordova OSX: 4.0.0

Cordova Ubuntu: 4.3.2

Cordova Windows: 4.3.0

Cordova WebOS: 3.7.0

Cordova WP8: 3.8.2

cordova-plugin-battery-status: 1.1.1

cordova-plugin-camera: 2.1.0

cordova-plugin-console: 1.0.2

cordova-plugin-contacts: 2.0.1

cordova-plugin-device: 1.1.1

cordova-plugin-device-motion: 1.2.0

cordova-plugin-device-orientation: 1.0.2

cordova-plugin-dialogs: 1.2.0

cordova-plugin-file: 4.1.0

cordova-plugin-file-transfer: 1.5.0

cordova-plugin-geolocation: 2.1.0

cordova-plugin-globalization: 1.0.2

cordova-plugin-inappbrowser: 1.2.0

cordova-plugin-legacy-whitelist: 1.1.1

cordova-plugin-media: 2.1.0

cordova-plugin-media-capture: 1.2.0

cordova-plugin-network-information: 1.2.0

cordova-plugin-splashscreen: 3.1.0

cordova-plugin-statusbar: 2.1.0

cordova-plugin-test-framework: 1.1.1

cordova-plugin-vibration: 2.1.0

cordova-plugin-whitelist: 1.2.1 Niektóre z tych wtyczek zostały zaktualizowane, by korzystać z nowości w platformie cordova-android 5.1.0, które pozwalają uniknąć błędów, jakie dotąd powstawały, gdy system operacyjny, w celu uwolnienia zasobów, czyścił pamięć i m.in. usuwał oczekujące wywołania zwrotne funkcji. Platforma cordova-windows 4.3 wspiera niektóre nowe metody wywoływania i logowania operacji, a platforma cordova-ubuntu 4.3.2 zawiera jedynie drobne aktualizacje. Wprowadzono też komunikat o zbliżającym się wycofaniu wsparcia dla platform amazon-fireos i wp8. Ma to nastąpić za ok. 6 miesięcy i zaleca się korzystanie zamiast nich z platform Android i Windows. Warto dodać, że cordova-ios w wersji 4.0.0. i 4.0.1 (a więc w opcjonalnej aktualizacji) pozwala na kompilację na urządzenia z systemem nie starszym niż iOS 8.0.

Podgląd wątków

Rysunek 11. Podgląd wątków w aplikacji

Każdy proces może mieć wiele wątków. Każdy wątek w DDMS ma dwa identyfikatory - jeden unikalny w ramach danej aplikacji (ID), a jeden unikalny w ramach całego urządzenia (Tid). Numer pierwszego, podstawowego wątku (main) pokrywa się z numerem PID uruchomionej aplikacji.

Podany jest też stan wątku, jego nazwa oraz czas wykorzystania procesora, podzielony na dwie kategorie: utime i stime (rysunek 11). Pierwsza z nich, utime, obejmuje czas procesora użyty do wykonywania kodu użytkownika. Drugi - stime, to czas, który dany wątek wykorzystał na żądania usług systemowych.

Obie wartości są podane w jednostkach "jiffie", których dokładna długość zależna jest od ustawień systemowych, ale zazwyczaj odpowiada 10 ms. Wątki o identyfikatorach (ID) z gwiazdką to demony systemu Linux, a więc programy działające w tle, trochę tak jak usługi w Windows.

Natomiast stan wątku może przybierać jedną z wartości podanych w tabeli 1. Należy przy tym zaznaczyć, że wątki zakończone są usuwane z listy. Natomiast nazwy wątków mogą być pomocne w określeniu tego, za którą operację odpowiadają. Wywołania zewnętrznych funkcji urządzenia mobilnego, wykonywane z poziomu Cordovy często są uruchamiane asynchronicznie z nazwą AsyncTask lub Thread-.

Warto też orientować się, że wątek GC odpowiada mechanizmowi czyszczenia pamięci po niepotrzebnych obiektach (Garbage Collector), a wątek JDWP (Java Debug Wire Protocol) służy do komunikacji z ADB, a więc i DDMS.

Zaznaczając wybrany wątek z listy otrzymujemy podgląd aktualnych ścieżek wywołania dla niego. Na rysunku 11 zaznaczono wątek odpowiadający wywołaniu skanera kodów QR, użytego w przykładzie aplikacji domofonu, opisanego w jednej z poprzednich części tego kursu.

Jeśli nie mamy pewności, który wątek odpowiada za interesujące nas zadanie, możemy przeglądać listy wywołania w poszukiwaniu rozpoznawalnych nazw bibliotek, które mogą być powiązane z używanymi wtyczkami Cordovy. Warto klikać przycisk "refresh", gdyż aktualne ścieżki wywołania stale się zmieniają dla wielu wątków.

Profilowanie wątków

Rysunek 12. Wynik śledzenia wykonywanych wątków w czasie

Jeśli problem z aplikacją leży w jej wydajności, można sięgnąć po narzędzie do profilowania, dostępne w DDMS. Uruchamia się je i zatrzymuje ręcznie, po czym prezentowany jest raport. Dostępne są dwa tryby monitorowania wykonania wątków: zgrubny, w którym debuger co jakiś czas odpytuje procesor o to, które wątki są uruchomione oraz dokładny, który ciągle monitoruje wykonanie programu w oparciu o wywołania i zakończenia poszczególnych metod.

Pierwszy tryb jest mniej obciążający procesor - można określić częstość odpytywań z dokładnością do jednej mikrosekundy (domyślna wartość to 1000 mikrosekund). Drugi, zdecydowanie bardziej ogranicza procesor i wydaje się, że wygodniejsze jest korzystanie z pierwszego trybu.

Gotowe raporty otwierają się w nowych zakładkach i składają z dwóch segmentów: wykresu określającego przebieg wykonywania wątków w czasie oraz tabelarycznego podsumowania czasu poświęconego na poszczególne wątki (rysunek 12).

Tabela 1. Dopuszczalne stany wątków w aplikacji androidowej w DDMS

Po raporcie można nawigować myszką, wnikając w szczegóły. Najechanie kursorem na dany wątek na wykresie informuje, co dokładnie było wykonywane w danej chwili - podawany jest numer wątku wywołanego w ramach danego wątku, jego ścieżka wywołania oraz informacje o wykorzystanym czasie.

Ponieważ wykres prezentowany jest z dokładnością do mikrosekund, można go powiększać poprzez zaznaczenie interesującego nas obszaru. Powrót do pełnej skali wymaga podwójnego kliknięcia lewym przyciskiem myszy w górnej części wykresu. Pojedyncze kliknięcie w obszarze wątków rozwinie natomiast listę wywołań danego wątku w tabelce poniżej wykresu.

W tabeli, dla czytelności, poszczególne wątki są oznaczane różnymi kolorami - kolory te nie mają większego znaczenia (jedynie czasem istotne są powiązania pomiędzy wątkami o tym samym kolorze). w Hierarchicznej postaci prezentowane jest, co wywołało dany wątek (Parents) i co dany wątek wywołał sam (Children) kliknięcie na dowolny wątek w ramach tych kategorii błyskawicznie przenosi nas do fragmentu tabeli z podglądem szczegółów dla właśnie niego. Przykładowo, wybierając dowolny wątek z listy i klikając zawsze na wątek z kategorii Parents, dotrzemy do wątku zerowego (toplevel).

Podane w tabeli czasy są zapisane w mikrosekundach oraz w procentach, a także zostały podzielone na cztery kategorie: czas łączny procesora, czas wyłączny procesora oraz czas łączny rzeczywisty i czas wyłączny rzeczywisty.

Czasy wyłączne obejmuje tylko te okresy, gdy funkcje faktycznie działa i wykonuje operacje, podczas gdy czasy łączne, zawierają też okresy, w których wątek ma przestój - nakazano mu czekać na wykonanie innej funkcji. Czasy rzeczywiste różnią się od czasu procesora tym, że obejmują również czas potrzebny na urządzenia wejścia i wyjścia, na które procesor musi czekać.

W efekcie, wątek 0 (toplevel), choć zajmuje bardzo dużo czasu łącznego procesora, właściwie wcale nie zajmuje procesora na wyłączność (czas na wyłączność wątku 0 widać praktycznie tylko przy bardzo dokładnym profilowaniu, np. z użyciem drugiego z wymienionych wcześniej trybów).

Warto też ewentualnie zwrócić uwagę na prawą stronę tabeli, gdzie znajduje się liczba wywołań funkcji oraz czas procesora i czas rzeczywisty, w przeliczeniu na pojedyncze wywołanie. Pozwalają one lepiej ocenić czas potrzebny na jeden przebieg konkretnej funkcji.

GPX i KML Formaty GPX i KML służą do przechowywania tras i ścieżek opartych o koordynaty geograficzne, pozyskiwane najczęściej z użyciem nawigacji satelitarnej - głównie GPS, a ostatnio także GLONASS. Format GPX (GPS Exchange Format) obejmuje schematy XML, w których ramach zapisywane są ścieżki, trasy i pojedyncze punkty na ziemi. Typowo dane zawierają informacje o długości i szerokości geograficznej, a także o wysokości nad poziomem morza i o czasie. Pliki te można wygenerować ręcznie, z użyciem oprogramowania lub za pomocą urządzeń do nawigacji - np. jako zarejestrowana, przebyta trasa. Format KML (Keyhole Markup Language) również obejmuje schematy XML. Pierwotnie został opracowany przez firmę Keyhole, twórcę programu, który obecnie (wraz z firmą) należy do Google i nazywa się Google Earth. Format KML zawiera różnego rodzaju obiekty, które można prezentować na dwu- i trójwymiarowych mapach. Przykładowo, można w nim zapisać punkty orientacyjne, wraz z ich nazwami, koordynatami i opisami. Istnieją konwertery przetwarzające pliki pomiędzy obydwoma formatami. Jednym z nich, dostępnym online jest

Monitorowanie sterty pamięci

Rysunek 13. Analiza zajętości sterty pamięci

Jeśli aplikacja wiesza się z czasem, bardzo możliwe, że następują jakieś wycieki pamięci. Da się wykryć ich istnienie poprzez monitorowanie sterty (kopca) pamięci. Informacje na ten temat zawiera zakładka "Heap", po włączeniu aktualizacji danych sterty.

Dane aktualizowane są za każdym razem, gdy uruchamiany jest mechanizm czyszczenia niepotrzebnych obiektów z pamięci (Garbage Collector), przy czym dzieje się to dosyć nieregularnie, więc w zakładce poświęconej stercie umieszczono też przycisk wymuszający włączenie GC (Cause GC).

W zakładce "Heap" można dowiedzieć się, jaki jest łączny rozmiar pamięci, zarezerwowanej dla aplikacji, ile z tej pamięci jest aktualnie w użyciu, a ile wolnej, jaki to procent całej zarezerwowanej oraz ile obiektów składa się na tę zajętą przestrzeń.

Poniżej prezentowany jest widok szczegółowy, w którym pokazane są rodzaje obiektów, takie jak klasy i tablice zawierające pola o różnych wielkościach. Dla każdej z kategorii wyświetlona jest liczba elementów danego typu, łączna zajmowana przestrzeń oraz statystyki: najmniejsza wielkość obiektu, największa, mediana i wartość średnia.

Rysunek 14. Śledzenie alokacji pamięci

Wybranie dowolnego z wierszy w tej tabeli powoduje wyświetlenie histogramu poszczególnych obiektów danego typu, a więc liczby zaalokowanych obiektów o konkretnym rozmiarze. Zademonstrowano to na rysunku 13.

Zajmowaną pamięć można też dokładniej obserwować dzięki mechanizmowi śledzenia alokacji. W tym celu używa się zakładki "Allocation Tracker". Na jej górze znajdują się dwa przyciski. Pierwszy włącza i wyłącza monitorowanie, a przycisk "Get Allocations" pozwala na pobranie aktualnej listy alokacji, w trakcie, gdy śledzenie jest włączone.

Ponieważ zajmowanie pamięci dla nowych obiektów odbywa się praktycznie non stop, powstała tabela z listą operacji tego typu już po chwili staje się ogromna. Na szczęście można ją sortować, a przede wszystkim filtrować.

Pozycje w tabeli obejmują numer porządkowy alokacji, wielkość zarezerwowanej pamięci, rodzaj alokowanego obiektu (np. liczba typu int, albo wskazanie miejsca definicji klasy obiektu), numer wątku odpowiedzialnego za alokację oraz klasę i funkcję, w której alokacja została dokonana. Kliknięcie na pozycję w tej tabeli spowoduje wyświetlenie ścieżki wywołania danej funkcji. Pokazano to na rysunku 14.

Monitorowanie komunikacji

Rysunek 15. Podgląd ruchu sieciowego w urządzeniu

Kolejnym elementem udostępnianym przez DDMS jest monitorowanie komunikacji z urządzeniem. W przypadku emulatorów możliwości jest więcej niż dla realnych urządzeń. Prawdziwy telefon pozwala na podgląd ilości danych przesyłanych przez sieć - służy temu zakładka "Network Statistics".

Zawiera ona wykres oraz tabelkę. Na wykresie prezentowana jest wykorzystywana przepustowość wysyłanych i pobieranych danych w czasie. Wykres może być odświeżany z różną częstością (co 100, 250 lub 500 ms), a proces ten zaczyna się od momentu wciśnięcia przycisku "Start".

Przycisk "Reset" pozwala wyczyścić aktualnie zebrane dane i przez to zzerować statystyki zebrane w tabeli poniżej. Tabela wskazuje liczby danych przesłanych i odebranych, liczone w bajtach i w pakietach (rysunek 15).

Rysunek 16. Narzędzie do sterowania emulatorem, umożliwiające symulowanie różnych warunków dostępu do sieci komórkowej, połączenia i wiadomości przychodzące oraz wskazania nawigacji satelitarnej

Znacznie ciekawsze możliwości oferuje zakładka "Emulator Control", która umożliwia symulowanie zjawisk zewnętrznych, dotyczących telefonu (rysunek 16). Przede wszystkim możliwe jest zmienienie stanu dostępności sieci dla połączeń głosowych i danych. Dostępne opcje to:

Unregistered, gdy telefon nie połączył się z żadną siecią, ponieważ np. nie ma włożonej karty SIM.

Home, gdy telefon jest połączony z siecią macierzystą.

Roaming, gdy telefon jest połączony z siecią inną, niż macierzysta (przypisana do włożonej karty SIM).

Searching, gdy telefon poszukuje sieci.

Denied, gdy dostęp do sieci jest zablokowany.

Można też określić szybkość połączenia. Dostępne opcje to: Full, GSM, HSCSD, GPRS, EDGE, UMTS i HSDPA. Lista wyboru opóźnień w transmisji zawiera pozycje: None, GPRS, EDGE i UMTS.

Poniżej znajduje się narzędzie do symulowania połączenia przychodzącego lub wiadomości. Wystarczy wpisać numer telefonu nadawcy i - jeśli ma to być wiadomość SMS - wpisać jej treść oraz nacisnąć przycisk wywołania. Efekt został przedstawiony na rysunkach 17 i 18.

Rysunek 17. Widok wiadomości wysłanej z zakładki "Emulator Control" do emulowanego urządzenia mobilnego Rysunek 18. Symulowane połączenie przychodzące

Przy budowie aplikacji, w której system korzysta z danych GPS można je symulować wpisując ręcznie w dziale Location Controls. Dostępne są dwie formy zapisu (dziesiętna oraz w postaci stopni, minut i sekund). Alternatywnie dane odnośnie lokalizacji albo ich szeregu można wprowadzić z plików GPX lub KML (patrz ramka o GPX i KML). Dzięki temu można odtworzyć raz zaprogramowaną ścieżkę, a nawet zmieniać szybkość poruszania się po niej.

Podglądanie zasobów

Rysunek 19. Dostęp do systemu plików urządzenia mobilnego

DDMS obejmuje jeszcze dwie interesujące zakładki. Jedna z nich to "File Explorer", który pozwala na wniknięcie w strukturę katalogową urządzenia mobilnego (rysunek 19). Jest to bardzo przydatne, gdy tworzona aplikacja zapisuje dane do pamięci trwałej lub gdy z nich korzysta.

"File Explorer" pozwala na przeglądanie drzewa katalogów systemu plików, podając nazwy, ścieżki, rozmiary, prawa dostępu i informacje o aliasach oraz uprawnieniach poszczególnych plików i katalogów. Można w trakcie pracy aplikacji stworzyć nowy katalog, usunąć plik, pobrać plik z urządzenia mobilnego na dysk komputera oraz przesłać plik z komputera w konkretne miejsce systemu plików urządzenia mobilnego.

Drugą zakładką jest "System Information", która wskazuje podział zasobów pomiędzy poszczególne procesy oraz zagospodarowanie pamięci urządzenia mobilnego.

Rysunek 20. Wykres kołowy obciążenia procesora w ostatnim czasie Rysunek 21. Wykres kołowy aktualnej zajętości pamięci

Wybierając z listy pozycję CPU load i klikając "Update from Device" otrzymujemy wykres kołowy wskazujący, które procesy w ostatnim czasie zużywały jaką część czasu procesora (rysunek 20). Najechanie na fragmenty wykresu pozwala poznać szczegółowe dane. Na rysunku 21 pokazano natomiast jak wyglądają informacje na temat podziału pamięci.

Podgląd logów

Rysunek 22. Okno narzędzia LogCat

Bardzo przydatnym narzędziem, również dla twórców programujących w Cordovie jest LogCat. Pozwala on przeglądać informacje o zdarzeniach zachodzących w urządzeniu i filtrować je na różne sposoby. Filtrowanie ma tu ogromne znaczenie, gdyż liczba zdarzeń, jakie są rejestrowane w każdej sekundzie pracy telefonu jest bardzo duża.

Okno LogCat domyślnie znajduje się na dole ekranu i jest raczej nieduże (rysunek 22). Jego główną część zajmuje tabelka z logami. Kolejne kolumny zawierają informacje o:

poziomie ważności danego wpisu,

czasie zarejestrowania wpisu,

identyfikatorze procesu, który dane zdarzenie wywołał,

identyfikatorze wątku bezpośrednio generującego wpis,

nazwie aplikacji, która spowodowała uruchomienie danego procesu i wątku,

tag, pozwalający grupować wpisy na różne sposoby,

treść logu.

Rysunek 23. Deklarowanie filtru narzędzia LogCat

Poszczególnym poziomom ważności odpowiadają różne kolory. Poziomy te to: assert, error, warn, info, debug i verbose. Wybranie ostatniego z nich, a więc najniższego sprawi, że wyświetlane będą komunikaty wszystkich poziomów. Każdy wyższy poziom sprawia, że komunikaty z niższego poziomu nie są pokazywane.

Czytelność logów znacząco utrudnia fakt, że urządzenie, zarówno emulator, jak i prawdziwy telefon, ciągle generują logi nawet na poziomie error. Błędy te praktycznie nie zależą od tworzonej aplikacji i należy je pomijać. Problemem jest, że przeszkadzają w znajdowaniu istotnych informacji szczególnie, że bufor rejestrowanych komunikatów nie jest nieskończony i szybko się przepełnia, powodując usunięcie starszych wpisów, gdy pojawiają się nowe. Dlatego warto korzystać z filtrów.

W praktyce, w przypadku deweloperów tworzących aplikacje Cordovy, warto stworzyć sobie filtr, który będzie pokazywał tylko komunikaty pochodzące z programu o interesującej nas nazwie. Posługiwanie się numerem procesu lub wątku nie sprawdza się, gdyż nierzadko wywoływane zewnętrzne biblioteki obsługiwane są przez inne wątki i nie wyświetlą się. A to właśnie w nich najczęściej pojawiają się problemy, wymagające skorzystania z narzędzia debugującego.

Filtry można dodawać na żywo, poprzez wpisanie odpowiednich poszukiwanych fragmentów (z ew. prefiksami) w górnej części okna LogCat lub za pomocą lewego fragmentu okna, który pozwala zapisać raz wprowadzony filtr. To chyba najwygodniejsze rozwiązanie (rysunek 23). Warto też skorzystać ze znajdującego się na skrajnej, prawej stronie okna LogCat przycisku strzałki, który blokuje ciągłe przewijanie widoku logów.

Dobrym sposobem na wykorzystanie LogCata jest umieszczanie w kodzie własnych poleceń wysyłania komunikatów do konsoli systemowej. Można to robić za pomocą poleceń JavaScriptowych console.log(), console. error(), console.info() i console. debug(), co powoduje wysłanie komunikatu o zadanym poziomie ważności. Co więcej domyślnie wysyłane z JavaScriptu w aplikacji Cordovy logi mają swój specyficzny tag, który zależy od wersji systemu, na której są uruchomione. To ułatwia ich odnajdywanie w rejestrze logów.

Tabela 2. Opcje programisty w systemie Android 4.4 w telefonie Samsung Galaxy S4

Umiejętne posługiwanie się poleceniami takimi jak console.log() i LogCatem pozwoli wykryć momenty, w których coś nie działa tak, jak powinno nawet, gdy wina leży po stronie wtyczki Cordovy. Bardziej doświadczony programista może nawet być w stanie samodzielnie naprawić błąd, bez znajomości języka Java - niekiedy komunikaty błędów z wtyczek wyraźnie wskazują, że problem leży w składni, która przykładowo nie jest już kompatybilna z daną wersją systemu operacyjnego.

Wtedy to wystarczy pozmieniać kilka rzeczy w kodzie wtyczki i ponownie skompilować aplikację, usuwając w ten sposób zewnętrzny błąd. Jeśli taki zabieg przekracza umiejętności twórcy aplikacji, może on poszukać alternatywnej wtyczki, która nie będzie podatna na specyficzny przypadek testowy, jaki występuje w danym programie.

Konsola debugera

Pozostałe okna Android Device Monitora nie mają większego znaczenia dla programisty tworzącego aplikacje Cordovy. Czasem tylko, gdy pojawi się jakiś problem z działaniem narzędzia, można zajrzeć do okna konsoli systemowej, które zawiera różne komunikaty - najczęściej informacje o błędach dotyczących działania poszczególnych modułów ADM. Jeden z przycisków w oknie konsoli umożliwia przełączanie się pomiędzy informacjami pochodzącymi z poszczególnych modułów, np. z DDMS lub OpenGL Trace View.

Opcje debugowania w telefonie

Podczas debugowania dowolnego rodzaju aplikacji androidowej pomocne mogą być możliwości zaszyte w ramach Opcji Programisty, w ustawieniach systemowych urządzenia. Wiele z nich pozwala na diagnozowanie aplikacji bez udziału zewnętrznego debugera.

W poprzedniej części kursu obiecaliśmy, że je opiszemy. Ich polskie i angielskie nazwy oraz krótkie opisy zostały podane w tabeli 2. Nazwy i zestaw opcji mogą się nieco od siebie różnić dla urządzeń mobilnych z innymi wersjami systemów i produkowanych przez różnych producentów.

Rysunek 24. Opcja „Zgłoszenie błędu” dodana dzięki Opcjom Programisty w ustawieniach telefonu Rysunek 25. Podgląd zarejestrowanego ruchu dotyku na urządzeniu mobilnym. Widać zarejestrowane ścieżki, a na górnym pasku pokazane jest m.in., że w aktualnej chwili 0 z wcześniej wykrytych 2 punktów dotyku jest obecnych

Z punktu widzenia twórcy aplikacji mobilnej w oparciu o Cordovę, wartościowa będzie tylko część opcji. Jedną z nich jest funkcja rejestrowania pakietów wysyłanych przez interfejs Bluetooth (Log Bluetooth HCI snoop). Przydatne może być też pozorowane położenie, dzięki któremu na prawdziwym telefonie można symulować ruch w przestrzeni, a nie tylko na emulatorze, jak to pokazano w niniejszej części kursu.

Bardzo pomocnymi narzędziami są mechanizmy pokazywania dotknięć, a szczególnie śledzenia wskaźnika (rysunek 25). Po włączeniu tej funkcji, oprócz śladów dotknięć na ekranie, na górnym wąskim pasku pojawia się informacja m.in. o aktualnej liczbie wykrywanych punktów, zarejestrowanym przesunięciu, a nawet o rozmiarze wykrywanych punktów dotyku.

Ważne są też funkcje z grupy Debugowanie, która pozwala m.in. zautoryzować narzędzia do debugowania czy wybrać aplikację, która ma być poddawana testowaniu i uniemożliwić jej uruchomienie, do momentu włączenia debugera.

Rysunek 26. Podgląd obciążenia procesora różnymi wątkami, wyświetlany na ekranie urządzenia, w trakcie działania aplikacji Rysunek 27. Podgląd elementów interfejsu, wyświetlany bezpośrednio na urządzeniu mobilnym

Szacowanie wpływu stworzonej przez nas aplikacji, np. w trakcie działania w tle można ocenić korzystając z funkcji wyświetlania zużycia procesora przez poszczególne wątki (rysunek 26). Pozwala to łatwo stwierdzić, czy nie zużywamy zbyt wielu zasobów systemowych.

Inną ciekawą i użyteczną, choć nieco mniej przydatną opcją dla twórców aplikacji w Cordovie jest Pokazywanie granic układu, które wskazuje jaką przestrzeń zajmują poszczególne elementy, składające się na całość wyświetlanej treści (rysunek 27).

Podsumowanie

Ta i poprzednia część kursu powinny wystarczyć do przygotowania dopracowanej i zoptymalizowanej aplikacji androidowej, pozbawionej błędów. A skoro tak, to gotową aplikacją można się już podzielić - np. poprzez wprowadzenie jej do dystrybucji w ramach któregoś ze sklepów z aplikacjami.

Jeśli program ma być oferowany darmowo albo promowany w Internecie, można też rozważyć instalacje modułów do obsługi reklam lub do integracji z serwisami społecznościowymi. W końcu nierzadko warto też wprowadzić obsługę map lub powiadomień typu PUSH, wysyłanych za pośrednictwem twórców danego systemu operacyjnego. Te i inne zagadnienia będą tematem kolejnych części kursu programowania aplikacji mobilnych dla elektroników.

Marcin Karbowniczek, EP

W jakim języku jest napisany Android?

Udostępnij

Facebook

Twitter

Adres e-mail

Kliknij, aby skopiować link

Udostępnij link

Link skopiowany

Android

System operacyjny

W jakim języku jest napisany kod źródłowy Androida?

Oficjalnym językiem programowania dla Androida jest Java. Duże części Androida są napisane w Javie, a jego interfejsy API są zaprojektowane tak, aby były wywoływane głównie z Javy. Możliwe jest tworzenie aplikacji w językach C i C++ przy użyciu zestawu Android Native Development Kit (NDK), jednak nie jest to coś, co promuje Google.

W jakim języku jest napisane Google?

Python

C

C + +

Czy Android jest napisany w C?

Ponieważ Android OS jest oparty na jądrze linux, które jest napisane głównie w C. OS musi komunikować się ze sprzętem i prawie wszystkie sterowniki są napisane w C/C++, dlatego OS musiał być napisany w tym. I aplikacje napisane w JAVA, bo po prostu był sławny i łatwiejszy niż C++ (to ostatnie jest moją osobistą opinią).

Który język jest najlepszy do tworzenia aplikacji na Androida?

Najlepsze języki programowania do tworzenia aplikacji na Androida

Java — Java jest oficjalnym językiem programowania dla Androida i jest obsługiwana przez Android Studio.

Kotlin – Kotlin to ostatnio wprowadzony język Androida i drugi oficjalny język Java; jest podobny do Javy, ale pod wieloma względami jest trochę łatwiejszy do opanowania.

Czy Android jest własnością Google?

Android to mobilny system operacyjny opracowany przez Google. Aplikacje te są licencjonowane przez producentów urządzeń z Androidem certyfikowanych zgodnie ze standardami narzuconymi przez Google, ale AOSP został wykorzystany jako podstawa konkurencyjnych ekosystemów Androida, takich jak Fire OS które wykorzystują własne odpowiedniki GMS.

Kto wynalazł Androida?

Andy Rubin

Bogaty górnik

Nick przypala

W jakim języku jest napisane Whatsapp?

Erlang

W jakim języku jest napisany Windows?

Mac OS X: Cocoa głównie w Objective-C. Kernel napisany w C, niektóre części w asemblerze. Windows: C, C++, C#. Niektóre części w asemblerze. Mac OS X używa dużych ilości C++ w niektórych bibliotekach, ale nie jest to ujawniane, ponieważ obawiają się złamania ABI.

Co jest kodowane w YouTube?

Języki programowania używane w najpopularniejszych serwisach

Strony Popularność (unikatowi użytkownicy miesięcznie) Back-end (po stronie serwera) 1,100,000,000 Hack, PHP (HHVM), Python, C++, Java, Erlang, D, XHP, Haskell 1,100,000,000 C, C++, Python, Java, Go Yahoo 750,000,000 PHP 500,000,000 Java, C++, Perl

10 więcej rzędów

Jaka jest najnowsza wersja Androida 2018?

Nougat traci swoją pozycję (ostatni)

Nazwa Androida Wersja Androida Udostępnij KitKat 4.4 7.8% Jelly Bean 4.1.x, 4.2.x, 4.3.x 3.2% Ice Cream Sandwich 4.0.3, 4.0.4 0.3% piernik 2.3.3 do 2.3.7 0.3%

4 więcej rzędów

Czy kotlin jest lepszy niż Java?

Aplikacje na Androida można pisać w dowolnym języku i uruchamiać na wirtualnej maszynie Java (JVM). Kotlin jest jednym z takich języków programowania zgodnych z JVM, który kompiluje się do kodu bajtowego Java i naprawdę przyciągnął uwagę społeczności Androida. Kotlin został stworzony, aby być lepszym od Javy pod każdym możliwym względem.

Czy możesz używać C++ do tworzenia aplikacji na Androida?

Teraz C++ można skompilować do docelowego systemu Android i tworzyć aplikacje natywnego systemu Android. Visual Studio zawiera szybki emulator Androida wraz z Android Development Kits (SDK, NDK) oraz Apache Ant i Oracle Java JDK, więc nie musisz przełączać się na inną platformę, aby korzystać z narzędzi zewnętrznych.

W jakim języku jest napisany Facebook?

Stos technologiczny Facebooka składa się z aplikacji napisanych w wielu językach, w tym PHP, C, C++, Erlang i innych. W tym momencie Twitter działa głównie na Scali (choć z dodanym Ruby on Rails) (cytat). Facebook działa głównie w PHP, ale używa również trochę C++, Java, Python i Erlang na zapleczu (cytat).

Czego powinienem się nauczyć przy tworzeniu aplikacji na Androida?

Oto krótka lista narzędzi, które musisz znać, aby zostać programistą Androida.

Jawa. Najbardziej podstawowym budulcem rozwoju Androida jest język programowania Java. SQL. Android Software Development Kit (SDK) i Android Studio. xml. Wytrwałość. Współpraca. Pragnienie wiedzy.

Jakiego języka programowania powinienem się nauczyć podczas tworzenia aplikacji?

Python to język programowania, którego uczy się w szkołach na poziomie uczelni, ponieważ ma zastosowanie do wielu aplikacji. Python jest językiem bardzo łatwym do nauczenia, a także łatwym do odczytania. Za pomocą Pythona można stworzyć dowolny rodzaj aplikacji. Python jest tym, co najlepsze firmy zajmujące się tworzeniem aplikacji wykorzystują do tworzenia aplikacji na Androida i komputery stacjonarne.

Czy Samsung jest własnością Google?

Według Neila Mawstona z Strategy Analytics, Samsung osiągnął prawie 95 procent wszystkich zysków z Androida w pierwszym kwartale 2013 roku. Pozyskał 5.1 miliarda dolarów, pozostawiając tylko 200 milionów dolarów dla LG, Motoroli (która, nie zapominajmy, jest własnością Google) , HTC, Sony, Huawei, ZTE i kilka innych do walki.

Czy Android i Google to to samo?

Google i Android to nie to samo i to jest dobra rzecz. Android i Google mogą wydawać się synonimami, ale w rzeczywistości są zupełnie inne. Projekt Android Open Source Project (AOSP) to stworzony przez Google stos oprogramowania typu open source dla dowolnego urządzenia, od smartfonów po tablety i urządzenia do noszenia.

Czy telefon Google działa na Androidzie?

Dostajesz telefon wyprodukowany przez Google, aby uruchomić własny system operacyjny Google, Android. Google używa chipów, które znajdziesz również w innych topowych telefonach z Androidem. Mimo to, jeśli chcesz korzystać z Androida tak, jak zamierzał Google, podobnie jak Apple sprawia, że ​​używasz iOS tak, jak zamierza to Apple, najlepszym rozwiązaniem jest Pixel 3 lub Pixel 3XL.

Czy Google jest właścicielem Samsunga?

Jest całkiem możliwe, że w 2013 roku Galaxy S4 wypchnie Samsunga o ponad połowę całej sprzedaży Androida. Niebezpieczeństwo polega na tym, że ciągły rozwój Androida przez Google stanie się przedsiębiorstwem nastawionym na wspieranie Samsunga, prawdopodobnie ze szkodą dla innych producentów OEM dla Androida – w tym własnego oddziału Google Motorola.

Dlaczego Android jest najpopularniejszym systemem operacyjnym?

Android wyprzedził teraz system Windows, stając się najpopularniejszym systemem operacyjnym na świecie, zgodnie z danymi Statcounter. Patrząc na łączne użycie na komputerach stacjonarnych, laptopach, tabletach i smartfonach, użycie Androida osiągnęło 37.93%, nieznacznie wyprzedzając Windows 37.91%.

Ile jest rodzajów telefonów z Androidem?

W tym roku OpenSignal naliczył ponad 24,000 2012 unikalnych urządzeń z Androidem – zarówno smartfonów, jak i tabletów – na których została zainstalowana jego aplikacja. To sześć razy więcej niż w XNUMX roku.

Kto jest teraz właścicielem Microsoftu?

Kto kupił Microsoft od Billa Gatesa? Były dyrektor generalny Steve Ballmer posiada więcej akcji niż Gates, chociaż nie kupił od niego firmy. Rzeczywiście, Gate nadal posiada miliony akcji firmy, choć w 2014 roku sprzedał ich 4.6 miliona – co dało mu 330 milionów akcji, o trzy miliony mniej niż Ballmer.

W jakim języku jest napisane C?

Większość z nich jest zaimplementowana przy użyciu samego C lub w różnych innych językach programowania z różnymi komponentami napisanymi również w asemblerze, na przykład. Kompilator GNU GCC był wcześniej zaimplementowany w samym C. Od 2012 roku C++ (ISO/IEC C++03) jest oficjalnym językiem implementacji GCC.

W jakim języku jest napisany Macos?

C + +

Objective-C

Szybki

Kto kodował Whatsapp?

Założyciel WhatsApp wysyła użytkownikom Facebooka zaszyfrowaną wiadomość, gdy rezygnują. Na początku 2009 roku dwóch byłych pracowników Yahoo, Brian Acton i Jan Koum, zasiadło, aby spróbować stworzyć aplikację do przesyłania wiadomości na smartfony. Mieli kilka prostych zasad projektowania.

W jakim języku programowania napisany jest YouTube?

Youtube jest napisany w Pythonie, C, C++, Javie i Go ze względu na jego działanie zaplecza. Na froncie Youtube wykorzystuje HTML5, aby umożliwić przyjazną interakcję użytkownika z komputerem. Wybór języka programowania musi być najmniejszym zmartwieniem podczas tworzenia YouTube.

Jakiego języka programowania powinienem się najpierw nauczyć?

Większość programistów zgodziłaby się, że języki skryptowe wysokiego poziomu są stosunkowo łatwe do nauczenia. JavaScript należy do tej kategorii, wraz z Pythonem i Ruby. Mimo że uniwersytety nadal uczą języków takich jak Java i C++ jako pierwszych języków, są one znacznie trudniejsze do nauczenia.

Jaki jest najlepszy system operacyjny Android dla tabletów?

Wśród najlepszych urządzeń z Androidem są Samsung Galaxy Tab A 10.1 i Huawei MediaPad M3. Osoby poszukujące modelu bardzo zorientowanego na konsumenta powinny rozważyć tablet Barnes & Noble NOOK 7″.

Które telefony dostaną Androida P?

Telefony Xiaomi, które mają otrzymać Androida 9.0 Pie:

Xiaomi Redmi Note 5 (przewidywany Q1 2019)

Xiaomi Redmi S2/Y2 (przewidywany Q1 2019)

Xiaomi Mi Mix 2 (przewidywany Q2 2019)

Xiaomi Mi 6 (przewidywany Q2 2019)

Xiaomi Mi Note 3 (przewidywany Q2 2019)

Xiaomi Mi 9 Explorer (w fazie rozwoju)

Xiaomi Mi 6X (w fazie rozwoju)

Jaka jest najnowsza wersja Androida 2018?

Nazwy kodowe

Nazwa kodowa Numer wersji Pierwsza data wydania Oreo 8.0 - 8.1 21 sierpnia 2017 r. Ciasto 9.0 6 sierpnia 2018 r. Android Q 10.0 Legenda: Stara wersja Starsza wersja, nadal obsługiwana Najnowsza wersja Najnowsza wersja zapoznawcza

14 więcej rzędów

Czy kotlin zastępuje Javę?

Dlaczego Kotlin zastąpi Javę do tworzenia aplikacji na Androida. W Google I/O '17 w końcu ogłosili, że dla Androida oficjalne wsparcie pierwszej klasy zostanie udzielone Kotlinowi.

Do czego mogę używać Kotlina?

Najsilniej obsługiwanym językiem JVM w ekosystemie Androida — poza Javą — jest Kotlin, otwarty statycznie typowany język, opracowany przez JetBrains. JetBrains stworzył jedno z najpopularniejszych IDE, IntelliJ IDEA, a także Android Studio, które Google ukoronowało jako standardowe IDE dla rozwoju Androida.

Dlaczego powstał kotlin?

Został stworzony przez czeską firmę JetBrains, która produkuje oprogramowanie dla programistów i kierowników projektów. Ale zespół nie zmusił Kotlina do sprzedaży. Udało im się rozwiązać własne problemy rozwojowe.

Jaka jest różnica między Android NDK a SDK?

NDK używa natywnych języków kodu, takich jak c i c++. Używanie natywnego kodu w Androidzie nie zwiększa wydajności, ale zwiększa złożoność. Dlatego większość aplikacji nie wymaga ndk do rozwoju. SDK jest napisany przy użyciu języka programowania java i działa na maszynie wirtualnej Dalvik.

W jakim języku są napisane aplikacje na Androida?

Jawa

Jarosław Kułak
Jarosław Kułak

Leave a Comment