To jest 5. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem będę  rozmawiał o programowaniu aplikacji mobilnych na platformę Android. Z tego odcinka dowiesz się:

* Z jakich języków i narzędzi korzysta się w programowaniu na Androida?

* Jak takie aplikacje się testuje a następnie deploy’uje?

* A także czy trudno zostać developerem Androida i jakie wyzwania przed Tobą staną, jeśli się na to zdecydujesz?

Witam Cię serdecznie w Porozmawiajmy o IT. Ja się nazywam Krzysztof Kempiński i w tym podcaście rozmawiam z moim współprowadzącym Jackiem Norbertem i moimi gośćmi o branży informatycznej, przedstawiam trendy, zjawiska i opinie. Staram się przybliżyć tę branżę tym, których w niej na co dzień nie ma, jak również zaciekawić stałych bywalców. Pozostań z nami.

A teraz zapraszam już na kolejny odcinek.

Krzysztof: Dzień dobry! Cześć! Witam Was w kolejnym odcinku podcastu Porozmawiajmy o IT. Moim i Waszym gościem jest dzisiaj Paweł Urban, z którym porozmawiamy o programowaniu aplikacji mobilnych na platformę Android. Cześć Paweł! Bardzo mi miło, że zgodziłeś się wystąpić w podcaście.

Paweł: Witaj! Cześć!

Krzysztof: Paweł jest Android Developerem z wieloletnim doświadczeniem. Programistą, trenerem języków Java i Kotlin. Pracował również z innymi technologiami po stronie frontendowej i backendu. Prowadzi swój blog na Medium, występuje w podcastach. Na co dzień jest Team Developerem we wrocławskiej firmie Objectivity, gdzie zajmuje się głównie aplikacjami na Androida. Współtworzy również aplikację nDriver dedykowaną dla spedytorów i kierowców. Od niedawna dumny tata. Paweł, to może zaczniemy od zupełnych podstaw. Jak byś mógł krótko powiedzieć, czym jest Android i jaka jest jego historia?

Paweł: Android jest systemem operacyjnym na urządzenia mobilne. Głównie opiera się na jądrze Linuxa, więc generalnie wszystkie te mechanizmy obowiązujące w tych systemach tam również można spotkać jak dostępy per użytkownik, per grupa, aczkolwiek z naszej perspektywy jako użytkowników czy developerów, raczej jest to schowane. Silnie też korzysta z dobrodziejstwa Java, bo oni tam zaimplementowali własną wersję JVM’a dla developerów na potrzeby platformy uruchomieniowej dla aplikacji. W tej chwili jest to najpopularniejszy system operacyjny, jeżeli chodzi o urządzenia mobilne i właściwie jedyna alternatywa dla IOS. Pozostałe systemy stanowią jakiś tam margines. Kiedyś był Symbian, ale on, że tak powiem, umarł śmiercią naturalną. Podobnie się stało z Windows Phonem, więc w tej chwili te dwie formy okupują rynek. Początkowo był on tworzony przez  małą firmę w stanach, ona też nazywała się Android. Android Inc., dokładnie. W pewnym momencie Google ją wykupiło i system ten rozwijało sobie dalej. W 2008 oni zaprezentowali pierwsze urządzenia, Google zaprezentował swoje prototypy, natomiast w 2009 wyszedł już pierwszy telefon taki dostępny dla wszystkich, był to HTC Dream. W Polsce znany Era G1, sam go posiadałem, był bardzo fajny, miał taki wysuwany wyświetlacz i pełną klawiaturę QWERTY pod spodem. Było to super do pisania smsów. W tamtym czasie, bo Internet jeszcze nie był tak powszechny. Jeżeli chodzi też o sam Android, to on teoretycznie jest open source’owy. Jest taki projekt IOSP, czyli Android Open Source Project. Tak czy inaczej, w większości przypadków producenci urządzeń muszą uzyskiwać zgody Google na wydanie własnego systemu, z tego względu, że Google do używania ichniejszych usług ich aplikacji jak np. właśnie sklep Play, czy YouTube, czy ta wyszukiwarka, ta aplikacja Googla wymaga jakiejś tam swojej certyfikacji, a siłą rzeczy wszystkie te rzeczy z perspektywy użytkowników, przynajmniej zdecydowanej większości są bardzo ważne, więc tak czy inaczej, pomimo tej otwartości systemu, Google musi certyfikować taki proces wydawania własnego systemy. Było parę tam przełomowych momentów w Androidzie. Z takich ostatnich chyba w 2015 jak wyszedł Android 6, to trochę zaczęli gonić IOS’a i wprowadzili uprawnienia dla aplikacji o które ona pyta już w trakcie uruchomienia, a nie, że jako użytkownik zgadzam się na wszystkie uprawnienia w momencie instalacji, bo tak naprawdę większość ludzi wcale tego nie czytała i wiadomo zgadzali się na ślepo na takie rzeczy jak np. dostęp do kontaktów czy sms’ów. Tak mniej więcej w dużym skrócie przedstawia się historia Androida i to czym on jest.

Krzysztof: Właśnie kilka razy wspomniałeś o Google jako takiej największej firmie, która stoi za Androidem, ale Google w kontekście Androida pewnie najbardziej kojarzy się z całym systemem operacyjnym. Natomiast przeciętnemu zjadaczowi chleba Android gdzieś tam też kojarzy się z telefonami na których system działa i jestem ciekaw, czy jeszcze jakieś inne firmy w kontekście nie tylko oprogramowania, ale również hardwaru stoją mocno za Androidem?

Paweł: Generalnie, jeżeli chodzi o Androida i jakieś firmy, powiedzmy takie z czołówki, które mogą się kojarzyć z samym systemem operacyjnym, oczywiście poza Google, który jest odpowiedzialny za sam system i w sumie też ekosystem, który urósł dokoła tego wszystkiego, myślę, że tak zaczynając od najważniejszych rzeczy, czyli samych urządzeń, samych telefonów, osobiście mam wrażenie i gdzieś tam chyba jest to też podparte statystykami, że Samsung tak naprawdę ma największy udział w rynku, jeżeli chodzi o sprzedaż telefonów związanych z Androidem. O ile wiem, to mocno też się trzyma Motorola czy LG, Huawei też ostatnio dosyć moim zdaniem dobre telefony wypuszcza, więc to bym powiedział tyle, jeżeli chodzi o producentów. Natomiast, jeżeli chodzi o takie podzespoły to o ile wiem, to Qualcomm chyba, jeżeli chodzi o producenta procesorów tutaj też wiedzie prym. Samsung, nie jestem tego do końca pewien, ale chyba też wypuszcza własne chipy, i to mogłoby być jakieś odstępstwo. Tak naprawdę większość tych wszystkich urządzeń działa gdzieś tam na procesorach warki czy armsu jakieś tam pojedyncze przypadki. Wiem, że w tabletach to się zdarzało nawet częściej, gdzie oparte było o architekturę procesora intelowską, więc tam też jakiś udział można przepisać Intelowi w tym, że ich procesory były stosowane w urządzeniach mobilnych.

Krzysztof: Właśnie, jest tych kilku producentów telefonów, kilku producentów rozwiązań hardware’owych. W związku z czym należy przypuszczać, że bardzo wiele jest też odmian wersji telefonów, na których działa Android i tutaj zastanawiam się, czy znasz jakieś statystyki jak duży jest ten rozrzut, ten rozstrzał telefonów jako urządzeń, na których działa Android?

Łukasz: Dokładnych statystyk nie znam, ale myślę, że każdy kto gdzieś tam, albo chociaż śledzi rynek tych telefonów czy się tym interesuje tak z perspektywy użytkownika, nie tyle nawet developera, już o developerach nie wspominając, to generalnie z producentów i tych modeli wypuszczanych jest naprawdę bez liku. Ciężko się w tym połapać, biorąc też pod uwagę jakieś historyczne, jakieś dawniejsze urządzenia, nie tylko te topowe czy wydane w tym czy tam w zeszłym roku, to jest tego naprawdę dużo, one się różnią takimi rzeczami jak np. komplet czynników, które posiadają, oczywiście nie wspominając o podstawowych parametrach jak taktowanie procesora czy tam ilość rdzeni, ilość pamięci RAM, obsługę karty SD, czy to właśnie jaki procesor, wielkość ekranu. Generalnie jest mnóstwo czynników, które gdzieś tam te urządzenia rozróżniają i to nam developerom, może nie wszystkie te rzeczy, ale na pewno większość potrafi niestety napsuć krwi. Szczególnie chodzi tu o rozmiar i tak naprawdę gęstość też pikseli na ekranie. To gdzieś tam są główne czynniki, które potrafią przysporzyć bólu głowy, jeżeli chodzi o Androida i projektowanie jakieś tam interfejsów użytkownika. Tutaj rozstrzał jest naprawdę spory. Nie znam dokładnie liczby czy rzędu wielkości, ale obstawiałbym kilka, może nawet kilkadziesiąt tysięcy tak różnych urządzeń, na których może to chodzić i też trzeba pamiętać o takim rynku jak np. Chiny, gdzie bywają tam jakieś urządzenia, których my w Europie nie spotkamy, ale u nich wiadomo jak to tam jest, niekoniecznie z prawem autorskim powiedzmy są zgodni czy tam przestrzegają, więc pojawia się mnóstwo podróbek opartych na Androidzie i jest jakaś tam szansa wiadomo, że nasza aplikacja akurat będzie na takim telefonie uruchomiona. Aczkolwiek raczej się tego nie bierze pod uwagę, ale przy jakichś tam większych aplikacjach może się tak zdarzyć.

