315 Mobile App Develop Review

R Batzinger

Part 1: Core Components & AndroidManifest.xml

Topic: The Big Four and the App’s Blueprint.

Messaging Types (The Big Four):

  • Activity: The entry point for interacting with the user; represents a single screen.

  • Service: Performs long-running operations in the background (no UI).

  • Broadcast Receiver: Listens for system-wide announcements (e.g., battery low).

  • Content Provider: Manages and shares a structured set of app data with other apps.

The Manifest (AndroidManifest.xml):

  • Purpose: Provides essential information to the Android build tools, the OS, and Google Play.

  • Role: Declares permissions, hardware features, and all app components.

  • Location: Strictly found in the root of the project source set (usually src/main/).

Notes: If a component (like a Service) isn’t in the Manifest, the OS cannot “see” or start it. <receiver> is the tag for Broadcast Receivers.

AndroidManifest.xml

  • This file found at the root of its source set.

  • This essential XML file serves as a “blueprint” or “passport” for the application

  • providing critical metadata for the following entities:

    • the Android operating system,
      • the set of build tools
      • the Google Play Store.

Message Tags in the AndroidManifest.xml:

Tag Component Purpose
activity Activity: Represents a single screen with a user interface.
receiver Broadcast Receiver: Allows the app to receive intents broadcast by the system or other apps.
provider Content Provider: Manages access to a structured set of data shared between apps.

Key Manifest XML Elements

Element - Purpose

  • manifest: The root element of the file; contains the package name.
  • application: Container for component declarations and global settings like themes and icons.
  • uses-permission: Requests specific system permissions needed for the app to function.
  • intent-filter: Describes the types of intents a component can respond to, such as defining the main “launcher” activity.

Manifest Core Functions

  • Declaring App Components: Every Activity, Service, Broadcast Receiver, and Content Provider must be declared here. If a component isn’t listed, the system cannot start it.
  • Managing Permissions: It defines the system permissions the app requires to access protected features like the camera, internet, or contacts.
  • Device Compatibility: It specifies hardware and software requirements (e.g., camera with autofocus, minimum SDK version) to ensure the app is only installed on compatible devices.
  • App Identity: It defines the unique package name, app icon, and user-readable label (name) that appears in the launcher.

Part 2: Intents & Inter-App Communication

How apps talk to each other and the system.

Intents:

An abstract description of an action to be performed.

  • Explicit Intent: Specifies the exact class name (e.g., “Start SettingsActivity.class”).

  • Implicit Intent: Specifies a general action (e.g., “Open a web page”); the system finds a matching app via Intent Filters.

Requesting External Services:

  • Taking a Picture: Use ACTION_IMAGE_CAPTURE.

  • GPS/Location: Requires declaring <uses-permission> for FINE_LOCATION in the Manifest.

  • Music/Timers: Often involves specific actions like ACTION_SET_TIMER.

Notes: The Disambiguation Dialog (App Chooser). If multiple apps can handle an implicit intent, the system asks the user which one to use.

Part 3: Activity Lifecycle & Fragments

Managing state transitions.

Activity Lifecycle

Explanation

  • Visible but no focus: onPause() is called (e.g., a dialog covers the screen).

  • No longer visible: onStop() is called; the activity is now a candidate to be killed if memory is low.

  • Returning to app: onRestart() → onStart() → onResume().

  • Transient State: Use onSaveInstanceState() to save “rememorable variables” (like a score) during screen rotations.

Fragments:

Modular UI sections that live inside an Activity; allow for flexible layouts across different screen sizes.

** Notes:** onStop() is the critical point where the activity “exists in memory” but is hidden. If it’s killed while stopped, it must be recreated via onCreate().

Part 4: Interfaces, Resources, and UI Styles

Declarative vs. Imperative design.

UI Paradigms:

  • Imperative: Manually mutating views (e.g., textView.setText("...")).

  • Declarative (Compose): Describing what the UI should look like for a given state.

UI Components:

  • Modifiers: Used in declarative UI to decorate or augment composables (padding, size, etc.) works from outside to inside.

  • Toast: A small, transient pop-up message for brief feedback.

Resources:

  • Role: Separation of logic from content (localization/themes).

  • res/raw: For arbitrary files like audio/video in their original format.

Notes: The strings.xml is a good example: it’s easier to translate an app into Spanish if the text isn’t hardcoded in the logic.

Part 5: Data Persistence: SQLite & Memory

Storing data permanently.

Internal vs. External Memory:

  • Internal: Private, app-specific files.

  • External: Large, shareable files (photos, downloads).

SQLite:

  • Best Use: Large amounts of structured data.

  • Queries: Provides a full relational database engine for complex SQL querying.

SharedPreferences: (Contrast with SQLite) Best for small key-value pairs (user settings).

Notes: SQLite is for complexity, while SharedPreferences is for simplicity.

Part 6: The Build Process & Gradle

From code to APK.

Gradle Roles:

  • Version Control: Module-level build.gradle defines specific library versions.

  • Build Pipeline:

    1. Compiling: Translates source code into DEX bytecode.

    2. Linking: Combines compiled code with library dependencies.

    3. Packaging: Bundles everything into an .apk or .aab file.

    4. Deployment: Pushing the final package to a device or emulator.

Notes: “Linking” is where references between your code and external libraries (like Retrofit) are resolved so they function as one unit.