Android 4.1.2 na Samsung Galaxy S II - aktualizacja poszła gładko

Pamiętam, jak wypatrywałem jego nadejścia, aż w końcu się doczekałem. I nie zapomnę mojego zdumienia, kiedy wyjątkowo wcześnie rozpoczynając poranek, 22 lutego zobaczyłem powiadomienie o oczekującej aktualizacji. Nie przypuszczałem, że może to być Android 4.1.2 "Jelly Bean", bo czas aktywnego wypatrywania miałem już dawno za sobą. Przegapiłem również wiadomość o dostępnej aktualizacji, która podobno była już w sieci od 18 lutego.

I w końcu do mnie dotarło!

"I teraz co?!", pomyślałem. Grzecznie przeczytałem informacje z ekranu mojego "najulubieńszego" Galaxy S II i zacząłem zastanawiać się nad kopią bezpieczeństwa. Najbardziej szkoda było mi stracić zdjęć i nagrań, więc szybko przeniosłem je w bezpieczne miejsce. Reszta mogła iść do kosza, gdyby podczas aktualizacji doszło do skasowania zawartości telefonu. A co mi tam.

Ekranów z instrukcją aktualizacji oprogramowania nie widać było końca. Najpierw ten wyżej, później następny...

...aż w końcu pojawił się ostatni.

Podekscytowany odłożyłem jednak telefon na bok i zabrałem się za śniadanie. "Jak się człowiek spieszy, to się diabeł cieszy."

I warto było czekać. Aktualizacja przeszła gładko (podobnie jak poprzednia do ICS - Android 4.0.3), więc do tej pory nie narzekam.

Od strony użytkownika zauważyłem pewne przyspieszenie działania telefonu i jakby siła sygnału wzmocniła się. Zwolniła aplikacja do robienia zdjęć i teraz trzeba trochę dłużej odczekać zanim kamera jest gotowa do działania. Zwiększyła się liczba opcji w panelu w belce i pojawiło się kilka znaczących zmian w samym korzystaniu z systemu. Jestem zadowolony z przejścia na Jelly Bean. Polecam!

Poznań by poznać - Eclipse DemoCamp i GDG DevFest

Jakoś tak umknęło mi, aby napisać, że od czwartku do niedzieli będę w Poznaniu na dwóch konferencjach w zaszczytnej roli prelegenta - Eclipse DemoCamp (EDC) w czwartek o 21:15 (!) oraz GDG DevFest Poland w sobotę o 12:00.

W ten sposób mam możliwość odwiedzić Poznań, aby poznać ludzi i ich opinie na prezentowane tematy. Na to liczę. Nie zamierzam występować w roli eksperta omawianych tematów. Wyrosłem z takiego myślenia (że w moim przypadku jest to w ogóle możliwe). Interesuje mnie wyłącznie rola osoby, która spędziła trochę czasu, aby zrozumieć tajniki współistnienia Enterprise OSGi z Java EE w ramach IBM WebSphere Application Server V8.5 Liberty Profile (to w czwartek na EDC) oraz współbieżności na platformie Android (sobota podczas GDG DevFest) i chciałaby podzielić się zdobytymi umiejętnościami z innymi, aby ukierunkować dalsze zgłębianie tematu.

Liczę na liczne przybycie oraz aktywny udział uczestników, aby poświęcony czas - organizatorów, uczestników oraz prelegentów - był wyłącznie mierzony w skali pozytywnych doznań (zamiast negatywnie jako zmarnowany).

Klimat konferencji tworzą wszyscy zaangażowani i ostatnią rzeczą powinno być narzekanie, że było nieciekawie, kiedy wystarczyło zawłaszczyć trochę czasu dla własnych potrzeb. Namawiam do zadawania pytań, nawet w sytuacji, kiedy istnieje przekonanie, że jest to najbardziej trywialne i najmniej pożądane pytanie w danej chwili (skąd w ogóle mogłoby nam przyjść takie myślenie do głowy, skoro pytanie jeszcze nie padło?!) Konwenanse zostawiamy w domu i pracy, a na konferencję przychodzimy z otwartymi umysłami pozbawionymi obostrzeń w postaci przeszłych (zamierzchłych?) doświadczeń, które nauczyły nas wyłącznie słuchać bądź akceptować prawdy oczywiste.

Zachęcam gorąco do zabrania pomidorów, aby skorzystać z kilku, jeśli okaże się to jedynym sposobem na wyrażenie swojej opinii nt. oprawy prezentowanego tematu, a pewnie i tym samym przegonienie prelegenta ze sceny (ze skutkiem natychmiastowym i pewnie dożywotnim) :-)

Współbieżność i Android na Mobilization^2

W najbliższą sobotę będę miał przyjemność występować na konferencji Mobilization^2 w Łodzi, podczas której przedstawię temat "Zrównoleglanie zadań w Javie na platformie Android". Prezentacja będzie podsumowaniem dotychczasowych doświadczeń w rozpoznaniu tematu zrównoleglania zadań na platformie Android i liczę na kontakt z osobami, których tematyka intryguje, a moje wystąpienie stanie się swoistym katalizatorem dalszych studiów.

Prezentacja zaplanowana jest na godzinę 10:15 w sali F10 – Fortress. Reszta na stronie konferencji. Zapraszam!

Zbiegi okoliczności wokół Android 4.1 Jelly Bean

Android 4.1, Jelly Bean "spotykam" na każdym kroku. Poza technicznymi detalami, które udaje mi się wyłapać podczas lektury artykułów, trafiłem ostatnio na informację o przygotowaniach do wydania Android 4.1 na Samsung Galaxy S II. Wcześniejsza zajawka o aktualizacji do 4.0.4 sprawiła, że przez tydzień sprawdzałem co godzinę, czy jest coś dostępnego. W przypadku Jelly Bean, odpuszczam. Na razie nie widzę powodów, abym potrzebował go. Jak będzie to będzie. I od razu mniej problemów na głowie.

A tu proszę. Wychodzę na spacer z Maksymem, a tu na telefonie informacja o dostępnej aktualizacji! Ni z gruszki ni z pietruszki pojawia się aktualizacja! Bajka!

Cóż było robić, aktualizacja ruszyła. Po 10 minutach telefon był już gotowy do ponownego użycia.

Jakby na dokładkę, w drodze powrotnej trafiłem na...

I jak to nazwać? Zbieg okoliczności? Próba zwrócenia na siebie uwagi? Ech, Androidzie, już do Ciebie wracam :)

Android 4.0.3 na Samsung Galaxy S II - aktualizacja poszła gładko

I jestem po aktualizacji do najnowszej wersji Androida 4.0.3 powszechnie nazywanego ICS lub Ice Cream Sandwich, który 13 marca Samsung udostępnił posiadaczom smartfona Samsung Galaxy S II.

Do dzisiaj rozkład za i przeciw aktualizacji oscylował na granicy 50/50. Wystarczy przejrzeć komentarze do wpisu Oficjalny ICS dla Samsunga Galaxy S2 i po prostu samodzielnie podjąć decyzję o aktualizacji. Trudno mi było opierać się na komentarzach, ale dusza programisty kusiła możliwościami ICSa. W końcu dałem upust mojej żądzy posiadania :)

Najpierw zrobiłem kopię zapasową przez Kies 2.0 dla Mac OS. Dodatkowo przekopiowałem wszystkie zdjęcia i nagrania, na jakich mi szczególnie zależało i byłem gotowy.

Rozpoczęło się pobieranie paczki z aktualizacją.

Pobranie i zainstalowanie trwały około 30 minut (pewnie szybciej, ale za szczęśliwym, abym racjonalnie myślał). Po instalacji moim oczom ukazał się cały i zdrowy SGS2 z ICS.

Pierwsze na co zwróciłem uwagę, to było utrzymanie tapety i zmiana ikonek systemowych na pasku na górze - status połączenia WiFi, siła sygnału sieci komórkowej i bateria. Brzydkie. Poprzednie bardziej mi się podobały. Zrzucam to jednak na barki przyzwyczajenia, a z nim tylko jeden sposób jest skuteczny - przyzwyczaić się do innego, nowego. Czcionka, mimo komentarzy, wydaje się być w porządku. Nic nie trzeba było zmieniać w ustawieniach. Skróty na pulpicie poznikały, ale same aplikacje są dostępne, więc pozostaje odtworzyć je ze zrzutów ekranu, które wykonałem jeszcze przez aktualizacją.

W Ustawieniach sprawdziłem wersję Androida.

Jak widać, zgłasza się najnowsza wersja.

Jeszcze pozostaje sprawdzić wersję przez *#1234# w telefonie.

Tu również właściwie. Jak widać miałem dużo szczęścia, że wszystko (poza usunięciem skrótów na pulpicie) jest na swoim miejscu. Nie potrzebne było odtworzenie kopii i wszystko zdaje się funkcjonować poprawnie.

Dla pewności, wyjąłem jeszcze baterię, odczekałem kwadrans i włożyłem ponownie. Podobno ma pomóc na przegrzewanie się aparatu. Wszystkim polecam tak bezinwazyjnej aktualizacji i rozpoczęcia nauki Android API dla najnowszej wersji Ice Cream Sandwich.

Ach, pewnie to wielu już zna, ale dla mnie to było odkrywcze - zrzuty ekranu robi się przez jednoczesne przytrzymanie klawiszy Power i Volume down przez kilka sekund.

Relacja z cracow.mobi w Krakowie

Dzień rozpocząłem dosyć wcześnie, bo aż o 5:30 i było to zdecydowanie za wcześnie, aby wystąpić jako prelegent na konferencji, jeśli dodać wydarzenia poprzednich dni

Dzień wcześniej poprowadziłem prezentację na temat IBM WebSphere Application Server V8 u jednego z klientów IBM na południu Polski (nazwa i miejsce nie mają znaczenia, więc pozostańmy przy anonimowych nazwach). Tym razem pobudka o 4:45, aby wyrobić się na 6:17 na pociąg. Oczywiście dzień wcześniej również zeszło mi się do po północy przed kompem. Wszystko takie interesujące i ekscytujące, że kiedy przychodzi wieczór i rodzinka kładzie się spać, albo część już dawno śpi, cisza zapada i tak się siedzi, i siedzi, i siedzi, aż zegar wybija północ (!) Pamiętam, jak uporałem się z tym problemem kilka miesięcy temu, kiedy regularnie chodziłem spać około 22, aby zrekompensować "straty" pobudką wcześnie rano. I człowiek wyspany, i jakoś spokojniej z rana, i wszystko takie dopiero budzące się do życia, a dorzucając do tego, że wszystko działo się w lato, kiedy słońce gorąco prażyło, aż się chciało w tym wszystkim uczestniczyć!

