Ku pamięci :-)

Hej,

   Dzisiejszy post piszę (głównie) dla siebie - żeby potem znowu nie szukać. Ale jeśli komuś skrócę czas szukania rozwiązania to też dobrze.

Ostatnio znalazłem dwie fajne rzeczy w internecie odnośnie robienia aplikacji mobilnych na Google android.

   Pierwsza z nich (i jak na razie jest to mój osobisty faworyt), to biblioteka do pobierania obrazków z sieci i "cache'owania" ich w pamięci stałej i ulotnej telefonu. Jest napisana w ten sposób, ze bardzo łatwo można ją wykorzystać wespół z ListView do tzw lazy list loading. Krótko mówiąc rzecz polega na tym, że lista ładuje tekstową zawartość, natomiast obrazki ładowane są przez naszą bibliotekę asynchronicznie z internetu i od razu zapisywane na karcie pamięci i w samej pamięci telefonu. Autorem jest Fedor Vlasov, zaś żródła samej biblioteki dostępne są na github'ie wraz z przykładową aplikacją.
   Druga ze znalezionych rzeczy jest znacznie mniej imponująca, ale mnie się dobrze przysłużyła. Chodzi mianowicie o wysyłanie i reagowanie na wysłane Broadcasty. Wstyd się przyznać, ale zawsze myślałem, że to strasznie skomplikowane, ale ten wpis przekonał mnie, że nie taki diabeł straszny ;-)

To tyle na dzisiaj :-)

Szczypek

Horoskop

   Niniejsza aplikacja powstała już jakiś czas temu na prośbę jednego z potencjalnych pracodawców. Czasem tak jest, że kandydat jest proszony o napisanie próbnej aplikacji tak by pracodawca mógł sprawdzić jak sobie osoba starająca się o pracę poradzi. Produktem takiej działalności jest właśnie Horoskop.

   Aplikacja jest ekstremalnie prosta - posiada tylko dwa widoki. Listę znaków zodiaku i widok szczegółowy, który pojawia się po wybraniu jednego ze znaków.

  Ale tak na prawdę to chodzi w niej o to co dzieje się "pod maską".

Pierwszy widok jest to lista znaków zodiaku (ikona graficzna reprezentująca znak i nazwa), drugi widok zawiera treść pojedynczego horoskopu wraz z ikoną i możliwością odświeżenia danych (ponownego pobrania ich z serwera).



Dane do aplikacji pobierane są z jednego z serwisów internetowych w postaci pliku JSON z zakodowanym horoskopem na cały tydzień dla wszystkich znaków. Symbole znaków również pobierane są z internetu. Przy czym grafiki są pobierane z sieci tylko przy pierwszym uruchomieniu aplikacji i "cache'owane" w telefonie.
Horoskop wygląda dobrze zarówno w trybie portretowym, jak i w trybie "landscape" (jeśli tekst się nie mieści, to można go przewijać).

Jeśli chodzi o interfejs użytkownika, to dzięki zastosowaniu Fragments aplikacja wygląda również dobrze na ekranie tabletu.

   Ogólnie rzecz biorąc Horoskop jest przykładem zastosowania sporej liczby technologii i możliwości Androida.
   Tak więc poza wykorzystaniem Fragments do tworzenia interfejsu graficznego dzięki czemu jedną, wspólną bazą kodu obsługuję i telefony i tablety (wystarczy tylko osobny plik z opisem layoutu aplikacji dla tabletu) jest w niej przykład pobierania danych z webserwisu i parsowania ich z formatu JSON.
Grafiki pobierane są w niezależnych wątkach, dzięki czemu nawet przy pierwszym starcie aplikacja jest interaktywna i responsywna a same grafiki pojawiają się stopniowo w miarę postępów pobierania. Do tego celu wykorzystalem bibliotekę LazyList.
Same dane z horoskopami pobierane i parsowane są również w tle z wykorzystaniem Services, które informują Broadcastem widok wyświetlający dane szczegółowe o konieczności przeładowania zawartości kontrolek. Tak więc również pobieranie danych i parsowanie JSONa również nie wpływa negatywnie na responsywność aplikacji.

   Po raz pierwszy postanowiłem kod zamieścić w publicznym repozytorium. Tak więc kod aplikacji można znaleźć na serwisie github.

To tyle :-)

Kfiatki

Dzisiaj coś dla początkujących (i przypomnienie dla doświadczonych ;-) ).

Od jakiegoś czasu ślęczę nad cudzym kodem javascript (nie pytajcie jak to się stało). No i co jakiś czas wyławiam "kfiatki" typu używanie niezdefiniowanej zmiennej itp.
Ale wczoraj znalazłem coś takiego, co umocniło mnie w przekonaniu żeby na prawdę uważać przy konstruowaniu instrukcji warunkowych i zawsze kilka razy przemyśleć, czy to co wpisałem ma jakikolwiek sens. Oczywiście nie muszę chyba przypominać, żeby stawiać nawiasy wszędzie tam, gdzie jest choćby mała wątpliwość odnośnie kolejności wykonywania działań, bo po miesiącu może być krucho z przypomnieniem sobie co tak właściwie jest sprawdzane w danym "ifie".

Poniżej jest "kfiatek" o którym mowa. Na pierwszy rzut oka jest to instrukcja jakich wiele, ale proponuję zastanowić się co tam się dzieje:

if (!zmienna == 'jakisString') { /* ciało warunku */ }

Zmienna o nazwie zmienna jest typu znakowego (string). Ponieważ w tej instrukcji nie ma nawiasów, to interpreter javascript widzi to tak:

if ((!zmienna) == 'jakisString') { /* ciało warunku */ }

Co z tego wynika? Ano to, że nie zostaną wykonane instrukcje zawarte w ciele warunku (w tym przypadku to tylko komentarz). Stanie się tak dlatego, że interpreter javascript widząc kod: !zmienna zamieni po cichu typ zmiennej zmienna, ze string na typ logiczny i potem zastosuje operator "!". 
Po lewej stronie operatora == będziemy więc mieli zmienną typu logicznego a po prawej zwykłego string'a. Niestety javascript w tym przypadku nie dokona automatycznego rzutowania  'jakisString' do zmiennej typu logicznego, zaś próba porównania zmiennych dwóch różnych typów zwraca zawsze wartość false (no bo przecież string nie jest boolean'em), co również następuje w naszym przypadku.


Autorowi owego wybryku chodziło prawdopodobnie o sprawdzenie, czy zmienna jest różna od 'jakisString', czyli o wyrażenie:

if (zmienna != 'jakisString') { /* ciało warunku */ }