everything.study
COMP 2601

Mobile Applications

0.5 credit · Undergraduate

Development of applications for mobile environments taking advantage of gesture-based input and using location and presence services. Topics include introduction to low-level network services and mobile platforms, description of architectural patterns, principles of mobile development and interaction styles for network service usage.

Study notes

Independent, AI-drafted study guide · Public sources linked below · Added November 5, 2026

Independent guide aligned with the public Winter 2023 offering. Modern Android documentation supports stable architecture concepts; specific Compose APIs, project requirements, and platform versions are not claimed to match a current course.

Layers, state ownership, and mobile constraints

A mobile application combines a UI layer, data access, and domain rules while operating under interruptions, limited resources, and variable connectivity. Give each important piece of state a clear owner. The UI renders state and emits actions; a repository can coordinate remote and local data behind a stable interface. Avoid making a screen responsible for every database query and network detail. Layer boundaries support independent testing and make it easier to replace a service without rewriting navigation. Process recreation should recover essential user progress rather than leave the application in an impossible intermediate state.

References: Somayaji — COMP 2601 public course schedule · Android Developers — Guide to app architecture

Gestures, navigation, and embedded content

A gesture is an interpretation of input over time, not just a single coordinate. Tap, drag, pinch, and scroll recognition can compete, so design predictable priorities and feedback. Offer accessible alternatives for actions that would otherwise require a precise gesture. Navigation history should correspond to user expectations about returning to a previous context. An embedded WebView introduces a second execution and navigation environment; define which links remain embedded and which leave the application. Treat bridges between web content and native capabilities as trust boundaries rather than granting arbitrary pages unrestricted access.

References: Somayaji — COMP 2601 public course schedule · Android Developers — Guide to app architecture

Network services, asynchronous calls, and request contracts

A mobile client calls a remote API using a documented method, endpoint, headers, and representation. Connection failure, timeout, server rejection, and invalid response data are distinct outcomes. Move potentially blocking work away from the UI thread and expose loading and error states. Retry only when the operation’s semantics permit it; repeating a payment request is different from repeating a read. A timeout does not prove the server performed no action. Use stable operation identifiers or another duplicate-prevention design for mutations when supported by the service contract.

References: Somayaji — COMP 2601 public course schedule · Android Developers — Connect to the network

Local databases, offline behavior, and synchronization

A local database makes data available without a live connection and supports durable user progress. Define which system is authoritative for each field and how updates are synchronized. Store pending operations with explicit status so that they survive process death. Conflict resolution must reflect domain meaning: silently replacing a shared checklist may discard another user’s work. Schema changes require migrations or a deliberate disposable-cache policy. A database transaction groups related writes so that a crash cannot leave half of an intended local update committed.

References: Somayaji — COMP 2601 public course schedule · Android Developers — Guide to app architecture

Location, presence, permissions, and battery

Location and presence features consume resources and can reveal sensitive patterns. Match precision and update frequency to the task. A nearby-campus feature may not need continuous high-accuracy location in the background. Request permission in context, explain the immediate feature, and handle denial without assuming the user made a mistake. Stop listeners and sensors when they are no longer needed. Cache only what remains useful and define retention. When sharing presence, distinguish a recent observation from a guarantee that a person is still at a location.

References: Somayaji — COMP 2601 public course schedule · Android Developers — Guide to app architecture

Worked example: an offline bookmark queue

Suppose a user bookmarks a room while offline. Create a local bookmark with a unique client identifier and pending status, update the UI immediately, and enqueue synchronization. On reconnection, send the identifier so a supported server can recognize a retry. When the server confirms, store its canonical record and mark the operation complete. If validation fails, retain enough information to explain or repair the bookmark. If the process stops between server success and local confirmation, the repeated request must not create an unintended second bookmark.

References: Somayaji — COMP 2601 public course schedule · Android Developers — Guide to app architecture

Practice & worked answers

Original exercises for this guide.

1. Why can blindly retrying every failed POST be incorrect?

Show worked answer

The server may have committed the action before the connection failed. A retry can duplicate the mutation unless the operation is idempotent or the API supports a stable duplicate-prevention identifier.

2. What belongs in a pending offline operation record?

Show worked answer

Enough durable information to retry or reconcile the action: an identifier, required payload, relevant ordering/version information, status, and an interpretable failure state. Avoid storing unnecessary secrets.

3. Why should a location feature tolerate permission denial?

Show worked answer

Permission is a user-controlled capability, not a permanent assumption. The interface should explain the limitation and provide a lower-capability path when possible instead of failing unrelated features.

Public notes & references

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

Topics

Course catalogue

Prerequisites & course information

Prerequisite(s): COMP 1601 . Lecture/lab four hours a week.

Sources