Zmęczenie jest zdecydowanie niewskazane przy jakiejkolwiek aktywności, a ta, która wymaga pełnego skupienia i udziału publiczności, jak wystąpienie na konferencji, jest nadzwyczaj niebezpieczna w takim stanie. Potrafi wydrenować ostatnie resztki energii.

Do Krakowa dotarłem na czas - 10:15. Niedługo po rejestracji trafiłem na Radka Holewę! Jakież było moje zdumienie widząc jego wesołą twarz, która musiała z pewnością kontrastować z moją, na której rysowało się postępujące (i sukcesywnie wyniszczające) zmęczenie. Moja ekscytacja spotkaniem z Radkiem jeszcze bardziej wpłynęła na moją kondycję (tak samo pozytywnie, co i negatywnie, więc możnaby założyć, że saldo pozostało bez zmian, ale wahnięcia również odciskają swoje piętno). Kilka późniejszych rozmów z Konradem "ktosopl", Andrzejem "ags" i dopiero co poznanym Bartkiem Filipowiczem (prelegentem po mnie) tylko pogarszało sprawę. Nawet gdybym o tym wiedział wcześniej, za nic i tak nie zrezygnowałbym z okazji zamienienia z nimi słowa. Właśnie podczas bezpośrednich spotkań dostrzegam ile tracę ślęcząc przed kompem zamiast wyjść "na miasto".

Za zmęczeniem przywlokło się inne "cudo" - niepokój o moje przygotowanie. Konferencja cracow.mobi była moją pierwszą, w której prezentacje były z bardzo wąskiego tematu - tworzenia aplikacji mobilnych na platformę Android. Do tej pory zwykłem brać udział w takich, na których poruszano zagadnienia związane z językiem Java, technologią Java EE i miękkimi technikami wytwarzania oprogramowania. Zakres tematyczny zwykle był na tyle obszerny, że trudno było porównywać poszczególne prezentacje pod względem merytorycznym. Pozostawała jedynie możliwość porównywania ich pod względem estetycznym - przygotowanie prelegenta w temacie, wygląd prezentacji i w ogóle interakcja z publicznością. To dawało stosunkowo obszerne pole do popisu (lub ukrycia swojego niewielkiego praktycznego doświadczenia).

To uzmysłowiłem sobie dopiero, kiedy zacząłem przyglądać się, w jaki sposób swoje tematy prezentują Konrad "ktosopl" Malawski i Marek Defeciński.

Konrad wystąpił z tematem "Deep dive into RoboGuice - beyond "Hello World" apps". Nie trudno było zauważyć jego ponadprzeciętną znajomość Androida - posługiwał się terminami androidowymi, jakby sam je tworzył i kilkukrotnie zapytany z sali, odpowiadał bez trudu. Słabiej, acz wciąż znośnie, wypadł prezentacyjnie. Kiedy wszedłem na salę, Konrad już mówił. Zacząłem uważnie przyglądać się, w jaki sposób przedstawiał temat, bo po raz pierwszy miałem możliwość zobaczyć go w akcji. I gdybym na pierwszym wrażeniu poprzestał i odpuścił sobie, to nota byłaby marna. Trudno było odgadnąć, jaki to temat wybrał sobie Konrad do przedstawienia. Tu miałem nie lada zagwozdkę. Przez pierwsze 30 minut Konrad przedstawiał Guice i założenia DI z @Inject. Ucieszyłem się z udziału Guice, a jednocześnie, przez cały ten czas, zachodziłem w głowę, co tak na prawdę skłania Konrada do jego omawiania. Koniec końców wszystkie prezentacje miały być z założenia o Androidzie, a tu czas mija, a o Androidzie ni widu ni słychu. Slajdy słabej jakości tylko pogarszały sprawę - wymagają dopracowania, bo prawie nic nie było widać. Trudno doszukiwać się problemu z projektorami, których ułożenie - jeden duży na dole i drugi na antresoli, oba z bardzo dobrą rozdzielczością - i sala, niewielka, acz dopasowana do liczby uczestników, gwarantowały komfort prelegentom i słuchaczom. W końcu nie wytrzymałem i zajrzałem do agendy - ma być o RoboGuice. Tego nie znałem. Ponownie podniosłem poziom zainteresowania na wysoki. I tak doczekałem się RoboGuice, aby na końcu doświadczyć testowania z nim. Konrad zasługuje na uznanie pod kątem jego obycia z Androidem i RoboGuice, ale na początku za bardzo odszedł od tematu i pod tym kątem zawiódł mnie. Widać potencjał prezentacyjny u Konrada i zrobię wszystko, co w mojej mocy, aby wziął udział w Confiturze 2012. RoboGuice wchodzi do mojego arsenału narzędziowego i z pewnością niebawem się nad nim będę rozwodził na tym blogu. Dzięki Konrad za inspirację!

Przerwa.

Całą prezentację Konrada przesiedziałem sam, aby móc w pełni skosztować jej smaków. Przesiadłem się do Radka, który rozmawiał z...Ryan'em Gosling'iem (!) Nie żartuję. Kolejny po mnie prelegent Bartek Filipowicz wygląda zupełnie, jakby zdjąć skórę z Ryan'a (nic nie ujmując jednemu czy drugiemu). Kto nie wierzy, niech zajrzy na stronę prelegentów cracow.mobi (na samym dole). Nie mogłem się powstrzymać i powiedziałem mu o tym. W ogóle nie widać było jego zdumienia. Bynajmniej u Radka. Podobno Bartek spotykał się z taką reakcją wcześniej. Nie mogłem zdjąć z niego oczu taki podobny! :) Później doszli do nas Andrzej i Konrad, któremu "sprzedałem" moją ocenę jego wystąpienia. Obiecał naniesienie poprawek. Może już na kolejną Confiturę? Gorąco będę go dopingował, aby zgodził się wziąć w niej udział. Konrad, mordo Ty moja, nie daj się prosić!

Po przerwie, mikrofon przejął Marek Defeciński z "Testowanie w systemie Android". Powiało nudą mimo, że temat i slajdy wręcz krzyczały, aby było inaczej. Gość ma wiedzę i doświadczenie w Androidzie - co do tego, nie mam żadnych wątpliwości, ale zdziwiłbym się, gdyby znalazły się osoby, które nie zarzuciłyby mu braku przygotowania od strony prezentacyjnej. Jak zwrócił uwagę Radek - 16 minut trwał wstęp o sobie! To jak za starych, dobrych czasów moich wystąpień, za które dostawałem cięgi. Później Marek zdecydował się na kod na żywo, ale z takimi wpadkami, że podziwiałem jego upór, aby go mimo trudności zaprezentować. Samoprezentacja przez 16 minut, niedziałające testy i w końcu uwagi odnośnie emulatora Androida, zmusiły mnie do zabrania głosu, aby wyprostować stwierdzenia o wolnym działaniu tego ostatniego. Jakoś w końcu musiałem zrekompensować sobie nudę! Można było odnieść wrażenie, że testy są złe, bo są baaardzo wolne w przypadku aplikacji androidowych. Jakkolwiek trudno mi potwierdzić tę tezę w ogólności, to w tym konkretnym przypadku Marek pracował na sprzęcie, na którym całe środowisko ADT wolno działało! Panowie i panie - nie twierdzę, że ADT to cudo inżynieryjne, ale nie łudźmy się, że procek i RAM to podstawa, aby poradzić sobie z takimi problemami. To na pewno nie pozwala na stwierdzenia, że testy są do kitu, bo...maszyna za wolna i kto je by tam robił.

Jakby tego było mało Marek przekroczył czas prezentacji o dobre 10 minut. Gdyby chcieć podsumować jego wystąpienie jednym zdaniem, to pozwoliłbym sobie na stwierdzenie, że w pewnym momencie stracił kontakt z horyzontem i zaczął pikować niebezpiecznie, ku niechybnemu rozbiciu. Szczęśliwie dla wszystkich nie doszło do niej - koniec wystąpienia nadszedł i ulga pojawiła się po obu stronach.

Mimo tylu gorzkich słów pod adresem Marka, cieszę się, że mogłem uczestniczyć w jego prezentacji, bo zgrabnie zaprezentował Robolectric, który wymaga android.jar, o którym wcześniej Konrad nie wspomniał, a jedynie pozwolił sobie na uwagi odnośnie niekompletności Android API, które kończą się komunikatami "Stub!". Jeśli dobrze rozumiem rozbieżność między Markiem i Konradem, to podobną sytuację mamy z bibliotekami Java EE 6 dostarczanymi przez GlassFish w repozytorium mavenowym, które są potrzebne przy kompilacji i odchudzono je o dostarczanie wyłącznie kompletnego API bez kompletnej implementacji. Nic nowego. Dzięki Marek za skorygowanie poprzednika! Już możesz szykować się na lipcową Confiturę!

Kiedy Marek zademonstrował uruchomienie testów z poziomu Maven'a z pomocą wtyczki Easy shell do Eclipse moja ogólna ocena prezentacji lekko się podniosła. Szkoda, że 30 minut prezentacji było do kosza.

Tak dotarłem do przerwy obiadowej. 1h nie pozwalała na wojaże po Krakowie w poszukiwaniu jedzenia, więc skoczyliśmy z Bartkiem "Ryan'em" do pobliskiej restauracji z kebabem. Zaczęło mnie jednak skręcać z obawy o moje przygotowanie, więc skończyło się na kilku gryzach i reszta wylądowała w koszu. Nerwy przed moim wystąpieniem kompletnie odebrały mi apetyt. Okazało się, że również i Bartkowi. Wspólnie przeszliśmy przez jego slajdy. To było dobre posunięcie, bo później okazało się, że nie dałem rady.

I w końcu moje wystąpienie. Pozostawiam jej ocenę samym uczestnikom. Była to moja pierwsza prezentacja o Androidzie, która pozwoliła mi przypomnieć sobie uczucie tremy, która wiąże gardło przed publicznym wystąpieniem. Na prawdę dało mi się to odczuć i samemu zwróciłem uwagę na mój łamiący się głos. Poprzedni prelegenci nie pozostawiali mi złudzeń, że wodolejstwo nie jest tu mile widziane. Machanie rękoma należy odłożyć na bok i oczekuje się prezentacji na wysokim poziomie. Raczej nie byłem przygotowany do tego.

Mimo wszystko jestem z niej zadowolony pod kątem zaangażowania kilku osób w jej przebieg (w ten sposób próbowałem markować niedostateczne przygotowanie). Udało mi się poznać Jurka "AsyncTask", Grzegorza "Service" i Pawła "wyciek Contextu". Pojawiło się jeszcze kilka innych osób, które zechciały zabrać głos, ale ich niestety nie poznałem z imienia. Brawa dla wszystkich. Życzyłbym sobie, aby cała trójca zechciała przyjąć moje zaproszenie na Confiturę. W ich wypowiedziach dało się słyszeć doświadczenie i pewność swoich tez. Takich ludzi potrzeba więcej, aby ich postawa prowokowała do dyskusji podczas konferencji, co ma służyć dalszej wymianie doświadczeń. Jeśli Panowie czytacie ten wpis, zachęcam do kontaktu. Sam też Was będę poszukiwał. Pawła znam już osobiście, a Grzegorza jedynie mailem, więc zostaje jeszcze Jurek.

