HelloAndroid.pl

Recenzja: Samsung Galaxy S II i9100

2011-05-03T11:45:00.013+02:00

Od 14 lutego, czyli od oficjalnej prezentacji nowego modelu Samsunga przestępowałem z nogi na nogę w oczekiwaniu na pojawienie się nowego Galaxy S II w oficjalnej sprzedaży. Samsung kazał nam sporo czasu czekać na ten moment. No ale w końcu jest. Co prawda mój nie pochodzi jeszcze z oficjalnej sprzedaży, ale myślę, że po kilku dniach użytkowania mogę już co nie co o nim powiedzieć.

Uwaga!
Świadomie pomijam w tekście większość szczegółów technicznych, cyferek i benchmarków, które w rzeczywistości rzadko mają odniesienie w codziennej eksploatacji. Postaram skupić się jedynie na subiektywnych odczuciach i zboczeniach ;)

Za punkt odniesienia (bo jakiś trzeba przyjąć), przyjąłem obecnie królującą wersję Samsunga Galaxy. Czyli model Galaxy S i9000.

Zapraszam także do obejrzenie małej foto-sesji nowego Samsunga.

Budowa

Telefon jest duży. Choć teoretycznie różnice na papierze w stosunku do poprzednika są niewielkie, telefon przekroczył pewną granicę, być może kolejną, na której do tej pory stał według mnie Galaxy S pierwszej generacji. Dużej różnicy w rozmiarach nie zauważymy nawet zestawiając bezpośrednio oba te telefony obok siebie. Wyraźna różnica pojawia się dopiero wówczas gdy weźmiemy telefon do ręki. Od razu dostrzeżemy nowe rozmiary, no i przede wszystkim nowy kształt. Nowa eska straciła zaokrąglone rogi, telefon stał się jeszcze bardziej płaski (wrażenie dzięki prostym ściankom bocznym i zwiększonej szerokości urządzenia), a sam telefon stracił na wadze. Składając powyższe do kupy, no cóż, musimy uczyć się Samsunga od nowa.

Telefon wykonany jest z podobnych materiałów jak jego poprzednik. Jest plastikowy, ale to całkiem porządny plastik. Na uwagę zasługuje świetne spasowanie elementów. Nic nie piszczy, nie trzeszczy i nie wygląda aby miało to się zmienić pod dłuższej eksploatacji. Zmianie uległa za to pokrywka baterii, która od teraz nie tworzy kompletnego tyłu telefonu, a jest jedynie mała klapką o długości mniejszej od samego aparatu. Sama klapka zyskała ciekawą fakturę, dzięki której telefon wygląda trochę „dostojniej”.

Istotną zmianą w samej konstrukcji było przeniesienie gniazda ładowania (micro usb) z górnej ścianki na dolną. Poprawę odczują szczególnie wszyscy Ci, którzy chcą skorzystać z ładowarki biurkowej (typu dock) albo telefonu jako nawigacji samochodowej. Łagodnie rzecz ujmując, obecne rozwiązanie nie należało do najbardziej szczęśliwych.

Wracając do rozmiarów. Samsung nie zwiększył rozmiarów nowego Galaxy nadaremno. Powodem tego rozrostu jest przede wszystkim nowy, powiększony o prawie jedną trzecią cala w stosunku do poprzednika, wyświetlacz.

Wyświetlacz

Galaxy S i9000 ze swoim Super AMOLED’em pod względem jasności i nasycenia barw nie miał konkurencji. Wyświetlacz ten robił, no i robi cały czas, wrażenie właściwie na wszystkich, którzy mieli z nim do czynienia. Ma tylko jedną wadę. Rozdzielczość. Ale tą prawdziwą. Teoretycznie rozdzielczość wyświetlacza to 800x480 pikseli. Jednak problem polega na tym, iż jego konstrukcja opiera się o matrycę typu PenTile, która do wyświetlania obrazu wykorzystuje piksele złożone z dwóch subpikseli. Większego subpiksela koloru niebieskiego lub czerwonego oraz mniejszego zielonego. Dlatego też, aby wyświetlić jeden punkt (kolor), na który składają się kolory z palety RGB potrzebne jest “zapalenie” dwóch sąsiednich pikseli. Powoduje to wrażenie ziarnistości ekranu, no i de facto obniża to realną rozdzielczość ekranu.

W nowym Samsungu zrezygnowano z technologii PenTile wprowadzając nowy typ wyświetlaczy - Super AMOLED Plus, który do wyświetlania obrazu używa tradycyjnej konstrukcji pikseli składających z trzech subpikseli RGB. Dlatego też, przy zachowaniu dotychczasowej rozdzielczości (800x480px), zwiększeniu wyświetlacza do rozmiaru 4.3 cala, uzyskano bardzo jasny, czysty obraz z mniejszym „ziarnem”.

Podsumowując. Jest dobrze. Nawet bardzo dobrze. Piksele są prawie niewidoczne, a soczystość kolorów oraz jasność przebiły według mnie o głowę i9000. Po każdorazowej zabawie nowym Galaxy, wracając do starego czuje się jakbym się cofnął o epokę. Jednak wystarczy na trochę odstawić dwójkę, a znów dostrzegamy jak dobry wyświetlacz zamontowany został w pierwszym Galaxy S.

Zwiększenie wyświetlacza pozytywnie wpłynęło na komfort użytkowania smartphona. Redagowanie maili, przeglądanie Internetu sprawia coraz większą frajdę, na którą składa się jeszcze jeden ważny, jak nie najważniejszy czynnik...

Wydajność

Mimo iż Galaxy S uważany był za wydajnościowego potworka, nie zawsze odzwierciedlało się to w wydajności samego systemu, a raczej interfejsu. Minimalne zacięcia podczas przewijania ekranów, oczekiwanie na otwarcie najbardziej prozaicznych funkcji jak telefon czy skrzynka odbiorcza sms’ów, potrafiło wystarczająco zirytować, szczególnie jeśli ktoś miał do czynienia np. z iPhonem czwartej generacji. Te małe opóźnienia (najczęściej nie przekraczające sekundy, ale jednak) potrafiły sprawić, że cały czar z obcowania z Galaxy pryskał.

Na szczęście wraz z nadejściem nowego Samsunga wszystko się zmieniło. Jest bardzo szybko. Interfejs działa ot tak. Natychmiastowo. Wydajność samego systemu zaskakuje. Do tej pory opóźnienia w reakcji np. w markecie brałem na karb opóźnień związanych z transmisją danych. Dopiero teraz widzę ile mojego czasu marnowało samo urządzenie. Nowy Galaxy działa teraz tak, że chce się go po prostu używać.

Muszę tutaj przypomnieć, że mój egzemplarz nie pochodzi z produkcyjnej serii, soft pewnie też nie jest najnowszy. Co widać w wynikach w Quadrancie. Najlepszy wynik jak zdołałem osiągnąć, a raczej zdołał osiągnąć Galaxy S II to 2700 punktów. Telefony, które trafiły do sprzedaży kręcą regularnie wyniki w okolicach 3500 punktów. Tak więc, jeśli wydajność telefonu w ostatecznej wersji jeszcze wzrosła, to szapo ba.

TouchWiz 4

Nie wiem gdzie podziały się dwie pierwsze wersję nakładki TouchWiz, zapewne zagubiły się gdzieś w zamieszłych czasach panowania Windowsa Mobile 6.0 albo i lepiej. Pewne jest jednak to, że TouchWiz w wersji, którą możemy spotkać zarówno w Samsungach z systemem Android jak i Bada jest całkiem udanym rozwiązaniem. Nie da się też za bardzo ukryć faktu, że wzorowany jest na rozwiązaniu pochodzącym z konkurencyjnej platformy z pod znaku zgniłego.... wróć nadgryzionego jabłka, czyli iOS. Skoro jednak tam się tak dobrze przyjęło, to i może warto dobre wzorce zaadaptować i kopiować na kolejne platformy. Z tego założenia wyszło też zapewne kierownictwo Samsunga. Czy jest to etyczne i zgodne z prawem? Hmm. Nie mi to oceniać. Idźmy dalej.

W nowym Galaxy zadebiutowała czwarta wersja tytułowego interfejsu. Jak i w poprzedniej wersji, zasadniczą część pełnią cztery ikony umieszczone na dolnym pasku, tj. telefon, kontakty, wiadomości oraz aplikacje (oczywiście mogą znaleźć się tutaj dowolne ikony dowolnych aplikacji). Wspomniany pasek dolny stracił tło oraz linię oddzielającą go od pozostałej części ekranu. Ale są to drobne zmiany, których znaleźć można więcej, a nie stanowią one o postępie rozwoju TouchWiz’a.

To co mi się spodobało i co się zmieniło w nowym TouchWizie, to przede wszystkim widgety.
Od teraz widgety stały się prostokątne, co sprawia, że pasują do całego kanciastego stylu telefonu. Lepiej też zagospodarowują miejsce na pulpicie. Widgetów znacznie przybyło, pojawiło się w końcu kilka nowych odpowiedzialnych za kalendarz, agendę, plan dnia, pogodę czy kilka nawet nieźle wyglądających zegarków. Większość z tych widgetów ma możliwość zmiany rozmiarów, tak aby móc w pełni wykorzystać przestrzeń jaką oferują nam poszczególne pulpity.

Cieszę się, że Samsung zdecydował się zmienić styl widgetów. Niestety te, które oferował TouchWiz 3, nie urzekały wyrafinowaniem, były zbyt cukierkowe. Nie będę ukrywał, nie polubiłem się z widgetami z TW3, szczególnie po przejściu z IMHO świetnego HTC Sense, z którego korzystałem na już obecnie zabytkowym HTC Hero. Oczywiście zdaję sobie sprawę, że większość widgetów dostarczanych jest z aplikacjami 3rd-party i nad kontrolą ich stylu za bardzo ani my ani tym bardziej Samsung wpływu nie ma, ale gdyby jednak Samsung zdecydował się rozwijać i dewelopwać kolejne widgety, z pewnością wpłynęło by to pozytywnie na spójność wyglądu oraz ład na pulpicie.

Co jeszcze się zmieniło. Zmieniły położenie cyferki identyfikujące pulpity i to za równo na głównym pulpicie jak i na liście aplikacji. Od tej pory ich miejsce znajduje się tuż nad dolnym paskiem “4 ikon”. Zmienił się także, a właściwie został dodany nowy sposób przewijania/przeglądania pulpitów. Wystarczy przytrzymać palec na wspomnianych cyferkach i przesuwać ów palec z lewa na prawo bądź też odwrotnie, a za pomocą bardzo fajnego efektu będziemy mogli przemieszczać się z pulpitu na pulpit.

