ICT-App Dev Specialist FA: App Development

App Development

The App Development domain tests whether you can turn a requirement into a working, testable app: how you structure code, model UI state, persist data, call APIs, handle permissions, and ship a build. Expect scenario questions that ask you to choose an architecture, predict failure behavior, or fix a state-handling bug.

Core rules and concepts

• Keep presentation separate from business logic. MVC, MVVM, or unidirectional data flow lets you test rules without a device and swap UI without rewriting logic.
• Model every screen with explicit states: loading, empty, content, error. Overlapping booleans (isLoading and hasError) produce impossible combinations.
• Persist local data with a versioned schema and migration path. Store tokens in the platform keystore or encrypted storage, never in plain preferences.
• Network calls need a timeout, bounded retries with backoff, and handling for non-2xx responses. Writes should be idempotent or carry a version/ETag so retries do not duplicate records.
• Request permissions just in time, with a rationale, and implement the denied path. A camera feature that crashes when permission is refused fails review and usability.
• Use semantic versioning, reproducible builds, and environment-specific configuration. Hard-coded base URLs and debug flags leak into production.

Worked example

A profile screen must show cached data instantly, refresh in the background, and preserve unsaved edits. Define a UiState with Loading, Content(user, isRefreshing), and Error(message, cachedUser). On open, read the cache and render Content immediately; start the refresh. If refresh fails, keep the cached user and show a non-blocking banner-do not replace content with a full-screen error. The edit form holds a local draft; on submit, validate, disable the button, send PUT /users/{id} with If-Match: <etag>, and handle 409 Conflict by showing both versions. Reasoning: this separates cache from network, avoids blank screens and duplicate writes, and makes conflict resolution explicit.

Traps that cost marks

• Using one isLoading flag for both initial load and refresh, so the whole screen flashes.
• Assuming the network is always available or fast; no timeout means an indefinite spinner.
• Storing secrets in local storage or logs.
• Requesting every permission at launch instead of at the point of use.
• Testing only the happy path; exam scenarios often target offline, expired session, and denied permission.