Pod względem merytorycznym u mnie było...średnio. Jakim to doświadczeniem mogę się mienić, skoro moje przygody z Androidem zacząłem pół roku temu?! Za to pod względem czasowym wypadłem perfekcyjnie. Zacząłem punktualnie, przygotowany psychicznie i sprzętowo. I tak też skończyłem - równo o czasie. Temat mojej prezentacji "RESTful Android" był nietrafiony, bo zdryfował na tematykę współbieżności na Androidzie, ale skoro przed samym rozpoczęciem wspomniałem o tym, czuję się zrehabilitowany. Jeśli tylko nie uraziłem uczestników swoim poziomem merytorycznym, cieszę się, że mogłem ponownie doświadczyć tego błogiego uczucia braku pewności w moje przygotowanie merytoryczne.

Slajdy dostępne są jako JacekLaskowski-cracow.mobi-RESTful-Android-2011.12.09.pdf.

Po moim wystąpieniu podeszło do mnie dwóch programistów androidowych z Comarchu - Maciej i kolega, którego imienia nie zapamiętałem (wybacz), którzy przedstawili mi problemy z dużą liczbą View w Activity (ponad 80) i problemami z działaniem Galaxy S2. Niestety, mimo, że szukali pomocy u mnie, to nie trwało długo, abym zreflektował się, kto tu potrzebuje pomocy - to nie ja im, ale oni mnie mogą pomóc. Mam do nich kontakt i nie zawaham się go użyć! Takich ludzi chciałbym więcej jako prelegentów na Confiturze 2012. Muszę nad nimi popracować jeszcze, bo nieświadomi moich planów względem nich.

Tak zeszła mi prezentacja Bartka. Wybacz Bartek! Zaproszenie na Confiturę wciąż podtrzymuję, więc pozostajemy w kontakcie.

Tak też skończyła się ścieżka wykładowa, ale nie moje poznawanie nowych twarzy. Mimo, że to wciąż konferencja javowa, to mało było osób, które wcześniej znałem. Wciąż zachodzę w głowę, czy Android to pole dla dotychczasowych znajomych z branży? Jakoś niewielu para się Androidem i trudno mi teraz odpowiedzieć dlaczego. Frapuje mnie to, więc niebawem pewnie jakaś odpowiedź się znajdzie.

Na sam koniec trafiłem na kilku napaleńców konferencyjnych, którzy zapowiedzieli już organizację konferencji o urządzeniach inteligentnych w Katowicach! Pozdrowienia dla Piotra "kosarock" i Marcina! Nie tylko zaskoczyli mnie swoim zdeterminowaniem, ale również wyborem miejsca (a może przede wszystkim tego drugiego). Sądziłem, że Kraków i Wrocław promieniują na okolicę tak silnie, że trudno mówić o kolejnej inicjatywie w pobliżu. W samym Krakowie mamy już GeeCON z ekipą z Polish JUG, JDD Proidei z Andrzejem i Anią na czele, 33rd degree Grześka Dudy, teraz cracow.mobi, a jeszcze są SFI i Eclipse DemoCamp. Dodać do tego silne oddziaływanie Poznania (Eclipse DemoCamp, Code Retreat i potencjalnie GeeCON) oraz Warszawy (Confitura, warsjawa i Eclipse DemoCamp), i nie widzę miejsca na nową propozycję w środkowej i południowej Polsce (może za wyjątkiem Łodzi, w której ostatnio mieliśmy do czynienia z mobilization i Code Retreat). Gdybym tylko mógł oddać zapał katowickich organizatorów, to pewnie wielu z Was nie miałoby złudzeń, że w 2012 będzie się mobilnie działo w Polsce, a Katowice stanie się kolejnym miejscem konferencyjnym po cracow.mobi i mobilization. Będę ich wszystkich gorąco dopingował. Z tyloma konferencjami w okolicy, będzie więcej okazji na wymianę doświadczeń. Bardzo się z tego cieszę i kiedykolwiek poproszony o pomoc, zawsze chętnie jej udzielę. Zresztą organizatorzy odgrażali się, że już jestem zaproszony! Z pewną nieśmiałością przyjmuję zaproszenie. Dziękuję!

O 16:45 byłem już w pociągu, aby przed 21 pojawić się w domu. Zmęczony i podekscytowany cieszyłem się, że wcześniej odwołałem udział w Agile Development Day 2011 w Warszawie, które zaplanowane zostało na całą sobotę! Po prostu nie dałbym rady. Tak bardzo chciałem w nim uczestniczyć, że kiedy już się pojawiła w harmonogramie, okazało się, że nie dane mi w niej wziąć udziału. Tak bardzo chciałem móc zasiąść z Jakubem Nabrdalikiem w parze i przy akompaniamencie Krzyśka Jelskiego ponownie wczuć się w melodię TDD. Następnym razem.

Trójka organizatorów cracow.mobi: Mateusz, Maria i Łukasz, których miałem przyjemność poznać podczas konferencji stanęła na wysokości zadania. Jestem im niezwykle wdzięczny, że umożliwili mi wziąć udział w konferencji i to w zaszczytnej roli prelegenta. Niech to będzie dzień, w którym upewniłem się, że inwestycja mojego czasu w rozpoznanie Androida była dobrym wyborem. Nowa technologia, zupełnie nowa klasa urządzeń, nowi ludzie - w roli uczestników, prelegentów i organizatorów. Jestem pozytywnie naładowany na kolejne androidowe przyjemności. Nie mógłbym sobie wymarzyć lepszego zakończenia roku 2011!

Nagrania z konferencji mają być dostępne na kanale mobiledeveloperpl na YouTube. Zapraszam do ich oglądania i komentowania. Uwagi zawsze mile widziane. Już nie mogę doczekać się, kiedy tylko pojawi się nagranie z mojego wystąpienia. Oj wstyd mi, oj wstyd, że można było tak wiele, a dałem tak niewiele. Kolejne książki czekają na moją przychylność i kolejne pomysły na aplikacje. Końcówkę roku 2011 zaplanowałem androidowo.

Październik z Java 7? Tylko, jak to praktycznie wykorzystać?

Czytanie książek technicznych zaczyna przypominać u mnie objawy nałogu. Uwielbiam czytać, a książki informatyczne wręcz pochłaniam. Przyczyna jest bardzo błaha - prostota w pozyskiwaniu wiedzy, a jeśli dodać do tego możliwość poprawienia języka obcego, to jedynie ciągłość tego "procederu" zaczyna mnie niepokoić. Podobnie jak z nałogiem.

Na początku, zwykle jest banalnie, od czasu do czasu. Później ma się wrażenie, że jest dokładnie tak samo - wciąż od czasu do czasu, a jedynie obserwatorzy zauważają, że owe "od czasu do czasu" skróciło się w czasie, tj. jest wciąż od czasu do czasu, ale częściej. Z książkami jest jakoś inaczej - nałóg jest akceptowalny mimo, że z definicji, z nałogiem należy walczyć (patrz pierwsze zdanie w definicji nałogu na Wikipedii). A może jest tak, że czytanie książek nie jest i nigdy nie może być nazwane nałogiem. A więc jak?

W czytaniu książek cenię sobie ułożenie wiedzy, skompletowanie jej w jednym miejscu i różnorodny format - na urządzenia mobilne (epub czy mobi) lub po prostu stary, dobry PDF, albo tradycyjnie - druk. Z ostatnim, moim zakupem Samsung Galaxy S2 dostęp do książek jest jeszcze powszechniejszy - mam je ze sobą wszędzie. Kiedyś chodziłem z jedną pod pachą i było to dosyć uciążliwe, ale teraz mam je zawsze pod ręką. Jestem zachwycony i moja żona jest zachwycona (wyjazdy na zakupy są dla mnie po prostu zaproszeniem do lektury), i dzieciaki też skaczą z radości, bo ojciec przestał marudzić, że "shopping" to już nie marnotrastwo czasu. To chyba nazbyt różowo, co?

I w zasadzie nie byłoby w tym nic nadzwyczajnego, bo każdy z nas ma swoje przywary, więc i moje uzależnienie od czytania można potraktować jak jedno, a skoro to czytanie, to nawet nie jest powszechnie traktowane w tej kategorii (paradoks?), gdyby nie fakt, że dzisiaj dotarła do mnie książka - "Java The Complete Reference", 8th Edition autorstwa Herberta Schildt'a z McGraw-Hill.

Kilka dni temu skończyłem czytać "Hello, Android", wydanie 3 i zaplanowałem sobie, i to właśnie dzisiaj, że zabiorę się za "Pro Android 2" z Apress. Cegła ogromna, bo ponad 700 stron, a mam ją w tradycyjnej postaci - drukowaną, więc taszczenie jej nie uśmiechało mi się zbytnio. Cóż jednak było robić - chce się wiedzieć więcej, to trzeba czasami pocierpieć - Android wciągnął mnie i zamiast samodzielnie rozpracowywać tematy (przynajmniej te początkowe, z którymi na pewno musiałbym się zmierzyć), wolałem postawić na przeczytanie książki. Teraz jednak, z "Java The Complete Reference" o Java 7 i nadchodzącym spotkaniu Warszawa JUG o niej, mam nielada problem. Przypomina mi się historia z osiołkiem i żłobem.

Z jednej strony chciałbym liznąć trochę tych nowości z Java 7 (skoro liznąć i wcześniej osioł to na myśl przychodzi mi scena ze Shreka, w której osioł chciał tylko liznąć gofra - patrz 0:30 w Shrek 4 Polski zwiastun HD), a z drugiej wiem, że nie dane mi z nich skorzystać w najbliższej przyszłości - powiedzmy jeszcze w tym roku. I to mnie właśnie zniechęca. Z trzeciej strony, ucząc się o Java 7 zgłębiałbym niuanse poprzednich wersji, bo nowe zwykle kontrastowane jest ze starym. Jeśli jednak miałbym postawić na inny temat niż Android w tym miesiącu, to byłaby to z pewnością tematyka Java EE 6 z IBM WebSphere Application Server 8. Skoro nie ma ciekawej pozycji książkowej na ten temat, nie mam wyboru i pozostanę jeszcze na dłuższy moment przy Androidzie. Takie wybory lubię najbardziej!

A jak to jest z Twoimi decyzjami - wybierasz książkę, czy raczej samodzielne zmagania z danym tematem z Google pod ręką. Dlaczego nie książka? I w końcu, czy masz już do czynienia z Java 7 produkcyjnie w projekcie? Zamieniam się w słuch.