Z godnych pochwał zmian, należy też wspomnieć o możliwości tworzenie katalogów oraz nowych stron aplikacji (zastosowania tego akurat nie do końca rozumiem). Możliwość tworzenia katalogów docenią wszyscy Ci, u których liczbę zainstalowanych aplikacji liczy się już w dziesiątkach a nawet setkach. To był dobrych ruch ze strony Koreanczyków.

Podobnych zmian jest jeszcze kilka.. Ale czy są one rewolucyjne? Raczej nie. To po prostu kolejny krok w ewolucji nakładki z serii TouchWiz, która w połączeni z całkiem szybkim sprzętem sprawia całkiem pozytywne wrażenie.

Foto/Video

Zmiany nie mogły ominąć i tego obszaru. Matryca aparatu zyskała kolejne 3 mln pikseli. Ma ich już w tym momencie osiem. O module kamery również nie zapomniano. Obecnie telefon dysponuje możliwością nagrywania w full hd (1080p).

Niewątpliwie najważniejszą zmianą było dołożenie lampy błyskowej (a raczej “diody błyskowej”). Co ważne, korzystać z niej możemy nie tylko podczas wykonywania zdjęć, ale także podczas filmowania, co jest dla mnie osobiście świetną wiadomością.

Poniżej zamieszczam kilka zdjęć i klipów wykonanych przy pomocy Samsunga. Podkreślam, że telefon, którym dysponowałem nie ma najprawdopodobniej ostatecznej wersji softu.

Muzyka

Pozytywnie zaskoczył mnie odtwarzacz muzyki. Przesłuchałem tę samą płytę w formacie FLAC, zarówno na pierwszej wersji Galaxy S jak i na drugiej. Dźwięk sprawia wrażenie bardziej detalicznego oraz wyraźnego. Dodatkowo jest o wiele głośniej. Odsłuch przeprowadzony na tych samych słuchawkach.

Zasilanie

Dwa procesory, a raczej rdzenie, wydajny układ graficzny Exynos, duży wyświetlacz, 1 GB pamięci operacyjnej to wszystko musi zostać nakarmione. Jeżeli powiem, że działa nie krócej niż poprzednik to będzie oznaczało to bardzo dobry wynik. Ostateczny wynik i tak będzie zależał od konkretnego ROM’u.

Podsumowanie

Śmiało można powiedzieć, że ulepszenia dotknęły nowego Galaxy na wszystkich frontach. Lepszy wyświetlacz, lepszy procesor, lepszy aparat i wiele innych (ma się rozumieć - lepszych rzeczy)). Wszystko to sprawia, że rozwój serii Galaxy S idzie w dobrą stronę. Widać, że Samsung jako firma nie drepcze w miejscu.

Jedynie nie mogę oswoić się z jego nowymi wymiarami i nie wiem czy ich zwiększenie to był dobry ruch ze strony Samsunga. Według mnie telefon trzyma się trochę gorzej od poprzednika. Jest jednak bardzo subiektywna opinia. Wszystko zależy od osobistych preferencji, rozmiaru dłoni itp. Z drugiej strony Galaxy S pierwszej generacji był już na tyle sporym urządzaniem, że chcąc go używać było trzeba zaakceptować wymiary odbiegającej od przeciętnej dzisiejszych komórek. Dlatego myślę, że dochodzimy tutaj do sedna sprawy. Galaxy S jak i Galaxy S II należą niewątpliwie do zacnej grupy urządzeń określanych mianem smartphonów, to też kupując je oczekujemy przede wszystkim posiadania przenośnego komputera w kieszeni. Smartphone umożliwia dzisiaj praktycznie wszystko to co umożliwia pełnowymiarowy komputer. Jest tylko jedno ograniczenie. Ergonomia. Jest oczywistym, że chcielibyśmy aby te wszystkie funkcje oferowane przez telefon nie były jedynie protezami pełnowymiarowych aplikacji, a ich godnym zamiennikiem. Dlatego też, jeżeli podejdziemy w ten sposób do sprawy, to okaże się, że może warto przeboleć pozorną niewygodę korzystania z urządzenia jako zwykłej “słuchawki” wynikającą z większych rozmiarów na rzecz posiadania niewyobrażalnie multifunkcyjnego kombajnu. Jak to mówią, albo rybki albo akwarium.

Na koniec pytanie na które pewnie wszyscy czekają. Czy warto zamieniać eske pierwszej generacji na nową. To zależy. Tak, jeśli kogoś nie zadowala wydajność obecnej wersji.
Myślę jednak, że nowy Galaxy pokaże pazur wówczas, kiedy do poziomu jego możliwości doszlusują nowe aplikacje i gry potrafiące wykorzystać potencjał nowego układu graficznego i procesora.. Dlatego, jeśli dla kogoś Galaxy S jest już w tej chwili za wolny to z pewnością może się zastanowić nad jego wymianą. Ulepszenia w pozostałych dziedzinach są duże, jednak racjonalnie patrząc, nie koniecznie uzasadniają wymianą telefonu na nowszy model. Wyświetlacz jest lepszy, ale w starym Samsungu też jest bardzo dobry. Różnice widać dopiero gdy zestawi się oba aparaty obok siebie. A propos aparatu, też nie jest to chyba powód, dla którego powinniśmy czym prędzej pobiec do sklepu po nowego Samsunga. Upchnęli kolejne trzy miliony pikseli, dodali full hd, jednak fizyki nawet Samsung nie oszuka i obiektyw(ik) jest jaki jest.

Ok. Już dość tego marudzenia. Jeszcze ktoś poważnie pomyśli, że nie warto kupować nowego Samsunga. Otóż nie. Warto. Bo sęk w tym, że gdyby telefon był usprawniony tylko na jednym z tych pól to rzeczywiście wątpliwym pomysłem byłaby wymiana obecnie posiadanego modelu (mam na myśli i9000). Biorąc jednak pod uwagę, że telefon ten został poprawiony pod każdym względem to otrzymujemy zupełnie nowy produkt, który jest wart swojej ceny.

Acha. Chyba nie muszę dodawać, że jeśli ktoś nie jest obecnie posiadaczem obecnego modelu i9000, to nie powinien zastanawiać się minuty dłużej nad oczywistym wyborem telefonu z Androidem na pokładzie jaki może być w tej chwili tylko jeden. Samsung Galaxy S II.

2011-05-02T10:00:00.001+02:00

Galeria: Samsung Galaxy S II

2011-04-30T14:47:00.000+02:00

Przed właściwą recenzją zamieszczam parę fotek nowego Samsunga. Solo oraz za starszym bratem.

Zapowiedź testu: Samsung Galaxy S II i9100

2011-04-30T00:29:00.007+02:00

Tym razem nie nowa lekcja, a nowy flagowy model Samsunga działający pod kontrolą Androida - długo wyczekiwany Samsung Galaxy S II.

Tak się sympatycznie złożyło, że wpadł dzisiaj w moje łapki następca można już chyba śmiało powiedzieć kultowego Galaxy S i9000. W najbliższych dniach postaram się zamieścić małą recenzję tego sprzętu.

Na tę chwilę mogę jedno powiedzieć - jest MOC! Warto było czekać.

Recenzja jest już dostępna!

Lekcja 17. Wykresy w Androidzie

2011-04-20T12:32:00.003+02:00

Wykres – graficzna forma przedstawienia zmienności zjawiska, procesu, wielkości, zależności lub jakichkolwiek danych.

Okazuje się, że pomimo tego, że wykresy są często spotykane w różnego rodzaju aplikacjach dostępnych w Android Market, nie łatwo jest znaleźć sensowne rozwiązanie w postaci biblioteki automatyzującej ich tworzenie.
Oczywiście można zacząć od pracy u podstaw i samemu opracować odpowiednią klasę opierając się na rysowaniu po Canvas'ie. Nie ma sensu jednak wymyślać koła. Wbrew pozorom wykres to nie tylko punkty na osi połączone linią. Dobry wykres musi być przede wszystkim czytelny graficznie, skalowalny, customizowalny, potrafiący przyjąć dane w różnych formatach i przede wszystkim wydajny. Czyli całkiem sporo pracy.

Wracając do tematu gotowych rozwiązań, to szczerze mówiąc nie znalazłem żadnego w pełni mnie satysfakcjonującego, notabene które to moim zdaniem powinno być zaimplementowane w samym Androidzie przez jego twórców. Mimo wszystko postanowiłem przybliżyć Wam rozwiązania które wydały mi się w miarę sensowne.

Online/Offline

Do Android-owych wykresów można podejść na dwa sposoby. Możemy próbować generować je w samym smartphonie, ale można pobierać je także przy pomocy widgetu WebView ze stron WWW z wygenerowanymi już wykresami. Szczerze mówiąc, póki co do własnych zastosowań zdecydowałem się na to ostatnie rozwiązanie. Jeżeli nie mamy, bądź nie chcemy stawiać serwera, instalować biblitek itp. w celu wystawienia WWW, możemy skorzystać z ciekawego rozwiązania jako oferuje nam... nie kto inny jak Google. Usluga nazywa się Google Chart Tools, a można ją znaleźć pod adresem http://code.google.com/apis/chart/.

Wypróbuj!

https://chart.googleapis.com/chart?cht=p3&chd=t:60,40&chs=250x100&chl=Hello|World

Google Chart Tools umożliwia dynamiczne generowanie przeróżnych typów wykresów za pomocą webgeneratora lub też poprzez przekazywanie parametrów metodą GET w adresie interenetowym. Wygenerowany wykres osadzony na stronie WWW może być zaprezentowany za pomocą komponentu WebView. Rozwiązanie to jest całkiem ciekawe. Czasami jednak nie chcielibysmy wysyłać naszych danych na zewnętrz, bądź też nie dysponujemy dostępem do Internetu. Dlatego w dalszej części artykułu przyjrzymy się rozwiązaniom offline. Przedstawione zostaną dwa: AndroidPlot, KiChart.

AndroidPlot

http://androidplot.com/wiki/Home

AndroidPlot jest biblioteką napisaną podobno w czystej Javie, umożliwiającą generowanie dynamicznych oraz statycznych wykresów. Póki co 4 typów: Line charts, Scatter charts, Bar charts, Step charts. Twórcy zapowiadają następne.

Darmowość, społeczność skupiona wokół forum czy też fakt iż projekt jest cały czas rozwijany, to według autorów główne "za" przemawiające za wyborem AndroidPlot. Jak jest w rzeczywistości? Nie najgorzej. Wykresy nie są brzydkie, ich cztery typy póki co są wystarczające, no i przy tym nieźle konfigurowalne. No i tu dochodzimy do piety achillesowej AndroidPlot'a. Wykresy są bardzo konfigurowalne, ale jest to według mnie tak skomplikowane, że mam wrażenie iż czasami sami twórcy nie wiedzą jak rozwiązać problemy forumowiczów zgromadzonych wokół projektu.
Jeżeli jednak przeskoczycie te trudności, okaże się, że AndroidPlot może być całkiem atrakcyjnym rozwiązaniem.