Krzysztof: Od problemów developerów związanych z tą wręcz nieprzewidywalnością konfiguracji, to chciałbym może przejść za chwilkę, a teraz chciałbym z tobą porozmawiać o temacie języka programowania, bo Android jest troszeczkę nietypowy, nie mamy już do czynienia z jednym językiem programowania, ale wręcz z dwoma, które gdzieś tam prawie że zaczynają być równoprawne. Kiedy ja jakiś czas temu zacząłem się developersko troszkę bawić Androidem, to była właściwie tylko Java, tak jak powiedziałeś na początku i z tego co wiem, to jak gdyby jest ciągle taki główny język, ale mamy do czynienia też z językiem Kotlin, który dosyć mocno tutaj wchodzi nam na rynek, zdobywa popularność i jestem właśnie ciekaw, jakie są twoje doświadczenia albo co masz do powiedzenia o tych dwóch wręcz konkurujących ze sobą językach?

Paweł:  Ogólnie, jeżeli chodzi o te języki, których się używa, to tak naprawdę zależy w jaki poziom szczegółowości wchodzimy, ale tak jak powiedziałeś od samego początku, to była Java. Gdzieś tam tak czy inaczej zetkniemy się z XML, może nie nazwijmy tego pełnoprawnym językiem, natomiast być może nie każdy miał okazje mieć z tym styczność, to też na to się często napotyka. Do tego od zawsze też była możliwość pisania dodatkowego kodu w C czy C++ ze względu być może na wydajność czy jakiś dostęp do nisko poziomowych rzeczy, ale od samego początku można było pisać za pomocą NDK, czyli Native Development Kit, swojego kodu C++, który dało się podłączyć do aplikacji Androidowej. I tak jak powiedziałeś, jakiś czas temu powstał, a na ostatnim Google IO, bodajże to było wtedy, został ogłoszony też oficjalnym językiem Kotlin. To jest język stworzony przez firmę JetBrains, czyli tą firmę, która odpowiada za Intellij, który z kolei jest też podstawą do stworzenia Android Studio. Android Studio, to tak naprawdę jest zmodyfikowany Intellij. Język Kotlin generalnie opiera się, powiedzmy, że na Java z tego względu, że on też jest kompilowany do takiego samego formatu, jak Java, czyli do takiego bajtkodu, który jest uruchamiany na tych wirtualnych maszynach Java, ale co on nam wnosi jako developerom? Przede wszystkim jest tam dużo tzw. syntax sugar, czyli jakichś tam cukierków składniowych, które ułatwiają pewne zadania. Dla mnie np. bardzo się podobają data klasy, nie trzeba pisać ręcznie tych metod, bardzo mi się podoba też, nie wiem czy to jest zaczerpnięte z typescriptu czy typescriptu zaciągnął od nich, ale to, że w momencie deklarowania parametrów do konstruktora można od razu uczynić te parametry polami, nie trzeba ich dodatkowo definiować. Bardzo mi się też podoba tam dodatkowa tak jakby z automatu załatwiona delegacja, czy np. tzw. właśnie delegaty do właściwości, że nie musimy pisać kodu, który odpowiada nam za tzw. leniwe ładowanie, tylko jest to załatwione jakoś tam bardzo prostą, dodatkową klauzulą. To są jakieś tam rzeczy, które w pierwszej kolejności przychodzą mi do głowy, natomiast jest ich dużo więcej, jeżeli chodzi o ułatwianie życia właśnie developerom. Także naprawdę gorąco zachęcam do zapoznania się z tym Kotlinem. Znam nawet osobiście przypadki osób, które były dosyć sceptyczne, ja sam zresztą na początku troszeczkę byłem, ale w momencie jak się zapoznały, spróbowały, zobaczyły, że tak powiem coś więcej i coś poważniejszego dane było im napisać w tym języku, to od razu się przekonały, że to jest naprawdę bardzo fajne rozwiązanie. Jeżeli piszemy kod w odpowiedni sposób, to nie musimy się też martwić takimi rzeczami jak wartości null. To jest jedna z podstawowych rzeczy, którą autorzy chcieli rozwiązać tworząc nowy język, czyli uniknięcie tych bardzo przykrych wyjątków typu null pointer exception, że gdzieś odwołujemy się do czegoś, co na daną chwilę niestety nie istnieje, jest tam po prostu referencja na pusty obiekt, no null.

Krzysztof: Zastanawiam się tutaj, czy to jest podobna rzecz jak w przypadku Apple np. koegzystencja na początku, Objectiv See i Swift’a, ale jednak Apple od początku mówił, że stawia na Swifta, że to będzie raczej przejście w kierunku Swifta i teraz właśnie to się dzieje, czy już wręcz się stało. Zastanawiam się jak to jest w przypadku Androida, czy polityką Googla jest to, żeby utrzymywać te dwa języki jako takie równoprawne, czy to być może jest raczej pierwszy krok, żeby to Kotlin stał się takim jedynym językiem, że tak powiem, codziennie używanym przez developerów? Co o tym myślisz?

Paweł: Tak szczerze powiedziawszy troszkę ciężko mi zgadnąć, co Google ma na myśli. Ja mam wrażenie, że z Java oni jednak prędko nie zejdą, ze względu na to, że Kotlin pomimo, że jest bardzo fajny i generalnie jest już któraś tam stabilna wersja, to jest dosyć młody. Zrzesza ludzi, którzy tą Java znają i być może będą chcieli na ten Android Development się w jakiś sposób przebranżowić, przekonwertować, więc zostanie przy tej Java myślę, że jak najbardziej będzie tu sensowne. Jedyne co mogliby też zrobić, żeby tą Java, jej nie ubić, i to myślę, że po tym będzie widać, czy oni w ogóle w tym kierunku idą, jest nadganianie z kolejnymi wersjami, bo niestety to jest tam jakiś minus tej platformy, że oni niezbyt dobrze nadążają za tym jak Java sama się rozwija i w tym momencie korzystanie z takich ciekawych fitcherów Java 8, tak jakby bez konieczności dodatkowych bibliotek oczywiście, to jest dostępny dopiero gdzieś tam od API 24 bodajże, nie pamiętam, który to jest Android, chyba 7, ale wcześniej niestety mogły być z tym problemy. Składnia jest dostępna, ale nie wszystkie API, takie jak streamy czy typy optional są dostępne. Trzeba do tego zaciągać dodatkowe biblioteki. Natomiast, jeżeli chodzi o Kotlin, ja myślę, że oni będą szli w dość powolnym tempie, w tym kierunku, żeby jednak ten Kotlin pojawiał się co raz więcej i co raz częściej. Mam wrażenie, że to jest kwestia czasu, kiedy on wyprze albo przynajmniej wskoczy na to pierwsze miejsce w preferowanych językach developmentu Androidowego. Tylko mam wrażenie, że ten czas nadejdzie dosyć późno, że to nie jest kwestia roku czy dwóch.

Krzysztof: Ja myślę podobnie. Myślę, że to będzie taka powolna raczej ewolucja niż rewolucja, a myślę sobie, że jest też dużo aplikacji, bibliotek i różnego softu napisanego z wykorzystaniem Java, więc to oczywiście nie może być tak, że nagle Java przestanie być wspierana. Ale skoro już sobie tutaj rozmawiamy o języku programowania, to może przejdźmy płynnie do całego środowiska developerskiego, które jest wykorzystywane na co dzień w pisaniu kodu. Jakie tutaj idee, jakie toole są używane przez programistów do tworzenia kodu?

Paweł: Jeżeli chodzi o takie środowisko developerskie, które nam developerom pozwala w ogóle pracować nad aplikacjami Androidowymi, to taką podstawą już wyłączając z tego na razie idee jakiekolwiek, to jest na pewno Android SDK, czyli zestaw tych wszystkich klas, komponentów, emulator, narzędzia do budowania, które pozwalają nam taką aplikację  w ogóle skompilować z tego kodu Java’owego. W skład tego wchodzi też takie narzędzie jak ADB, którym ja uważam każdy Android Developer mniej lub więcej do czynienia musi mieć i tam jakieś podstawowe jego użycie znać. To jest takie narzędzie z linii poleceń, które ja np. bardzo często używam, ono też jeżelibyśmy konfigurowali kiedyś jakiś swój serwer Continous Integration też się sprawdzi, żeby tam pisać odpowiednie polecenia np. do uruchomienia testów automatycznych na urządzeniu, czy instalacji tej naszej aplikacji, czy pozwala np. dostać się do shella, do powłoki na urządzeniu, żeby tam sobie odpalić jakąś komendę czy pobrać pliki, sprawdzić logi systemowe itd. Do tego od czasu tak naprawdę wprowadzenia Android studio parę lat temu. Takim narzędziem, które warto znać i które będzie nieodzowne dla developera jest Grey Doo. System do budowania, tak bym to nazwał, tożsamy  nawet z Mavenem, mało tego, w zależności pobiera z tych samych źródeł, co Maven, jeśli pozwala sobie ustawić repozytoria, ale działa to na podobnej zasadzie. Wszystkie repozytoria Mavenowe przez Grey dla będą spokojnie obsługiwane. Mało tego tam są pisane skrypty, które definiują nam jak to budowanie aplikacji ma wyglądać, jaka jest jej wersja, czy może jakieś dodatkowe zadania, możemy sobie definiować tzw. bilt warianty, czyli możemy wypuścić aplikację w wersji, załóżmy tam, demo, free and paid, tak pierwszy przykład, który przyszedł mi do głowy. Z takich dodatkowych rzeczy, które nie są dostarczane powiedzmy na start od samego Googla, to może być jakieś opcjonalne kastomowy emulator. Jeżeli komuś nie odpowiada ten zwykły. Tutaj przykładem takiego emulatora może być Jenny Motion, który opiera się tak naprawdę na wirtual boxie. On instaluje obraz Androida na maszynie wirtualnej. Tam podpina jakieś swoje interfejsy, żebyśmy mogli łatwo takie urządzenie udawać. Jeżeli chodzi idee, to tutaj prym wiedzie w tej chwili Android Studio, raczej to się nie zmieni. Kiedyś był to eclipse. Ja raczej słabo wspominam te czasy. Nie za bardzo mi się to podobało, więc bardzo się cieszyłem, w momencie jak ten Android wyszedł i można już było korzystać z tego grejdla, czy to środowisko było bardziej stabilne. Często miałem problemy z jakimiś aktualizacjami wtyczek, pluginów i co najmniej parę razy w przeciągu kwartału musiałem go przeinstalowywać . Też się tak zdarzało. Słyszałem też, że są ludzie, że to jest możliwe, którzy piszą aplikacje Androidową w netbeans, przynajmniej za czasów Eclipsa jeszcze tak było. Nie wiem, jak to wygląda teraz, natomiast widzę, że zdecydowana większość, to jest Android Studio. Tu warto też wiedzieć, że, już o tym wspominałem, ono się opiera na Intelij’u i można pisać również aplikacje Androidowe mając samego Intelij’a. Nie trzeba instalować dodatkowego środowiska w postaci Android Studio, tylko wystarczy doinstalować sobie plugin do Intelij’a, Android Tools i w tym momencie możemy już zacząć pracę nad aplikacją. pierwszą naszą. Krzysztof: Tak, Eclipse to jest kobyła zdecydowanie, ale zastanawiam się jakie są różnice w stosunku do IOS, X Code, zwłaszcza w kontekście emulacji, bo tutaj można powiedzieć, że Apple ma łatwiej. Ma ograniczony zestaw kombinacji, że tak powiem IOS i sprzętu, więc na pewno łatwiej to emulować. A jak to jest właśnie w przypadku Androida? Czy te emulatory pozwalają na pewne dobranie tej konferencji sprzętowej, którą chcesz uregulować, czy to jest raczej wybór z pewnych, gotowych już prekonfigurowanych, że tak powiem zestaw?