Zapiski z czwartej części "Hello, Android" - "Next Generation" i piątej "Appendixes"

To już miesiąc od kiedy zadeklarowałem poświęcić swój czas na poznanie Androida i na sam koniec androidowego września, który zacząłem od wpisu Wrześniowy Android, skończyłem czytanie książki "Hello, Android", wydanie 3.

W tym wpisie przedstawię zapiski z czwartej części książki - "Next Generation" oraz części piątej "Appendixes".

Zapiski z poprzednich części książki "Hello, Android" znajdziesz we wpisach:

• Zapiski z pierwszej części "Hello, Android" z 15 września
• Zapiski z drugiej części "Hello, Android" z 21 września
• Zapiski z trzeciej części "Hello, Android" - "Beyond the Basics" z 27 września

Ekrany dotykowe ze wsparciem wielopalcowych gestów

Tak, przynaję, że użycie słowa "wielopalcowych" (zamiast "wielodotykowych") może budzić swego rodzaju "podziw", że mogło mi to przyjść w ogóle do głowy, ale preferuję takie tłumaczenie, bo oddaje ich źródło powstania przez użycie wielu palców, co niekoniecznie może oznaczać, że dotknięć, które pojedynczy palec również może być źródłem, np. podwójne puknięcie. Gdyby ktoś jednak zechciał uzasadnić mój błąd, byłbym niezmiernie wdzięczny.

Rozdział 11. "Multi-touch" omawia zdarzenia generowane przez więcej niż jeden palec.

Wyróżniono gesty związane z jednym palcem: stuknięcie (ang. tap) oraz przesuwanie (ang. drag), np. przy przewijaniu.

Popularność iPhone wymusiła na dostawcach urządzeń z Androidem wsparcie gestów wielopalcowych, np. skalowanie (ang. pinch zoom), tj. zbliżanie lub oddalanie dwóch palców na ekranie w celu zmniejszenia lub zwiększenia treści pod nimi.

Nowa klasa android.view.ScaleGestureDetector do skalowania w Android 2.2.

Autor przedstawia stworzenie prostej przeglądarki obrazków do wyjaśnienia obsługi gestów.

Pojawiły się klasy android.view.MotionEvent, android.view.View.OnTouchListener, android.widget.ImageView, android.util.FloatMath, android.widget.FrameLayout z @drawable oraz android:scaleType="matrix" w pliku układu. Ich znajomość zdaje się być kluczowa do napisania własnych aplikacji, które udostępniają tego rodzaju interakcję z użytkownikiem.

@drawable wskazuje na dowolny JPG lub PNG z res, pewnie najczęściej z podkatalogu drawable-nodpi (trochę więcej o tym poniżej).

android:scaleType="matrix" - macierz do zmiany położenia (przesuwanie) i skalowania obrazka - za pomocą macierzy możemy wyrazić dowolne przekształcenie (i znowu wracam do macierzy, które niekoniecznie przypadły mi do gustu na studiach).

Pojawiają się również klasy android.graphics.Matrix (głównie metody Matrix.set() oraz Matrix.postTranslate()), android.graphics.PointF oraz użycie metody ImageView.setImageMatrix(matrix). Odnotowane do dalszego rozpoznania.

W trakcie czytania tego rozdziału, doświadczam tego błogiego stanu, w którym poznawanie urządzenia odbywa się przez poznawanie możliwości jego oprogramowywania, czyli kontrolowania na niższym niż na poziomie końcowego użytkownika (aczkolwiek wciąż nie tak nisko jak na poziomie systemu operacyjnego, poniżej poziomu Dalvik VM). Jestem zdania, że to właśnie programiści mają tę przewagę nad końcowymi użytkownikami lub administratorami (którzy również są swego rodzaju końcowymi użytkownikami produktu), że wiedzą jak i dlaczego dana cecha tak działa, a nie tylko jak.

W tym samym momencie, mój syn przerabia na matematyce (3 klasa gimnazjum) pojęcie podobieństwa trójkątów, w którym termin "skala" jest fundamentalne. Mimo, że takie proste na pierwszy rzut oka, to i tak zaskoczyła mnie łatwość wyliczania skali powiększenia/pomniejszenia obrazka za pomocą przyrównania wyjściowej odległości do bieżącej (nowej). To są te chwile, w których stwierdzam, że trzeba było uważać na lekcjach matematyki, kiedy i tak należało siedzieć w sali i trawić, co podaje wykładowca. Zakładam przy tym, że Ci, którzy uczą, robią to właściwie i z należytym zaangażowaniem.

UWAGA: Nie wszystkie urządzenia androidowe mają wsparcie sprzętowe dla obsługi równań z użyciem typu float i częste ich użycie może znacząco wpływać na prędkość działania aplikacji.

UWAGA: W książce zwrócono również uwagę na odśmiecacz (GC) w Javie i aby niepotrzebnie nie tworzyć nowych obiektów, które za moment trafią do kosza i wydłuży działanie GC, wykorzystuje się ten sam obiekt zmieniając jego stan. Tutaj Clojure, który wymusza programowanie z krótkotrwałymi obiektami (cecha języka funkcyjnego na JVM, w którym nacisk kładzie się na niezmienność struktur danych, aby tym samym ułatwić programowanie współbieżne) nie sprawdzi się. Ale czyż umiejętność wyboru właściwego narzędzia do problemu nie jest podstawowym wymaganiem w naszej branży?

android:theme="@android:style/Theme.NoTitleBar.Fullscreen" (mała litera S w Fullscreen!) - widok zajmuje całą dostępną przestrzeń bez paska tytułowego lub postępu na górze.

Obsłużenie zdarzenia wymaga, aby metoda przechwytująca je zwróciła true, np. implementacja onTouch(View v, MotionEvent event) { return true; }

Emulator na niewiele się zda, ponieważ nie wspiera gestów wielopalcowych. Nie pozostaje nic innego jak zaopatrzyć się w prawdziwe urządzenie i testowanie aplikacji bezpośrednio na nim.
Obsługa zdarzeń dot. gestów to jak przetwarzanie całej masy komunikatów i niektóre należy filtrować, aby czas spędzony na ich obsłudze nie wpływał miażdżąco na działanie aplikacji.

Teoretycznie Android API wspiera 256 palców, ale większość urządzeń kończy swoje wsparcie na 2 (tutaj autor powołuje się na osobników z filmu Faceci w Czerni, w którym istnienie istot z więcej niż 10 palcami u rąk nie jest czymś nadzwyczajnym). Nie pomyślałem o tym wcześniej, ale biorąc pod uwagę, jak wiele różnych modeli urządzeń z Androidem istnieje na rynku, można sobie śmiało wyobrazić takie, które obsługują wręcz wiele osób, np. przewodniki interaktywne w muzeach, halach, konferencjach, itp. (już w mojej głowie tworzy się obraz dzieciaków pochylonych nad dotykowym ekranem, który prowadzi przez muzeum, czy inny obiekt, które na różne sposoby weryfikują poprawność wsparcia wielu palców).

Autor poleca stronę http://gestureworks.com, aby przekonać się, jak wiele gestów jest już używanych w aplikacjach. Jako użytkownik Mac OS X na MacBook Pro korzystam z gestów z 4 palcami (góra/dół do pokazania wszystkich okien) i uważam je za co najmniej interesujące (aczkolwiek przyzwyczajenie się do nich, zwane nauczeniem się ich, trało dłuższą chwilę).

Widgety na ekranie początkowym - stronie domowej

Widgety w Androidzie to niewielkie (funkcjonalnie) aplikacje uruchamiane bezpośrednio na pulpicie, np. zegarek, pogoda, wyświetlanie obrazka, itp.

Nie ma wsparcia do tworzenia widgetów w Eclipse ADT. Tworzymy projekt androidowy ze zmianami - nie jest potrzebna początkowa aktywność (activity), a w AndroidManifest.xml używamy <receiver> z <intent-filter> zamiast <activity>. Układ elementów graficznych określamy w pliku XML wskazany przez <meta-data> w AndroidManifest.xml.

Przeczytałem o NinePitch, który jest rozszerzalnym obrazkiem PNG, często używanym jako tło dopasowujących się przycisków. Do ich tworzenia korzystamy z narzędzia draw9patch (w Android SDK w katalogu tools). Utworzony plik musi mieć rozszerzenie 9.png i być w res/drawable.

Klasa bazowa widgetów android.appwidget.AppWidgetProvider.

Uruchomienie widgeta podobne do aplikacji z tą różnicą, że po wgraniu musimy jawnie uaktywnić przez umieszcznie na pulpicie. Widget może odświeżać swoją zawartość. Wystarczy zadeklarować intent APPWIDGET_UPDATE i pojawienie się zdarzenia wzbudza onUpdate naszego widgeta. Częstotliwość aktualizacji określana jest parametrem android:updatePeriodMillis w widget.xml wskazywanym przez AndroidManifest.xml. Uwaga na częstość odświeżania, bo bateria urządzenia bardzo niewielka i na niewiele starczy.

Więcej na temat widgetów w dokumentacji App Widgets.

Dynamiczne tapety

Autor zaprezentował utworzenie projektu z użyciem OpenGL. Ponownie zabawa z AndroidManifest.xml - użycie znacznika <service>, ponownie intent-filter z meta-data z android:name="android.service.wallpaper".

Po raz pierwszy przeczytałem o usługach (ang. service) uruchamianych w tle, które reagują na zdarzenia z urządzenia. Klasa macierzysta android.app.Service i po trosze przypomina Activity - mamy onCreate() i onDestroy(). Są jeszcze onStartCommand() przy uruchomieniu usługi.

Kolejny raz, kiedy przychodzi dokładniejsze rozpoznanie tematu, autor skraca temat wskazując na dokumentację.

Tworzenie dynamicznych tapet sprowadza się do rozszerzenia klasy android.service.wallpaper.WallpaperService. Poznaję również nieodłączną klasę tapet android.service.wallpaper.WallpaperService.Engine.

Czasami autor przesadza z wprowadzaniem czytelnika w arkana programowania aplikacji na Androida i niepotrzebnie tłumaczy, jak programować w Javie, np. konstrukcję klas wewnętrznych oraz wykorzystanie final dla pól poza ich ciałem, aby były widoczne. Później jeszcze przydługawe omówienie generowania domyślnych ciał metod klasy nadrzędnej oraz rozwiązywania problemów braku właściwych importów z Quick Fix lub Organize Imports w Eclipse. Niejednokrotnie byłem zaskoczony, że w ogóle przedstawia się takie tematy.

Przy okazji poznawania tapet w Androidzie mogłem poczytać o klasie java.util.concurrent.Executor. Podobnie jak w Swingu należy bacznie rozplanować zrównoleglanie operacji, szczególnie tych, które modyfikują elementy graficzne. W przykładzie korzysta się z java.util.concurrent.Executors.newSingleThreadExecutor().