W następnych kilku akapitach zaprezentowana została prosta aplikacja, wykorzystująca wykres liniowy dostępny w bibliotece AndroidPlot. Jest to zmodyfikowany przykład dostępny na stronach twórców projektu.

MainActivity.class

Jak widać, same modyfikatory wyglądu przytłaczają. Dodatkowo zawierają tyle warstw, że nie wiadomo, która za co odpowiada. Najlepiej rozpoznać je metoda prób i błędów. Starałem się dodać stosowne komentarze przy poszczególnych modyfikatorach. Jak wyszło. Nie mnie oceniać ;)

Mały konkurs dla dociekliwych czytelników! - Jak odsunąć/przesunąć napis "oś X" od skali osi X. Nagroda do ustalenia.

main.xml

Rezultat powinien prezentować się mniej więcej tak:

KiChart

http://www.kidroid.com/kichart/

KiChart jest kolejną ciekawą biblioteką. Ciekawą dla mnie z powodu prostoty jest jej użycia. Jednak póki co udostępniona jest jedynie wersja trial. Autor planuje wydanie odświeżonej wersji biblioteki, łącznie z dokumentacją, przykładami użycia. Dlatego też polecam zaglądać na stronę KiDroida. Ewentualnie warto odezwać się do niego osobiście - na pewno nie zostawi w potrzebie.

Przykład użycia biblioteki został przedstawiony na poniższym kodzie.

Właściwości opisane zostały przez autora w krótkim przewodniku w formie pliku pdf http://www.kidroid.com/uploads/kiChart/kiChart-Help.pdf

Rezultat działania kodu:

Podsumowanie

Wydaje się, że na chwilę pisania tego artykułu nie ma rozwiązań idealnych. Jeżeli nasze dane nie sa wrażliwe, a aplikacja będzie miała stały dostęp do Internetu, z pewnością warto zwrócić uwagę na rozwiązania online. Przemawia za nimi łatwość użycia, dodatkowo są zazwyczaj bardziej rozwinięte. W przeciwnym wypadku pozostają nam rozwiązania offline. Niestety zwykle ich głównym ograniczeniem jest początkowe stadium rozwoju - odnosi się to szczególnie do wersji darmowych, czyli takich o których była tu mowa. Jeśli jednak szukasz rozwiązania profesjonalnego, a koszty nie grają roli, to warto przyjrzeć się multiplatformowej bibliotece aiCharts, http://www.artfulbits.com/products/android/aiCharts.aspx. Niestety koszt developerskiej licencji wynosi $299, co może skutecznie wystudzić pragnienie posiadania wykresów wyglądających jak na poniższych screenie.

Lekcja 16. Połączenie SSH

2011-04-13T17:39:00.003+02:00

Tym razem dosyć krótka i uboga w treść lekcja. Postaram się przedstawić na przykładzie prostej klasy możliwość zastosowania zewnętrznej biblioteki Ganymed SSH2 w celu stworzenia połączenia SSH. Podejrzewam, że to trochę niszowe zastosowanie, dlatego też będzie więcej samego kodu niż opisów. Mam nadzieję, że osoby zainteresowane nie będą mieć problemu z interpretacją poniższego przykładu. Zresztą nie jest to żaden "rocket science".

Ganymed SSH2
http://www.ganymed.ethz.ch/ssh2/

Dla swoich potrzeb postanowiłem wykorzystać popularną bibliotekę Ganymed SSH2 napisaną w czystej Javie, implementującą protokół SSH2, a umożliwiającą między innymi zdalne wykonywanie komend oraz dostęp do shell'a, czyli akurat to czego szukałem.

Aby już nie przedłużać, przedstawiam kod.

SSHConnection.class

MainActivity.class

Z obowiązku wspomnę, abyście nie zapomnieli ~~zadeklarować klasy SSHConnection w manifeście aplikacji~~ oraz pamiętali aby dodać biblioteki Ganymed do "build path" projektu.

Nie udostępniam projektu w formie paczki bo kodu jest niewiele, a druga sprawa to to, że potrzebny jest dostęp do jakiegoś serwera umożliwiającego połączenie SSH. Dlatego też tym razem lekcja bardziej teoretyczna.

Lekcja 15. AsyncTask - Zarządzanie wątkami w Androidzie

2011-04-09T21:24:00.003+02:00

Android na swoje szczęście lub też nieszczęście dostarcza model pojedynczego wątku, który tworzony jest podczas uruchomienia aplikacji. Jest to tzw. UI Thread, czyli wątek główny.

Oznacza to nie mniej nie więcej, że wszelkie procesy (czynności), które wykonywane są w naszej aplikacji realizowane są liniowo. I tak na przykład, gdy chcielibyśmy w naszej potencjalnej aplikacji połączyć się z serwerem bazodanowym i wykonać na nim szereg czasochłonnych operacji, to w czasie tego procesu, „wątek” obsługujący interfejs zostałby zawieszony w oczekiwaniu na zakończenie tej operacji. Brak reakcji interfejsu odbierany jest przez użytkowników jako „wolne działanie” lub co gorsza „wieszanie się”. Dodatkowo jeśli aplikacja nie odpowiada przez co najmniej 5 sekund, Android wyrzuca błąd o braku odpowiedzi (parafrazując słowa wróżbity Macieja: Myślę, że wiecie o czym mówię... ;))

Na szczęście Google, a dokładnie twórcy Androida pomyśleli i dostarczyli nam mechanizm wątków (Threads) dobrze znanych z innych języków.

Problem pojawia się w momencie gdy chcielibyśmy aby nasz nowy wątek dokonał modyfikacji w wątku interfejsu. Jednym z kilku możliwych rozwiązań jest użycie popularnych Handlerów, nie o nich jednak będzie dzisiejsza lekcja. W zamian będzie coś o wiele lepszego.

AsyncTask

Użycie handlerów uzasadnione jest w przypadku prostych aplikacji, wykorzystujących nie wielką liczbę wątków, nad którymi jesteśmy w stanie łatwo zapanować. Jednak gdy aplikacja korzysta z większej liczby wątków i to w dodatku czasochłonnych przychodzi nam z pomocą mechanizm do zarządzania wątkami zaimplementowany w klasie AsyncTask.

Przykładowa klasa wykorzystująca możliwości AsyncTask zaprezentowana została poniżej.

Klasa korzystająca z AsyncTask powinna definiować:

Trzy typy generyczne: Params, Progress, Result, odpowiadające paremetrom wejściowym, stopniu postępu, a także wynikowi przeprowadzonych operacji przez wątek

Cztery metody odpowiadające poszczególnym etapom działania wątku:

doInBackground – jedyna z obowiązkowych metod. W przypadku istnienia metody onPreExecute wykonywana jest zaraz po niej. To do tej metody przekazywane są parametry wejściowe, a także tutaj przeprowadzane są główne operacje. Za pomocą metody publishProgress(Progress...) możliwe jest przekazywanie postępów działania wątku. Każdorazowe wywołanie publishProgress powoduje wykonanie metody onProgressUpdate, dzięki której możliwe jest prezentowanie postępu w wątku głównym UI.
onPreExecute – wywoływana przed doInBackground. Służy głównie do ustawienia parametrów początkowych np. wyzerowaniu widgetu progressbar, czy też zablokowania przycisku, itp.)
onProgressUpdate – służy do przekazywania parametrów postępu do wątku UI. Wywoływana przez przeciążenie metody publishProgress() w metodzie doInBackground()
onPostExecute – wywoływana po zakończeniu działań metody doInBackground. Jako parametr jest do niej przekazywany rezultat działania wątku.

AsyncTaskApp

Poniżej zamieszczam kod oraz źródło przykładowej aplikacji wykorzystującej AsyncTask. Jedynym zadaniem wątku jest uaktualnianie progressbar'a.

MainActivity.class

main.xml

A tak powinna wyglądać aplikacja po skompilowaniu i uruchomieniu.

Lekcja 14. Przygotowanie środowiska cz.2 - Eclipse

2011-04-03T18:40:00.011+02:00

Jako, że od pierwszej instrukcji instalacji oraz konfiguracji środowiska do programowania pod Androida już trochę bajtów w światłowodach upłynęło - postanowiłem temat odświeżyć.

Wiele się zmieniło, linki do źródeł się zdezaktualizowały, Android doczekał się wersji SDK o numerze 2.3.3 (pomijam tu świadomie wersje "tabletową" 3.0), a Elicpse wydaję się, że objął prym jako platforma IDE w świeci programistów Androida.

1.) Instalacja Eclipse'a

http://www.eclipse.org/downloads/

Ściągamy wersję zaznaczoną na screenie czerwoną ramką.

Ściągniętą paczkę .zip rozpakowujemy, a następnie umieszczamy rozpakowany katalog w dogodnym dla nas miejscu. Instalacja Eclipse'a jest już zakończona.

2.) Instalacja JDK (Java Development Kit)

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Ściągamy wersję zaznaczoną na screenie czerwoną ramką.

Uruchamiamy instalator i postępujemy według instrukcji.

3.) Instalacja Android SDK

http://developer.android.com/sdk/index.html

Ściągamy wersję zaznaczoną na screenie czerwoną ramką.

Przystępujemy do instalacji SDK. Na samym początku możecie się natknąć na problem z przejściem do drugiego czy też trzeciego etapu instalacji. Instalator będzie twierdził, że komputera nie ma zainstalowanej odpowiedniej wersji JDK. W tym momencie mały trick. Należy kliknąć przycisk BACK po czym ponownie NEXT, tym razem instalator powinien nas puścić do przodu... Dlaczego wystęuje taki problem ? Pytanie do wujka Googla.

W przypadku gdy powyższy problem Was nie dotyczy, albo też udało się przy pomocy powyższego tricku przejść dalej, dochodzimy do ekranu wyboru wersji SDK do instalacji. Moja sugestia, to odznaczyć wersję wcześniejsze niż 2.1 - pożytku raczej z nich już nie będzie, a oszczędzić na dysku miejsce można.

W tym momencie instalator zaczyna pobierać zaznaczone wersje SDK. Chwilę to potrwa. Także trochę cierpliwości.

4.) Konfigurowanie Eclipse'a

a) Instalacja pluginu ADT - rozszerzającego możliwości Eclipse'a o możliwość budowy aplikacji Android.

Udajemy się na stronę...
http://developer.android.com/sdk/eclipse-adt.html,
gdzie znajdziemy linko do plugin'u: https://dl-ssl.google.com/android/eclipse/ - kopiujemy link do schowka.

Następnie z górnego paska aplikacji wybieramy opcję Help -> Install New Software...

Klikamy przycisk Add i w okienko, które się pojawiło wklejamy nasz wcześniej zapamiętany adres.

Zaznaczamy checkbox przy Developer Tools...

Dalej postępujemy według instrukcji.

b) Dodanie SDK Android do Eclipse'a