Paweł: Symulacją na Androidzie, to akurat moim zdaniem jest dosyć ciekawy temat, bo generalnie mamy kilka czy nawet kilkanaście czy kilkadziesiąt dostępnych presetów. One swoje nazwy noszą od urządzeń, najczęściej Googleowskich czyli tych z serii Nexus, więc możemy sobie wybrać np. Nexusa 6, że będzie miał 6 calowy ekran, odpowiednią rozdzielczość, odpowiednią pamięć. Co też myślę, że jest ważne, bo z tego, co ja pamiętam w IOS’ie na symulatorze pamięć dostępna w całym symulatorze była równa pamięci dostępnej na komputerze, który się uruchamiało. Pamiętam to stąd, że kiedyś przy projekcie IOS’owym nie mogłem odtworzyć na symulatorze błędu związanego z brakiem pamięci, bo występował on tam na jakimś starym Ipadzie 2, natomiast na samym urządzeniu to odtwarzane bez problemu. Natomiast w Androidzie jak ustawimy sobie pamięć taką, a nie inną, to ten emulator faktycznie tyle zarezerwuje. Oczywiście poza tymi pre setami, sami mamy możliwość tam ustawienia odpowiednich parametrów, takich właśnie jak pamięć, dyskowa, pamięć RAM, rozdzielczość, gęstość tego ekranu itd., więc akurat ja tu mówię cały czas o tym oficjalnym emulatorze. Udostępniają też oni, co wydaje mi się bardzo fajne, usługi Google Play, w ramach emulatora i to może być o tyle plus, że ostatnio Google bardzo szeroko wychodzi z tymi swoimi usługami z pod flagi Fairebase, czyli wszelakie bazy danych, jakieś tam cloud message, czyli te notyfikacje puszcz, to wszystko da się wtedy bez problemu sprawdzić na emulatorze, czy jak się tam korzysta z tych usług Google Play, to też jest to możliwe do przetestowania. Nie ma jakichś tam problemów i kiedyś to tak było, że niestety te usługi nie były dostępne na emulator i nie dało się aplikacji korzystającej z usług Google przetestować. Trzeba było mieć realne urządzenie. Emulator Androidowy  W ostatnim roku przeszedł jakiś dosyć gruntowny remont, że tak to nazwę i moim zdaniem, jest dużo wydajniejszy. Bo kiedyś to była strasznie ciężka kobyla i mam wrażenie, że właśnie w odpowiedzi na to powstał ten Jenny Motion, ten castomowy emulator, który opierał się na virtual box’ie. Natomiast w tej chwili ja mam wrażenie, że te emulatory działają bardzo sprawnie, bardzo szybko i nie ma tu jakichś większych kłopotów z nimi.

Krzysztof: No to dobrze, to słyszeć, bo, jeżeli chodzi o platformę IOS, to faktycznie dosyć dobrze te symulatory działają, podobnie jak w przypadku Androida, ale tak jak wspomniałeś na początku, zdarzają się od czasu do czasu takie wpadki, że to środowisko jednak nie jest w pełni oddane i nie zawsze da się powtórzyć jakiś błąd, który na sprzęcie występuje. A powiedz, czy do pisania aplikacji na Androida potrzebujemy jakiś specjalny sprzęt albo np. system operacyjny, czy to jest dowolne?

Paweł: Jeżeli chodzi o Androida, to akurat porównując go co nie co do IOS’a, mam wrażenie, że tu jest dużo lepiej, bo właściwie możemy na dowolnym systemie operacyjnym, takie środowisko, czyli ten Android Studio sobie uruchomić. W sensie może to być Windows, może to być Linux, może to być z powodzeniem MacOS. Nie ma z tym problemu, to wszystko tam uruchomimy. Natomiast, jeżeli chodzi o sprzęt, ja bym powiedział tylko, że raczej powinien być dość mocny. W sensie zdarzyło mi się pracować na komputerze, który załóżmy miał tam 4 GB RAM i zwykły dysk talerzowy, nie SSD, to tutaj już potrafił być problem. Moim zdaniem takie optimum, jeżeli ktoś chciałby faktycznie tak poważnie się tym zajmować, to jest minimum 8 GB RAM, jakiś tam dysk SSD, żeby był w miarę szybki, wtedy to odczucie z tej pracy jest takie dosyć fajne, w sensie nic się tam nie przecina, nic się nie zawiesza, da się to w rozsądnym czasie te aplikacje budować, uruchamiać i nie sprawia nam to, jako developerom żadnego problemu. Żadnej frustracji. Dobrze jest też, moim zdaniem, mieć dwa monitory na stanowisku, bo gdzieś tam sam widzę też po sobie, że często gęsto mamy odpalone te IDE i fajnie mieć też obok dostęp do dokumentacji, czy tam do właśnie jakiegoś Stuck Over Flow czy Git Haba, żeby sobie pewne rzeczy móc łatwo wyszukać. Ale to już kwestia preferencji jak kto lubi pracować i oczywiście jakie ma możliwości.

Krzysztof: Powiedzmy, że mamy już tą aplikację naszą napisaną, przechodzimy do etapu testów i jestem ciekawy jak to tutaj wygląda na Androida? Czy mamy jakieś narzędzia do tego, czy jesteśmy zdani na testy na urządzeniach?

