git/Bachelor-Informatik
1
0
Fork 0
Code Issues Pull requests Projects 3 Releases Packages Wiki Activity Actions
Page: LernzettelMobileAndroid
Pages
Bachelorarbeit DataScienceSE Home IT-Architektur LernzettelArchitekturmanagment LernzettelMobileAndroid LernzettelProjektManagement MobileAndroid Projektmanagement Se6DSSEVorl5 Se6DSSEVorl_5 Se6PMVorl1 Se6PMVorl2 Se6PMVorl3 Se6PMVorl4 Se6PMVorl5 Semester_1 Semester_2 Semester_3 Semester_4 Semester_5 Semester_6 Semester_7 Testpage
4 LernzettelMobileAndroid
Patryk Hegenberg edited this page 2025-06-04 21:19:56 +02:00
Unescape Escape
Table of Contents
This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Lernzettel: Mobile Software Engineering – Android Plattform

Kapitel 01: Grundlagen der mobilen Software-Entwicklung

Lernziele des Kapitels:

  • Besonderheiten mobiler Endgeräte kennen[cite: 630].
  • Auswirkungen dieser Besonderheiten auf die Software-Entwicklung für mobile Anwendungen verstehen[cite: 631].
  • Kategorien mobiler Endgeräte unterscheiden können[cite: 632].
  • Verstehen, was die Android-Plattform ist[cite: 632].

1.1 Besonderheiten von mobilen Endgeräten

  • Marktentwicklung:
    • Verlagerung von stationären PCs zu mobilen Endgeräten[cite: 634].
    • Mobile Endgeräte dominieren die Internetnutzung[cite: 635].
    • Evolution von reinem Browserzugriff auf Desktop-Webseiten hin zu Geräten mit großen Touchscreens und Touch-Funktionalität[cite: 636].
  • Apps als Erfolgstreiber:
    • Zugriff auf gerätespezifische Funktionen (GPS, Kompass etc.)[cite: 655].
    • Offline-Funktionalität durch lokale Datenspeicherung[cite: 655].
    • Vorteile gegenüber mobilen Webseiten: Volle Funktionalität ohne Internet, höhere Usability[cite: 656, 657].
  • Herausforderungen und Einschränkungen:
    • Ressourcenbegrenzung: Geringere CPU-Leistung, kleinere Displays, begrenzter Akku, potenzieller Offline-Betrieb[cite: 658, 659].
    • Sicherheitsaspekte: Höheres Risiko von Geräteverlust/-diebstahl; sicherheitsrelevante Daten serverseitig speichern[cite: 660].
  • Zusatzfunktionen mobiler Geräte:
    • GPS: Positionsbestimmung für Location-Based Services (LBS)[cite: 661].
    • Kompass: Richtungsbestimmung[cite: 662].
    • Gyroskop: Erfassung von Rotations- und Neigungsdaten (wichtig für Spiele)[cite: 662].
    • NFC: Kontaktlose Datenübertragung (Bezahlen, Ticketing, Zugang)[cite: 663].
    • Weitere: Beschleunigungssensoren, Barometer[cite: 664].
  • Best Practices:
    • Ressourcenschonung: Stromverbrauch minimieren, auf außerplanmäßiges Beenden von Apps vorbereiten[cite: 668, 669].
    • Sicherheitsmaßnahmen: Lokale Speicherung sensibler Daten vermeiden, zusätzliche Sicherheitskonzepte wegen Verlustgefahr[cite: 670].
  • Einflussfaktoren auf mobile App-Entwicklung:
    • Leicht: Verbesserte Hardware, Leistungsveränderungen im OS, Aufbau digitale Tastatur[cite: 672].
    • Stark: App-Store-Regeln, UI/UX, neues OS, dynamische Navigation/Tastaturersatz (Touch, Multitouch)[cite: 672].

1.2 Besonderheiten der mobilen Software-Entwicklung

  • Entwicklungsprozess für stationäre Anwendungen:
    1. Anforderungsanalyse (Funktionen, Zielplattformen, nicht-funktionale Anforderungen)[cite: 675].
    2. Implementierung (Programmiersprachen, IDEs, Sourcecode)[cite: 676].
    3. Test (Testfälle, Testdaten, realistische Testumgebung)[cite: 677].
    4. Deployment (Installation, Konfiguration in Produktivumgebung; bei Servern einmalig)[cite: 678].
  • Unterschiede bei mobilen Anwendungen:
    • Zielplattform: Diverse Gerätearten (Smartphones, Tablets) mit variierender HW/SW-Konfiguration, Displaygrößen; Fragmentierung durch kontinuierliche OS-Weiterentwicklung[cite: 679, 680].
    • Programmiersprachen: Evtl. neue Frameworks/Tools trotz Java-Kenntnissen[cite: 681].
    • Test: Erhöhter Aufwand durch Gerätevielfalt, OS-Fragmentierung; Emulatoren für Entwicklertests[cite: 682, 683].
    • Deployment: Individuelle Installation auf Endgeräten; erschwert durch Konfigurationsvielfalt; Unterstützung durch App-Stores (z.B. Google Play)[cite: 684, 685, 686].
  • Zusätzliche Erkenntnisse:
    • Fragmentierung als Herausforderung: Festlegen unterstützter Geräte/Versionen[cite: 687, 688].
    • Neue Tools/Techniken: IDEs, Emulatoren, Deployment-Tools, App-Stores[cite: 688, 689].
