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 Projekt aplikacji Wygląd aplikacji Develop Programowanie 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 Współdziałanie 2 aplikacji: Które funkcje/kiedy zostają wywołane Aplikacja A oncreate() onstart() onresume() Przebieg symulacji: Aplikacja B oncreate() onstart() onresume() 1. Uruchamiamy aplikację A 2. Następnie uruchamiamy aplikację B Aplikacja A onpause() onstop() 3. Wyłączamy aplikację B Aplikacja B 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
Plik AndroidManifest.xml 18
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ę. 19
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 20
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 21
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. 22
Elementy aplikacji 23
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ę. 24
Elementy aplikacji Activity 25
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 26
Elementy aplikacji Layout Podstawowa wiedza z inżynierii oprogramowania. 27
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 28
Elementy aplikacji Intent (Intencja): Podstawowa wiedza z inżynierii oprogramowania. 29
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 30
Elementy aplikacji Broadcast Receivers (Odbiorniki komunikatów): Podstawowa wiedza z inżynierii oprogramowania. 31
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. 32
Elementy aplikacji Service (Usługa): Podstawowa wiedza z inżynierii oprogramowania. 33
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 34
Elementy aplikacji Content Providers (Dostawcy treści): Podstawowa wiedza z inżynierii oprogramowania. 35
Koniec! mgr inż. Anton Smoliński 36