Widzę u siebie duże braki w temacie zmian w Java SE 5 i nowszych w obszarze java.util.concurrent. Kolejna książka musi być właśnie o tym. Sugestie mile widziane (poza Java Concurrency in Practice Brian's Goetz'a, którą już niejednokrotnie zaczynałem, ale chyba dopiero teraz dojrzałem do zmierzenia się z nią).

Testowanie

Należy testować. Każdy to wie i trochę niepoważnie przypominać o tym. Jeśli testowanie w Javie stanowiło swego rodzaju wyzwanie, to zmiana środowiska na androidowe będzie nakładała dodatkowe ograniczenia i wymagania. Wiele różnych rodzajów urządzeń wymaga stworzenia wielu AVD w Eclipse. Należy testować na różnych wymiarach ekranów i rozdzielczości. Nie zapominamy o testowaniu w różnych orientacjach - poziomie i pionie (w Emulatorze Ctrl+F11 lub 7 i 9 na klawiaturze).

Podczas uruchamiania określamy w zakładce Target, Deployment Target Selection Mode na Manual i wybieramy odpowiednie urządzenie. Wskazanie tego właściwego urządzenia odbywa się przez AndroidManifest.xml przez znacznik <uses-sdk> z elementami android:minSdkVersion oraz android:targetSdkVersion. W ten sposób określamy minimalne wymagania wersji Androida ze wskazaniem na zalecaną wersję.

Poznaję wyjątek java.lang.VerifyError, który pojawia się, kiedykolwiek wywołujemy metodę, która nie istnieje podczas uruchomienia (a istniała podczas kompilacji). Dosyć popularny wyjątek, kiedy zapomnimy o różnych wersjach Androida i różnicach między nimi w klasach i ich metodach. Rozwiązaniem było zastosowanie wzorców Delegator i Fabryka. Jak widać, przy okazji poznawania Androida można poznać również wzorce. Krótko i rzeczowo - mi się podobało.

Następnie autor przedstawia sposoby na poznawanie Androida od strony jego błędów. Warto od czasu do czasu zajrzeć do kodów źródłowych Android API - platform/frameworks/base.git. Zmiany w klasach opatrzone są zwykle komentarzem ze wskazaniem na błędy, które zapoczątkowały je.

Jest jeszcze trochę o podkatalogach w res dla obrazków na różne rozdzielczości ekranów - drawable-hdpi, drawable-mdpi, drawable-ldpi lub drawable-nodpi. Dowiedziałem się również o różnych kwalifikatorach w nazwach katalogów, dla różnych wersji językowych, rozdzielczości, wymiarach ekranu, położeniu (orientacji), wersji SDK i in. Więcej niż jeden kwalifikator oddziela się w nazwie myślnikiem.

Na koniec wzmianka o android:installLocation w AndroidManifest.xml, który wskazuje na możliwość instalowania aplikacji na karcie SD (zamiast bezpośrednio na urządzeniu). Dwie dozwolone wartości auto i preferExternal. Brak wartości oznacza instalację na urządzeniu. Google zaleca, aby nie instalować na karcie SD aplikacji korzystających z pewnych funkcjonalności Androida, np. tapety, usługi, widgety.

Ponownie, na koniec rozdziału zalecenie, aby zapoznać się z oficjalną dokumentacją, aby poznać więcej. Normalka.

Publikowanie w Android Market

Na zakończenie części czwartej rozdział o udostępnianiu aplikacji, czyli publikowaniu aplikacji w Android Market. Autor przeprowadza przez cały proces, począwszy od wyboru odpowiedniego i unikatowego pakietu (patrz AndroidManifest.xml), testowania, podpisywania i wrzuceniu do Android Market.

Raz wybrany pakiet aplikacji nie podlega zmianie (bez odinstalowania aplikacji). Niech to będzie pakiet główny naszych klas javowych, np. pl.japila.aplikacja (tzn. ta jest zarezerwowana dla moich aplikacji, ale rozumiem, że Ty rozumiesz, że chodzi o odwrotną notację z domenami w tle, jak w Javie).

Do zapamiętania: "Make your program do one thing well, rather than a lot of things poorly." 

Poznaję android:versionCode i android:versionName z AndroidManifest.xml.

Warto zapoznać się z User Interface Guidelines.

Później omówienie apk i podpisania z użyciem keytool, jarsigner lub oprzeć się na Eclipse ADT - Android Tools > Export Signed Application Package. Więcej na Signing Your Applications. Na koniec otrzymujemy podpisany plik apk. Z plikiem apk udajemy się do Android Market i po opłaceniu jednorazowej, podobno niewielkiej, opłaty, wybieramy Upload Application. Wypełniamy formularz, w którym wyłączamy Copy Protection (podobno jedynie irytuje użytkowników i wcale nie zabezpiecza), wybieramy All Current and Future Countries w Locations i nie podajemy numeru telefonu - użytkownicy skorzystają z niego w najmniej odpowiednim momencie (!) Publish i aplikacja jest dostępna od ręki w Markecie.

Aktualizacja aplikacji wymaga zmiany android:versionCode o jeden w górę i android:versionName w AndroidManifest.xml. Publish i zmiana dostępna. Sugeruje się częste aktualizacje - utrzymuje (często błędne?) przekonanie o ciągłym wsparciu aplikacji (co nie wprost może być faktycznie prawdą, bo w końcu nowe funkcje są wprowadzane) oraz nasza aplikacja znajduje się w Recently Updated, co podnosi widoczność aplikacji.

Warto rozważyć opublikowanie aplikacji w dwóch wersjach - darmowej (light) oraz płatnej (pro). Płatną aplikację możemy zmienić na darmową, ale nie na odwrót.

Obecna wersja Android Market nie daje możliwości zakupienia własnej aplikacji.

Dodatek: "Różnice programowe" w Android API vs Java API

Pisanie aplikacji na Androida sprowadza się w dużej mierze do umiejętności posługiwania się Java SE 5 API. Istnieje jednak kilka różnic wynikających ze specyficznego środowiska, na którym będą działały aplikacje mobilne.

Zanim aplikacja trafi na urządzenie androidowe, aplikacja przechodzi proces kompilacji, jak to ma miejsce w typowych aplikacjach javowych, z tą różnicą, że bajtkod jest dodatkowo tłumaczony na instrukcje Dalvik VM.

Wszystkie konstrukcje języka Java SE 5 są wspierane (nie dotyczy to jednak API, a wyłącznie samego języka Java). W ten sposób możliwe jest korzystanie z aplikacji javowych, które nie były pierwotnie pisane na Androida (z dokładnością do używanych bibliotek i API, które mogą być niedostępne - o tym za moment).

Uwaga na użycie typów prostych float oraz double. Niektóre urządzenia mogą nie posiadać wsparcia sprzętowego dla operacji zmiennoprzecinkowych i przez to działanie aplikacji będzie znacznie opóźniane przez obliczenia aplikacyjne.

Wątki są wspierane przez przydzielanie kawałków czasu na uruchomienie jednego, tzw. time slicing. Stąd korzystanie z wątków powinniśmy sprowdzić do użycia jednego bądź maksymalnie dwóch. Pierwszy będzie dedykowany do obsługi interakcji z użytkownikiem, a drugi dla długotrwałych operacji, np. obliczenia, operacje I/O.

Dalvik VM wspiera słowo kluczowe synchronized oraz Object.wait(), Object.notify(), Object.notifyAll() oraz (preferowane jako konstrukcje wyższego poziomu) pakiet java.util.concurrent.

Na urządzeniach mobilnych ograniczanych dostępnymi zasobami tym bardziej ważne jest zamykanie/zwalnianie zasobów tak szybko, jak to możliwe, korzystając z oferowanych przez nie metod close() lub terminate() (super byłoby, gdyby można było stosować try-with-resources z Java 7).

Android wspiera większą część Java SE 5 API, poza tymi, których użycie i tak nie miałoby sensu. Wspierane:

• java.awt.font
• java.beans
• java.io
• java.lang - poza java.lang.management
• java.math
• java.net
• java.nio
• java.security
• java.sql
• java.text
• java.util - wraz z java.util.concurrent - dopiero teraz zauważam, że oferowane w tym pakiecie klasy są rzeczywiście uproszczeniami i powinny być oferowane w Javie od pierwszego jej dnia publikacji
• java.crypto
• java.microedition.khronos
• javax.net
• javax.security - poza kilkoma podpakietami - auth.kerberos, auth.spi, sasl
• javax.sql - poza podpakietem rowset
• javax.xml.parsers
• org.w3c.dom - bez podpakietów
• org.xml.sax

Jakkolwiek udostępniono JDBC API, to zaleca się korzystanie z android.database do dostępu do SQLite (preferowanej bazy danych SQL na Androidzie) Poza standardowymi bibliotekami Java SE 5 API mamy jeszcze org.apache.http, org.json, org.xml.sax i org.xmlpull.v1. Na tym kończę lekturę książki. Jestem zachwycony, że mogłem ją przeczytać, mimo że często doprowadzała mnie do pasji spłycając analizę problemu do "Po więcej należy udać się do oficjalnej dokumentacji Androida". Recenzja wkrótce.

Układ w Androidzie - jedno słowo, dwa znaczenia

Trafiłem na pokaźne źródło wiedzy nt. Androida - serwis mobiletuts+, a tam trzy serie artykułów - Android User Interface Design, Android Fundamentals oraz Android Essentials. Poza tym wiele dodatkowych artykułów spoza tych serii, a wszystkie wydają się być pisane zrozumiale i przede wszystkim zwięźle. Wszystko jedynie za koszt Twojego czasu.

Czytając Android User Interface Design: Layout Basics zrozumiałem, a właściwie napisano, że layout (układ, rozkład) może oznaczać dwie rzeczy w Androidzie - plik XML z rozkładem elementów wizualnych w katalogu res/layout lub klasę, która odpowiada za pożądany rozkład, odpowiadającej elementowi we wspomnianym pliku XML. Dzięki temu możemy wszystko oprogramować, albo obsłużyć deklaratywnie, wynosząc do pliku XML.

