Tworzenie aplikacji na platformę Android

android logo

Ostatnio zainteresowałem się platformą Android, która wydała mi się dość interesująca z uwagi na ciekawe podejście oraz duże ułatwienia w tworzeniu aplikacji. Już pierwsze kilkanaście minut z przykładami na Androida wystarczy aby zauważyć świeże (na ile to możliwe) pomysły twórców tej platformy.

W całej platformie chyba najbardziej podoba mi się podejście do tworzenia interfejsów użytkownika, osoby zapoznane z Flexem mogą znaleźć tu pewną analogię a mianowicie podobnie jak we Flexie interfejs użytkownika może być tworzony deklaratywnie w pliku XML, oczywiście w dalszym ciągu istnieje możliwość stworzenia interfejsu standardowo (w czystej Javie ala Swing), jednak to właśnie deklaratywne tworzenie interfejsu w moim skromnym mniemaniu jest kierunkiem w którym wszystkie rozwiązania wspierające tworzenie UI powinny się kierować.

Aby nie przedłużać przystąpię w tym momencie do opisu całej koncepcji i podstawowcyh zagadnień związanych z Androidem. Na samym początku warto zaznaczyć, że Android opiera się na systemie Linux, każda aplikacja napisana na tą platformę jest uruchamiana w odrębnym procesie. Każda aplikacja jest również uruchamiana w swojej instancji JVM nie jest to jednak JVM od Oracle, tfu miało być Sun’a a maszyna stworzona przez inżynierów Androida na bazie Apache Harmony, nazywa się ona Dalvik. Dalvik na tyle się róźni od JVM z Sun’a, że kod napisany na JVM Sun’a musi zostać skonwertowany przy użyciu specjalnego narzędzia które docelowo stworzy plik z rozszerzeniem .dex, plik taki jest mniejszy od jar’a stworzonego pod JVM Sun’a, spowodowane jest to optymalizacją kodu i jego konwersją na bytecode Dalvika. Warto też tu dodać, że Dalvik VM nie jest zgodny z żadnym standardem wypracowanym przez JCP (myślę tutaj głównie o JME i innych standardowych bibliotekach).

Tyle o samym backgroundzie na którym będą uruchamiane aplikacje, czas przybliżyć koncepcję wg. której tworzone są aplikacje na Androida. Wyróżnić tutaj możemy cztery podstawowe kategorie komponentów na bazie których stworzyć możemy większość aplikacji, są nimi aktywności (activities), usługi (services), adresaci (broadcast receivers) i wreszcie dostawcy treści (content providers). Opiszę teraz pokrótce każdą z nich:

Aktywności (activities)

Aktywności możecie identyfikować z pewnego rodzaju prostym zadaniem jak np. wyświetlenie listy osób w książce adresowej, pokazanie galerii zdjęć czy wreszcie pokazanie szczegółów kontaktu w komunikatorze. Każda aktywność może być wywołana niezależnie a jej wywołanie może się odbywać z poziomu różnych aplikacji (tu wchodzą w grę uprawnienia które opiszę w jednym z kolejnych postów). Aktywność powinna być utożsamiana przez was z tym co widzicie na wyświetlaczu.

Usługi (services)

Usługi w stosunku do aktywności nie są widoczne dla użytkownika w sposób bezpośredni. Usługa służy do wykonywania czegoś w tle (background) jak np. pobierania pliku, synchronizacji danych czy też odtwarzania muzyki.
Usługa może zostać wywołana z poziomu aktywności np. kliknięcie na liście plików do pobrania spowoduje schowanie ekranu aplikacji przy jednoczesnym uruchomieniu usługi pobierania pliku w tle.

Adresaci (broadcast receivers)

Adresaci reagują na zdarzenia, zdarzenia są rozgłaszanie w systemie i mogą przekazywać naprawdę różne informacje m.in. rozładowanie baterii, utrata zasięgu sieci. Użycie komponentu adresata pozwala w łatwy sposób reagować na takie zdarzenia, adresat taki może w konekwencji uruchomić pewną aktywność (np. uruchomić listę sieci do wyboru przy nagłym braku zasięgu wcześniej obsługiwanej sieci).

Dostawcy treści (content providers)

Dostawcy treści to komponenty odpowiedzialne za współdzielenie treści pomiędzy aplikacjami, umożliwiają one aplikacją dostęp do zasobów innych aplikacji (tutaj również w grę wchodzą uprawnienia).

To chyba tyle tytułem wstępu. W kolejnym poście omówię podstawy tworzenia interfejsów, wspomnę też o tajemniczej klasie R :)

July 26, 2009 | 5 Comments