Paweł: Jeżeli chodzi o testy takie w trakcie developmentu, to generalnie już o tym wspominałeś. Mamy emulator, czyli możemy tu sobie na nim odpalić, więc na upartego nie potrzebujemy mieć telefonu, aczkolwiek teraz w tych czasach, jeżeli Android stanowi większość w rynku, ktoś chce się tym zajmować, więc najprawdopodobniej taki telefon ma albo przynajmniej ktoś z rodziny, może ktoś w domu też posiada. Myślę, że to nie jest problem gdzieś takie urządzenie zdobyć. Ja nawet preferuję testowanie na urządzeniach, bo to jest jednak telefon na żywo, można to sobie dokładniej sprawdzić, zobaczyć też wielkość elementów, czy to jest czytelne, czy da się trafić pewne elementy, tak to wygląda. Na pewno testy manualne, zarówno my jako developerzy, ja myślę, że to jest bezdyskusyjne, że każdą zmianę czy każdy nowy fitcher zaimplementowany powinien być uruchomiony na telefonie i chociaż jakoś pobieżnie przeklikany. To zależy oczywiście, czy mamy jeszcze testerów takich dedykowanych dostępnych, ale gdzieś tam strasznie nie lubię sytuacji, jak słyszę, że bywają developerzy, którzy piszą kod, nie sprawdzą tego, bo twierdzą, że to do nich nie należy. Niestety Android może i jest fajny, ale jest dużo miejsc, w których można się wyłożyć, to niezależnie od doświadczenia, więc fajnie sobie wszystko, co piszemy zawsze sprawdzać, więc mieć takie urządzenie, uruchomiony emulator pod ręką. Do tego jeszcze poza takimi manualnym testami, one są oczywiście też wykonywane przez Qway’ów, jeżeli pracujemy w jakimś większym projekcie, gdzieś tam w firmie, to mamy do dyspozycji zwykłe testy jednostkowe, tutaj nic, co by wykraczało po klasyczną Java, czyli G Unit lub jakiś Spok, czy tam wiem, że powstają nowe narzędzia do testowania w Kotlinie, tam Spek, chyba jest takie coś, mamy te Mockito do mokowania sobie naszych klas, czy tam Power Mockito, w zależności od potrzeb. Problem może się tylko zdarzyć, jeżeli piszemy testy jednostkowe komponentów, które w jakiś sposób korzystają z klas Androidowych i to nawet tak trywialnych jak, np. taka klasa jak Rekt, czyli reprezentująca nam jakiś prostokąt. Ten dżar, który mamy lokalnie, tą zależność, którą posługuje się Intellij, czy środowisko, to jest po prostu jeden wielki mock. Tam nie ma nic. Tam są tylko definicje i dokumentacja i potrafi się to objawiać np. tym, że pisząc zwykły test w G Unit’cie, uruchamiając go oczywiście lokalnie, bo testy G Unit’owe są uruchamiane na komputerze. Może być taka sytuacja, że tworząc prostokąt załóżmy o wymiarach 5 na 5 w pozycji 1 na 1, on zwróci nam same zera, bo niestety Android jest zdeka zamockowany.  I tu wchodzi takie narzędzie, które się nazywa Robolectric, które, że tak powiem, pozwala na wykorzystywanie tych klas Androidowych, tam jest popisany szereg tzw. shadow’ów, czyli takich cieni, które udają te klasy Androidowe i to pozwala nam na uruchomienie tych testów, mając zachowaną tak jakby tą logikę Androidową, czy tam przynajmniej udawaną tą logikę na komputerze. Nie musimy uruchamiać tych testów na urządzeniu. Te testy uruchamiają się wtedy trochę wolniej, ale w dalszym ciągu nie potrzebujemy urządzenia czy emulatora do uruchomienia takowych testów, więc polecam z takim narzędziem się zapoznać. Do tego mamy oczywiście jeszcze szereg możliwości, jeżeli chodzi o testowanie tzw. funkcjonalne czy testowanie iWaya. Mamy Espresso, to jest framework od Androida, on generalnie ma dostęp do całej aplikacji, kodu aplikacji, tam odwołujemy się do elementów po tekście czy po identyfikatorze i możemy testować sobie w ten sposób interfejs użytkownika. Oczywiście taki test musi być odpalony na emulatorze lub na urządzeniu. Z Espresso trzeba pamiętać tylko o tym, że ono obejmuje tak jakby tylko naszą aplikację, bo jest jeszcze inne narzędzie, które się nazywa Iwaya Automator i ono pozwala, że tak powiem, na wykonywanie tzw. testów black boxowych, czyli mamy dostęp do naszej aplikacji, ale już jakby z perspektywy bardziej użytkownika, ale możemy też w pewien sposób tam gdzieś sobie poza zakres naszej aplikacji troszeczkę wyjść. Mało tego, dla większych i dłuższych projektów, możemy też wykorzystać takie narzędzie jak np. chmury testowe i mamy nasz polski test Droid, mamy coś takiego od AWS, co nazywa się Device Farm i Google właśnie pod szyldem Fairebase oferuje taką usługę jak Test Cloud i te usługi w dużym skrócie polegają na tym, że mamy jakąś tam pulę urządzeń, możemy sobie wybrać różne przeróżne i na nich możemy właśnie uruchamiać te testy interfejsu użytkownika. Wykorzystanie tego jest różne, zarówno jako pojedynczy developer możemy np. na AWS’ie sobie wykupić parę minut, odpalić test np. na jakimś telefonie, którego wiemy, że nie mamy i ciężko będzie nam zdobyć, żeby sprawdzić w jaki sposób coś się psuje albo czy właśnie coś co się wiemy, że się zepsuło, czy to już jest naprawione, albo może np. zaprząc sobie większą pulę urządzeń do cyklicznego uruchamiania testów, żeby np. wyłapywać jakieś regresje w naszych aplikacjach, więc tutaj zastosowań tych chmur testowych też może być wiele.

Krzysztof: Czyli faktycznie mamy bardzo wiele możliwości, żeby testować naszą aplikację pod różnymi względami. A powiedz jeszcze a propos testowania, czy takie testowanie funkcjonalne czy klikanie po interfejsie, to jest coś, co jest czasochłonne i zjada dużo zasobów, czy też można dosyć swobodnie sobie to używać?

Paweł: Mówisz teraz o tych testach automatycznych, Iway’owych, czy o manualnych?

Krzysztof: O testach automatycznych.

Paweł: Z testami automatycznym generalnie, problem czy nie problem, jest taki, że te testy trzeba napisać. Jeszcze jak jednostkowe w miarę, powiedzmy jest na to czas, czy nawet często w ramach implementowania pewnych fitcher’ów się pisze, bo mamy dostęp do kodu, do klas, do metod, więc i tak chcemy je sprawdzić i jakoś to tam pokrywamy tymi testami jednostkowymi. Tak już przy tych testach Iway’owych trzeba się troszeczkę tam napracować. Różne rzeczy tam też mogą nie wypalić. To jest kwestia synchronizacji z pewnymi zdarzeniami, jak np. oczekiwanie na dane, kwestia zamockowania takich zewnętrznych zależności, jak jakieś API na przykład, czy jakieś źródła danych. Wiadomo, testy niekoniecznie dobrze, jeżeli polegają na jakimś zewnętrznym serwisie, chyba, że są to testy integracyjne, więc tu może to stanowić jakieś wyzwanie. Szczerze, to bardzo mało projektów widziałem, które tak silnie korzystają z tego Espresso, czyli Iway Automatora. Ja w tej chwili w takim projekcie w pracy się znajduje, aczkolwiek te testy gdzieś tam kiedyś były napisane przez testerów, powiedzmy z umiejętnościami w obszarze automatyzacji takich testów. W poprzedniej pracy też znałem po prostu gdzieś tam prywatnie osobę, która była takim testerem automatycznym i jej zadaniem, ona tam sobie skakała po projektach, było właśnie dopisywanie tego typu testów do już istniejących aplikacji. Oni implementowali takie własne frameworki do pisania takowych testów czy wręcz te testy realizowali. Natomiast, jeżeli chodzi o developerów, to jeszcze się nie spotkałem, żeby to Espresso czy Iway Automator, najczęściej to jest tak niestety, że ta aplikacja powstaje dla jakichś startupów, czy coś takiego, i nie ma na to czasu, czas goni, LSU z fitcherami i niestety one często gęsto nie powstają, aczkolwiek chciałbym, żeby to wyglądało inaczej, ale rzeczywistość niestety jest jaka jest.

Krzysztof: Czyli tutaj Android nie jest jakoś szczególnie różny od innych platform programistycznych, w sensie każdy wie, że testy pisać trzeba i, że należy i, że to ma sens i się opłaca, ale oczywiście już w praktyce, rzeczywistości okazuje się, że albo nie ma na to czasu albo pieniędzy. Albo wręcz chęci, bo nie zawsze jest to coś łatwego, przyjemnego. Ok, a powiedz jakie są problemy powiedzmy developerów, jeżeli chodzi o programowanie na Androida, plusy i minusy tej developerki, bo na początku wspomnieliśmy, że jest mnogość tych urządzeń, tych konfiguracji, co na pewno nastręcza właśnie niemałych problemów, jeżeli chodzi o obsłużenie tych różnych możliwości, a jest też coś takiego, że przyjęcie nowych wersji Androida też nie jest tutaj na jakimś znaczącym poziomie porównując np. do IOS i wszystko to może się przyczyniać, że developerka, pisanie aplikacji na Androida może mieć pewne, może nastręczać pewnych problemów i tutaj jakbyś mógł powiedzieć o swoich doświadczeniach, jakie są plusy i minusy tworzenia aplikacji na Androida z punktu widzenia programisty?

Paweł: To tak jak już wspomniałeś, sama ta adopcja jest tutaj dosyć problematyczna. Ja może przedstawię to, dzisiaj nawet sprawdzałem statystyki jak to wygląda, jeżeli chodzi o najnowsze relisy, zarówno Androida jak i IOS, to w tej chwili najnowszy IOS 11, który został, pierwsza wersja tej 11 wydana w grudniu 2017 roku, czyli dosłownie 4 miesiące temu, ma adopcje 65%, czyli większość urządzeń. Natomiast najnowszy Android licząc tu wersję 8.0/8.1, który został wydany w sierpniu tamtego roku, czyli to już jest jakieś pół roku mniej więcej, ma tylko 1,1% adopcji, więc tak jak w IOS’ie możemy wspierać obecną i poprzednią wersję, ewentualnie dwie do tyłu i ma to jak najbardziej sens, tak w Androidzie ja np. najczęściej jak zaczynam projekt, to na te minimalne API ustawiam 19, czyli to jest Android 4.4, wtedy mamy jakieś dziewięćdziesiąt, dziewięćdziesiąt parę procent pokrycia urządzeń, czyli jak w tej chwili mamy API 27, to to jest jakieś 8 wersji do tyłu, najnowszą plus osiem wstecz. Niestety tak to wygląda, więc to jest na pewno jeden z minusów. Po drodze oczywiście przez te osiem wersji dużo rzeczy się pozmieniało, bo tam właśnie w szóstce weszły te uprawnienia, które musimy obsłużyć, aczkolwiek na starszych urządzeniach ta obsługa nie będzie w żaden sposób efektywna, bo nie będzie się system wcale o te uprawnienia pytał, bo one domyślnie zostaną zaakceptowane. Weszło też np. nowe API do planowania zadań, tzw. Job Scheduler, który niestety na starszych wersjach nie jest dostępny, na nowych jest, trzeba jakoś sobie z tym radzić, ale, że tak powiem ta kompatybilność wsteczna, to nie jest też nic nowego, to od zawsze było w tym Androidzie. Po prostu osoby, które się decydują na pracę w tej roli muszą zdawać sobie sprawę z tego, że niestety, ale to tak będzie wyglądać i trzeba mieć na uwadze wsparcie dla nowszych, starszych urządzeń, więc też zachęcam, jeżeli ktoś się za to zabiera, to starych telefonów nie wyrzucać, nie sprzedawać, szczególnie, jeżeliby się skasowało za to jakieś tylko grosze, bo nigdy nie wiadomo, kiedy jakieś starsze urządzenie ze starszym systemem nam się przyda do przetestowania chociażby naszej aplikacji.