flowchart TD
    A[Stationäre Entwicklung] --> B[Anforderungsanalyse]
    B --> C[Implementierung]
    C --> D[Test]
    D --> E[Deployment]
    F[Mobile Entwicklung] --> G(Anforderungsanalyse - Fragmentierung, HW/SW)
    G --> H(Implementierung - neue Tools/Frameworks)
    H --> I(Test - Gerätevielfalt, Emulatoren)
    I --> J(Deployment - App-Store, Konfigurationsvielfalt)

1.3 Einteilung von mobilen Endgeräten

graph TD
    A[Mobile Endgeräte]
    A --> B[Hardware]
    A --> C[Software]
    B --> D[Smartphones]
    B --> E[Tablets]
    B --> F[Embedded-Systeme]
    C --> G[Android]
    C --> H[iOS]
    G --> I[Offenes System, viele Hersteller]
    H --> J[Geschlossenes System, Apple-exklusiv]
  • Hardwareseitig:
    • Smartphones[cite: 691, 696].
    • Tablets (füllen Lücke zwischen Smartphones und Laptops)[cite: 691, 692, 696, 697].
    • Embedded-Systeme[cite: 691, 696].
  • Softwareseitig (Betriebssysteme):
    • Primär Android und iOS, nachdem Microsoft und Blackberry Entwicklung eingestellt haben[cite: 693, 694, 698, 699].
    • iOS:
      • Herstellerbindung: Apple-exklusiv (iPhone, iPad)[cite: 701].
      • Marktverbreitung: Eingeschränkte Hardwarebasis, hoher Marktanteil[cite: 702].
      • Testaufwand: Reduziert (wenige Endgeräte)[cite: 702].
      • Systemarchitektur: Geschlossenes System, Kontrolle durch Apple[cite: 703].
      • Entwicklung: Swift, Xcode (optimiert für macOS)[cite: 703, 704].
    • Android:
      • Offenes System: Open Source, Entwicklung durch Open Handset Alliance (OHA, ~90 Firmen)[cite: 705, 710].
      • Marktverbreitung: Breite Hardwarebasis, dominant im Embedded-Markt[cite: 706, 711].
      • Entwicklungssprachen: Java (ursprünglich, verbreitet), Kotlin (modern, von Google bevorzugt)[cite: 707, 712].
      • Basis: Linux (Betriebssystemkern), XML (UI-Gestaltung, Layouts)[cite: 708, 709, 713, 714].
  • Zielplattformen und Herausforderungen:
    • HW/SW-Abhängigkeit: Funktionierende Anwendungen erfordern Zusammenspiel[cite: 715, 716].
    • Separate Entwicklung: Unterschiedliche Systemarchitekturen erfordern separate Apps für Android/iOS[cite: 716, 717].
  • Lösungsansätze für plattformübergreifende Entwicklung:
    • Cross-Plattform-Entwicklungsumgebungen (z.B. Flutter, React Native): Ein Sourcecode für mehrere Plattformen[cite: 718].
    • Mobile Webseiten: Plattformunabhängig, lauffähig in Browsern[cite: 719].

1.4 Die Android-Plattform

  • Geschichte:
    • 2003: Gründung Android Inc. (ursprünglich für Digitalkameras)[cite: 723].
    • 2005: Übernahme durch Google, Weiterentwicklung als offenes mobiles OS[cite: 724].
    • 2007: Gründung der Open Handset Alliance (OHA) zur Förderung von Android[cite: 725, 727].
    • Seit 2008: Veröffentlichung Android 1.0 und 15 Nachfolgeversionen[cite: 726].
  • Definition:
    • Entwickelt von Google, erste Version 2008 unter OHA[cite: 728].
    • Betriebssystem: Angepasste Linux-Distribution, ressourcenoptimiert[cite: 729].
    • Plattform: Umfasst OS und Tools für Erstellung, Wartung, Deployment von Apps[cite: 730].
  • Entwicklungsansätze:
    • Native Entwicklung: Spezifisch für ein OS (z.B. Android oder iOS)[cite: 733].
      • Vorteile: Höchste Performance, optimale UX, voller Hardware-/Software-Zugriff[cite: 740, 741, 742].
      • Nachteile: Getrennte Codebasen, längere Entwicklungszeit für Multi-Plattform[cite: 742, 743].
      • Ideal für: Maximale Effizienz und Performance pro Plattform, höhere Entwicklungskosten[cite: 748].
    • Cross-Plattform Entwicklung: Ein Sourcecode für mehrere Plattformen (z.B. mit Flutter)[cite: 732].
      • Vorteile: Schnellere Entwicklung, geringere Kosten, Zugriff auf viele native Funktionen via Plugins[cite: 744].
      • Nachteile: Performance kann geringer sein, Abhängigkeit von Frameworks[cite: 745, 746].
      • Ideal für: Knappe Budgets, kurze Zyklen, leichte Kompromisse bei Performance/Integration[cite: 747].
    • Bundler für Webapps: Webanwendungen in nativen App-Containern verpackt (z.B. mit Ionic)[cite: 734].
    flowchart TD
