Introduction to Mobile Application Development

Mobile applications as event-driven systems

A mobile app responds to events rather than running one uninterrupted script from beginning to end. Events include taps, navigation, network completions, orientation changes, and lifecycle transitions. Model the app as state plus event handlers that produce new state. Keep domain data separate from the view displaying it. For a shopping list, the items and their completion states are the model; a row’s color is a presentation decision. This separation makes it easier to test behavior and rebuild the interface after the operating system recreates a screen.

References: COMP 1601 — Winter 2022 course outline · Android Developers — The activity lifecycle

Lifecycle, resource ownership, and restoration

The operating system may pause, stop, recreate, or terminate application components as users switch activities and memory pressure changes. Do not treat an in-memory screen object as permanent storage. Release resources according to their useful lifetime: a camera preview should not keep the camera unnecessarily when the screen is no longer active. Distinguish small UI restoration state from durable user data. A saved scroll position helps restore a screen; a submitted order belongs in persistent storage with a clear completion status. Test leaving and returning during an unfinished operation.

References: COMP 1601 — Winter 2022 course outline · Android Developers — The activity lifecycle

Interface state, rendering, and user actions

A declarative interface describes what should be shown for the current state. User actions update that state, and the framework reconciles the display. Avoid maintaining two contradictory copies of the same fact, such as a checkbox’s checked flag and an unrelated completion flag in the model. Derive presentation values when possible. Loading, empty, success, and error are distinct visible states. Buttons should remain understandable with large text, assistive technology, and alternative input; a small icon alone may not convey an action’s purpose.

References: COMP 1601 — Winter 2022 course outline · Apple — SwiftUI documentation

Persistence and a worked draft example

Suppose a user types a note, switches to another app, and returns after the process was removed. Keeping the text only in a local view variable loses the note. A robust design updates an in-memory model for immediate responsiveness and saves a draft to durable storage at deliberate points or with a short debounce. Assign the draft an identifier, load it when reopening, and distinguish draft saving from final submission. If a save fails, expose a recoverable state rather than silently displaying an unearned saved indicator.

References: COMP 1601 — Winter 2022 course outline · Android Developers — The activity lifecycle

Asynchronous work and stale responses

Network and file operations can take an unpredictable amount of time. Performing lengthy work on the UI thread prevents timely input and drawing. Run suitable work asynchronously and update UI state through the platform’s supported mechanism. Cancellation matters: a result for a screen that has closed may no longer be useful. Also handle response ordering. If a user searches for cat and then car, an older cat response must not overwrite the newer results. Associate requests with an identifier or compare the result’s query with current state before applying it.

References: COMP 1601 — Winter 2022 course outline · Android Developers — The activity lifecycle

Permissions, privacy, and mobile testing

Request a capability when its purpose becomes clear and design a useful response when permission is denied. Store only the information the feature requires, and avoid placing credentials or private content in diagnostic logs. A simulator helps test navigation and state transitions, but real devices can expose timing, keyboard, camera, and resource constraints that a desktop environment hides. Test interrupted operations, absent connectivity, process recreation, unusual screen sizes, and accessible text sizes. Keep data conversion and validation logic independently testable so that failures can be reproduced without replaying every gesture.

References: COMP 1601 — Winter 2022 course outline · Android Developers — The activity lifecycle

Practice & worked answers

Original exercises for this guide.

Public notes & references

Course sources establish the scope above. Reference materials support the explanations; linked lecture notes and books remain with their authors.

• COMP 1601 — Winter 2022 course outline ↗Course scope · Winter 2022
• Android Developers — The activity lifecycle ↗Primary reference · Public reference; checked 2026-11-05
• Apple — SwiftUI documentation ↗Primary reference · Public reference; checked 2026-11-05
• Somayaji — COMP 1601 lectures and tutorials ↗Public course reading · Winter 2022