Ostatnio rzeczą jaką musimy zrobić jest wskazanie Eclipse'owi lokalizacji naszych wcześniej zainstalowanych SDK.

W tym celu wchodzimy w menu Window - > Preferences i konfigurujemy ustawienia w poniższy sposób.

I już. Środowisko zainstalowane i skonfigurowane.

*5.) Już na prawdę ostatnim krokiem, a właściwie o podpowiedzią co do dalszych działań, jest utworzenie maszyny wirtualnej - emulatora Androida.

W tym celu wybieramy z menu Window - > Android SDK and AVD Manager. Klikamy New. Uzupełniamy okienko.

Teraz już naprawdę mamy przygotowane środowisko do pracy ;)

We want Android Market!

2010-05-07T10:07:00.002+02:00

Nowa notka po dłuższej nieobecności. Do tego notka interwencyjna.

W skrócie. Koledzy z forum android.com.pl zainicjowali akcję mającą na celu przekonanie Googla do otwarcia polskiej wersji Android Market na płatne aplikacje. Dotyczy to zarówno zakupu jak i możliwości ich udostępniania przez developerów.

Jeżeli chcesz się przyłączyć do akcji, krzyknąć w ethernetowy eter - "hej! Wójku Googlu, dlaczego nas dyskryminujesz?", to nic prostszego jak udać się na stronę http://www.petycje.pl/5210 i spełnić swój droidowy obowiązek.

Postępy w sprawie możesz bacznie obserwować na stronie - http://we-want-android-market.blogspot.com/

Lekcja 13. Instalujemy reklamy sieci AdMob.

2010-02-15T21:58:00.005+01:00

O sieci reklamy mobilnej AdMob zrobiło się ostatnio głośno w związku z przejęciem jej przez naszego 'ukochanego' wujka Google.

Pomijając aspekt czysto biznesowy umieszczania tego typu reklam na ekranach potencjalnych odbiorców Waszych aplikacji, chciałbym w kilku akapitach przedstawić proces instalacji oraz konfiguracji AdMoba dla przykładowej aplikacji.

Krok 1

Przygodę z reklamą AdMob zaczniemy od rejestracji na stronie http://www.admob.com/. Po ukończeniu której, klikając na przycisk 'Add Site/App' przejdziemy krótki formularz, wybierając między innymi interesującą nas platformę reklamową (w naszym przypadku oczywiście Android), nazwę aplikacji, określimy także kategorię do jakiej owa należy itp.

Po udzieleniu wszystkich satysfakcjonujących formularz odpowiedzi, serwis udostępni nam do pobrania AdMob Android SDK - niezbędne do utworzenia reklamy, a także przykład w postaci lekko zmodyfikowanej aplikacji LunarLander (w postaci podstawowej dostępnej na stronie http://developer.android.com). Nie zabraknie także w pobranym archiwum dokładnego tutoriala oraz dokumentacji biblioteki AdMob'a. Najważniejszą jednak zdobyczą jest tzw. publisher ID, czyli identyfikator naszych reklam.

Krok 2

Krok drugi zaczniemy od utworzenia w katalogu głównym naszej aplikacji - katalogu libs (tak aby znajdował się obok katalogów src, res, bin... itd.), a następnie umieszczenia w nim pliku Jar (admob-sdk-android), znajdującego się w paczce zip ściągniętej z AdMob'a.

Pozostaje nam dodać naszą nową bibliotekę do naszego projektu.
W tym celu wykonajmy poniższe kroki (opis dla Eclipse).
1.) Klikając prawym przyciskiem na korzeniu naszego projektu, wybieramy Properties.
2.) Z lewego panelu wybieramy Java Build Path.
3.) Następnie z prawego panelu wybieramy zakładkę Libraries.
4.) Klikamy na przycisk Add JARs..., poczym wskazujemy naszą bibliotekę w katalogu libs.

Po jej dodaniu powinniśmy uzyskać mniej więcej taki stan:

Krok 3

Uzupełniamy manifest aplikacji.
Dodajemy linijkę z naszym publisher ID, otrzymanym po dodaniu aplikacji w serwisie.

Następnie zezwalamy aplikacji na korzystanie z połączenia internetowego (Wifi,GSM).

Krok 4

Kolejnym krokiem jest stworzenie pliku zawierającego atrybuty określające naszą reklamę (AdView). W tym celu przechodzimy do pliku /res/values/attrs.xml, a w przypadku gdy go jeszcze nie posiadamy - tworzymy go. Wypełniamy go według poniższego wzoru:

Krok 5

Ostatnim krokiem jest umieszczenie reklamy (AdView) na Layout'cie. Zanim jednak to uczynimy, musimy stworzyć referencję do wcześniej stworzonego pliku attrs.xml. W tym celu dodajemy poniższą linijkę, gdzie yourpackage oznacza nazwę Twojego pakietu.

Poniżej zamieszczam przykładowy kod layoutu zawierający jedynie samą reklamę. Z rozgryzieniem parametrów nie powinno myślę być problemu.

Krok 6 - Testowanie

Ludzie z AdMoba sugerują, aby podczas procesu jego integracji (konfiguracji itp.) korzystać tylko z trybu testowego, dzięki czemu zawsze otrzymujemy tę samę (działającą!) reklamę.

W celu uruchomienia trybu testowego, wklejamy poniższą linijkę do tagu
Ważne tylko, aby usunąć ten atrybut przez publikacją aplikacji.

μLekcja 4. Karta SD w emulatorze Androida.

2010-02-08T21:45:00.016+01:00

Do tej pory udało mi się wytrwać bez karty SD w emulatorze Androida. Co więcej, nawet nie widziałem, że można takową zaaplikować. Było to po prostu poza moim zainteresowaniem.

Jak to w życiu bywa, na wszystko przychodzi czas. Przyszedł i na emulację karty SD.

Do dzieła!

Przede wszystkim uruchamiamy konsolę CMD (Start->Uruchom->CMD, właściwie nie wiem po co to piszę na blogu programistycznym ;-))

Przechodzimy do katalogu tools w Android SDK. W zalezności od tego gdzie usadowiliśmy nasze SDK na dysku wpis może/powinien wyglądać mniej więcej tak:

D:\android-sdk_r3-windows\android-sdk-windows\tools>

Następnie poprzez aplikację mksdcard, tworzymy naszą kartę... wydając polecenie:

mkscard -l sdcard 128M d:\sdcard.img

Przy czym odpowiednio: sdcard - jest etykietą naszej karty, 128M jak można się domyśleć jest wartością wyrażającą jej rozmiar w megabajtach, a ścieżka na końcu d:\sdcard.img - odpowiada miejscu utworzenia karty.

W tym momencie mamy utworzony obraz karty sd, zamieszczony (w tym przypadku) w katalogu głównym dysku d.

Ostatnią czynnością którą musimy zrobić, jest wskazanie naszej wirtualnej maszynie nowo utworzonej karty.

Niestety, stety ale poniższe rozwiązanie dotyczy jedynie Eclipse'a, tak więc jak ktoś korzysta z NetBeans'a musi pomęczyć się sam.

Tak więc jeśli korzystamy z Eclipse'a, klikamy na...

... a następnie konfigurujemy nową maszynę ze wskazaniem na obraz naszej karty.

I to wszystko, mamy wirtualną maszynę Androida z kartą SD.

No ale zastanówmy się. Mamy kartę ale pustą, jak coś na niej umieścić?!!?

Znów przychodzi z pomocą nam Eclipse.

Klikamy na DDMS w prawym górnym rogu okna Eclipse'a.

Po przełączeniu się Eclipse'a w tryb DDMS, wybieramy zakładkę File Explorer

"...i oczom ich ukazał się las", a dokładnie zawartość karty sd - parafrazując kultowy tekst z niemniej kultowego filmu.

Kopiowanie plików na kartę odbywa się albo poprzez "przeciągnięcie" pliku do katalogu, albo klikając na ikonkę zaznaczoną na żółto na powyższym screenie.

Zarządzaniem kartą możemy także zająć się z poziomu konsoli, a dokładniej przez adb.
W tym celu, będąc w katalogu \tools wydajemy komendę adb shell, po wylistowaniu zawartości naszego telefonu (komendą ls) dojrzymy naszą kartę SD.

Wchodzimy do katalogu sdcard... cd sdcard, nastepnie listujemy jego zawartość ls

Oczywiście w tym momencie mamy dostępne wszelkie komendy unixowe, tak więc możemy dowolnie "bawić" się zawartością naszej karty ;)

To tyle... do następnego razu!

[Na przerwie] Dlaczego warto zaprzyjaźnić się z Androidem!?

2010-01-29T12:38:00.011+01:00

Wstęp

Na początku chciałbym zaznaczyć, że poniższy tekst jest subiektywnym poglądem autora na świat smartphonów. Nie jest poparty szczególnymi badaniami rynku, dogłębnymi analizami, a tylko albo aż codziennymi obserwacjami z punktu widzenia przeciętnego użytkownika.

Stan obecny

Jakiś czas temu trafiłem na artykuł, o intrygującym i dumnie brzmiącym tytule w stylu "Koniec ery smartphonów". Aż lekko mi się ciśnienie podniosło, jak to zobaczyłem. Kliknąłem w link i co się okazało, a to, że powoli możemy mówić o schyłku ery urządzeń zwanych smartphonami. Dlaczego schyłku? Otóż do tej pory "zmyślne telefony" były pewną niszą na rynku, skierowaną do konkretnego odbiorcy, np. klienta biznesowego albo po prostu dla grupy tzw. power-userów.
Musimy tutaj na chwilę przystanąć i odpowiedzieć sobie na pytanie jak charakteryzujemy smartphony. Według wikipedii, smartphone jest "urządzeniem telefonicznym integrującym w sobie kilka funkcji... łączy funkcje telefonu komórkowego, poczty elektronicznej, przeglądarki sieciowej, pagera, GPS, jak również cyfrowego aparatu fotograficznego i prostej kamery wideo". Co się okazuje? Śmiało można stwierdzić, że 95% nowych sprzedawanych telefonów komórkowych podpada pod tą grupę. Dlatego też, śmiało można powiedzieć, że era smartphonów przemija, bo wszystkie urządzenia mobilne są teraz smartphonami. Innych nie ma i nie będzie.

Smartphony a OS i dlaczego Android

Przy takiej rozpiętości funkcji, przy rosnących wydajnościach procesorów (itp.) i tym samym co raz większych możliwościach drzemiących w smartphonach, nie obejdzie się bez nowoczesnego systemu operacyjnego, który będzie sprawnie pośredniczył pomiędzy hardwarem, a tysiącami codziennie powstających aplikacji poszerzających użyteczność opisywanych urządzeń.

Krótki przegląd rynku mobilnych systemów operacyjnych

Symbian OS