Weźmy na przykład układ formatki, z której korzystam do wprowadzenia lokaty w Lokatniku - res/layout/deposit.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:orientation="vertical"
  android:layout_width="match_parent"
  android:layout_height="match_parent">
  <TextView
    android:textAppearance="?android:attr/textAppearanceLarge"
    android:id="@+id/textView1"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/deposit_name"></TextView>
  <EditText
    android:id="@+id/editText1"
    android:layout_width="match_parent"
    android:layout_height="wrap_content">
    <requestfocus></requestFocus>
  </EditText>
  <TextView
    android:textAppearance="?android:attr/textAppearanceLarge"
    android:id="@+id/textView2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/bank_name"></TextView>
  <EditText
    android:id="@+id/editText2"
    android:layout_height="wrap_content"
    android:layout_width="161dp"></EditText>
  <TextView
    android:textAppearance="?android:attr/textAppearanceLarge"
    android:id="@+id/textView3"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/procent_text"></TextView>
  <EditText
    android:id="@+id/editText3"
    android:layout_height="wrap_content"
    android:inputType="number"
    android:layout_width="160dp"></EditText>
  <TextView
    android:textAppearance="?android:attr/textAppearanceLarge"
    android:id="@+id/textView4"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/amount_text"></TextView>
  <EditText
    android:id="@+id/editText4"
    android:layout_height="wrap_content"
    android:inputType="number"
    android:layout_width="158dp"></EditText>
  <LinearLayout
    android:id="@+id/linearLayout1"
    android:layout_width="match_parent"
    android:layout_height="wrap_content">
    <Button
      android:layout_width="fill_parent"
      android:layout_height="wrap_content"
      android:layout_weight="1"
      android:text="@string/save_label"
      android:id="@+id/save"></Button>
    <Button
      android:layout_width="fill_parent"
      android:layout_height="wrap_content"
      android:layout_weight="1"
      android:text="@string/discard_label"
      android:id="@+id/discard"></Button>
  </LinearLayout>
</LinearLayout>

Plik układu deposit.xml korzysta z elementu LinearLayout, którego javowym odpowiednikiem jest klasa android.widget.LinearLayout. I tak dla każdego elementu.

Podczas uruchomienia mamy taki oto efekt:

Budowanie układu może być bardzo zajmującym zajęciem, więc warto wesprzeć swoje wysiłki korzystając z dedykowanego edytora w Eclipse ADT - Eclipse layout resource designer (aczkolwiek dochodzą mnie słuchy, że nie jest to najbardziej wyrafinowane, a przez to i pomocne, narzędzie). Dla mnie, do tej pory, narzędzie spełnia pokładane w nim nadzieje i choćby dla celów poznawczych zwykle od niego zaczynam budowanie układu. Poniżej graficzna reprezentacja powyższego pliku XML w edytorze Eclipse.

Z ostatnimi zmianami w aplikacji Lokatnik (dostępna w repo na githubie) przygotowałem sobie przyczułek do zapisu lokat do lokalnej bazy danych, a to oznacza, że nadeszła pora popróbować się z SQLite. Już nie mogę się doczekać!

Zapiski z trzeciej części "Hello, Android" - "Beyond the Basics"

W Zapiski z pierwszej części "Hello, Android" oraz Zapiski z drugiej części "Hello, Android" przedstawiłem swoje spojrzenie na zawartość dwóch pierwszych części "Hello, Android", wydanie 3. Dzisiaj skończyłem trzecią część "Beyond the Basics".

Już wspominałem, że książka wręcz przykuwa do siebie swoją prostotą i nie zagłębia się w sztuczki i kruczki związane z danym tematem. Książka jest wprowadzeniem we wszystko, co możemy znaleźć na platformie Android bez zagłębiania się w niuanse posługiwania się daną cechą. "Poszukiwacze skarbów", czyli osoby, które co najmniej wertują książki w poszukiwaniu czegoś odkrywczego, mogą się zawieść jej zawartością, ale to może równie dobrze świadczyć, że są to osoby, które już spędziły trochę czasu z Androidem i być może jeszcze nie wiedzą dokładnie, jak on działa, ale wiedzą wystarczająco wiele o każdej z cech. Porównałbym to do mojego rozumienia roli architekta i specjalisty w IBM (pewnie w każdej innej firmie sprzedającej oprogramowanie wspomagające budowanie rozwiązań końcowych jest podobnie). Architekt posiada szeroką wiedzę, która jest stosunkowo płytka patrząc na każdy z produktów, ale wystarczająca, aby zaproponować architekturę systemu. W przeciwieństwie do architekta, specjalista wie dużo na temat wybranego produktu lub produktów, ale z pewnością będzie to podzbiór produktów, o których cokolwiek może powiedzieć architekt. Zwykłem to porównywać do wiedzy poziomej, w poprzek wielu produktów u architekta, a wiedzy pionowej w bardzo niewielu produktach, w szczególności jednego, u specjalisty. Książka "Hello, Android" jest bardzo dobrym kompedium wiedzy na temat platformy Androida dla architekta, ale zdecydowanie na niewiele się zda dla osób, które potrzebują wiedzy specjalistycznej, tej pionowej, np. podczas rozwiązywania problemu lub poszukiwaniu wiedzy tajemnej. To nie jest ten typ książki.

Już z samego tytułu można wnosić, że jej celem jest jedynie wprowadzenie, ale takie szersze, do wielu, jeśli nie wszystkich, głównych funkcjonalności oferowanych przez platformę Android. Uważam, że książka jest doskonałym wprowadzeniem dla początkujących i jeszcze przed częścią 4. "The Next Generation" śmiało mogę ją polecić wszystkim, którym marzy się zrozumienie istoty programowania w Javie na platformę Android lub samodzielnym spróbowaniem się z tematem tworzenia aplikacji androidowej.

Śmiem również twierdzić, że nie dane mi było jeszcze czytać książki, która swym rozmiarem nie przerażałaby mnie, lub nastawiała na dłuższą lekturę, a jednocześnie była na tyle bogata w treść, aby stanowić doskonały przyczułek do dalszych badań. Mógłbym nawet posunąć się do stwierdzenia, że często była zbyt przewidywalna w swojej prostocie i kiedykolwiek można byłoby spodziewać się czegoś bardziej trudnego, autor po prostu kończył rozdział proponując odnośniki do powszechnie dostępnej dokumentacji, np. tej na Android Developers.

W części trzeciej dowiadujemy się o możliwości komunikacji poza urządzenie, np. komunikacji z zewnętrznymi stronami, zabawą z JavaScript oraz użyciem usług RESTowych. Jest też dostatecznie wiele na temat SQLite i OpenGL, więc śmiało możnaby stwierdzić, że dla każdego coś dobrego. Uważam, że ta przekrojowa wiedza w książce zadowoli nawet najbardziej wybrednego czytelnika, bo choćby sam styl pisarski autora gwarantuje dobrą zabawę, nawet przy czytaniu o czymś, co już znamy. W naszym przypadku, czytanie angielskojęzycznych książek pisanych przez rodowitych anglojęzycznych już samo w sobie daje zysk, więc trudno mówić o stracie, jeśli poświęcimy tej książce trochę swojej uwagi. Ja nie mogę narzekać.

Moje nieśmiałe trudy związane z pisaniem aplikacji androidowej Lokatnik można znaleźć w repozytorium android-examples. I tu mam pytanie do znawców tematu posługiwania się gitem na GitHubie. Chciałbym stworzyć jedno repozytorium, np. android-examples z wieloma aplikacjami, np. Lokatnik czy Powitanie (czyli tak, jak jest teraz), ale nie chciałbym podczas git commit w Eclipse dla Lokatnik być informowanym o zmianach w drugim projekcie - Powitanie i vice versa. Czy jest na to rozwiązanie inne niż stworzenie dwóch oddzielnych repo?

ListView w res/layout czy android.app.ListActivity?

To chyba jedno z tych pytań dotyczących zalet definiowania widoku (rozkładu elementów graficznych na ekranie) deklaratywnie jako zasób w res/layout w porównaniu z oprogramowywaniem go jako podklasa android.app.Activity.

W przykładzie Hello, Views > List View użyto tego drugiego podejścia, w którym widok w większości budowany jest w ramach podklasy android.app.ListActivity z rozkładem R.layout.list_item.

Przeglądając android.widget.ListView trafiłem na możliwość definiowania wielu elementów deklaratywnie, tak że ostatecznie moja wersja prezentuje się nieznacznie inaczej. Chciałoby się wręcz napisać lepiej, ale tutaj moja skromność bierze górę, więc pozostanę przy skromniej.

package pl.japila.android;

import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.AdapterView;
import android.widget.AdapterView.OnItemClickListener;
import android.widget.ListView;
import android.widget.TextView;
import android.widget.Toast;

public class ContactsActivity extends Activity {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        this.setContentView(R.layout.main);

        ListView lv = (ListView) findViewById(R.id.listView1);
        lv.setOnItemClickListener(new OnItemClickListener() {
            public void onItemClick(AdapterView<?> parent, View view, int position, long id) {
                Toast.makeText(getApplicationContext(), ((TextView) view).getText(), Toast.LENGTH_SHORT).show();
            }
        });
    }
}

Użyty widok R.id.listView1 wygląda następująco:

<?xml version="1.0" encoding="utf-8"?>
<ListView xmlns:android="http://schemas.android.com/apk/res/android"
     android:id="@+id/listView1"
     android:layout_height="fill_parent""
     android:layout_width="fill_parent""
     android:entries="@array/names_array"
     android:textFilterEnabled="true"
     android:clickable="true">
</ListView>

Rozumiem, że jeśli pozycje na liście są statyczne (jak w przykładzie) to android:entries (linia 6) w znaczniku ListView wystarczy. Zastanawia mnie, czy istnieje jakakolwiek przewaga użycia klasy android.app.ListActivity. Na chwilę obecną nie widzę żadnej. W końcu zawsze mogę dostać się do odpowiedniego elementu widoku przez View.findViewById() lub Activity.findViewById(), więc mogę równie wiele w obu przypadkach. Czy ktoś mógłby uchylić rąbka tajemnicy, dlaczego/kiedy powinienem stosować jedno nad drugie?

Zapiski z drugiej części "Hello, Android"

Jak już pisałem w Zapiski z pierwszej części "Hello, Android", Pragmatic Programmers udostępnił mi darmową wersję "Hello, Android", wydanie 3, którą powoli acz nieprzerwanie czytam w wolnych chwilach - podczas dojazdów do/od klienta, a zwykle wieczorem. Nie sądzę, aby dane mi było całkowicie poświęcić się Androidowi, czy osiągnąć szczyty tworząc aplikacje mobilne na niego, ale frajdy jest z nim co niemiara (właśnie uzmysłowiłem sobie, że jest to mój pierwszy raz, kiedy napisałem "co niemiara" i to początkowo z błędem!). Twierdzę, że nauka Androida pomaga zrozumieć tworzenie aplikacji graficznych w ogólności, więc może przydać się również poza obszarem tworzenia aplikacji mobilnych. Poznawanie nowego, jeśli jeszcze dodatkowo podparte stosunkowo gładkim wejściem w temat, najwyraźniej sprawia mi dużo zadowolenia.

