Wykład 2 - cykl życia, komponenty

Programowanie aplikacji
dla technologii mobilnych
mgr inż. Anton Smoliński
Agenda
•
Cykl życia aplikacji
•
Struktura plików
•
Plik AndroidManifest.xml
•
Elementy aplikacji
• Activity
• Layout
• Intent
• BroadcastRecivers
• Service
• Content Providers
2
Cykl życia aplikacji
3
Cykl życia aplikacji
4
Cykl życia aplikacji
Design
Cel aplikacji
Develop
Projekt aplikacji
Programowanie ☺
Wygląd aplikacji
Testowanie
Distribute
Sprzedaż
Promocja
Model biznesowy
5
Cykl życia aplikacji
•
Design
•
•
Od Androida 5.0 wbudowano szablon/skórkę/motyw Material Design
Udostępnia ona wystandaryzowany (i estetyczny) wygląd poszczególnych komponentów
interfejsu użytkownika
•
Korzystanie z Material Design ułatwia stosowanie się do pryncypiów projektowania
interfejsów graficznych (Android design principles):
• Enchant Me – Oczaruj mnie
• Simplify My Life – Uprość mi życie
• Make Me Amazing – Zrób to niesamowicie
6
Cykl życia aplikacji
•
3 stany działania aplikacji
•
Uruchomiona
• Ekran aplikacji jest widoczny
• Użytkownik pracuje z daną aplikacją
•
Zapauzowana
• Inna aplikacja wyskakuje na ekran ALE nasza aplikacja dalej jest widoczna
(np. gdy wyskoczy komunikat, czy inne okno nie na cały ekran)
• Aplikacja jest funkcjonalna, nie działa tylko sprzęg z użytkownikiem
• Może być zakończona przez system w ekstremalnych sytuacjach
•
Zatrzymana
• Aplikacja zostaje zatrzymana, użytkownik jej nie widzi
• Aplikacja chodzi w tle (dalej zajmuje pamięć)
7
Cykl życia aplikacji
8
Cykl życia aplikacji
•
Określa się 3 cykle:
•
entire lifetime
•
visible lifetime
•
foreground lifetime
9
Cykl życia aplikacji - ZADANIE
•
Współdziałanie 2 aplikacji:
Aplikacja A
•
Które funkcje/kiedy zostają wywołane
•
Przebieg symulacji:
Aplikacja B
• onCreate()
• onStart()
• onResume()
1. Uruchamiamy aplikację A
Aplikacja A
2. Następnie uruchamiamy aplikację B
3. Wyłączamy aplikację B
Aplikacja B
• onCreate()
• onStart()
• onResume()
• onPause()
• onStop()
• onPause()
• onStop()
• onDestroy()
4. Przywracamy aplikację A
Aplikacja A
• onRestart()
• onStart()
• onResume()
10
Struktura plików
11
Struktura plików
•
Utworzenie projektu w Android Studio
12
Struktura plików
•
Folder aplikacji „app”
• build – pliki wynikowe .apk + dane debug + testy
• libs – zewnętrzne biblioteki
• src – źródła aplikacji
13
Struktura plików
•
Folder aplikacji „src/main”
• java – kod aplikacji i poszczególnych jej komponentów (klas)
• res – pliki xml + obrazki z używanymi zasobami aplikacji
• AndroidManifest.xml – Plik opisu aplikacji
14
Struktura plików
•
•
•
•
Starsza wersja AndroidStudio czy Eclipse+SDK miała nieco
inną strukturę plików.
src zawierało pliki java (obecnie src to folder java+res+manifest)
folder gen z wartościami generowanymi (obecnie ukryte w build)
bin zawierający skompilowaną aplikację i jej zasoby (obecnie
w build)
•
W nowej wersji domyślnie dodano projekty testów jednostkowych
•
Plik R.java nie jest też widoczny z poziomu domyślnego widoku
15
Struktura plików
•
•
Plik R.java
plik zawierający automatycznie generowaną klasę z identyfikatorami zasobów, do
których odwołuje się programista w kodzie aplikacji.
•
Automatycznie generowana klasa R zawiera identyfikatory zasobów aplikacji z
podkatalogów katalogu /res. Dla każdego rodzaju zasobu zostaje utworzona publiczna
statyczna klasa wewnętrzna z modyfikatorem final. Identyfikatory zasobów (pola danych
klas wewnętrznych) mają postać stałych typu int, będących identyfikatorami zasobów
•
Dzięki temu aby odwołać się do zasobu należy:
• Wynaleźć zasób w klasie R
• Utworzyć nową klasę typu danego zasobu
• Przypisać klasę zasobu do klasy na której można wprowadzać zmiany
16
Struktura plików
•
Plik R.java
•
Dzięki niemu IDE co chwile
coś kompiluje
•
Brak odświeżania pliku
R.java sprawia, że
komponenty czy zasoby
nie są widoczne i nie
można na nich operować
17
Struktura plików - ZADANIE
• Gdzie (w jakim folderze) szukać:
• kodu aplikacji?
• widoków (layouts)?
• obrazków używanych w aplikacji?
• klas pomocniczych?
18
Plik AndroidManifest.xml
19
AndroidManifest.xml
•
Wymagany plik zawierający niezbędne dla systemu Android informacje o wytworzonej
aplikacji.
•
Zawiera nazwę pakietu Java będącą unikalnym identyfikatorem danej aplikacji w
systemie.
•
Zawiera opis komponentów aplikacji takich jak Aktywności, Usługi, Odbiorniki
komunikatów i Dostawców treści oraz ich wymagania.
•
Zawiera ustawienia zabezpieczeń (do których elementów aplikacja ma mieć dostęp).
•
Zawiera spis zewnętrznych bibliotek używanych w aplikacji.
•
Określa minimalny poziom Android API wymagany przez aplikację.
20
AndroidManifest.xml
•
•
•
•
•
•
Elementy <manifest> i <application> są wymagane,
pozostałe – opcjonalne.
Właściwości elementów są określane jako atrybuty,
a nie jako nowe znaczniki z zawartością
Kolejność elementów tego samego poziomu nie ma
znaczenia (wyjątek: activity-alias)
Niemal wszystkie atrybuty mają prefix „android:”,
pomijany w dokumentacji
Wszystkie atrybuty „name” (android:name) muszą
zawierać pełną ścieżkę pakietu
Jako atrybuty można wykorzystywać pliki zasobów:
@[package:]type:name
lub pliki motywów:
?[package:]type:name
21
AndroidManifest.xml
•
•
Intent filter pozwala na tworzenie domyślnych Activity
Określa też zdarzenie, na które będą reagować komponenty systemu
•
Android zapewnia kompatybilność kodu w 3 obszarach: Urządzenia, Platformy, Ekranu
22
AndroidManifest.xml
•
•
Należy wykazać urządzenia/API które są używane w aplikacji
Można określić atrybut „required”, który uniemożliwi instalację aplikacji z GooglePlay
•
Podobnie należy określić permission aplikacji – system blokuje dostęp do niektórych
funkcji systemowych (sandbox dla każdej aplikacji)
Istnieje podział na Normal i Dangerous persmission.
•
•
http://developer.android.com/reference/android/Manifest.permission.html - lista
możliwych permission aplikacji.
23
AndroidManifest.xml - ZADANIE
Czy aplikacja może działać bez pliku Manifest?
24
Elementy aplikacji
25
Elementy aplikacji
•
Activity (Aktywność):
•
•
•
•
•
•
•
Aktywność reprezentuje pojedyncze okno aplikacji służące do komunikacji z
użytkownikiem.
Każdy ekran w aplikacji to osobna Aktywność.
Aktywność nie jest tożsama z widokiem/ułożeniem elementów interfejsu graficznego
– za to odpowiadają Layouty (widoki).
Aktywność odpowiada za reagowanie na zdarzenia i obsługę elementów
interfejsu.
W danym momencie może być uruchomiona tylko jedna Aktywność
Aktywności są grupowane i przechowywane na stosie
W skrócie – Główny element aplikacji – to co uruchamiamy i odpowiada za
interakcję.
26
Elementy aplikacji
•
Activity
27
Elementy aplikacji
•
Layout (widoki):
•
Podstawowa wiedza z inżynierii oprogramowania.
•
Klasy odpowiadające za graficzny interfejs użytkownika.
•
Pojedyncza aktywność może posiadać wiele Layoutów, np. dla różnych wielkości
ekranów czy ich orientacji.
•
Layout opisuje za pomocą języka XML wyświetlane elementy oraz ich parametry
•
Prace nad Layoutem można wykonywać za pomocą Designera – programowania
wizualnego
•
W skrócie – Layout to to co widać na ekranie: elementy UI oraz ich położenie
28
Elementy aplikacji
•
Layout
•
Podstawowa wiedza z inżynierii oprogramowania.
29
Elementy aplikacji
•
Intent (Intencja):
•
Podstawowa wiedza z inżynierii oprogramowania.
•
•
•
•
•
Abstrakcyjny mechanizm odpowiedzialny przede wszystkim za obsługę rozkazów
wydawanych przez użytkownika (np. uruchamianie aktywności, uruchamianie usługi
(z ang. service) czy nadanie komunikatu (broadcast))
Za pomocą intencji możemy wprowadzić komunikację pomiędzy aplikacjami (lub
mniejszymi komponentami, jak Usługi, Aktywności itp.).
Jest wykorzystywana przez system lub aplikację do powiadamiania różnych
komponentów aplikacji o pojawiających się zdarzeniach. Dla aktywności lub
usługi intencja określa akcję do wykonania i dane do przetworzenia. Dla odbiorników
komunikatów (broadcast receivers) definiuje rozgłaszany komunikat.
Najważniejszym zadaniem tego komponentu jest uruchamianie odpowiednich
aplikacji/Aktywności.
W skrócie – komunikacja wewnątrz aplikacji i uruchamianie aktywności
30
Elementy aplikacji
•
Intent (Intencja):
•
Podstawowa wiedza z inżynierii oprogramowania.
31
Elementy aplikacji
•
Broadcast Receivers (Odbiorniki komunikatów):
•
Podstawowa wiedza z inżynierii oprogramowania.
•
Mechanizm komunikacji z systemem i innymi aplikacjami.
•
Możliwość odbioru powiadomień (np. SMS, Stan baterii, Zdjęcia, Połączenia
przychodzące)
•
Jest to mechanizm bez interfejsu graficznego.
•
Korzystanie wymaga jego zarejestrowania (AndroidManifest lub kod)
•
W skrócie – reagowanie na zdarzenia systemowe
32
Elementy aplikacji
•
Broadcast Receivers
(Odbiorniki komunikatów):
•
Podstawowa wiedza z inżynierii oprogramowania.
33
Elementy aplikacji
•
Service (Usługa):
•
Podstawowa wiedza z inżynierii oprogramowania.
•
Element aplikacji, który obsługuje długo działające procesy w aplikacji (np.
pobieranie/wysyłanie plików przez sieć).
•
Może istnieć samodzielnie lub być powiązany (bound).
•
Nie zawiera elementów interfejsu graficznego.
•
W skrócie – część programu działająca w tle – niezależnie do tego co widzi/robi
użytkownik.
34
Elementy aplikacji
•
Service (Usługa):
•
Podstawowa wiedza z inżynierii oprogramowania.
35
Elementy aplikacji
•
Content Providers (Dostawcy treści):
•
Podstawowa wiedza z inżynierii oprogramowania.
•
Abstrakcyjne źródła danych, zapewniające dostęp do składowanych danych (system
plików, baza SQLite, sieć) oraz odczyt i zapis danych.
•
Dzięki dostawcom treści możliwe jest współdzielenie danych pomiędzy aplikacjami.
(wbudowane w system bazy SQLite zawierają m.in. Kontakty, Historię połączeń,
Dane multimedialne, Ustawienia)
•
Jest to interfejs zarządzania danymi oparty o adresy URI (które wykorzystują
schemat content://)
•
W skrócie – Dane wykorzystywane w aplikacji
36
Elementy aplikacji
•
Content Providers
(Dostawcy treści):
•
Podstawowa wiedza z inżynierii oprogramowania.
37
Elementy aplikacji - Zadanie
Wymień 6 podstawowych „cegiełek”
aplikacji w androidzie?
38
Koniec!
mgr inż. Anton Smoliński
39