Krzysztof: A czy to nie jest takie troszkę dołujące, deprymujące dla programisty, że powiedzmy nie może się pobawić nowymi fitcherami z ostatniej wersji systemu operacyjnego, czy nie może wykorzystać tych możliwości, tylko gdzieś tam musi walczyć powiedzmy „z tymi starymi wersjami”? Czy to jest tak, że po prostu trzeba się na to nastawić w przypadku Androida czy jak najlepiej do tego podejść?

Paweł: Tutaj akurat sytuacja wygląda tak, że to też nie do końca jest tak, że wszystko dosłownie w 100% spoczywa na nas, jeżeli chodzi o tą kompatybilność, bo Goolge wypuszcza te biblioteki App Compat, które, jeżeli chodzi np. o właśnie użycie np. fragmentów, bo one też nie były od początku, czy o pewne kontrolki, czy podstawowe takie klasy jak właśnie activity, oni nam już zapewniają powiedzmy wersje, które możemy używać normalnie tak jak w najnowszej wersji, aczkolwiek one wstecz będą zachowywały się po prostu odpowiednio dla danej wersji systemu. Podobnie się tyczy np. z API do powiadomień, do notyfikacji i tam bardzo dużo, bardzo często się zmienia. Generalnie ciężko byłoby np. wprowadzić grupy powiadomień, które w tej chwili już są, w starszych Androidach, bo tam tego nie było, więc ta biblioteka App Compat po prostu, jeżeli używa się tego ichniejszego API do notyfikacji, to ona zignoruje taką metodę, która gdzieś tam tą grupę ustawia, tak dla przykładu. Są też zewnętrzne biblioteki, które zapewniają tą kompatybilność. Tutaj wrócę do tego Job Schedulera, o którym wspominałem, Evernote wypuścił bibliotekę, która stanowi swojego rodzaju abstrakcję na wszystkie te API Androidowe i działa to tak, że jeśli ten Job Scheduler jest dostępny, to wszystkie te zadania planowane będą uruchamiane przez ten komponent w systemie. Natomiast, jeżeli nie, to oni nadpisali jakąś tam warstwę pod starsze systemy, która opiera się o dostępny właściwie odkąd pamiętam Alarm Manager, czyli taki stary, prymitywny mechanizm do planowania zadań i na własną rękę sprawdzają takie warunki jak dostępność sieci, czy to, że telefon się ładuje, czyli generalnie te możliwości, które Job Scheduler nam udostępnił. Więc to też nie jest tak, że wszystko, dosłownie wszystko spoczywa na naszych barkach. Są jakieś ta rzeczy, o które sami musimy zadbać, o ile wiem, to kamera API do tej pory chyba się nie doczekała żadnego wrapera, który zapewniłby kompatybilność wstecz. Po prostu mamy kamera API i kamera API 2, i gdzieś tam trzeba sobie samemu zdecydować na to z którego będziemy korzystać, więc tak to wygląda. Z plusów na pewno jest to, że jeżeli ktoś już się tym zajmie i będzie miał chęć do rozwoju, to na pewno bardzo dobrze samą Java jako taką można sobie poszlifować, bo tego języka chcąc, nie chcąc człowiek się uczy pisać na tego Androida, bo w tym się programuje, czy nawet tego Kotlina. Kotlin jest językiem, które również może być wykorzystywany wszędzie tam, gdzie Java, nawet na płytkach typu Android Pings można zaprząc Kotlina do pracy, czyli taki już trochę embedded czy na backendzie też z powodzeniem można tą Java tym Kotlinem zastąpić. Na pewno plusem jakimś mogą być ciekawe wyzwania, bo tam bawienie się rzeczami typu właśnie bluetooth, jakaś komunikacja, jakieś wyświetlanie jakichś danych z różnych API, to wszystko na telefonie, wysyłanie powiadomień, możliwość np. dzwonienia, wysyłania smsów czy ich odbierania, to gdzieś tam ta otoczka sprawia, że naprawdę moim zdaniem z dużą przyjemnością takie aplikacje się pisze, bo tych możliwości jest dosyć sporo, niestety coś za coś, bo ten framework mam wrażenie dla osoby początkującej może być dosyć skomplikowany. Minusem też na początek np. może być to, że ta dokumentacja oficjalna, ale to czuję, że to jest bolączka każdej dokumentacji czegokolwiek, ona pokazuje po prostu jak pewnych komponentów, pewnych API czy tam pewnych obszarów używać, ale bez jakiegoś nacisku na jakość tego kodu i po prostu w konsekwencji może być tak, że kopiowanie tych sampli z dokumentacji Google nie będzie najlepszym pomysłem i ten kod nie będzie zbyt czysty, czy jakoś uporządkowany. To już spoczywa ta organizacja tego wszystkiego, ułożenie tego po klasach i metodach na nas, aczkolwiek też tu trochę nadganiają, bo jak do tej pory, nie obstawiali na żadną jakąś architekturę, tak wypuścili nie dawno coś takiego co się nazywa Architecture Components, gdzie obstawiają mocno za taką architekturą jak MVVM, czyli Model View View Model. Udostępniają jakieś tam API i klasy do implementacji takiego wzorca. Poza tym większych minusów mam wrażenie, że chyba nie ma. Trzeba po prostu, ta kompatybilność i ta fragmentacja, to są jakieś największe bolączki.

Krzysztof: Czyli tak jak zawsze jest to kwestia świadomej decyzji. Paweł, ty już masz wieloletnie doświadczenie developerskie, jeżeli chodzi o Androida. Powiedz, jak najlepiej zacząć swoją przygodę i czy trudno jest zostać developerem Androida?

Paweł: Jeżeli chodzi o trudność, to ja ze szkoleń, które prowadziłem widzę taką prawidłowość, że ludziom, którzy byli na początku i, którzy dopiero co poznali język Java, prościej było się nauczyć Springa, czyli czegoś pod kątem Backend Full Stuck Developmentu niż Androida. Niestety taka smutna rzeczywistość. Z tego względu, że tutaj to dosyć mocno opiera na takich konceptach programowania zorientowanego obiektowo, czyli mamy tam sporo interfejsów do zaimplementowania klas, do podziedziczenia. Samo to wiem, że osobom początkującym czasami może sprawiać trudność, a jeżeli już chcemy to faktycznie dobrze ułożyć, dobrze to sobie zorganizować i napisać jakiś sensowny kod, który nie będzie zlepkiem kopiuj wklej z różnych stron i z różnych tutoriali, to to może gdzieś tam przysporzyć początkującym osobom trochę bólu głowy. Gdzie w Springu duża część opiera się na adnotacjach i tak jakby ten podział jest trochę bardziej naturalny. Więc to jest taka moja obserwacja. Jeżeli chodzi o to, z czego się uczyć, uważam, że tutaj tak naprawdę zależy na co obstawiamy. Jeżeli chodzi o aktualność powiedzmy tych źródeł, to najlepsza będzie oficjalna dokumentacja Google, bo oni ją po prostu na bieżąco aktualizują i te ich sample. Tutoriale gdzieś tam na zewnętrznych stronach niestety mają to do siebie, że ta wiedza z czasem się zdezaktualizuje. I taki tutorial w tej chwili dwu, trzy czy czteroletni to może być już nieaktualny, jeżeli ztargetujemy przynajmniej na najnowszą wersję systemu.

Myślę też, że w przypadku akurat Androida, dobrym pomysłem jest przerabianie, może nie tyle tutoriali, co kursów wideo. Z tego względu, że my widzimy co się dzieje, z reguły wykładowca tłumaczy na bieżąco co robi, dlaczego robi, więc to nie jest też przeklepywanie z tutoriala i usiłowanie doczytania się o co chodzi, więc to moim zdaniem jest taka forma dosyć ciekawa i chyba najłatwiej trafiająca do uczącego się. Z takich ostatnich kursów od podstaw, które wiem, że powstały niedawno, to Michał Geller na you demi wypuścił taki właśnie podstawowy kurs Androida, czyli jak rozpocząć pracę, jak zacząć, jak się w to wdrożyć, stworzyć jakąś pierwszą aplikację, żeby już później móc sobie dalej z jakąś tam swoją pracować. Oczywiście jak już pójdziemy sobie krok dalej, to pozostaje kwestia rozwiązywanie jakichś problemów, które napotkamy, bo ile można pisać aplikację z tutoriali, w końcu zdecydujemy, że chcemy pisać jakąś swoją i tutaj można napotkać szereg jakichś przeszkód, jakichś problemów z którymi będzie nam ciężko samemu walczyć. Oczywiście poza takim źródłem, chyba pierwszym, który przychodzi do głowy jakim jest Stuck Over Flow, to myślę, że przede wszystkim społeczność. Jeżeli chodzi o Androida, można oczywiście  poszukać sobie różnych forów. Polecam też takie miejsce jak Slucket czy Discord, poszukać sobie odpowiednich kanałów, gdzie można zadać jakieś tam pytanie czy kogoś zapytać o pomoc. Przykładami takich społeczności w Polsce, to np.Slucket DSPL albo JVM Poland, gdzie mamy dedykowane kanały po prostu Androidowe, gdzie można się o coś zapytać. Ja tam też często jestem i często się udzielam, staram się przynajmniej. Jeżeli chodzi o zagraniczne, bo też ta społeczność, że tak powiem jest dosyć szeroka międzynarodowo, są też takie slucki jak Android Chat czy Adroid United. Tam można spotkać osoby z przeróżnych krajów, to są slucki anglojęzyczne, można tam również wejść, zapytać się o pomoc czy pochwalić się jakąś swoją aplikacją. A dla osób, które interesują się Kotlinem i w tej materii chciałyby jakąś pomoc uzyskać, jest jeszcze sluck Kotlinlang, na którym również można się dopytać o jakieś tam problemy. Więc tutaj miejsc jest naprawdę sporo. Mało tego, myślę, że warto też spróbować w pewnych przypadkach poszukać sobie kogoś doświadczonego i gdzieś tam właśnie czy w takich społecznościach czy na Twitterze, czy np. z agend jakichś tam konferencji czy meetupów, zaobserwować ich na Twitterze, ewentualnie napisać wiadomość, myślę, że znajdzie się na pewno ktoś, kto będzie skory do pomocy. Więc myślę, że to takie dość ciekawe źródła , jeżeli chodzi o początki i poszukiwanie jakichś tam porad.