Dzisiaj skończyłem czytać 2. część zatytułowaną "Android Basics" i przyznam, że, ku mojemu ogromnemu zdumieniu, czytanie jej na S2ce bardzo przypadło mi do gustu. Obawiałem się, że będzie mi brakowało możliwości oznaczania sekcji, do których warto wrócić, podczas dalszej nauki, ale od kiedy znalazłem tę funkcję w czytniku Amazon Kindle for Android i mam dodatkowo możliwość umieszczania notatek - "zapisków na marginesie", jestem w pełni usatysfakcjonowany. Drukowanie odeszło do lamusa. Dodatkowo jest funkcja tłumaczenia słówek, co tym bardziej uzasadnia moją inwestycję (warto przypomnieć, że jest to bodaj pierwsza moja inwestycja stricte "naukowa" powyżej 1000 PLN i krążyłem koło niej przez miesiące rozważając iPhone, iPad, Kindle i właśnie smartfona z Androidem - HTC Sensation lub Samsung Galaxy S2). Chciałbym, aby dalsze inwestycje były tak udane.

Dzięki lekturze oswoiłem się z tworzeniem interfejsu użytkownika, opanowałem rozumienie znaczenia aktywności (android.app.Activity), widoków (android.view.View) i poznałem klasy android.content.Intent oraz android.widget.Toast. Poznałem AndroidManifest.xml i generowaną klasę R. Bardzo proste (żeby nie napisać prostackie) aplikacje są już w moim zasięgu. Kiedykolwiek widzę to niewielkie okienko w czytniku Google Reader, które informuje o oznaczeniu wpisu gwiazdką, już wiem, że użyto Toast. Zacząłem przyglądać się aplikacjom, które używam na S2ce, pod kątem użytych klas i jak rozwiązano komunikację pomiędzy aktywnościami (wciąż zastanawia mnie, jak napisano górną belkę w Google Reader, ale rozumiem, że wszystko w swoim czasie). W rozdziale mogłem zapoznać się z LogCat - widokiem Eclipse ADT do przeglądania zapisów w dzienniku Androida i co mnie niezwykle zaskoczyło, są tam również zapisy z fizycznego urządzenia, kiedy podłączone jest do komputera po USB. Trzeba było widzieć moją minę, kiedy poszukując wpisów z klasy android.util.Log, zobaczyłem zdarzenia o wygaszaniu ekranu, ładowaniu baterii i w ogóle niskopoziomowych zdarzeń, które fruwają po "magistrali" androidowej. Aż do rozdziału 5. "Multimedia" bawiłem się przednio.

Od rozdziału 5. "Multimedia" zacząłem się lekko nudzić. Może dlatego, że oswoiłem się trochę ze środowiskiem i gdyby narysować krzywą ilości wiedzy, jaką musiałem przyswoić względem rozdziałów, to naturalnie na początku było jej więcej i chyba była bardziej przydatna. Mimo, że daleko mi do tytułu znawcy tematu, to zdążyłem już nabrać pewności, że tytuł jest na wyciągnięcie ręki i nie jest to szczególnym wyzwaniem (czyżbym był zbyt pewny siebie?!). Ot, programowanie w Javie z nowym API. Tego doświadczyłem już wielokrotnie, więc kolejne ślęczenie nad dokumentacją, wcale mnie nie przeraża. Oczywiście, wymaga to wielu godzin spędzonych nad dokumentacją i ciągłego konfrontowania jej w praktyce, ale obawiałem się, że całe środowisko będzie wymagało całkowitej zmiany myślenia, przyzwyczajeń, czy czegoś w ten deseń. Nic bardziej mylnego. Uważam, że wybór S2ki był strzałem w dziesiątkę, bo swoimi możliwościami - ekran, procesor, pamięć - zdejmuje ze mnie karby zestawiania właściwego środowiska wykonawczego, co niejednokrotnie wpływa na ogólny pogląd sprawy i dalszej nauki. Dodatkowo, wejście w temat Androida z książką "Hello, Android" jest dopasowane na miarę. Dziękuję Bartek za pomoc! (patrz jego komentarz do wpisu Wrześniowy Android).

Rozdział 5. to omówienie sposobów na odgrywanie muzyki w tle, czy podczas wciśnięcia przycisków w aplikacji, wyświetlanie filmów i na zakończenie wprowadzenie do przechowywania stanu aplikacji w przestrzeni zarezerwowanej dla niej bezpośrednio na urządzeniu lub karcie SD. Na szczęście jest tego tyle, aby dać ogólny pogląd, bez wnikania w szczegóły. I dobrze, bo na tym etapie nie jest mi to potrzebne. Nie mogę doczekać się przedstawienia SQLite, ale to już wiem, że wcześniej zapoczątkuję wieczorną lekturą artykułu Understanding Android local data store APIs, na który dzisiaj trafiłem. Więcej na moim kanale @jaceklaskowski na twitterze. Zapraszam do nasłuchiwania.

Przy okazji, coraz częściej dochodzą do mnie głosy, że wstrzeliłem się z tym moim androidowym wrześniem w plany wielu osób, które również rozważały wejście w Androida. Super móc zamienić słowo z innymi - na blogu, Google Buzz, czy GTalku, rozumiejąc, o czym się do mnie mówi. Niesamowite uczucie wszechobecnego wsparcia i wspólnego badania tematu. Cudownie, że dzięki Androidowi mam również okazję poznać nowe osoby. Bezcenne! Pojawiła się wręcz oferta przeprowadzenia przeze mnie autorskiego szkolenia z Androida. Wszystko to sprawia, że aż się chce zintensyfikować wysiłki. Chyba złapałem falę! :)

Znikające okienka z android.widget.Toast

Przykłady dostępne w zestawie Technical Resources (oznaczone Tutorial) z łatwością spełniają większość potrzeb nowicjusza w temacie tworzenia aplikacji androidowych. Pisane są przystępnym językiem, tak że bez względu na znajomość Javy, czytelnik powinien odnaleźć się w nawale informacji. Polecam!

Mam już za sobą przestudiowanie Hello World i zabrałem się za Hello Views.

Analizując przykłady trafiłem na klasę android.widget.Toast:

"A toast is a view containing a quick little message for the user."

Ku mojemu zdziwieniu klasa nie dziedziczy po android.view.View czy android.app.Activity, ale zakładam, że tworzy rodzaj Activity na potrzeby wyświetlenia komunikatu użytkownikowi. Komunikat może pochodzić z "resource" (a już miałem napisać "zasób", ale dla dobra sprawy pohamowałem się) lub podany jest jawnie (niezalecane ze względu na lokalizację aplikacji). Wywołujemy metodę statyczną Toast.makeText(Context context, CharSequence text, int duration) i pojawia się okienko z wybranym tekstem. Przypomina mi to w zastosowaniu javax.swing.JOptionPane, ale Toast znika samo (po zadanym czasie, np. przez stałą Toast.LENGTH_SHORT lub Toast.LENGTH_LONG).

W repo android-examples/Powitanie jest już wersja aplikacji z użyciem Toast.makeText() - wyświetla imię podane przez użytkownika w polu tekstowym. Wciąż nic imponującego, ale utrzymuje mnie w ciągłym kontakcie z nowym środowiskiem, a to bardzo ważne na początku.

Początkowy ekran aplikacji androidowej - o intent-filter

Nie tak dawno temu zastanawiałem się nad sposobem, w jaki Android wybiera główny ekran aplikacji, co wiedziałem, że jest reprezentowane przez aktywność (ang. activity) - podklasę android.app.Activity. Każda "odsłona" widoku to kolejna aktywność na stosie wyświetlanych ekranów. Chcesz coś wyświetlić użytkownikowi, stwórz odpowiednią aktywność.

Pamiętaj: Aktywność musi być zarejestrowana w pliku konfiguracyjnym aplikacji androidowej AndroidManifest.xml przez znacznik <activity> (z jedynym wymaganym elementem android:name).

Wyświetlenie widoku odbywa się przez metodę android.content.Context.startActivity(Intent intent). Aktywność (widok, ekran) jest podklasą Context.

Aplikacja androidowa może posiadać wiele ekranów (aktywności), a wybór tego jednego, początkowego odbywa się przez znacznik <intent-filter> w ramach aktywności, w pliku AndroidManifest.xml:

<activity android:name="...">
  <intent-filter>
    <action android:name="android.intent.action.MAIN" />
    <category android:name="android.intent.category.LAUNCHER" />
  </intent-filter>
</activity>

Podczas tworzenia aplikacji w Eclipse ADT czy z linii poleceń z android, jesteśmy pytani o nazwę głównej aktywności, która staje się właśnie początkowym ekranem użytkownika przez określenie go z <intent-filter> w AndroidManifest.xml.

Teraz wszystko jasne. Nie mam więcej pytań. A Ty?

Czym jest android.content.Intent oraz android.app.Activity?

Kiedy analizowałem aplikację na Androida, spotykałem się zwykle z klasą android.content.Intent. Wszędzie było jej pełno. Na tyle dużo, aby zwróciła moją uwagę i postanowiłem doczytać, jaka jest jej właściwie rola. Śmiem twierdzić, że jest jedną z bardziej ważnych (jeśli nie najważniejszych) klas w Androidzie.

Już pierwsze zdanie w dokumentacji javadoc dla android.content.Intent wyjaśniło znaczenie klasy:

"An intent is an abstract description of an operation to be performed."

Śmiało możemy przetłumaczyć Intent na jego najbliższy odpowiednik w polskim - zamiar, bo każdorazowe utworzenie Intent będzie wyrażało zamiar wykonania pewnej operacji. W takiej formie widziałem ją w "Hello, Android", kiedy to zamiar wyświetlenia (uruchomienia) android.app.Activity był związany ze stworzeniem obiektu Intent.

Pewnie zastanawiasz się, po co chciałbym wyświetlić Activity? I ponownie wystarczy zajrzeć do dokumentacji, aby dowiedzieć się o jej roli:

"An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with setContentView(View)."

Jeśli dodać, że obie klasy są częścią platformy od wersji 1.0, to staje się jasne, skąd tego tyle w aplikacjach androidowych, z którymi miałem do czynienia do tej pory (przede wszystkim podczas lektury "Hello, Android"). Najczęściej moje spotkanie z obiema klasami miało postać:

Intent i = new Intent(this, A.class);
startActivity(i);

gdzie this wskazuje na klasę dziedziczącą po android.app.Activity, a A.class nową Activity, która zostanie umieszczona na stosie ekranów prezentowanych użytkownikowi.

Pamiętajmy, że każda aktywność uruchomiona przez metodę android.content.Context.startActivity(Intent intent) musi być zarejestrowana przez w AndroidManifest.xml.

I krótka aplikacja do odpalenia na własnym smartfonie - wystarczy podać własne imię, aby pojawiło się przywitanie. Jest to ten typ aplikacji, którą moglibyśmy śmiało nazwać "Hello World". Kompletny projekt, gotowy do importu do Eclipse, znajduje się w repozytorium android-examples/Powitanie. Proszę o uwagi, które mógłyby pomóc mi w udoskonaleniu aplikacji.