A[Entwicklungsansatz] -->|Native| B[Getrennte Codebasen]
A -->|Cross-Plattform| C[Ein Code für mehrere Plattformen]
B --> D[Vorteile: Maximale Performance, Optimale UX]
B --> E[Nachteile: Höhere Kosten, Längere Entwicklungszeit]
C --> F[Vorteile: Schnellere Entwicklung, Geringere Kosten]
C --> G[Nachteile: Kompromisse bei Performance, Abhängigkeit von Frameworks]
  • Technische Aspekte:
    • Programmiersprachen: Hauptsächlich Java, zunehmend Kotlin (prägnantere Syntax, Sicherheitsfunktionen)[cite: 749].
    • Aktuelle Trends: Jetpack Compose für deklarative UIs[cite: 750].
    • Virtuelle Maschine (VM): Apps laufen in VM; Java-Bytecode bei Installation in maschinenabh. Binärcode umgewandelt (AOT)[cite: 751, 752].

Kapitel 02: Android-Systemarchitektur

Lernziele des Kapitels:

  • Bestandteile eines Android-Systems kennen[cite: 767].
  • Für die Software-Entwicklung bedeutsame Komponenten identifizieren[cite: 768].
  • Relevante Netzwerk- und Kommunikationstechnologien für Android verstehen[cite: 769].

2.1 Das Android-System (Schichtenmodell)

  • Application Framework (Anwendungsrahmen):
    • Stellt Entwicklern APIs zur Verfügung[cite: 773].
    • Tools zur Verwaltung von UI, Ressourcen, App-Komponenten (Activities, Services, Content Provider)[cite: 774].
    • Einfacher Zugriff auf Android-Dienste (Standort, Benachrichtigungen, Sensoren)[cite: 775].
  • Binder IPC Proxies:
    • Ermöglicht Inter-Process Communication (IPC)[cite: 776].
    • Vermittelt sicher Daten/Befehle zwischen Anwendungen und Systemdiensten[cite: 777, 778].
  • Android System Services:
    • Media Server: Verarbeitet medienbezogene Dienste (Audio, Kamera, Video)[cite: 779]. Enthält AudioFlinger, Camera Service, MediaPlayer Service[cite: 780, 782, 783, 784, 785, 786, 787].
    • System Server: Zuständig für systembezogene Aufgaben[cite: 780]. Enthält Search Service, Activity Manager, Window Manager, Package Manager, Battery Manager[cite: 781, 789, 790, 791, 792, 793, 794].
  • Hardware Abstraction Layer (HAL):
    • Vermittelt zwischen Hardware und Android-System[cite: 811].
    • Komponenten: Camera HAL, Audio HAL, Graphics HAL, etc.[cite: 812, 813].
  • Linux Kernel:
    • Technische Basis, angepasst für mobile Geräte[cite: 814].
    • Komponenten: Camera Driver, Audio Driver (ALSA, OSS), Display Drivers, etc.[cite: 815, 816].
  • Android Runtime (ART):
    • Bis Android 4.4: Just-In-Time (JIT) Compiler (erzeugt Maschinencode bei jedem App-Start)[cite: 817].
    • Ab Android 5.0: Ahead-Of-Time (AOT) Compiler (erzeugt Maschinencode einmalig bei Installation)[cite: 818].
      • Nachteil AOT: Erhöhter Speicherbedarf, längere Installation[cite: 819].
      • Vorteil AOT: Schnellerer App-Start, spürbarer Performance-Gewinn[cite: 820, 821].
  • Sandbox-Prinzip:
    • Technische Abschottung eines Prozesses gegen unbefugte Zugriffe[cite: 808].
    • Jede App hat eigenen Speicherbereich, schützt vor Datenmissbrauch und Zugriff auf fremde Speicher[cite: 808, 809, 810].
graph TD
    A[Application Framework] --> B[Binder IPC Proxies]
    B --> C[Android System Services]
    C --> D[Hardware Abstraction Layer - HAL]
    D --> E[Linux Kernel]
    C --> F[Android Runtime - ART]
    A -. nutzt .-> C
    C -. nutzt .-> D
    D -. nutzt .-> E
    F -. läuft auf .-> E

