Architektura systemu. Środowisko programistyczne. Emulator

Architektura systemu. Środowisko programistyczne. Emulator

WSTĘP DO PROGRAMOWANIA APLIKACJI MOBILNYCH
DLA SYSTEMU ANDROID
Architektura systemu.
Środowisko programistyczne.
Emulator systemu Android.
Przegląd podstawowych pojęć.
Pierwszy program.
Wykorzystane materiały:
http://developer.android.com; Conder, Darcey „Programowanie aplikacji na urz. przen.; Wikipedia
APLIKACJE
MOBILNE
Architektura systemu
APLIKACJE
MOBILNE
Opis warstw
APLIKACJE
MOBILNE
Linux Kernel (jądro linuksowe)
Android opiera się na wersji jądra 2.6 dla podstawowych usług
systemowych, takich jak bezpieczeństwo, zarządzanie pamięcią,
zarządzanie procesami, stos sieciowy i model sterownika. Jądro działa
również jako warstwa abstrakcji pomiędzy sprzętem i resztą stosu
oprogramowania.
Android Runtime (środowisko uruchomieniowe)
Android zawiera zbiór bibliotek, które dostarczają większość funkcji
dostępnych w bibliotekach podstawowych języka Java.
Każda aplikacja działa we własnym procesie, z własnej instancji
maszyny wirtualnej Dalvik. Dalvik została napisana tak, że na
urządzeniu można uruchomić wiele maszyn wirtualnych.
Dalvik VM wykonuje pliki wykonywalne (.dex) skonstruowane tak, aby
zużywały minimalną ilość pamięci
Opis warstw (c.d.)
APLIKACJE
MOBILNE
Libraries (biblioteki)
Android zawiera zestaw bibliotek C / C++ używanych przez różne
elementy systemu. Możliwości te są udostępnione programistom
poprzez Application Framework.
Niektóre z głównych bibliotek:
System C library - implementacja standardowej systemowej biblioteki C (libc),
dostrojona dla urządzeń wbudowanych opartych na Linuksie
Media libraries – bazuje na OpenCORE PacketVideo; wsparcie dla odtwarzania i
nagrywania wielu popularnych formatów audio i wideo, jak i statycznych plików
graficznych, w tym MPEG4, H.264, MP3, AAC, AMR, JPG i PNG
Surface manager - zarządza dostępem do podsystemu wyświetlania grafiki 2D i 3D z
wielu aplikacji
LibWebCore - silnik przeglądarki internetowej, wykorzystywany zarówno w
przeglądarce jak i WebView
SGL - podstawowy silnik graficzny 2D
3D libraries - realizacja w oparciu o OpenGL ES 1.0 API, biblioteki używają
sprzętowej akceleracji 3D (jeśli jest dostępna) lub dołączonego, zoptymalizowanego
renderera 3D
SQLite - lekki silnik relacyjnych baz danych
Opis warstw (c.d.)
APLIKACJE
MOBILNE
Application Framework (framework aplikacji)
Deweloperzy mają pełny dostęp do tego samego API, używanego przez aplikacje
podstawowe systemu.
Architektury aplikacji ma na celu uproszczenie ponownego używania komponentów,
każda aplikacja może publikować swój interfejs i każda inna aplikacja może wówczas z
niego skorzystać (z zastrzeżeniem ograniczeń bezpieczeństwa). Ten sam mechanizm
pozwala na wymianę komponentów przez użytkownika.
Framework oferuje zestaw usług i systemów, w tym
Bogaty i elastyczny zestaw widoków (Views), które można wykorzystać do budowania
aplikacji, w tym list, siatek, pól tekstowych, przycisków, zagnieżdżania przeglądarki
internetowej (WebView)
Dostawców treści (Content Providers), które pozwalają aplikacjom dostęp do danych z
innych aplikacji, (np. takich jak Kontakty), lub dzielić się swoimi danymi
Menedżer zasobów (Resource Manager), umożliwiając dostęp do zasobów, takich jak
zlokalizowanych treści, grafik, plików układu aplikacji
Notification Manager, który umożliwia wszystkim aplikacjom wyświetlanie powiadomień w
pasku stanu
Activity Manager, który zarządza cyklem życia aplikacji
Architektura systemu (c.d.)
APLIKACJE
MOBILNE
Każda aplikacja działa w obrębie
własnej maszyny Dalvik (jest
odizolowana od innych).
Aplikacje są kodem zarządzanym.
Każda aplikacja działa jako osobny
użytkownik systemu Linux, w
osobnym procesie.
Każda aplikacja musi uzyskać
odpowiednie uprawnienia, aby
skorzystać z „czułych” elementów
systemu (kontakty, rozmowy, karta
SD itp.) albo z danych
udostępnianych przez inne
aplikacje.
Aplikacje muszą być odpowiednio
podpisane przy użyciu certyfikatów,
aby można je było publikować i
instalować.
Środowisko programistyczne
APLIKACJE
MOBILNE
Java Platform JDK 6 (JDK 7 nie jest oficjalnie wspierane)
http://www.oracle.com/technetwork/java/javase/downloads/
Android SDK
http://developer.android.com/sdk
Jakieś IDE, np. Eclipse, Netbeans, IntelliJ IDEA,
MOTODEV Studio, czasem z odpowiednią wtyczką
większość przykładów w sieci jest dostosowana do Eclipse
za najwygodniejsze uchodzi MOTODEV Studio
ja używam Netbeans z wtyczką nbandroid…
http://netbeans.org/, http://www.nbandroid.org/
… i nie narzekam
Dodatkowo: Android NDK
Szkielet aplikacji Androida
APLIKACJE
MOBILNE
Główne komponenty aplikacji:
akcje (actions) – funkcje wykonywane przez aplikacje
grupy widoków (views) – definiujące interfejs użytkownika
intencje (intents) – informujące system o planach aplikacji
usługi (services) – pozwalają na przetwarzanie danych w tle
powiadomienia (notifications) – informują użytkownika o wykonaniu
jakiegoś zadania czy o zajściu czegoś co użytkownika może
zainteresować
Aplikacje wchodzą w interakcję z systemem oraz sprzętem przy
użyciu kolekcji menedżerów, np. LocationManager (lokalizacja),
ViewManager (interfejs użytkownika)
Aplikacje mogą prowadzić wzajemne interakcje korzystając z
dostawców treści (ContentProvider), bądź same udostępniając
swoje dane.
Najważniejsza terminologia (1)
Aktywność (Activity)
Podstawowy składnik aplikacji, realizujący pewne zadanie.
Na przykład (aplikacja „e-Doświadczenia w fizyce”):
aktywność wyświetlająca ekran początkowy
aktywność wyświetlająca informacje
aktywność wyświetlająca listę e-doświadczeń
aktywność wyświetlająca szczegóły wybranego e-doświadczenia
aktywność uruchamiająca e-doświadczenie
Zwykle aktywności są skojarzone z pojedynczym ekranem
interfejsu użytkownika
Reprezentacja: klasa android.app.Activity
UWAGA! Nie ma metody main(), za to można daną aktywność
oznaczyć jako główną (w pliku manifestu – o tym później)
APLIKACJE
MOBILNE
Najważniejsza terminologia (2)
APLIKACJE
MOBILNE
Kontekst (Context)
Centralny punkt aplikacji (obiekt Context), zapewniający dostęp do
głównych funkcjonalności, np. do pobierania zasobów, preferencji,
żądania usług systemowych, zarządzanie prywatnymi plikami i
bazami danych, uruchamiania aktywności itp.
Context context = getApplicationContext();
String jakisString = context.getResources().getString(R.string.jakis_string);
Uwaga! Klasa Activity dziedziczy po klasie Context, więc czasem
można jej używać, zamiast jawnie pobierać obiekt Context. Może to
jednak powodować wycieki pamięci!
String jakisString = getString(R.string.jakis_string);
Generalnie lepiej pobierać „duże” zasoby poprzez kontekst aplikacji
(przykład u góry), niewielkie zasoby mogą być pobierane poprzez
kontekst aktywności (przykład u dołu).
Stos aktywności
Aktywności są umieszczane na stosie – tzn. np. gdy aktywność uruchamia
inną aktywność, to jest odkładana na stos, a na szczycie stosu pojawia się
nowo uruchomiona aktywność.
APLIKACJE
MOBILNE
Cykl życia aktywności
APLIKACJE
MOBILNE
onCreate(Bundle savedInstanceState) –
wywoływana przy pierwszym
uruchomieniu aktywności. Jej parametr
zapewnia odtworzenie stanu aktywności,
na wypadek gdyby system skasował ją z
pamięci.
Umieszczamy w niej wszelkie statyczne
elementy aplikacji, np. ładujemy widok,
ustawiamy Listenery itp.
onResume() – wywoływana, gdy
aktywność ponownie stanie się procesem
na pierwszym planie, mimo że sam ekran
aktywności nie musi jeszcze być
wyświetlony. Można w niej np. pobrać i
rozpocząć odtwarzanie muzyki czy
animacji.
Cykl życia aktywności
APLIKACJE
MOBILNE
onPause() – wywoływana w momencie
gdy aktywność jest spychana na dalszy
plan. W metodzie zatrzymujemy
odtwarzanie multimediów, zwalniamy
niepotrzebne zasoby, zapisujemy dane
(niepotrzebny jest przycisk „Zapisz”).
onDestroy() – wywoływana w momencie
usuwania aktywności, czyli gdy aktywność
została planowo zakończona (finish()),
bądź skasowana przez system. Te
przypadki można odróżnić za pomocą
metody isFinishing(), która zwróci false
w tym drugim przypadku.
W metodzie niszczymy to, co się da ;), tzn.
usuwamy statyczne dane.
UWAGA! Metody onDestroy() i onStop()
mogą się nigdy nie wykonać, gdy aplikacja
zostanie skasowana zaraz po wywołaniu
onPause().
Model – Widok – Kontroler
APLIKACJE
MOBILNE
Model: dane
Widok: ekrany
Kontroler: sterowanie
W aplikacjach androidowych nie ma tak wyraźnego rozdzielenia między
poszczególne warstwy wzorca MVC jak np. w iOS.
Widokiem może być część aktywności ładująca układ ekranu, ale sama jest
też kontrolerem. Modelem mogą być wykorzystywane struktury danych, bądź
np. baza danych.
Najważniejsza terminologia (3)
APLIKACJE
MOBILNE
Intencja (Intent)
Asynchroniczne żądanie (realizowane przy pomocy komunikatów)
wykonania jakiegoś zadania, np. uruchomienia kolejnej aktywności
należącej do aplikacji, uruchomienia przeglądarki WWW/PDF itp.
Można je sobie wyobrażać jako komunikat o intencji (chęci)
wykonania określonego zadania.
Inaczej: służą do kojarzenia żądań wykonania konkretnego zadania
z odpowiednimi aktywnościami lub usługami (co może wymagać ich
uruchomienia) oraz do rozsyłania zdarzeń po systemie.
Przykład: uruchomienie innej aktywności:
Intent intent = new Intent(context, JakasAktywnosc.class); startActivity(intent);
(wysyłamy intencję uruchomienia nowej aktywności, zakładamy
wcześniejsze pobranie obiektu Context). Można też napisać:
startActivity(new Intent(getApplicationContext(), JakasAktywnosc.class));
Intencje – przykłady
Uruchomienie marketu z daną aplikacją:
Uri marketUri =
Uri.parse(„http://market.android.com/details?id=com.adobe.flashplayer”);
// Można też tak (bezposrednio do marketu):
// Uri marketUri = Uri.parse("market://details?id=com.adobe.flashplayer");
// ... ale np. emulator nie rozpoznaje protokulu "market„
Intent marketIntent = new Intent(Intent.ACTION_VIEW, marketUri);
Uruchomienie dialera:
Uri number = Uri.parse(tel:123456789);
Intent intent = new Intent(Intent.ACTION_DIAL, number);
startActivity(intent);
APLIKACJE
MOBILNE
Widoki i układy (1)
APLIKACJE
MOBILNE
Układy (Layouts) i Widoki (Views) – tworzą układy
zawartości ekranu
Statyczne układy i widoki umieszczamy w katalogu
/res/layout projektu
Dla różnych rozmiarów ekranu:
xlarge – co najmniej 960dp x 720dp
large – co najmniej 640dp x 480dp
normal – co najmniej 470dp x 320dp (tzw. baseline)
small – co najmniej 426dp x 320dp
tworzymy osobne układy, umieszczane np, w katalogu
/res/layout-xlarge
UWAGA! – patrz kolejny slajd
Widoki i układy (2)
APLIKACJE
MOBILNE
Od wersji 14 (Android 3.2 i nowsze), zalecane są nowe
kwalifikatory:
sw<N>dp – minimalna wymagana szerokość ekranu (smallestWidth), np.
sw720dp (niezależnie od orientacji ekranu!)
czyli na przykład:
res/layout/main_activity.xml
res/layout-sw600dp/main_activity.xml
res/layout-sw720dp/main_activity.xml
# dla smartfonów
# dla tabletów 7’’
# dla tabletów 10’’
Pozostałe kwalifikatory:
w<N>dp – dostępna szerokość ekranu, np. w720dp, w1024dp
h<N>dp – dostępna wysokość ekranu, np. h720dp, h1024dp
Widoki i układy (3)
Dopuszczalne rozmiary ekranów należy zapisać w pliku
AndroidManifest.xml, np.
<manifest ... >
<supports-screens android:requiresSmallestWidthDp="600" />
...
</manifest>
albo (w starszych wersjach)
<supports-screens
android:smallScreens="false"
android:normalScreens= "false"
android:largeScreens="false"
android:xlargeScreens="true"
/>
APLIKACJE
MOBILNE
AndroidManifest
APLIKACJE
MOBILNE
Specjalny plik konfiguracyjny, określający nazwę aplikacji,
jej ikonę, numer wersji, akceptowane wersje SDK,
dopuszczalne konfiguracje sprzętowe, uprawnienia
aplikacji, zestawienie aktywności i ich właściwości, filtry
intencji itp.
Umieszczany w katalogu głównym projektu
AndroidManifest – przykład
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="pl.gda.pg.mif.edoswiadczenia"
android:versionCode="1"
android:versionName="1.0">
<uses-sdk android:minSdkVersion="11" android:targetSdkVersion="13" />
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<supports-screens
android:smallScreens="false"
android:normalScreens= "false"
android:largeScreens="false"
android:xlargeScreens="true" />
<application
android:icon="@drawable/ic_launcher"
android:label="@string/app_name">
<activity
android:name=".StronaTytulowa"
android:label="@string/app_name"
android:screenOrientation="landscape"
android:configChanges="locale">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
APLIKACJE
MOBILNE
AndroidManifest – przykład (c.d.)
<activity android:name=".Info"
android:screenOrientation="landscape">
</activity>
<activity android:name=".ListaED"
android:screenOrientation="landscape">
</activity>
<activity android:name=".SzczegolyED"
android:screenOrientation="landscape">
</activity>
<activity android:name=".UruchomED"
android:theme="@android:style/Theme.NoTitleBar.Fullscreen"
android:hardwareAccelerated="true"
android:screenOrientation="landscape">
</activity>
</application>
</manifest>
APLIKACJE
MOBILNE
Przykład układu ekranu
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<TextView
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text=„jakiś tekst"
android:textSize="12pt" />
<Button
android:id="@+id/button1"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="Zakończ"/>
</LinearLayout>
APLIKACJE
MOBILNE