Krzysztof: To fajnie. Dobrze słyszeć, że te community są szerokie i pomocne, i tak jak wspomniałeś, ja też jestem fanem takiego podejścia, że najlepiej jest w praktyce uczyć się nowych umiejętności programistycznych, ale powiedz, według ciebie lepiej jest początkowemu programiście Androida rozpocząć od Java czy może jednak od Kotlina?

Paweł: Tutaj zdania są podzielone bardzo, jak to zauważyłem, bo czasami też gdzieś tam rozmowy na ten temat się trafiają. Jeżeli chodzi o moje osobiste zdanie, to ja jednak pomimo wszystko jeszcze o tą Java bym zahaczył, przynajmniej na jakimś podstawowym poziomie, bo po prostu wydaje mi się, że osoba nieznająca Java, nie do końca doceni to, co wnosi Kotlin. Bo on po prostu, jeśli chodzi o ten świat Java’owy, to dużo upraszcza, ale tam pewne założenia też się zmieniają i w związku z tym, że to i to działa na tej maszynie wirtualnej Java, która jakby nie patrzeć jest tworzona pod język Java głównie, to to warto jednak zacząć od tego języka Java, tak czy inaczej. Chociażby na jakichś podstawowych konceptach, a później przejść sobie krok dalej. Że tak powiem, poza tym co sama Java udostępnia, to Kotlin ja bym powiedział, że raczej jest rozszerzeniem. Może i upraszcza pewne rzeczy, ale na takiej zasadzie, że raczej dokłada uproszczenia, a nie zamienia różne koncepcje, więc tak czy inaczej ja bym obstawiał, że warto tej Java się pouczyć, a Kotlina to sobie później jako taki dodatek.

Krzysztof: Jasne, czyli zacznijmy od podstaw, a tak później przyjdzie czas na pewne rozszerzenia.

Paweł: Przypomniała mi się jeszcze sytuacja, ostatnio rozmawiałem z osobą, która gdzieś tam odpowiadała za rekrutacje w pewnej firmie, rekrutowała Androidowców i generalnie, jeżeli chodzi o ten poziom juniorski, to Java jest wymagana i z Java się pyta, natomiast Kotlin jest raczej na zasadzie nice to have, czyli chociażby pod kątem rekrutacji tak czy inaczej warto tą Java jeszcze jednak sobie utrwalać, uczyć się i wiedzieć o co chodzi.

Krzysztof: Dobrze, że wspomniałeś o rekrutacji. Żyjemy teraz w takich czasach, gdzie jest rynek zdecydowanie pracownika dla programistów i powiedz, jak to wygląda, jeśli chodzi o developerów Androida? Czy zapotrzebowanie na programistów jest duże? Jak to się tutaj na naszym polskim rynku kształtuje?

Paweł: Jeżeli chodzi o zapotrzebowanie, ja generalnie mam wrażenie, że ono w ostatnim czasie się ustabilizowało. W sensie jeszcze dwa lata temu, coś około tego, przynajmniej tu na rynku wrocławskim, bo to gdzieś tam jest najbliższy dla mnie i głównie jego obserwuję, to tych ofert było masę. W tej chwili nie jest ich mało, dalej jest w czym przebierać, natomiast mam wrażenie, że jest ich mniej niż było jakiś czas temu. Trochę mam wrażenie, że ten powiedzmy rynek czy ten obszar się lekko może nie nasycił, ale właśnie ustabilizował. W sensie nie szukają już tak ludzi tak naprawdę masowo, aczkolwiek w dalszym ciągu są mile widziani. Po prostu porównując to do Java, do developerów takich typowo Java developerów czy Dot Net developerów, to tych ofert jest dużo mniej, Natomiast  w dalszym ciągu mówię nie jest to na tyle margines, nie powiedziałbym o tym, że to są jakieś nieliczne oferty, że mamy, jeżeli szukamy, w czym przebierać i wybierać, więc zapotrzebowanie jak najbardziej jest, za równo w Polsce jak i za granicą, bo tam gdzieś LinkedIn też obserwuję, czy to zagraniczne Sluck’i, to również pojawiają się oferty jak najbardziej ciekawe, więc tak, myślę, że jak najbardziej tutaj na pewno się znajdzie. Chociaż przede wszystkim myślę, że w Polsce, to takie duże miasto, typu właśnie Wrocław, Warszawa, Kraków, to chyba takie najbardziej oblegane, jeżeli chodzi o Android Development miejsca. Ewentualnie jeszcze gdzieś tam okolice Trójmiasta tak. Pojawiają się oczywiście w innych miastach, ale tu mam wrażenie, że tego jest najwięcej.

Krzysztof: Chciałbym teraz porównać programowanie mobilne do innych takich najbardziej popularnych gałęzi, że tak powiem programistycznych, typu programowanie webowe czy desktopowe. W przypadku programowania webowego mamy dosyć taki wyraźny podział na front end i back end. Jak to jest w przypadku programowania mobilnego? Czy to jest programowanie bliższe front endu czy też tak naprawdę połączenie obydwóch tych części, frontendowych i backendowych w jednym? Jak to można najlepiej byłoby tutaj porównać?

Paweł: Ja kiedyś usłyszałem takie stwierdzenie, że Android, to tak naprawdę jest front end i nie jestem w stanie się z tym nie zgodzić, bo tak naprawdę to jest interfejs użytkownika, oczywiście z jakimiś tam dodatkowymi możliwościami, ale sprowadza się do tego, że mamy aplikację, którą musimy użytkownikowi wyświetlić, zaprezentować mu jakieś dane, umożliwić mu wykonanie jakichś tam akcji, więc z tym się na pewno zgodzę. Natomiast nie powiedziałbym, że to jest tylko front end, w sensie ja bym bardziej umiejscowił to gdzieś pomiędzy, między frontendem, a backendem, bo poza tym, że coś właśnie pokazujemy, coś musimy zaprojektować, wyświetlić itd., to czasami pod takim niepozornym interfejsem użytkownika potrafi się kryć dość sporo logiki. Przypominam też już o tym, że sam Android ma dosyć dużo tych ciekawych opcji, typu właśnie wysyłki tych smsów, operacji na połączeniach, manipulacje na kontaktach, tego typu sprawy. Jakaś komunikacja przez bluetooth czy po wifi, czujniki itd. Więc tutaj gdzieś bym to obstawiał między, natomiast też nie porównałbym go takim stricte backendem, bo tu nie mamy takich typowych problemów, które że tak powiem na backendzie spotykamy. Tu nie mamy możliwości skalowania, że na ileś serwerów nie występują jakieś tam znane powiedzmy problemy z back ndu, gdzieś tam pomiędzy. Ale są takie aplikacje, które bym raczej nie powiedział, że są stricte frontendem jak np. aplikacja aparatów, gdzie tam trzeba dosyć mocno operować na tym sterowniku kamery czy tak jak ta aplikacja, którą ja rozwijam Ndrivrer, gdzie sam you way jest dosyć skromny bym powiedział, tam jest parę ekranów na krzyż i tak naprawdę odnoszą się one tylko do jakiegoś tam ułamka funkcjonalności całej aplikacji. Cała reszta dzieje się, że tak powiem gdzieś tam w tle bez wiedzy użytkownika i pozwala właśnie poza samym wyświetlaniem danych czy możliwości wysłania jakiegoś tekstu na takie rzeczy zdalnie jak instalacja jakiejś aplikacji, blokada połączeń, blokada smsów czy coś tego typu, więc z tych chociażby powodów ja nie zaklasyfikowałbym tego w 100% jako front end, tylko gdzieś pomiędzy.

Krzysztof: Czy takie lekkie przesunięcie w kierunku front end’u, ale jednak większość aplikacji mobilnych swoją logikę zawsze tą ma, czyli tak jak wspomniałeś, gdzieś tam pomiędzy. A właśnie, a propos interfejsu użytkownika, Apple ma swój IOS Human Interfejs Skylines, czyli taki zestaw wytycznych, jak te interfejsy użytkownika mają być konstruowane, według jakich zasad. Ja sam na swoim przykładzie doświadczyłem odrzucenia aplikacji z Appstore’a, ponieważ właśnie nie spełniała tych wytycznych. Wiem, że w przypadku Androida, Google ma swój material design, pytanie na czym to w przypadku Androida polega i czy równie restrykcyjnie jest traktowana w przypadku przyjmowania aplikacji przez Google?