2.2 Sicherheit

  • Berechtigungen (Permissions):
    • Apps fordern vor Installation Berechtigungen an[cite: 826].
    • Ab Android 6.0 ("Marshmallow"): Dynamische Genehmigung/Verweigerung zur Laufzeit[cite: 827].
    • Endnutzer muss explizit genehmigen; Ablehnung kann Installation verhindern[cite: 828].
    • Schützt Privatsphäre und ermöglicht Kontrolle über App-Zugriffe[cite: 829].
    • Beispiele: Internetverbindung, Kontaktezugriff, GPS-Standort, SMS-Versand/-Empfang[cite: 830].
    • Permissions werden in AndroidManifest.xml deklariert (z.B. android.permission.CAMERA)[cite: 797].
    • Normale Berechtigungen: Automatisch erteilt (kein Risiko)[cite: 802].
    • Gefährliche Berechtigungen: Explizite Nutzergenehmigung erforderlich (sensible Infos)[cite: 802].
  • Sandbox-Prinzip (Sicherheitskontext):
    • Jede App läuft in eigenem OS-Prozess[cite: 831].
    • Dedizierter Speicherbereich (Hauptspeicher, Dateisystem), kein Zugriff durch andere Apps[cite: 832].
    • Vorteile: Schutz der App-Daten, reduziert Risiken von Datenmissbrauch/Sicherheitslücken[cite: 833].
    • Ergänzt durch Berechtigungen: Nutzer entscheidet über Daten-/Dienstzugriff[cite: 834].
  • Client-Server-Architektur:
    • Apps basieren oft darauf[cite: 835].
    • Funktionen/Daten können zwischen Gerät (Client) und Server verteilt sein (z.B. Cloud-Sync, Internet-APIs)[cite: 836, 837].