Na rynku, jak zapewne wiadomo do tej pory królował i króluje Symbian OS. Niestety jego piętą achillesową jest ograniczona dostępność, zawężona tylko do telefonów marki Nokia. Za dziwne, uważam więc statystyki mówiące, że za 3-4 lata będzie systemem numero uno. Przy spadającej popularności Nokii... no sam nie wiem.
Nokia co prawda wypuszcza nową, uwspółcześnioną wersję Symbiana, ale dopóki jego zastosowanie będzie ograniczało się do ich telefonów, to prawdopodobnie podzieli los naszego następnego bohatera, czyli...

iPhone OS

Kolejnym, pozornie liczącym się system jest iPhone OS. Dlaczego pozornie. Dopóki iPhone nie zmieni strategii dotyczącej jednego (w danej chwili na rynku) uniwersalnego telefonu, nigdy nie osiągnie znaczącej pozycjii na rynku, a będzie tylko ciekawostką z olbrzymim i skutecznym PR'em. Nie chcę tutaj drążyć tematu, bo nic z tego dobrego nie wyniknie, prócz kolejnej wojny na linii apple kontra reszta świata ;)

Windows Mobile

Nie zapominajmy także o starym i poważnym graczu jakim jest Windows Mobile, który trochę przysnął, podobno się budzi, ale zwłoka z tym budzeniem przez kolejny rok (Window Mobile 7) może wpłynąć na jego popularność. Tak czy owak, jest obecnie nie wiadomą. Jednakże, nie powinniśmy lekceważyć potentata z Redmond.

Android

Dlaczego według mnie Android wyjdzie na prowadzenie. Otóż, składa albo złoży się na to kilka czynników.

1. Firma matka - wszech obecny Google. Nie oszukujmy się, to oni w dużym stopniu kreują Internet i wytyczają nowe trendy. Dodatkowo, jest to firma z praktycznie nie ograniczonym budżetem i zasobami ludzkimi.

2. System jest oparty na Linuxie, czyli kolejny atut - możliwości plus otwartość.

3. Równe szanse startu. Linux na rynku PC nie może nadal konkurować z hegemonią Microsoftu, ale na rynku urządzeń mobilnych wszyscy gracze mają póki co równe szanse na starcie.

4. Czwarty punkt dla mnie najważniejszy. Wydaje mi się, że Google nie chce Androidem konkurować z iPhonem czy czymkolwiek innym. Ludzie błędnie usiłują cały czas znaleźć w Androidzie iPhone killera.
Według mnie Android, ma być takim cichym (ukrytym w cieniu) systemem instalowanym w telefonach wszelkich marek. Android nie ma być kojarzony z konkretnym urządzeniem. Google zapędziło się trochę z Nexusem One, wypuszczając go pod swoją marką. Prawdopodobnie jest to jednak tylko zagranie czysto marketingowe. Tak czy owak, trochę szumu wokół Androida nie zaszkodzi, a sam Nexus wydaje się, że rzeczywiście może konkurować z iPhonem (smile). Wracając jednak do tematu.
Większość użytkowników kupując nowy telefon nie będzie zdawała sobie sprawy, że ich telefon pracuje pod obsługą systemu spod znaku zielonego robota. Google nie mówi, w jakim telefonie może być zainstalowany Android, a w jakim nie. Producenci sami będą chętnie sięgali po Androida, co jest już wyraźnie zauważalne. Prawdopodobnie ten rok, to będzie prawdziwa ekspansja słuchawek z Androidem. Sama Motorola zapowiedziała wypuszczenie w tym roku od 20 do 30 słuchawek pod tym systemem.

Pozostałe systemy

Nie wymieniłem w tym krótkim przeglądzie systemów takich jak WebOS, Maemo, czy też Bada, bo to raczej ciekawostki.

Przyszłość

W najjaśniejszych kolorach rysuje się przyszłość dla Androida. Faktem są systemy operacyjne w telefonach, a raczej to już w małych i całkiem wydajnych komputerach. Numerem jeden, będzie oczywiście system który trafi pod strzechy, czyli będzie instalowany na większości urządzeń dostępnych na rynku. Symbian, dopóki tylko na Nokii, na pewno nie. Tak samo z iPhone OS. Konkurentami mogą być dla siebie tylko Windows i Android, jednak fakt otwartości systemu, (jednak) większego zaplecza i braku negatywnych odczuć, które często towarzyszą produktom od Microsoftu, prawdopobonie pozwolą wejść Androidowi na najwyższy stopień podium.

Developers, developers, developers...

Czy warto zacząć naukę programowania i pisać aplikację na platformę Android? Tu już musisz sobie sam odpowiedzieć na to pytanie. Póki co wszystkie gwiazdy na niebie wskazują, że tak.
Dodatkowo, startując w tym momencie, masz wyrównane szanse z innymi developerami, którzy także dopiero teraz poznają tę platformę, bo nie zapominajmy, że Android jest młodym robocikiem, który ledwo skończył 2 latka...

...dlatego kubek kawy w dłoń i do klawiatury!

Ps.
No proszę, pisałem kilka dni temu o tym, że Symbian nie ma szans na zawładnięcie rynku póki jest systemem komercyjnym i w dodatku stosowanym przez jednego producenta, a tu dzisiaj z rana taka wiadomość: Symbian uwalnia kod źródłowy: głównym konkurentem jest Android? Robi się coraz ciekawiej ;)

μLekcja 3. Dostęp do bazy danych z linii poleceń.

2010-01-21T00:04:00.000+01:00

W trakcie pracy nad pewną aplikacją, zaistniała potrzeba bezpośredniego dostępu do bazy danych wykorzystywanej właśnie w tej aplikacji (Przez bezpośredni dostęp rozumiem możliwość połączenia się z BD z zewnątrz programu). Jeżeli, ktoś się nie przedarł przez dokumentację deweloperską Androida, to może nie wiedzieć o istnieniu takiej możliwości. Postanowiłem więc przybliżyć Wam jeden z takich sposobów!

Z odsięczą przychodzi nam ADB, a właściwie Shell ADB (Android Debug Bridge) oraz program do obsługi bazy danych sqlite3.

Krok po kroku.
1.) Uruchamiamy emulator bądź telefon.
2.) Uruchamiamy CMD.exe (Start -> Uruchom -> cmd.exe).
3.) Przechodzimy do katalogu tools z Android SDK.
4.) Wydajemy komendę adb shell. Uzyskujemy dostęp do shella na naszym emulatorze.
5.) Przechodzimy do katalogu: cd /data/data/, gdzie mamy dostępną listę wszystkich zainstalowanych aplikacji na naszym urządzeniu/emulatorze.
6.) Wybieramy interesującą nas aplikację, np. cd /my.lesson.sampledb (aplikacja z jednej z poprzednich lekcji).
7.) Przechodzimy do katalogu z bazami danych... cd /databases
8.) Ostatnim krokiem jest uruchomienie interesującej nas BD w Sqlite3, komendą sqlite3 mojaBaza (Istotna wielkość liter!!!).
9.) Dla testu możemy wydać komendę .tables, która zwróci nam istniejące tabele.

W tym miejscu odsyłam do dokumentu Command Line Shell For SQLite, gdzie wyjaśnione zostały zasady obsługi bazy danych z linii poleceń.

μLekcja 2. Formatowanie tekstu w locie

2010-01-11T19:17:00.000+01:00

Kolejna piko-lekcja. Tym razem chciałbym napisać kilka zdań na temat formatowania wyświetlanego (np. w TextView) tekstu "w locie".

Nierzadko zdarza się, że chcemy wystylizować fragment tekstu wyświetlanego na ekranie Androida.
Jednym z możliwych rozwiązań jest umieszczenie np. dwóch pól TextView na View, każde "sformatowane" wedle własnego uznania. Czego można dokonać poprzez deklaracje odpowiednich atrybutów w pliku (.xml) zawierającym layout interesującej nas aplikacji.

Przykład

Nie zawsze jest to jednak pożądane rozwiązanie, albo wręcz nie możliwe do realizacji z powodów np. konstrukcji aplikacji.

Na pomoc przychodzi możliwość formatowania tekstu w locie. Dodatkowo mamy na to nie jeden, a dwa sposoby.

Sposób pierwszy

W pierwszym sposobie skorzystamy z klasy Spannable, rozszerzającej możliwości pola TextView.

W przypadku, gdy formatowanym polem będzie pole typu EditText, nie musimy informować tegoż pola o potrzebie użycia wspomnianej klasy, gdyż EditText korzysta z niej domyślnie.

Inaczej ma się sytuacja przy polu TextView, które wymaga poinformowania o potrzebie użycia Spannable.

Przykład

Następnie deklarujemy obiekt typu Spannable...

... po czym przystępujemy do stworzenia naszych "span"-sekcji

I to wszystko. Sprawdź jakie wyniki otrzymałeś!

Drugi sposób

Z drugim sposobem formatowania tekstu w locie jest jeszcze mniej kłopotu, a niekiedy jego użycie jest jedyną możliwością np. w RemoteViews (chyba, że ktoś wie jak zastosować sposób pierwszy?).

Otóż, możemy skorzystać ze starego poczciwego HTML'a, bezpośrednio formatując tekst przesyłany do elementu przy pomocy metody .setText() albo .setTextViewText() jak ma to miejsce na poniższym listingu.

Lekcja 12. Jak skonfigurować widget!

2010-01-06T16:38:00.000+01:00

Jak wiadomo, najlepszym sposobem nauki programowania (jak i w ogóle nauki) jest postawienie sobie konkretnego celu do zrealizowania. Moim celem miało być napisanie prostej aplikacji w formie widżetu realizującego pewne zadanie. Jednak zanim umieścimy nasz widżet na pulpit-droidzie, zdarza się, że musimy go najpierw skonfigurować, podać dane jak np. login czy też hasło. Z pozoru trywialna rzecz i taka naprawdę jest ale po kolei.

ETAP 1

Pierwszym krokiem jest stworzenie prostego widgetu, takiego jaki był zaprezentowany w lekcji 4.

Potrzebne będą nam pliki:
MainWidget.class - nasz główna klasa odpowiedzialna za działanie widgetu,
main.xml - layout widgetu,
widget_provider.xml - informacje o naszym widgetcie (przypominam aby umieścić plik w lokalizacji res/xml)
oraz manifest.

Zaczymy od layoutu widgetu main.xml

Uwaga! Jeśli po wklejeniu tego kodu do edytora, będziesz miał błędy to najprawdopodobniej nie masz tła android:background..., które możesz wykorzystać z poprzedniej lekcji o widgetach.

Następnie klasa MainWidget.class

Uproszczona jak tylko się dało.

Kolej na widget_provider.xml

Wymiary widgetu, użyty layout oraz czas odświeżania metody onUpdate.
Ponadto uwaga, od wersji SDK 1.5 updatePeriodMillis działa jedynie dla wartości powyżej 30 minut. Google się tłumaczy oszczędnością baterii - słaba wymówka ;). Jeżeli potrzebujesz częściej wywoływać (okresowo) pewne zadanie, to zachęcam do zapoznania się z Timerem i jego metodami, a przede wszystkim klasą Alarm Manager - notabene o niej będzie także wkrótce lekcja.