Paweł: Jeżeli chodzi o weryfikacje i material design, to, że tak powiem te sprawy mam wrażenie, że nie są ze sobą tożsame, w sensie Google nie weryfikuje, jeżeli chodzi o wygląd tych aplikacji, to jest jakaś tam tylko automatyczna weryfikacja, ona trwa parę godzin i o ile się orientuję, to oni sprawdzają tylko i wyłącznie jakieś tam kwestie bezpieczeństwa, jakieś tam znane luki, bardziej skupiają się na tym. Nie jest to tak wnikliwe jak w Apple, jak w Appstoreze. Jeżeli chodzi o sam you way, to generalnie z naszej perspektywy jako developerów nie wymagany jest jakiś dodatkowy wysiłek już w tej chwili, żeby ten material design gdzieś tam przynajmniej pobieżnie był wypełniony. Same te biblioteki App Compat tak jakby dorzucają nam już styl do aplikacji, który powoduje, że one są tworzone zgodnie z tym. Jest jeszcze też dodatkowa biblioteka App Compat Design, która udostępnia pewne kontrolki, które mogły nie pojawić się w poprzednich wersjach, żebyśmy mogli używać ich tak, żeby na każdym urządzeniu to było, to wyglądało tak samo. Natomiast, jeżeli chodzi o nas, to poza jakąś tam stylizacją czy jakimiś naprawdę specyficznymi rzeczami, raczej ten material design wychodzi dosyć naturalnie. Oczywiście tam warto się trzymać tych deadlinów dotyczących pozycjonowania, odstępów, jakichś tam styli. Natomiast, to nie jest tak, że te style musimy sobie realizować sami od początku, tylko one gdzieś tam są w tych bibliotekach dostępne, wystarczy po prostu ich użyć, z nich skorzystać, więc nie jest to jakieś bardzo trudne. Sam interfejs też, tutaj w większości przypadków z którymi się spotkałem, to są poprostu pliki XML’owe,w których definiujemy sobie te kontrolki, layout’y w których one się znajdują i w ten sposób system wie, co, kiedy ma wyświetlić, w jakim miejscu.

Krzysztof: Ok, porozmawiajmy chwilę o deploymencie aplikacji, czyli po tym jak już aplikacja jest gotowa od strony developerskiej, chcielibyśmy ją pokazać szerokiemu światu i w przypadku IOS, i w przypadku X Code, mamy kilka takich różnych możliwości. Możemy sobie tą aplikację uruchomić na swoim telefonie podłączonym do laptopa, możemy ją poprzez aplikację Test Flight wysłać testerom, czy nawet klientom taką wersję beta, żeby ją sobie zweryfikowali i później, jeżeli już jesteśmy pewni, możemy oczywiście ją zdeployować do Appstore’a. Zastanawiam się, czy w przypadku Androida mamy tutaj podobne możliwości, czy może jeszcze coś więcej istnieje?

Paweł: Możliwości mamy tak naprawdę podobne, aczkolwiek mam wrażenie, że w Androidzie porównując go do IOS, jest to trochę prostsze nawet. Tak po kolei idąc, jeżeli chodzi o uruchamianie tego na swoim telefonie , to tutaj jest bardzo prosto. Tam są dwie opcje na samym urządzeniu, które trzeba po prostu włączyć, podłączając telefon, w tym momencie kablem USB jesteśmy w stanie z Android Studio, bardzo łatwo, prostot taką aplikację sobie uruchomić. Bo o ile pamiętam, w IOS telefon musiał być dodany do profilu developerskiego, odpowiednio zprowiżjonowany, jakiś tam certyfikat zainstalowany. Tutaj tego nie ma. Tu w ogóle, żeby rozpocząć development, nie potrzebujemy tak naprawdę żadnych kont, żadnych dostępów. Nie potrzebujemy nigdzie też tego urządzenia dodawać, czy w jakiś specyficzny sposób, poza tą jedną, dwoma opcjami go konfigurować. Jeżeli chodzi o wysyłkę aplikacji testerom czy tam klientom, to generalnie samo generowanie, to zostaje nam ręczne lub użycie jakiegoś rozwiązania typu Continous Integration, jak dzenkins intensity, NCA z Git Laba, czy np. Bit Race, który jest dedykowany, że tak powiem pod aplikacje mobilne. Oczywiście wynikiem tu jest plik APK, możemy dostarczyć to testerowi ręcznie, mailem czy przez jakiś magazyn danych typu FTP czy jakiś udział sieciowy, ale możemy też wrzucić np. do Google Play Store, ale w wersji alfa czy beta, czyli dostęp do niej będą miały tylko odpowiednie wskazane osoby. Ona nie będzie jeszcze wtedy dostępna publicznie. Możemy też użyć jakiegoś zewnętrznego narzędzia, tutaj najbardziej mi znany, to jest Fabric Beta, gdzie możemy właśnie taką aplikację w wersji testowej udostępniać użytkownikom, dla mnie to jest taki odpowiednik właśnie test lighta z IOS, tylko to nie jest zintegrowane. Oczywiście pomijając te alfy i bety z Play Store’a, to to można by sobie do test lighta w 100% porównać, bo to jest mechanizm dostępny jakby od dostawcy systemu, ale też są zewnętrzne usługi, jak ten Fabric Beta. Plus jest taki, że nie musimy wtedy zakładać konta Google na Play Store, który kosztuje 25 dolarów, tylko Fabric Beta jest darmowy, więc jeżeli chcemy tylko i wyłącznie dystrybuować wersje testowe, to się bardziej finansowo opłaca. Sama publikacja już publicznie do sklepu, tak jak wspominałem w Google wystarczy konto za 25 dolarów i możemy w tym momencie nasze aplikacje wrzucać do sklepu, tam oczywiście trzeba mieć odpowiednie screeny, opisy itd. Ta weryfikacja trwa zazwyczaj kilka godzin i o ile pamiętam bywało często tak, że wieczorem wrzucając aplikację czy aktualizację, ona rano była już z dużą prawdopodobieństwa dostępna dla wszystkich, więc to idzie dosyć szybko i właśnie tam mamy te ciekawe opcje jak alfa czy beta rylisy lub możemy stopniowo wypuszczać nową wersję, określając procent użytkowników do których ma trafić update, monitorować, jeżeli wszystko jest ok, to sobie albo ten procent zwiększać albo wypuścić już dla reszty. Dosyć ciekawe rozwiązanie, bo pozwala, że tak powiem szczególnie przy jakichś dużych ryzykownych zmianach sprawdzić czy wszystko jest w porządku na jakimś procencie użytkowników, jeżeli coś jest nie tak, to możemy update wycofać, jeżeli wszystko ok, to możemy wtedy puścić na całą resztę, więc tutaj możliwości też jest dosyć sporo i są dosyć fajne.

Krzysztof: To faktycznie bardzo fajna opcja. Tak jak wspomniałeś w przypadku IOS, żeby nawet na swoim urządzeniu, na swoim telefonie podłączonym kablem coś przetestować, to faktycznie trochę tych certyfikatów trzeba różnych wygenerować, aczkolwiek te nowsze wersje X Code już gdzieś tam pozwalają to troszeczkę zautomatyzować, tym nie mniej ciągle jednak jakieś manualne kroki są wymagane. Nie wiem czy w przypadku Androiida istnieje też taka możliwość, że taka aplikacja działająca na telefonie właśnie podłączonym przez kabel jest możliwa do zdebagowania, czyli działa sobie na tym urządzeniu, a my mamy wgląd do różnych rzeczy, które mogą się wydarzyć, możemy sobie obserwować, możemy po prostu debagować aplikacje. Czy w przypadku Androida też podobne możliwości istnieją?

Paweł: Tak, jak najbardziej. To też jest dosyć proste. Polega na tym samym, co zwykłe uruchomienie, tylko po prostu uruchamiamy to z Android Studio w trybie debug i na tym się to sprowadza, w tym momencie tam możemy mieć podgląd na pamięć, możemy zatrzymywać program w odpowiednim momencie, oczywiście możemy wyrzucać pewne rzeczy do logów i te logi możemy sobie podglądać. Tu o logach też warto wspomnieć, że logi z aplikacji są dostępne z całego systemu, czyli nawet jeżeli mamy aplikację nie naszą, której my nie rozwijamy, która jest po prostu zainstalowana i ona coś do logów wrzuca, to my je możemy podejrzeć takim narzędziem jak Locca. Myślę, że warto o tym pamiętać, żeby z naszej aplikacji czegoś nie wyrzucać i już publikujemy ją do sklepu, bo każdy może to obejrzeć, więc jeżeli gdzieś sobie logujemy jakieś żądania sieciowe czy jakieś wrażliwe dane, to niestety może powodować wyciek jakiś tam tych danych, ponieważ każdy może to zobaczyć, Więc na to warto uważać, ale też warto wierzy, że inne aplikacje, jeżeli logują też możemy podglądać, ale tylko na zasadzie logów, bo zdebagować już nie możemy. Debagujemy tylko i wyłącznie nasze aplikacje.

Krzysztof: Wspomnieliśmy tutaj już kilka razy już o sklepie z aplikacjami i zastanawiam się, czy na tworzeniu własnych aplikacji na Androida i później publikowanie ich można zarobić? Pytam dlatego, że jakiś czas temu słyszałem coś takiego, że większość producentów gier, ale to już było jakiś czas temu, pewnie kilka lat temu, większość producentów gier i tego typu rzeczy bardziej się skupia na AppStoreze, ponieważ tam użytkownicy bardziej skłonni są do płacenia za aplikacje, a w przypadku Androida jednak użytkownicy przyzwyczajeni są do darmowych wersji oprogramowania i czy według ciebie na wypuszczaniu swoich aplikacji można, da się zarobić?