A może masz pytania o Androidzie, na które mógłbym odpowiedzieć? Może sugestie, w jakim kierunku powinienem zmierzać z moim rozpoznawaniem Androida? Ten typ nauki najbardziej mi odpowiada - czytelnicy pytania, a ja odpowiedzi, albo wersja bardziej interaktywna - uczestnicy spotkania pytania, a ja w roli prelegenta z odpowiedziami. Już mnie kręci na zaprezentowanie swojej dotychczasowej wiedzy na spotkaniu Warszawa JUG. To mogłoby zachęcić przyszłych i aktualnych androidowiczów do spotkania i podzielenia się doświadczeniami. Tego mi trzeba. Niedługo (tydzień, dwa) rodzi się kolejny Laskowski i muszę zintensyfikować naukę, póki "wolny czas" to nie coś wirtualnego :-)

Androidowe WTF - PM też może

Trudno mi to teraz wytłumaczyć, ale posiadanie smartfona znacząco poprawiło moją chęć spróbowania kolejnej nowinki programistycznej bezpośrednio na telefonie. Nauka Androida widocznie przyspieszyła, bo bardziej się chce.

Chciałbym wierzyć, że nie interesują mnie gadżety - czy ich posiadanie dla poprawienia sobie samopoczucia z samego posiadania, czy dla chęci poprawienia sobie pozycji w społeczeństwie, czy z powodu ślepego podążania za trendem konsumpcyjnym (acz w tym przypadku mam pewne wątpliwości, czy zakup Galaxy to nie właśnie "owczy pęd"?!), ale każdorazowo, kiedy tylko biorę go w ręce, zaraz nachodzi mnie ochota, aby sprawdzić, jak też napisać własną aplikację na niego.

Uruchomienie aplikacji na smartfonie

Pisałem ostatnio, że przede mną jest sprawdzenie, jak to jest uruchomić aplikację bezpośrednio na urządzeniu. Do tej pory, niespełna 3-4 dni, jedynym środowiskiem, na którym uruchamiałem aplikacje androidowe był emulator - Android Virtual Device (AVD), którego podniesienie trwało wieki. Okazało się później, że można pozostawić emulator już uruchomiony i powinno być sprawniej. W zasadzie naturalne, kiedy przyrówna się to do smartfona, który jest włączony, kiedy uruchamiamy na nim aplikacje. Nic nadzwyczajnego, nieprawdaż? A jednak mnie to dziwiło.

To było w piątek, wieczorem. Postanowiłem sprawdzić, co można zrobić z poziomu Mac'a na S2 po porcie USB. Zacząłem poszukiwania jakiegoś narzędzia zarządzającego zawartością i po kwadransie, nie mając nic ciekawego, znużyło mnie. Zabrałem się za pisanie mojej aplikacji androidowej - z S2ką podłączoną do kompa. Całkowicie zapomniałem o nim, bo też, co mi miało przeszkadzać.

Po kilku zmianach postanowiłem sprawdzić działanie aplikacji i odpaliłem ją. Nic więcej nie zmieniając w samej konfiguracji środowiska odpaliłem emulator i jakoś tak dziwnie szybko zobaczyłem, że uruchamianie się zakończyło, tzn. wgranie aplikacji i jej uruchomienie, ale na ekranie nic się nie zmieniło - zero emulatora, ale jednak gdzieś ta aplikacja została uruchomiona. Tylko gdzie?!

I wtedy sobie przypomniałem, sekcję "1.4 Running on a Real Phone" z książki "Hello, Android", w której napisano:

"As long as the phone is plugged in, Eclipse should load and run applications on the phone instead."

Wymaga to wcześniejszego włączenia opcji USB debugging na urządzeniu - opcja Ustawienia > Aplikacje > Opracowywanie > Debugowanie USB (Ciekawie przetłumaczono "Development" na "Opracowywanie" - przyznaję, że jestem znany z wymyślnych tłumaczeń, ale na takie nie posunąłbym się).

I teraz już powinno być wszystko jasne, gdzie "poszła" moja aplikacja - nieświadomie uruchomiłem ją na smartfonie! Chciałbym móc wyrazić swoje zdumienie i radość, kiedy zobaczyłem aplikacje działającą na mojej S2ce! Sprawdź samemu i przekonaj się o roli gadżetów dla poprawienia efektywności pracy zespołu :) Niewielkim kosztem można zdopingować zespół do ponadplanowych działań na własną rękę, albo wręcz uatrakcyjnić prace rozwojowe (projektu i samych uczestników). Gorąco polecam zakup S2ki każdemu z członków zespołu przy projekcie androidowym.

PMowie też mogą tworzyć aplikacje androidowe

I jakby na dokładkę, spotkałem się wczoraj w biurze z jednym z kierowników projektów (PM, ang. project manager) i kiedy wspomniałem o moim, wieczornym wydarzeniu, poprosił, abym mu pomógł zestawić środowisko (Java SDK, Android SDK, Eclipse, Eclipse ADT), bo on też myślał, aby spróbować. Widziałem, jaki był zachwycony, kiedy uruchomił aplikację na swoim smartfonie, bez specjalnej wiedzy programistycznej. Sądzę, że na tym jednym "wybryku" się nie skończy.

WTF = What a Terrible Failure

Od wersji Android 2.2 (API Level 8) mamy metodę android.util.Log.wtf(), której zadaniem jest zgłoszenie sytuacji wyjątkowej w logu, która nie powinna w ogóle wystąpić. Interesujące, że zanim zabrałem się za Androida, sądziłem, że WTF znaczy coś zupełnie innego. Od tej pory, kiedykolwiek usłyszę WTF, będę sądził, że mówiący "siedzi" w Androidzie :)

Zapiski z pierwszej części "Hello, Android"

Dzięki uprzejmości wydawnictwa Pragmatic Programmers oraz Bartka (komentarz do wpisu Wrześniowy Android) zabrałem się za lekturę "Hello, Android", wydanie 3, pióra Ed Burnette.

Czytanie połączyłem z rozpoznawaniem smartfona Samsung Galaxy S II, na którym zainstalowałem Amazon Kindle Reader i jestem zachwycony - treścią i stylem książki oraz samym urządzeniem, na którym mogę doświadczać owych achów i echów. W końcu skończyłem moją gehennę związaną z czytaniem pRaSSówki na Nokii E51 z mikroskopijnym ekranem (nie wspominając o podchodach do czytania na nim książek!). Ten splot wypadków pozytywnie wpływa na moje poznawanie Androida - jakoś tak się bardziej chce i napawa wszechogarniającym optymizmem.

"Preface" oraz część 1. "Introducing Android" przeczytałem w mgnieniu oka. Styl pisania Ed'a odpowiada mi w stu procentach. Język żywy i zachęcający do czytania, jak również własnych prób. Dokładnie taki, aby pozwolić sądzić, że czytanie książek jest wciąż wartościowe (nawet najbardziej zagorzałym przeciwnikom, a niestety spotykam takowych coraz częściej).

W "Preface" dowiadujemy się o powodach, dla których Android jest fajny, ale skoro ja czytam tę książkę dla niego właśnie, można ten rozdział śmiało pominąć, chyba że któregoś dnia przyjdzie nam przedstawić powody, dla których Android jest fajny i wtedy ten rozdział będzie nieoceniony. W mojej profesji wymaga się ode mnie i praktycznego, i bardziej naukowego podejścia do problemu, więc wcale nie żałuję, że go przeczytałem.

Cześć 1. "Introducing Android" składa się z dwóch rozdziałów: "Quick Start" oraz "Key Concepts".

W "Quick Start" rozpoczynamy przygodę z programowaniem prostej, żeby nie napisać prostackiej, aplikacji mobilnej "Hello, Android". Jej prostota jest jednocześnie siłą tej aplikacji, bo pozwala na przejście przez instalację środowiska Eclipse IDE, Android SDK oraz Android Development Tools (ADT). W tym rozdziale, definiujemy pierwsze wirtualne urządzenie Android Virtual Device (AVD) z Android 2.2 - API Level 8 i rozpoczynamy tworzenie aplikacji. W międzyczasie dowiadujemy się o różnicach między poszczególnymi wersjami Androida począwszy od Android 1.5 (Cupcake) aż do Android 2.3 (Gingerbread).

Znacznie sprawniej przyjdzie nam weryfikować postępy przy tworzeniu aplikacji, jeśli raz uruchomiony emulator użyjemy każdorazowo przy testowaniu zmian, bez jego ponownego odpalania. Wielokrotnie słyszałem o powolnym uruchamianiu emulatora i że znacznie łatwiej od razu testować na fizycznym urządzeniu - smartfonie - ale rozumiem, że przy włączonym emulatorze, nie jest to już problem (przetestuję przy najbliższej okazji skuteczność tej tezy).

Rozdział "Key Concepts" to oswojenie czytelnika ze składowymi Android SDK i środowiska uruchomieniowego. Jak mi to przypomina OSGi, w którym mamy Activator (w Androidzie Activity) oraz usługi, których na obu platformach wiele. Deklaratywne konstruowanie aplikacji za pomocą Intents i XML również nie jest niczym nowym (szczególnie w ostatniej deklaratywnej wersji OSGi Declarative Services albo OSGi Blueprint). Mam jednak wrażenie, że podobieństwo kończy się na koncepcjach i wiedza o OSGi na niewiele się tutaj zda. Obym się mylił.

Warto przeczytać ten rozdział, aby mieć pogląd na składowe platformy androidowej, które wspomagają pośrednio (niedostępne dla aplikacji wprost), albo bezpośrednio nasze aplikacje mobilne.

Android oparty jest na specjalnie zestrojonym jądrze Linuksa, które tworzone jest przez producenta urządzenia. Jasnym jest, że tam znajdują się sterowniki urządzeń, z których korzystają biblioteki, środowisko uruchomieniowe Androida - Dalvik Virtual Machine oraz wyżej - zarządcy (ang. managers) jak Activity Manager, Window Manager, Content Providers, itp. Jest tego sporo, a ich użycie określa się deklaratywnie w pliku XML - AndroidManifest.xml. Można również oprogramować całość i zrezygnować z deklarowania w XMLach. Jest wybór, aczkolwiek zaleca się, aby korzystać z deklaratywnego sposobu, który pozwala dostawcom urządzeń na łatwiejsze, własne ich realizowanie.

Zabieram się za część 2. "Android Basics" i liczę, że do końca tygodnia będę mógł pochwalić się własną aplikacyjką na moim S2. Nabieram przekonania, że pisanie aplikacji mobilnych jest wyjątkowo proste, a wszystko sprowadza się do poznania narzędzi, które wspomagają programowanie. Optymizm mnie nie opuszcza (i liczę, że nie skończy się na pustych przechwałkach o łatwości stworzenia aplikacji).