Tip: W przypadku wybrania updatePeriodMillis="0", widget nie będzie się automatycznie aktualizował.

Ostatnim krokiem jest edycja manifestu...

ETAP 2

Ok. W tym momencie pierwszy etap zakończony. Mamy gotowy widget, którego funkcja ogranicza się do wyświetlenia zdefiniowanej wcześniej frazy.

Kolejnym etapem będzie dodanie ekranu konfiguracyjnego, który wyświetli się w trakcie dodawania widgetu na pulpit.

Pierwszym krokiem niech będzie uzupełnienie pliku widget_provider.xml o atrybut configure, wskazujący na aktywności (Activity), która powinna być wywołana przy próbie dodania widgetu.

Ostateczny wygląd providera powinień prezentować się mniej więcej tak:

Następnie tworzymy layout ekranu konfiguracyjnego.

Layout zawiera pole tekstowe, w które wprowadzimy tekst, a następnie "prześlemy" go do widgetu.

Możemy teraz przystąpić do implementacji naszej klasy obsługującej widget.
W tym celu stwórzmy nową klasę w naszym pakiecie o nazwie np. WidgetConfigure.class i doprowadźmy ją do postaci...

Szczegółowe objaśnienia w kodzie.

Zmiany zajdą także w klasie MainWidget

W powyższej klasie pojawiła się tylko jedna zmiana, a dokładnie nowa metoda updateWidget(), która uaktualni tekst na naszym widgetcie o dane pochodzące z etapu konfiguracji.

Teoretycznie można by tą metodę pominąć, a samo przypisanie nowej wartości polu R.id.widget_textview zaimplementować w metodzie onUpdate(), niestety pojawia się pewien problem. Z moich obserwacji wynika, że metoda onUpdate() jest wykonywana wcześniej niż powinna, czyli dopiero po zakończeniu (zwróceniu RESULT_OK) etapu konfiguracji widgetu, a wykonywana jest przed. A taki przebieg zdarzeń wynikałby z dokumentacji Androida. Jeśli ktoś coś na ten temat wie więcej, byłbym wdzięczny za informacje.

Acha bym zapomniał. Oczywiście mamy także metodę onDeleted(), która wywoływana jest podczas usuwania widgetu. Dzięki niej możemy posprzątać trochę po sobie.

Ostatni w kolejce do edycji jest manifest.

Koniec.

μLekcja 1. Własny ListView

2009-12-08T21:34:00.001+01:00

W ostatniej lekcji, poświęconej rejestrowi połączeń, do ich wyświetlenia wykorzystaliśmy wbudowaną listę simple_list_item_1. Niestety wadą takiego rozwiązania jest to, że dostarczamy do danego item'u jeden konkretny string, co jednocześnie pozbawia nas możliwości przekazania oraz wyświetlenia większej liczby oddzielnych danych (jak np. numer telefonu, data połączenia, czas połączenia) w sposób jak my byśmy tego chcieli.

W takim przypadku najlepiej utworzyć swoją własną listę, w której poszczególne elementy możemy rozmieścić według własnego uznania. Przykładowa lista może wyglądać tak:

Co prawda powyższy layout nie jest za bardzo wyszukany, ale nic nie stoi na przeszkodzie, aby Twój był. Możesz między innymi zdefiniować czcionki, kolory, style i rozmieszczenie poszczególnych pół tekstowych i wiele innych.

Samo przypisanie wartości (które pobierzemy z rejestru połączeń) do pól na View jak się okazało nie jest skomplikowane.

Z pomocą przychodzi nam klasa SimpleCursorAdapter, umożliwiającą mapowanie danych pochodzących z Cursor'a na TextView oraz ImageView zdefiniowanych w plikach XML'owych (np. main.xml).
Konstruktor tej klasy wygląda tak:

... i przyjmuje parametry:

context - kontekst miejsca z którego ListView jest uruchamiane
layout - nasz layout
c - kursor z danymi
from - lista z nazwami kolumn reprezentujących dane w kursorze
to - lista pól typu TextView, do których mają być przekazane dane.

[Na przerwie] Nie może być. Reality show dla programistów!

2009-12-08T11:52:00.000+01:00

Ponoć zebrała się międzynarodowa ekipa designerów oraz programistów chcąca w siedem dni stworzyć od zera aplikację na iPhone'a. Co ciekawe cały cykl powstawania tej aplikacji można obejrzeć na żywo w internecie. Transmisja trwa już od 6 grudnia, a zakończyć się ma 12. Hmmm co Wy na to? ;)

News znaleziony na webhosting.pl

Lekcja 11. Tworzymy rejestr połączeń.

2009-12-03T16:40:00.000+01:00

Wiele osób korzystających z Androida narzeka na brak, a właściwie to bardzo ograniczoną wersję rejestru połączeń, jakby się wydawało niezbędnego minimum na wyposażeniu każdego telefonu od co najmniej piętnastu lat.

Oczywiście w mniejszym bądź większym stopniu problem rozwiązują zewnętrzne aplikacje, a w Androidzie w wersji 2.0 jest już całkiem nieźle.

Tak czy owak problem występuję, bo i można to zauważyć po liczbie postów na forach, jak i ciągle pojawiających się aplikacjach rozszerzających możliwości standardowego rejestru.
Jak łatwo można stworzyć podobną aplikację, chciałem udowodnić w tej lekcji. Nie będzie to zaawansowany kombajn, a prosta aplikacja dająca przyczółek do stworzenia czegoś lepszego, czegoś dostosowanego do własnych potrzeb.

Tyle słowem wstępu. Zaczynamy.

Nawigacja w aplikacji oparta jest o TabWidget, czyli o system zakładek. Więcej informacji możesz uzyskać pod adresem http://developer.android.com/guide/tutorials/views/index.html
Natomiast historia połączeń, wraz z detalami jest wyświetlana w postaci domyślnej listy simple_list_item_1, o której już zresztą pisałem w lekcji o Sql'u.

Aplikacja opiera się na klasie RejestrActivity.class, będącej jej kontrolerem. Dodatkowo aplikacja składa się trzech klas "pomocniczych", odpowiedzialnych odpowiedniego za pobranie informacji o połączeniach przychodzących, wychodzących oraz nieodebranych.

RejestrOut.class, RejestrIn.class, RejestrMissed.class

Na pierwszy ogień, niech pójdą klasy odpowiedzialne za samo pobranie informacji o połączeniach, choć przedstawię tylko jedną, gdyż budowa pozostałych jest analogiczna, różniąca się właściwie jednym detalem. Właściwie mogłaby być tylko jedna klasa, ale musiałbym przekazywać z kontrolera informacje o TAB'ie który został kliknięty, a szczerze mówiąc nawet nie wiem jak to zrobić ;) Pomyślę o tym później.

Tymczasem zawartość klasy RejestrOut.class

W pierwszej kolejności, wykorzystując Cursor (patrz Lekcja 9) pobieramy zawartość rejestru telefonu, wstępnie go sortując po dacie.

Kolejnym krokiem jest pobranie indeksów kolumn odpowiedzialnych za interesujące nas dane/informacje. Zachęcam, do zapoznania się z dokumentacją odnośnie dostępnych pól CallLog.Calls

Ostatnią rzeczą jaką musimy zrobić, jest umieszczenie wybranych danych na liście, a następnie poprzez setListAdapter wyświetlenie jej za pomocą wspomnianej na początku defaultowej listy.

Tutaj wspomniana uwaga. W linii...

decydujemy o typie zrealizowanego połączenia. W powyższym przykładzie, przyjmujemy tylko połączenia wychodzące .OUTGOING_TYPE. Odpowiednio dostępne są także .INCOMING_TYPE oraz .MISSED_TYPE.

RejestrActivity.class

Przejdźmy teraz do naszego kontrolera. Jak wspomniałem wykorzystamy do jego budowy menu w postaci zakładek (TabWidget). Wykorzystanie ich jest dość łatwe.

Do przekazania rezultatów zwróconych przez klasy RejestrOut/In/Missed do zakładek, wykorzystałem Intenty z którymi mogłeś się już zaznajomić w jednej z poprzednich lekcji.

Zmierzamy powoli do końca lekcji. Jednak zanim ten nastąpi musimy stworzyć View dla naszych zakładek. W tym celu edytujemy plik main.xml zgodnie z poniższym wzorem.

Już naprawdę ostatnim krokiem, jest poinformowanie Androida, o chęci użycia nowych Activity, co czynimy dodając odpowiednie wpisy w manifeście. Mój manifest wygląda tak:

...and that's all

Uwaga!
Aplikacja napisana została z wykorzystaniem Android SDK 2.0
W tej formie nie będzie działać na telefonach z wersjami o niższym oznaczeniu.
Wiem, że w momencie pisania tego tutoriala, na rynku nie ma jeszcze telefonów z Androidem 2.0 na pokładzie. Jednakże pisanie w starszych wersjach Androida, mijałoby się z celem.

Lekcja 10. Hello Circle, czyli rysuj z Androidem.

2009-11-30T23:44:00.000+01:00

Szukając tematu do nowej lekcji trafiłem na blog użytkowniczki Kellbot z Nowego Jorku, która zaprezentowała bardziej niecodzienną wersję aplikacji Hello World, a mianowicie Hello Circle.

Aplikacja zamiast wyświetlić tekst, wyświetla kolorowe kółko po "tapnięciu" przez użytkownika w dowolny obszar ekranu telefonu.

Postanowiłem przybliżyć temat, a właściwie spolszczyć ten krótki tutorial...

Zaczynamy.

Tworzymy nowy projekt.

Edytujemy widok View naszej przyszłej aplikacji. Zamiast dotychczasowego LinearLayout, zastosujemy FrameLayout, który dostarczy nam obszaru na ekranie, na którym będziemy mogli umieszczać własne elementy. W naszym przypadku będą to tytułowe koła. FrameLayout umożliwia dodanie wielu swoich potomków, które zawsze będą powiązane z lewym górnym rogiem ekranu. Dzieci FrameLayout układane są na stosie, czyli najnowsze na górze.

Jako, że naszym celem będzie umieszczenie wielu elementów (kółek) na ekranie, najlepszym rozwiązaniem będzie stworzenie klasy np. Circle - odpowiedzialnej za nasze koło.

Polami klasy Circle są:

współrzędne docelowej lokalizacji elementu na ekranie (x,y),
promień koła (r),
obiekt klasy Paint odpowiedzialnej za informacje o stylach, kolorach tworzonych figur geometrycznych czy też tekstów.

Następnie tworzymy konstruktor klasy, który jest metodą wywoływaną zawsze podczas tworzenia nowej instancji klasy. W naszym konkretnym konstruktorze, bez rewelacji. Wszystko powinno być jasne.

