SortedQueue.
Phase 4 complete track

Operate like a senior Android engineer.

Senior work is not just harder code. It is owning feature design, failure modes, review quality, performance, accessibility, security, and rollout evidence.

Feature design
Module boundary
Quality gates
Rollout evidence
Step 1

Write a feature design before coding

Feature: Saved provider reminders

User problem:
- Users save clinics and schools but forget to contact them.

Proposed behavior:
- Let user set a reminder from the business detail screen.
- Show upcoming reminders on the home screen.

Non-goals:
- No calendar sync in v1.
- No server notification service in v1.

Risks:
- Alarm behavior differs by OEM.
- Notification permission may reduce completion.

Verification:
- Unit tests for reminder time validation.
- Manual test on Android 13+ notification permission.
- Rollout behind a remote flag.
Step 2

Split modules by ownership, not fashion

:app
:core:model
:core:network
:core:database
:feature:catalogue
:feature:favourites
:feature:reminders
// Rule: feature modules can depend on core modules.
// Rule: core modules must not depend on feature modules.
// Rule: shared UI belongs in core only after two real features need it.

A module boundary is useful only if it reduces build coupling, ownership confusion, or change risk.

Step 3

Measure performance before optimizing

StartupTrack cold start and avoid heavy work before first draw.
ListsUse stable keys and avoid expensive work inside item composition.
NetworkCache intentionally and avoid duplicate requests on rotation/recomposition.
BuildWatch module graph, annotation processors, and unnecessary dependencies.
Senior review question:
"What evidence shows this change improved performance?"
Step 4

Accessibility checklist for every feature

  • All interactive elements have clear labels.
  • Touch targets are large enough for repeated use.
  • Dynamic font sizes do not break layout.
  • Color is not the only way to communicate state.
  • Screen reader order follows the visible workflow.
  • Error messages explain what the user can do next.
Step 5

Security and privacy threat pass

Data collectedWhat is stored locally, sent to network, logged, or shared?
Failure caseWhat happens if token, cache, or intent data leaks?
PermissionCan the feature work without a dangerous permission?
LoggingAre names, phone numbers, tokens, or addresses printed to logs?
Step 6

Senior code review rubric

  • Does the code match the agreed feature design?
  • Are states explicit and recoverable?
  • Are module dependencies pointing in the right direction?
  • Are tests protecting business behavior?
  • Is rollout reversible if metrics regress?
  • Is the README or release note clear enough for the next engineer?
Continue to Phase 5Phase overview