2.3 Kommunikation mit Netzwerken

  • Verteilte Systeme: Funktionen/Daten auf mehrere Rechner verteilt; Kommunikation über Nachrichten in Netzwerken[cite: 839, 840].
  • Client-Server-Architektur:
    • Server: Zentrale Dienste (Datenbanken, Berechtigungen), sicherer Standort[cite: 841].
    • Client: Endgerät als Nutzerschnittstelle[cite: 842].
  • URI, URL, URN:
    • URI (Uniform Resource Identifier): Identifikator für Ressourcen[cite: 843]. Schema: <scheme>:[<authority>]<path>[“?”<query>][“#”<fragment][cite: 846]. Bestandteile: Scheme, Authority, Path, Query, Fragment[cite: 844, 845].
    • URL (Uniform Resource Locator): URI mit Zugriffsmethode (z.B. http://)[cite: 846].
    • URN (Uniform Resource Name): URI ohne Lokalisierungsangabe (z.B. urn:isbn:...)[cite: 847].
  • HTTP und REST:
    • HTTP (Hypertext Transfer Protocol): Protokoll zur Datenübertragung (z.B. Webseiten, App-Kommunikation)[cite: 848, 849].
    • REST (Representational State Transfer): Prinzip für verteilte Systeme; Ressourcen eindeutig durch URIs adressiert; Fokus auf einfache, ressourcenorientierte Schnittstellen[cite: 849, 850].
    • SOAP: Protokoll zum Datenaustausch (XML, HTTP)[cite: 851].
  • Mobiler Netzzugang:
    • GSM (2G): 9,6 kBit/s; LTE (4G): bis 100 Mbit/s; 5G: bis 10 Gbit/s, geringe Latenz[cite: 852, 853].
    • WLAN: Schnellere Verbindung, geringere Kosten, aber keine konstante Verfügbarkeit[cite: 854].
    • Uplink (Endgerät → Server) vs. Downlink (Server → Endgerät)[cite: 855].
    • Herausforderungen: Netzwerkabbrüche, Minimierung von Netzwerkanfragen[cite: 856, 857].

Kapitel 03: Entwicklungsumgebung

Lernziele des Kapitels:

  • Installation und Einsatz von Android Studio[cite: 859].
  • Test einer Android-Anwendung auf einem Emulator[cite: 860].
  • Laden einer Android-Applikation auf ein reales Endgerät[cite: 861].

3.1 Android Studio

  • Offizielle, von Google empfohlene IDE für Android-Entwicklung, zukunftssicher[cite: 862, 863].
  • Bezug über offizielle Android-Developer-Webseiten; aktuelle Version installieren[cite: 864].
  • Basiert auf IntelliJ IDEA[cite: 886, 891].
  • Hauptfunktionen:
    • Intelligentes Code-Editing (Java, Kotlin, C++)[cite: 888].
    • Visueller Layout-Editor[cite: 889, 893].
    • Emulator für Tests ohne physische Geräte[cite: 889, 893].
    • Integriertes Version Control System (Git, GitHub)[cite: 890].
    • Integriertes Gradle-Build-System[cite: 893].
  • Android SDK (Software Development Kit):
    • Sammlung von Tools, Bibliotheken, APIs für Android-Entwicklung[cite: 894].
    • Ermöglicht Zugriff auf Android-spezifische HW/SW-Funktionen[cite: 895, 896].
    • Integriert in Android Studio über SDK Manager; unterstützt verschiedene Android-Versionen[cite: 897].
  • Kompatibilität von Android-Versionen:
    • Jede Version hat spezifisches API-Level (verfügbare Funktionen/Klassen)[cite: 868, 869].
    • Google stellt Sicherheitsupdates nur für neuere Android-Versionen bereit (ab 11 genannt)[cite: 870, 871].
    • Herstellerabhängigkeit bei Updates und Funktionsverfügbarkeit[cite: 872, 873].

3.2 Erste App und Emulator-Test ("Hallo Welt" mit Jetpack Compose)

  • Wichtige Imports und Konzepte:
    • android.os.Bundle: Datenpaket für Zustandsdaten (pausiert, Neustart, Wiederherstellung)[cite: 902].
    • androidx.activity.ComponentActivity: Basis-Klasse für Activity, optimiert für Jetpack[cite: 903].
    • androidx.activity.compose.setContent: Stellt Compose-Inhalte in einer Activity dar (ersetzt XML-Layouts für UI-Definition)[cite: 903, 904].
    • androidx.activity.enableEdgeToEdge: Aktiviert Edge-to-Edge-Darstellung (Inhalte unter Status-/Navigationsleiste)[cite: 905].
    • androidx.compose.foundation.layout.fillMaxSize: Modifier, füllt gesamten verfügbaren Platz[cite: 907].
    • androidx.compose.foundation.layout.padding: Modifier für Innenabstand[cite: 908].
    • androidx.compose.material3.Scaffold: Layout-Grundgerüst für typische App-Oberflächen (Top App Bar, FAB etc.)[cite: 909, 910].
    • androidx.compose.material3.Text: Composable zur Textdarstellung[cite: 910, 911].
    • androidx.compose.runtime.Composable: Annotation für UI-Funktionen in Compose[cite: 911].
    • androidx.compose.ui.Modifier: Verändert Layout und Aussehen von Composables (Größe, Abstände)[cite: 913].
    • androidx.compose.ui.tooling.preview.Preview: Annotation für Vorschau von Composables in Android Studio ohne Emulator[cite: 913, 914].
    • @Preview Funktionen dürfen keine Parameter erwarten[cite: 918].
    • Preview und App können unterschiedlich sein (z.B. Greeting("World") in App, Greeting("Android") in Preview) für Designflexibilität[cite: 920, 921, 922, 923].
  • Projektstruktur:
    • AndroidManifest.xml: Definiert App-Komponenten, Berechtigungen, Start-Activity etc.[cite: 925, 926, 927, 928, 929].
    • java (oder kotlin) Verzeichnis: Enthält Logik der Anwendung (Activities, Klassen, etc.)[cite: 930, 931].
    • res Verzeichnis: Ressourcen
      • drawable/: Bilder, Icons[cite: 932, 933].
      • layout/: XML-Layoutdateien (traditionell, weniger bei reinem Compose)[cite: 933].
      • values/: Strings, Farben, Stile, Dimensionen[cite: 933].
      • mipmap/: App-Symbole für verschiedene Bildschirmdichten[cite: 934].
      • raw/: Rohdateien (Audio, Video)[cite: 934].
    • build.gradle Dateien: Build-Konfigurationen, Abhängigkeiten (projekt- und modulebene)[cite: 935, 936, 937, 938, 939].
  • Anwendungsdeployment:
    • Starten auf angeschlossenem mobilen Endgerät[cite: 949].
    • Starten auf dem Emulator[cite: 949].

Kapitel 04: Kernkomponenten einer Android-App

Lernziele des Kapitels:

  • Grundlegende Bausteine einer Android-App verstehen[cite: 951, 952].
  • Die Rolle und Funktion jeder Kernkomponente erläutern können[cite: 952].

4.1 Überblick

  • Android-Apps bestehen aus lose gekoppelten Komponenten mit spezifischen Aufgaben[cite: 955, 958].
  • Komponenten kommunizieren miteinander (z.B. über Intents)[cite: 956, 959].
  • Entwickler planen Apps komponentenbasiert[cite: 957, 959].
  • Komponenten können auch von Drittanbietern integriert werden[cite: 961].

4.2 Kernkomponententypen

  • Activities (Präsentationsschicht):
    • Repräsentieren einzelne UI-Bildschirmseiten[cite: 962, 977].
    • Verantwortlich für Darstellung und Nutzerinteraktion[cite: 963, 979].
    • Wechsel zwischen Activities erfolgt über Intents[cite: 964].
    • Jede Activity durchläuft einen Lebenszyklus (Lifecycle):
      • Notwendig wegen begrenzter Ressourcen auf mobilen Geräten[cite: 984].
      • Android-System überwacht Ressourcen und kann Prozesse beenden[cite: 985].
      • Zustandswechsel (z.B. onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy()) können nicht verhindert, aber via Callback-Methoden behandelt werden[cite: 986].
      • Phasen: Interaktive Phase (onResume() bis onPause()), Sichtbare Phase (onStart() bis onStop()), Inaktive Phase (nicht sichtbar)[cite: 989, 990, 991].
  • Intents (Nachrichtenübermittlung):
    • Ermöglichen Kommunikation zwischen App-Komponenten oder verschiedenen Apps[cite: 964, 992, 993].
    • Explizite Intents: Zielkomponente innerhalb der eigenen App ist bekannt (z.B. Starten einer neuen Activity)[cite: 965, 995].
    • Implizite Intents: System wählt geeignete App für Aktion (z.B. Mailversand, Link öffnen)[cite: 966, 996, 997, 998].
  • Services (Hintergrundverarbeitung):
    • Arbeiten ohne UI, laufen im Hintergrund[cite: 971, 1005].
    • Für lang andauernde oder regelmäßig wiederkehrende Aufgaben (z.B. Foto-Upload, E-Mail-Abruf)[cite: 972, 1006, 1007, 1008, 1009].
  • Content Provider (Datenzugriffsschicht):
    • Ermöglichen strukturierten Zugriff auf App-interne Daten (z.B. Kontakte)[cite: 968, 1000].
    • Oft in Kombination mit SQLite-Datenbanken[cite: 969, 1001, 1004].
    • Unterstützen Datenfreigabe für andere Apps (mit Berechtigung)[cite: 970, 1001, 1003].
  • Broadcast Receiver (Reaktionskomponenten):
    • Reagieren auf empfangene (Broadcast-)Intents und führen Aktionen aus[cite: 967].
    • Beispiel: Reaktion auf "Mail senden"-Intent oder System-Events (Akkustand niedrig)[cite: 968, 998].
  • Android Manifest (AndroidManifest.xml) (Konfigurationsdatei):
    • Zentrale XML-Datei zur Definition aller App-Komponenten[cite: 973, 1010].
    • Gibt Start-Activity an, regelt Berechtigungen und Intents[cite: 973, 1011].
    • Wird bei Projekterstellung automatisch generiert[cite: 974].
    • <application>-Element definiert Activities, Services, Receiver[cite: 1012].
    • <intent-filter> bestimmt, welche Intents von einer Komponente empfangen werden können[cite: 1014, 1015].
  • Views und Layouts (UI-Elemente):
    • Views sind einzelne UI-Elemente (Text View, Button etc.)[cite: 982].
    • Layouts definieren die Anordnung von Views (LinearLayout, ConstraintLayout etc. - traditionell XML; Column, Row, Box - Jetpack Compose)[cite: 982, 983].

4.3 Jetpack Compose Grundlagen (UI-Entwicklung)

  • Composable Functions:
    • Moderne UI-Entwicklung in Android mit Kotlin-Funktionen, annotiert mit @Composable[cite: 1037, 1038, 1039].
    • Built-in Composables: Text, Button, Image, TextField, Card, LazyColumn/LazyRow[cite: 1040].
  • Layouts in Compose:
    • Column(): Vertikale Stapelung von Elementen[cite: 1052, 1053]. Parameter: horizontalArrangement, verticalAlignment[cite: 1054].
    • Row(): Horizontale Anordnung von Elementen[cite: 1055, 1056]. Parameter: verticalAlignment, horizontalArrangement[cite: 1056].
    • Box(): Vielseitiger Container, Elemente überlagern/stapeln[cite: 1057, 1058]. Parameter: contentAlignment[cite: 1058].
    • Scaffold(): Übergeordnetes Layout für gängige UI-Strukturen (TopAppBar, BottomNavigation, FAB)[cite: 1059, 1060].
  • Modifiers:
    • Verzieren oder ergänzen Composables[cite: 1063].
    • Ändern Größe, Layout, Verhalten, Darstellung; fügen Barrierefreiheitsinfos hinzu; verarbeiten Nutzereingabe; ermöglichen Interaktionen (klickbar, scrollbar etc.)[cite: 1064, 1065].

Kapitel 05: Interaktion zwischen Anwendungskomponenten

Lernziele des Kapitels:

  • Verständnis der Kommunikationswege zwischen Android-Komponenten[cite: 1070, 1071].
  • Anwendung von Intents, Services und Broadcast Receivern[cite: 1071].

5.1 Intents

  • Zentraler Kommunikationsmechanismus in Android zwischen Komponenten[cite: 1075, 1076, 1107].
  • Dienen als "Absichtserklärung" (Intent) für eine Aktion[cite: 1132].
  • Typen:
    • Explizite Intents:
      • Geben genaue Komponente an (z.B. eine bestimmte Activity oder Service-Klasse)[cite: 1093, 1111].
      • Häufig innerhalb derselben App für Navigation oder Service-Kommunikation[cite: 1094, 1096, 1112].
      • Beispiel: Intent(context, TargetActivity::class.java).apply { putExtra("key", "message") }[cite: 1097, 1098].
    • Implizite Intents:
      • Beschreiben allgemeine Aktion (z.B. URL öffnen, Inhalt teilen) ohne spezifische Komponente[cite: 1079, 1109].
      • System sucht passende Komponente/App[cite: 1080, 1110].
      • Verwendet für Interaktionen zwischen Apps[cite: 1081, 1087].
      • Beispiel: Intent(Intent.ACTION_VIEW).apply { data = Uri.parse(url) }[cite: 1088, 1089].
      • resolveActivity(packageManager) prüft, ob eine App den Intent verarbeiten kann[cite: 1090].
  • Intent Filter:
    • Ausdruck in AndroidManifest.xml, der Typ der Intents angibt, die eine Komponente empfangen soll[cite: 1099, 1100].
    • Ermöglicht anderen Apps, eine Aktivität direkt zu starten[cite: 1100].
    • Bei mehreren kompatiblen Filtern: Dialog zur App-Auswahl[cite: 1101].
  • Häufige Intent-Aktionen:
    • AlarmClock.ACTION_SET_ALARM: Erstellt einen Alarm[cite: 1104, 1105]. Extras: AlarmClock.EXTRA_MESSAGE, AlarmClock.EXTRA_HOUR, AlarmClock.EXTRA_MINUTES[cite: 1106].
    • Weitere: Kamera starten, Kontakte anzeigen, E-Mail senden[cite: 1103].

5.2 Services und Broadcast Receiver

  • Services:
    • Spezielle Komponenten für Hintergrundoperationen ohne sichtbare UI[cite: 1117, 1118, 1120, 1121].
    • Sinnvoll für langlaufende Operationen (Bild-Uploads, Datensynchronisierung, Musikwiedergabe)[cite: 1118, 1119, 1135].
    • Interaktion oft über Starten (z.B. Button-Klick) und Abschlussmeldung (z.B. Benachrichtigung)[cite: 1122].
    • Unterschiedliche Typen basierend auf Prozesszugehörigkeit und Ressourcenmanagement[cite: 1123, 1124].
  • Broadcast Intents:
    • Systemnachrichten, die vom Android-System gesendet werden, um Apps über Systemzustandsänderungen zu informieren (z.B. geringer Akkustand, neue App installiert, System-Shutdown)[cite: 1125, 1126, 1133].
  • Broadcast Receiver:
    • Komponenten, die auf Broadcast Intents reagieren[cite: 1127].
    • Beispiele: Energiesparmodus bei Akkuwarnung aktivieren, App-Zustand vor System-Shutdown sichern[cite: 1127].
    • Statische Broadcast Receiver: Registrierung im Android-Manifest; läuft unabhängig von der App; kann Systemnachrichten empfangen, auch wenn App nicht aktiv ist[cite: 1128].
    • Dynamische Broadcast Receiver: Registrierung zur Laufzeit in einer Komponente; nur aktiv, während registrierende Komponente läuft; programmatische Registrierung/Abmeldung[cite: 1129, 1130].

Kapitel 06: Fortgeschrittene Techniken

Lernziele des Kapitels:

  • Verständnis fortgeschrittener Architekturkonzepte (MVVM)[cite: 1140, 1141].
  • Grundlagen von Threading, Anwendungsspeicher und Jetpack Compose vertiefen[cite: 1141, 1142].

6.1 Architektur: MVVM (Model-View-ViewModel)

  • Definition: Architektur-Muster für UI-Entwicklung, trennt Benutzeroberfläche (View) von Geschäftslogik (ViewModel) und Daten (Model)[cite: 1147, 1148].
  • Ziele:
    • Trennung der Verantwortlichkeiten (Separation of Concerns, SoC): UI, Logik, Daten klar getrennt[cite: 1144, 1146, 1148].
    • Testbarkeit: Business-Logik und Daten unabhängig von UI testbar[cite: 1145].
  • Rollen:
    • Model: Verwaltet Daten und Geschäftslogik; liefert Daten an ViewModel[cite: 1149]. In Android oft Repositories, Use Cases, Datenquellen (Netzwerk, Lokal)[cite: 1166, 1167].
    • ViewModel: Vermittler zwischen Model und View; bereitet Daten für View auf; enthält keine UI-Infos[cite: 1149]. Sammelt Daten (Flows), ist lebenszyklusbewusst[cite: 1163, 1164, 1165].
    • View: Präsentation der UI; bindet sich an Daten/Befehle des ViewModels; reagiert auf Nutzerinteraktionen[cite: 1149]. In Android oft Activities/Fragments; zeigt UI, beobachtet ViewModel[cite: 1160, 1161, 1162].
  • Schichten (Beispiel Clean Architecture mit MVVM):
    • Presentation Layer: Schnittstelle Nutzer-Anwendung; verarbeitet Nutzereingaben; zeigt Ergebnisse[cite: 1151, 1152, 1153]. (View, ViewModel)
    • Domain Layer: Enthält zentrale Geschäftsregeln/Prozesse; Datenverarbeitung (Konvertierung, Filterung, Sortierung)[cite: 1154, 1155]. (Use Cases)
    • Data Layer: Organisiert Datenfluss; Datenpersistenz; Abstraktionsschicht zu Datenquellen[cite: 1156, 1157, 1158]. (Repositories, Local/Remote Data Sources)

6.2 Threading

  • Definition: Threads sind Ausführungseinheiten innerhalb eines Prozesses; teilen Ressourcen, arbeiten aber unabhängig; ermöglichen parallele Programmierung[cite: 1169, 1170, 1171].
  • Vorteile: Bessere Nutzung von Multi-Prozessorsystemen; schnellere Umschaltung/Datenaustausch als Prozesse[cite: 1172].
  • Herausforderungen:
    • Inkonsistenter Datenzugriff: Gemeinsamer Zugriff auf globale Variablen kann Fehler verursachen[cite: 1173].
    • Deadlocks: Zyklische Abhängigkeiten zwischen Threads führen zu Stillstand[cite: 1174, 1180]. Beispiel: Thread A hat Ressource X, braucht Y; Thread B hat Y, braucht X[cite: 1175, 1181, 1182].
    • Speicherprobleme: Freigabe von Ressourcen, die noch genutzt werden, kann Abstürze verursachen[cite: 1177].
    • Schwieriges Debugging: Fehler oft unvorhersehbar, schwer reproduzierbar[cite: 1178].
  • Deadlock-Lösungen: Algorithmen zur Vermeidung (feste Reihenfolge für Ressourcenanforderung), Timeouts[cite: 1185].

6.3 Anwendungsspeicher

  • Seit Android 6 (API 23): Zugriff auf Speicher mit Laufzeitberechtigungen[cite: 1187].
  • Interner Speicher (Internal Storage):
    • Nur von der App selbst nutzbar[cite: 1188].
    • Für Einstellungen, Datenbanken, temporäre Dateien; wird bei Deinstallation gelöscht[cite: 1189].
  • Externer Speicher (External Storage):
    • Außerhalb der App (z.B. SD-Karte); von anderen Apps/Nutzer einsehbar[cite: 1190, 1191].
    • Für persistente Daten (Bilder, Dokumente); ab Android 10 durch Scoped Storage eingeschränkt[cite: 1191, 1192].
  • Cache-Speicher: Temporärer Speicher zur Performance-Optimierung; kann automatisch/manuell gelöscht werden[cite: 1193].
  • Datenbank-Speicher: SQLite-Datenbanken für strukturierte Daten; liegt im internen Speicher; Zugriff via SQLiteOpenHelper[cite: 1194, 1195].
  • Shared Preferences: Schlüssel-Wert-Paare für kleine Konfigurationsdaten (Login-Status, Einstellungen); im internen Speicher[cite: 1195, 1196].

6.4 Jetpack Compose (Vertiefung)

  • Definition: Modernes, deklaratives UI-Toolkit für Android; weniger Code, bessere Wartbarkeit; ersetzt XML-Layouts durch Kotlin-APIs[cite: 1198, 1199, 1200].
  • Kernkonzepte:
    • Deklarativer Ansatz: UI wird durch Funktionen definiert, die App-Zustand widerspiegeln[cite: 1201].
    • Composable Funktionen: UI-Komponenten als @Composable annotierte Kotlin-Funktionen[cite: 1205, 1206].
    • State Management: UI aktualisiert sich automatisch bei Zustandsänderung[cite: 1206, 1207].
    • Layout-System: Flexible Anordnung mit Column, Row, Box etc.[cite: 1207].
  • State Management in Compose:
    • State: Ein Wert, der sich ändern kann (Datenbankeintrag, Variable etc.)[cite: 1211]. Beispiele: Snackbar-Sichtbarkeit, Blogpost-Kommentare[cite: 1212].
    • Compose ist deklarativ: UI wird durch erneuten Aufruf des Composables mit neuen Argumenten aktualisiert[cite: 1213]. Composable muss explizit über neuen Status informiert werden[cite: 1213].
    • remember API: Speichert Werte über Kompositionszyklen hinweg im Arbeitsspeicher[cite: 1215].
    • mutableStateOf: Erstellt ein Observable MutableState<T>, das bei Änderungen Neuzusammensetzung auslöst[cite: 1215].
  • Navigation in Compose:
    • Navigation Controller (NavController): Zentraler Koordinator für Navigation, Back-Stack-Verwaltung, Deeplinks[cite: 1222]. Wird mit rememberNavController() erstellt.
    • Navigation Host (NavHost): UI-Element, das aktuelles Navigationsziel enthält; tauscht Ziele aus; legt Startbildschirm (startDestination) fest[cite: 1223, 1224].
    • Navigation Destination (composable Block im NavHost): Ein Knoten im Navigationsdiagramm; zeigt Inhalt bei Aufruf[cite: 1225, 1226, 1227].
    • navController.navigate("route") zum Wechseln der Destination[cite: 1229].
    • navController.popBackStack() zum Zurückkehren[cite: 1237].
    • Grafische NavGraph-Ansicht in Android Studio funktioniert nur mit XML-basierter Navigation, nicht für reine Compose-Navigation[cite: 1231, 1232, 1233].

Wichtige Links

Studium an der IU Internationale Hochschule am Standort Hannover im Zeitraum von Oktober 2022 bis April 2026