Zapomniałem na początku wspomnieć, że nasza kulka, tfe.. kółko zostanie utworzone w nowym widoku (View) dlatego też musimy rozszerzyć naszą klasę Circle właśnie o klasę View.

Ostatnim element klasy jest metoda onDraw niezbędna do wyprowadzenia naszego rysunku na nowo powstałe View.

Na tym etapie mamy gotowy główny widok, a także klasę odpowiedzialną za rysowanie naszego koła.
Ostatnim etapem tworzenia aplikacji jest utworzenie akcji dzięki której będziemy mogli umieszczać kółka na ekranie za pomocą palca. W tym celu edytujemy główną klasę aplikacji.

Jak zapewne zauważyłeś, pierwszą czynnością jest utworzenie "chwytaka" (fLayout) do naszego View (z Main.xml).
Następnie zaprezentowane zostały dwie metody umieszczenia elementu na ekranie. Pierwsza (//1) - ordynarne określenie parametrów "na sztywno". Element zostanie umieszczony w lewym górnym rogu z marginesem 50pix.
Druga metoda (//2), jest tym co tygryski lubią najbardziej. Dzięki metodzie setOnTouchListener wykryjemy położenie palca na ekranie, a metoda onTouch zwróci nam dostęp do nowego View, a także do obiektu MotionEvent, przechowującego informacje o naszym "tapnięciu". Teraz nie pozostaje nic innego jak dodać nowy obiekt Circle na View.

To tyle. Dziękuje za uwagę.

Lekcja 9. SQLiteDatabase. Po prostu.

2009-11-24T21:30:00.001+01:00

SQLite jest jednym z systemów zarządzania bazami danych. Obok takich tuz jak MSSQL, MySQL, PostgreSQL czy też Oracle stanowi jedną z najpopularniejszych implementacji silnika SQL w szeregu aplikacji/urządzeń. Jak pewnie się domyślasz w Androidzie również został wykorzystany (jak i w Iphonie czy Firefoxie). Do głównych zalet (choć akurat to zależy od punktu widzenia) SQLite, możemy zaliczyć możliwość użycia bazy danych bez konieczności uruchamiania osobnego procesu, a także fakt, iż dane przechowywane są w jednym pliku binarnym (do 2TB) w postaci B-drzew. Dodatkowym atutem opisywanej BD jest wydajność przy wykonywaniu (w sczególności) podstawowych zapytań typu INSERT lub SELECT. SQLite (jak i wszystko) nie jest wolny od wad, ale nie o tym jest ta lekcja, dlatego w tym miejscu zakończę teorię z nim związaną.

W tej lekcji zapoznasz się z podstawami użycia bazy danych SQLite w Androidzie.
Stworzymy prostą aplikację, której celem będzie utworzenie bazy danych, zapisanie do niej pewnych informacji, a następnie wyprowadzenie ich na ekran Androida.

Zacznę od zaprezentowania kodu aplikacji, po czym przystąpię do jego omówienia.

Zajmijmy się ciekawszymi fragmentami kodu. I tak zaczynamy od metody openOrCreateDatabase(), za pomocą której otworzymy bazę danych lub w przypadku jej nie istnienia, utworzymy ją. Parametrem metody jest między innymi nazwa bazy danych, a także tryb dostępu - w naszym przpadku jest to MODE_PRIVATE stosowany w przypadku standardowych operacji. Następnie tworzymy nową tabelę, po czym umieszczamy w niej dane.

Linijka 38. Tworzymy instancję Kursora, który posłuży nam do dostępu do rezultatów zwróconych przez zapytanie SQL.

Linijki 40-45. Umieszczamy pobrane z zapytania dane na liście. Tutaj polecam zapoznać się z dokumentacją Kursora w AndroidSDK, a dokładnie z linkiem http://developer.android.com/reference/android/database/Cursor.html, gdzie opisane są wykorzystane w powyższym przykładzie metody, jak moveToFirst() czy moveToNext().

Zawartość listy wyprowadzamy na ekran przy pomocy metody setListAdapter(), na jeden z domyślnych layoutów (widoków) zaimplementowanych w Androidzie. Tutaj uwaga! Aby można było skorzystać z powyższej metody musimy rozszerzyć naszą główną klasę o klasę ListActivity, która umożliwia wyświetlanie listy elementów dzięki powiązaniu z źródłem danych, jak np. Cursor.

To by było na tyle. Nic ciekawego już nie ma.

Efekt...

Lekcja 8. Serwisy w Androidzie. Bynajmniej nie informacyjne.

2009-11-18T21:00:00.001+01:00

Service jest jednym z podstawowych komponentów dostępnych w androidowych aplikacjach. Jednak to co go wyróżnia, to fakt iż "chodzi" w tle, bez potrzeby interakcji z użytkownikiem.

Prezentowany service należy do grupy tak zwanych local service, charakteryzujących się tym, że chodzą w tym samym procesie z którego zostały uruchomione, co między innymi oznacza, że ich żywotność jest ściśle powiązana z wątkiem z którego zostały wywołane. W przypadku serwisów "długochodzących", trwających cały czas w systemie (np. klient email), albo mocno zasobożernych typu odtwarzacz muzyczny, poleca się użycie remote service, pozwalających umieścić serwis w osobnym wątku, do którego będzie mogła się odwoływać większa liczba klientów (O remote service wkrótce będzie osobna lekcja).

Poniżej zaprezentowałem prosty przykład użycia serwisu (przepraszam za to niezbyt trafne spolszczenie). Aplikacja umożliwia uruchomienie oraz zatrzymanie usługi (serwisu). Do tego wykorzystamy nieskomplikowany kontroler. Nic nam po serwisach, gdybyśmy nie mogli zobaczyć efektów ich pracy, bo trzeba pamiętać, że serwisy same w sobie nie posiadają interfejsu. Dlatego też do uwidocznienia ich działań, wykorzystamy notyfikację opisaną kilka lekcji wstecz.

Tradycyjnie tworzenie aplikacji zaczniemy od zaprojektowania intefejsu aplikacji "matki".
Jedyne co nam potrzeba, to dwa przyciski, jeden do uruchamiania, a drugi do zatrzymywania serwisu.

Całość widoku może wyglądać np. tak...

Ok. Utwórz teraz nową klasę. nazwij ją np. myService. Podstawową klasę możesz przemianować na myController.

Zaczynamy od zaprogramowania kontrolera serwisu (myController.class).

Tak kod kontrolera wygląda u mnie. Samo uruchamianie i zatrzymywanie serwisu jest jak widać banalnie proste...

Teraz pora na bohatera wieczoru, czyli źródło nie kogo innego jak samego serwisu (myService.class)

Widzimy, że klasa myService dziedziczy po klasie Service. Następnie widzimy interfejs do zdalnego wywoływania serwisu IBinder, dzięki któremu możemy nawiązać stałe połączenie z serwisem.

W dalszej kolejności dochodzimy do metody onCreate, która wykona dla nas dwie rzeczy.
Wyświetli tekst, informujący o fakcie uruchomienia serwisu, a przede wszystkim wywoła funkcję okresowePowiadamianie() , które co określony czas (np. 50 sekund) wyświetli powiadomienie na pasku statusu.

Ostatnią metodą jest metoda onDestroy(), która zostanie wywołana w momencie zatrzymania serwisu.

Jeżeli w tym momencie chciałeś uruchomić aplikację, to niestety pewnie się to nie udało i nie uda, a przynajmniej do momentu aż nie poinformujesz Androida w AndroidManifeście, o chęci użycia serwisu.
W tym celu dodaj przed znacznikiem zamykającym application poniższą linijkę.

W tym momencie możesz już w pełni cieszyć się swoją pierwszą usługą uruchomioną w tle systemu.

Lekcja 7. Pobieramy źródło strony WWW

2009-11-12T20:13:00.001+01:00

Jakiś czas temu zmuszony byłem do "wyłuskania" pewnego fragmentu treści z kodu źródłowego pewnej strony. Jak się okazało nie było to bardzo skomplikowane, a moje początki z tym zagadnieniem są tematem lekcji którą czytasz.

Stworzymy aplikację dzięki której będzie możliwe pobranie tytułu dowolnej strony.

Let combat begin

W pierwszej kolejności poproszę Cię o utworzenie View, które będzie zawierało jedno pole EditText oraz jeden Button. W pole tekstowe wprowadzisz adres internetowy interesującej Cię strony, a przyciskiem wywołasz metodę parsującą stronę.

Następnym krokiem jest dodanie pozwolenia aplikacji na dostęp do Internetu.
W tym celu w manifeście aplikacji powyżej tagu application... dopisz poniższą linijkę:

Ok. Teraz możesz uzupełnić główną klasę aplikacji o treść z poniższego listingu.

Metoda onCreate zawiera obsługę naszego jedynego przycisku w aplikacji, którego użycie powoduje wyzwolenie funkcji Parse, która odpowiedzialna jest za wyszukanie w podanym stringu treści umieszczonej pomiędzy wskazanymi przez nas tagami. Wspomnianym stringiem jest wynik działania funkcji urlGet, która za parametr przyjmuje adres WWW interesującej nas strony. Jest ona przy okazji najciekawszą częscią aplikacjji. To w niej dochodzi do utworzenia połączenia, zbufforowania strony, w konsekwencji umieszczenia "umieszczenia" jej w zmiennej typu String.

Koniec

Efekt.Patrz niżej.

Lekcja 6. N jak Notification, czyli alfabetu ciąg dalszy.

2009-11-05T21:17:00.002+01:00

Idąc za ciosem, a raczej za Intentami (patrz lekcja numer 5), chciałbym przedstawić kolejną aplikację korzystającą z tych jakże niezwykłych kreaturek, a przy okazji pokazać coś nowego, bez czego żaden system nie mógłby się obejść, czyli powiadomień użytkownika o wydarzeniach zachodzących w jego systemie.

Notyfikacja. Po polskiemu powiadomienia. To one będę bohaterami poniższej lekcji.

Na początek trochę teorii.

Powiadomienia w systemie Android zazwyczaj pojawiają się na pasku statusu (status bar). To po pierwsze. Jednak ich możliwości na tym się nie kończą. Nie dość, że mamy możliwość "rozwinięcia" powiadomienia, to możemy dołączyć do niego dźwięk, alarm wibracyjny czy też migającą diodę LED.

Ideą powiadomień jest to, że pojawiają się one bez naszej ingerencji, pochodzą od aplikacji/serwisów chodzących w tle. Np. poczta e-mail, sms itp.

Jednak na potrzeby tej lekcji powiadomienie wywołamy sami, z okienka (Activities), klikając na przycisk.

Lets get it started

Celem aplikacji będzie wyświetlenie powiadomienia (komunikatu) na pasku statusu, które będzie można rozwinąć, a następnie klikając w nie zostanie otwarta przeglądarka internetowa ze wskazaną przez nas stroną WWW.

Do stworzenia powiadomienia wykorzystamy dwie klasy:

Notification - odpowiedzialna za to jak powiadomienie zostanie wyświetlone. Przykładowo jaka ikona zostanie wyświetlona pasku statusu, jaki dźwięk zostanie odtworzony, jakie View zostanie użyte po rozwinięciu paska statusu itd.
NotificationManager - klasa do zarządzania powiadomieniami użytkownika o zdarzeniach w systemie. NotificationManager jest klasą, dla której nie można utworzyć jej instancji. W zamian tego używamy metody getSystemService(String) zwracającej do niej referencję. Parametrem tej metody jest jeden z systemowych serwisów, np. VIBRATOR_SERVICE (w przypadku chęci użycia takowego), WIFI_SERVICE itp. Nas interesuje NOTIFICATION_SERVICE.

Zwyczajowo zaczynamy od stworzenia View aplikacji. Tym razem nie będzie inaczej, z wyjątkiem, że sam(a) utworzysz odpowiednie view. Ważne, żeby zawierało przynajmniej jeden przycisk, który będzie odpowiedzialny za wywołanie powiadomienia.

Na tym etapie nie pozostaje nic więcej, jak zaprezentować źródło naszej aplikacji.

Przyjrzyjmy się mu bliżej.

Pobieramy referencję do NotificationManager

Tworzymy instancję Notification. Jako parametry przyjmuję ikonę jaka zostanie wyświetlona przy powiadomieniu po rozwinięciu, tekst jaki zostanie wyświetlony na pasku statusu oraz moment kiedy powiadomienie ma się pojawić.

Tworzymy obiekt typu Intent. Uruchomi przeglądarkę, a następnie przejdzie na stronę o podanym adresie.

Tworzymy obiekt typu PendingIntent. Umożliwia on przekazanie intentu do innej aktywności (Activities). Np. w naszym przypadku zostanie wywołany z powiadomienia.

Ustawiamy intent oraz teksty jakie mają się pojawić po wywołaniu powiadomienia.

Opcjonalnie można dodać flagi, w tym przypadku poniższa flaga powoduje automatyczne usunięcie powiadomienia po "wejściu w nie".

Ostatnim krokiem jest przekazanie (metoda notify()) do NotificationManagera naszego powiadomienia. Drugim parametrem jest unikalny dla całej aplikacji identyfikator naszej notyfikacji.

Koniec. Efekt - patrz niżej.

Lekcja 5. I jak Intents.

2009-11-02T19:19:00.004+01:00

Do tej pory prezentowane we wcześniejszych lekcjach aplikacje korzystały tylko z jednego widoku, z jednego okienka. Byłoby to idealne rozwiązanie z punktu widzenia wygody użytkownika, niestety głównym ograniczeniem są rozmiary ekranów urządzeń mobilnych. Dlatego też, dla zwiększenia przejrzystości, a także „upchnięcia” większej liczby opcji, a raczej ich ustawień dobrze jest wykorzystać dodatkowe widoki, otwierane w nowych oknach. Niby nic takiego, ale pojawia się problem komunikacji pomiędzy tymi okienkami, a dokładnie to przesyłania pomiędzy nimi danych.
W Javie Dalvik do realizacji tej funkcjonalności wykorzystujemy obiekty zwane Intents.

Do dzieła!

Tworzymy nowy projekt.

W pierwszej kolejności edytujemy plik z wyglądem podstawowego okienka według poniższego schematu.

main.xml

Zawartość mam nadzieje jasna.

Dodajemy nową klasę do naszego pakietu. Nazwijmy ją SecondActivity, po czym chwilowo o niej zapomijmy.

Skierujmy teraz nasze kroki do klasy MainActivity.

MainActivity.class

Uzupełniamy metodę onCreate. To co nas interesuje, znajduje się wewnątrz metody onClick. W niej tworzymy nową instancję klasy Intent, jako parametry podajemy informacje o kontekście aplikacji oraz nazwę klasy z którą będziemy chcieli się komunikować. Następnie „wystartowujemy” nasz intent z możliwości zwrócenia rezultatów. Jako parametr podajemy referencję do stworzonego przez nas intentu, oraz unikalną liczbę identyfikującą konkretną „sesję”.

W tym miejscu przerywamy edycję plików związanych z pierwszym okienkiem, zajmując się drugim.

Zwyczajowo zaczynamy od „naszkicowania” jego wyglądu. Nie możemy zrobić tego w pliku main.xml gdzie zdefiniowany został wygląd pierwszego okienka. W związku z tym, tworzymy nowy plik xml w katalogu /res/layout, o nazwie np. main_second.xml. Jego zawartość odpowiadać powinna poniższemu listingowi.

MainSecond.xml

Głównymi elementami tego okna jest pole wprowadzania/edycji tekstu (EditText) oraz przycisk.

Uzupełniamy, wcześniej stworzoną przez nas klasę SecondActivity.

SecondActivity.class

Wyjaśniam szybko co tu się dzieje. Otóż po kliknięciu przez użytkownika przycisku button_close, wyzwalamy metodę onClick, w której stworzony zostaje obiekty typu Intent. Przy pomocy metody putExtra przypisujemy do zmiennej(?) result zawartość tekstu wprowadzonego w polu EditText. Następnie przekazujemy rezultaty (setResult) do pierwszego okienka. Metoda finish zamyka bieżące okno.

W momencie wykonania metody finish, program powróci do naszego pierwszego okienka (MainActivity). Powróci z pewnymi danymi, które musimy jakoś odebrać. Z pomocą przychodzi metoda onActivityResult, która pozwoli nam przyjąć przesłana dane.

Jej zawartość powinna przedstawiać się mniej więcej tak:

MainActivity.class

Jako, że metodą onActivityResult odbierać może dane pochodzące z wielu okienek (activities), wykorzystujemy podany wcześniej identyfikator wywołania.
Do sprawdzenia poprawności działania komunikacji między oknami, wykorzystujemy obiekt Toast „dymek”.

Uwaga! Zwróćcie uwagę na wersję SDK Androida, bo coś mi się zdaje, ze na przestrzeni ewolucji wspomnianego sdk'a mieszali coś w Intentach.
Powyższy przykład został zrealizowany przy wykorzystaniu SDK 1.6

Ps.
Przez jakiś czas brakowało tu jednej ważnej informacji (której zapomniałem umieścić) o pewnej czynności, którą trzeba dodatkowo wykonać, aby aplikacja zadziała.

Otóż, w powyższym tutorialu zabrakło wpisu informującego aplikację o istnieniu drugiego Aktywności (Activity). Co czynimy oczywiście Manifeście.

Podziękowania za zwrócenie na to uwagi, możecie słać do kolegi DrafFter'a ;)

Lekcja 4. Pierwszy Widget, a w dodatku funkcjonalny !

2009-10-21T22:36:00.002+02:00

Wi..., Ga.. i inne dżety zadomowiły się już chyba na wszystkich systemach operacyjnych. Od dużych po małe. Oczywiście w Androidzie też ich nie zabrakło. Przyjrzyjmy się więc procesowi powstawania jednego z nich.

Nasz pierwszy widget, będzie realizował pewną prostą acz przydatną czynność, mianowicie będzie informował nas o godzinach wschodów i zachodów słońca.

Do dzieła!

Część wizualna

Tworzymy nowy projekt – tu po staremu. Następnie, zgodnie z naszą tradycją przystępujemy do projektowania layoutu (main.xml).

Jak widać, korzystamy tylko z jednego komponentu - TextView.

UWAGA!
Być może część z Was zauważyła atrybut:background w tagu LinearLayout. Jest to tło naszego widgetu. Jednak najpierw musi ono znaleźć się w podanej lokalizacji, a dokładnie w katalogu res/drawable/, który to trzeba najpierw stworzyć, poczym umieścić w nim poniższy plik tła (.png)

Idziemy dalej. Edytujemy plik strings.xml znajdujący się katalogu Resources/values/. Uzupełniamy go o opisy nowych pól.

Dochodzimy w tym miejscu do istotnego punktu, jakim jest poinformowanie Androida o tym, że będziemy tworzyli widget. Dlatego też otwieramy do edycji plik AndroidManifest.xml znajdującym się w korzeniu projektu.

AndroidManifest jest to plik w którym między innymi deklarujemy jaki typ aplikacji tworzymy, na dostęp do jakich elementów systemu/telefonu zezwalamy tworzonej aplikacji (np. do książki telefonicznej, danych z GPS), itp.

Wracając do tematu, wygląd naszego, a raczej Androidowego Manifestu przedstawia się następująco:

Ostatnim krokiem w projektowaniu i kodowaniu strony wizualnej jest edycja pliku res/xml/zachodnik_widget_provider.xml (trzeba go utworzyć ręcznie), tak zwanego widget providera.

W widget providerze definiujemy podstawowe parametry widgetu, takie jak jego wymiary, czas podany w milisekundach co jaki widget ma się odświeżać. Dodatkowo mamy podany użyty layout – tu ważne jego nazwa musi być zgodna z nazwą naszego pliku z layoutem. Przypominam u nas jest to main.xml.

Część logiczna

Pierwszym krokiem jest utworzenie nowej klasy w pakiecie org.me.zachodnik. Nazywamy ją Zachodnik.

Ok. W tym momencie, możemy spróbować skompilować naszą aplikację. Rezultatem powinien być widget wyświetlający napis Hello World! Acha, oczywiście widget musimy najpierw umieścić na jednym z pulpitów Androida.

Zrzutu ekranu na tym etapie nie przedstawiam, bo nie to nas interesuje.

Długo myślałem… eee właściwie to nie długo ;) jakby „ufunkcjonalnić” nasz widget. Wybór padł na implementacje algorytmu obliczającego godziny zachodów i wschodów słońca. Skorzystałem z algorytmu udostępnionego na stronie http://cybermoon.w.interia.pl/

Poniżej zamieszczam cały kod implementacji widgetu. Plik Zachodnik.java

Sam kod składa się właściwie tylko z metody onUpdate oraz klasy ZachodyWschody.

Metodę onUpdate wykorzystujemy podczas tworzenia widgetów. Wywoływana jest w momencie dodania widgetu na pulpit. Odświeżana jest co określony czas, zdefiniowany wcześniej w atrybucie updatePeriodMilli. W przypadku naszej aplikacji rolą odświeżania przejmie obiekt typu Timer.

Klasę ZachodyWschody na wstępie rozszerzamy o TimerTask (niezbędne do użycia metody scheduleAtFixedRate). Składa się ona z konstruktora, funkcji algorytm() oraz metody run().

Zastosowania elementów RemoteView, AppWidgetManager myślę, że można się domyśleć.

Jeżeli kompilacja kodu przebiegła poprawnie, powinniśmy móc użyć naszego widgetu.