Paweł: Wydaje mi się, że jeżeli chodzi o Androida wypuszczanie płatnych aplikacji może się niestety spotkać z jakimś tam drobnym oporem. Faktycznie tak jak mówisz, raczej tendencja jest taka, że użytkownicy IOS z jakiegoś powodu są skłonni po prostu chociaż sam fakt zapłacić za aplikację, już nie wnikając w to ile, w Androidzie niekoniecznie, ale mam wrażenie, że właśnie nawet patrząc na jakieś tam gry czy aplikacje użytkowe, to w Androidzie to działa bardzo często tak, że mamy takie wersje freemium, że pewną część funkcjonalności udostępniamy, ale jak ktoś coś więcej, to nam dopłać i wykup subskrypcje albo po prostu usługę w aplikacji, takie płatności wewnętrzne, czy po prostu wrzucają wersję z reklamami za darmo i wersję płatną, w której te reklamy nie istnieją, czy tam właśnie w tej ogólnej wersji darmowej z reklamami jest możliwość wykupienia takiej usługi, jak usuń reklamy za które już trzeba zapłacić, więc to są jakieś tam opcje zarobku. Natomiast wydaje mi się, że to też zaczyna się dopiero zwracać jak mamy dużą audiencję, dużo odbiorców, którzy z tej aplikacji korzystają, bo gdzieś tam przy paru set, czy tysiącu, czy może nawet dwóch, nie wiem. czy tam ten zarobek będzie duży, czy też jeżeli chodzi o reklamy. Oczywiście gdzieś tam rozbijamy się cały czas o zarabianie na Play Storze, bo można też zarabiać na aplikacji po prostu udostępniając ją na własną rękę i sprzedając ją w ramach abonamentu, czy w ogóle mając aplikację, która już jakiś sukces odniosła, możemy ją sprzedać, jeżeli ktoś będzie zainteresowany przejęciem takiego produktu i rozwijaniem go na własną rękę, Czasami tak się zdarza.

Krzysztof: Czyli efekt sky tutaj ma znaczenie. W związku z tym pojawia się taki pomysł i zakusy, żeby za jednym zamachem stworzyć jednocześnie aplikację na Androida i na IOS, i co jakiś czas słyszy się o takich rozwiązaniach typu Sanmarine, React Native, czy kiedyś Phone cap, których da się jednocześnie na wiele platform te aplikacje tworzyć i zastanawiam się, czy miałeś z takimi platformami do czynienia i czy to są faktycznie rozwiązania, które mogą coś wnieść czy też raczej robią więcej złego niż dobrego?

Paweł: Jeżeli chodzi o takie rozwiązania, to kiedyś swojego czasu miałem do czynienia z Phone Gapem i tu powiem niestety nie wspominam tego zbyt dobrze i raczej też widzę taką tendencję, że raczej się od tego odchodzi. A phone gap, to jest nic innego jak przeglądarka internetowa opakowana w formę aplikacji. Oczywiście tam można sobie dokładać kod natywny, który da się wywoływać z Java Scriptu, ale w dalszym ciągu jest to strona internetowa. Jest to renderowane po prostu jako zwykły HTML, tam można sobie wrzucić jakiś CSS, Java Script, natomiast to wszystko też jest wtedy zależne, jaki poziom tych wszystkich standardów jest obsługiwany na danym urządzeniu. Możemy się spotkać z problemem, to szczególnie kiedyś było gdzieś tam widoczne, że CSS jakaś tam była inna wersja, inne selektory obsługiwane między jednym a drugim urządzeniem, bo starszy Android zatrzymał się na 2 a w nowszym była 3, i tego typu rzeczy, więc tutaj niestety moim zdaniem to było bardzo niewdzięczne rozwiązanie, ten Phone Gap. Xamarin tutaj trochę ciężko mi się odnieść, nie miałem do czynienia tak na zasadzie, że korzystałem z niego. Jako samo rozwiązanie wydaje się dosyć fajne, minusem wydaje mi się jedna sprawa mianowicie taki trochę konflikt, że te Xamarin Forms tzw. czyli rozwiązanie pozwalające tworzyć interfejs na obie platformy, ponoć jest dosyć sztywny, ciężko tam sobie to rozszerzyć. Druga sprawa, ciężko ponoć w Xamarinie jest zintegrować sobie jakieś biblioteki natywne na Androida, czyli Java’owe czy napisane w Kotlinie, to musi być gdzieś tam w jakiś sposób przeprocesowane o ile wiem, ale to jest status mojej wiedzy sprzed roku, coś koło tego, co też był jakiś tam problem. I tutaj z tych trzech, które wymieniłeś, raczej moim faworytem byłby React Native, tam się pisze też co prawda w Java Script czy tam Type Script, natomiast to już jest ten nowoczesny Java Script, Type Script, czyli taki już z interfejsami, z typowaniem itd. Tam mamy zaprzęgnięte nie pamiętam tylko, które z tych dwóch webpack czy bubble,  w każdym razie on potrafi też ten standard skompilować do niższego, w każdym razie dla developera, pisze się w tym moim zdaniem całkiem przyjemnie. Oni tam też opierają się na tym, że istnieje pewien pomost między tą warstwą Java Sript’ową a natywną i on tak naprawdę nie rysuje czy nie renderuje nam z HTML, nie renderuje nam strony internetowej. On opiera się na normalnie natywnych kontrolkach, które w odpowiedni sposób styluje, w zależności od tego jak my ten styl opiszemy sobie w kodzie Java Scriptowym, ta logika też jest reużywalna. Więc tutaj jak narazie dla mnie React Native z tych przynajmniej trzech rozwiązań z perspektywy developera jest najbardziej ok, a myślę, że z perspektywy jako tako biznesu, też będzie to znośne. O ile wiem, front end developerowi, który na React’cie sam takim webowym dobrze się zna, też nie jest to duży problem wskoczyć w React Native’a. Też wydaje mi się, że stosując tego typu rozwiązanie, że przerzucamy front end developera do aplikacji mobilnej pisanej we frameworku hybrydowym, ta wiedza jednak o platformie mobilnej w dalszym ciągu się przydaje i jest niezbędna. Tak czy inaczej, ta osoba musi wiedzieć, Jest jeszcze jedno rozwiązanie gdzieś tam na horyzoncie , nazywa się flatter, jest to rozwiązanie od Google, też jest to rozwiązanie hybrydowe, czyli pozwala na pisanie jednocześnie pod Androida i pod IOS. Jedynym minusem moim zdaniem jest tam po prostu język inny niż wszędzie, którego trzeba się douczyć, oni używają tam Darta, ale to gdzieś tam myślę, że bariera jest do przejścia. Nie miałem też jeszcze możliwości tego przetestować, ale tak na pierwszy rzut oka wygląda mi to tak trochę, że jak ktoś miał do czynienia z Kotlinem czy ze Swiftem, to nie powinien mieć większego problemu, żeby w tego Darta się wdrożyć i tam oni w ogóle zastosowali inne podejście, bo tam całe renderowanie interfejsu użytkownika tak od zera już rysowanie, jego obsługa zdarzeń itd, jest po stronie tego ichniejszego frameworku. Czyli tam już nie renderujemy strony internetowej, tam nawet nie opieramy się na kontrolkach natywnych, tylko cały interfejs użytkownika, jest rysowany przez ten framework, dzięki temu też ten interfejs, ta aplikacja chodzi bardzo szybko, bardzo płynnie. To w tej chwili jest rozwiązanie w fazie1 beta, oni tam pracują chyba nad optymalizacjami w tej chwili, więc tylko czekać, aż wypuszczą wersję stabilną, ale zapowiada się bardzo obiecująco.

Krzysztof: Super. Paweł, bardzo ci dziękuję za dzisiejsze spotkanie. Świetnie, że podzieliłeś się swoją wiedzą i doświadczeniem na temat Androida. Powiedz, jak najlepiej się z tobą skontaktować i gdzie cię można znaleźć w internecie?

Paweł: Najszybciej można mnie znaleźć właśnie na Sluckach, DSPL, lub JVM Poland, tam praktycznie codziennie gdzieś tam jest dostępny. Dodatkowo na Twitterze, na LinkedIn czy na Medium, tak jak już wspominałeś, można odnaleźć moje profile, na Medium poczytać sobie jakieś tam artykuły, które wyprodukowałem i to chyba takie główne kanały, którymi się komunikuje na zewnątrz.

Krzysztof: Świetnie. Na pewno linki do wszystkich tych źródeł i miejsc, gdzie można cię znaleźć załączę w notatkach do tego odcinka. Jeszcze raz ci bardzo dziękuję. Dzięki i do usłyszenia.

Paweł: Dziękuję, również do usłyszenia.

Krzysztof: : I to na tyle z tego, co przygotowałem dla Was na dzisiaj. Wyszła nam dosyć długa, ale bardzo rzeczowa rozmowa z Pawłem, która mam nadzieję przybliży Wam wszystkie aspekty związane z programowaniem aplikacji mobilnych na Androida. Po więcej informacji zapraszam Was na stronę porozmawiajmyoit.pl/5. Tam też możecie zadawać pytania i skomentować ten odcinek podcastu. Wielkie dzięki. Zapraszam do subskrypcji  i do usłyszenia następnym razem. Cześć.

Dziękuję Ci serdecznie za wysłuchanie kolejnego odcinka podcastu Porozmawiajmy o IT. Chcielibyśmy, by ten podcast docierał do jak najszerszego grona słuchaczy. Możesz nam w tym pomóc, zostawiając gwiazdki i opinię w katalogu iTunes lub innej aplikacji z której korzystasz do słuchania podcastów. Będziemy Ci wdzięczni za podzielenie się informacją o tym podcaście w mediach społecznościowych. Jeszcze raz dzięki za bycie z nami i do usłyszenia w kolejnym odcinku. Cześć.