Mobile Architecture and Scalable Codebases

Introduction

A mobile application may begin as a small collection of screens, API calls, and state variables. As features accumulate, however, the same codebase can become difficult to test, release, and extend. Authentication becomes entangled with navigation; screens directly manipulate databases; business rules are duplicated across platforms; and a minor change produces failures in unrelated features. These problems are architectural rather than merely syntactic.

Mobile architecture is the disciplined organization of responsibilities, dependencies, data, and boundaries in an application. In React Native and Flutter, architecture must also account for asynchronous execution, platform APIs, offline behavior, navigation, build variants, state management, and differences between JavaScript or TypeScript and Dart environments. A scalable architecture does not eliminate complexity. It places complexity in explicit locations and controls how it spreads.

This chapter examines separation of concerns, layered and clean architecture, repositories, dependency injection, modularization, reusable packages, monorepos, maintainability, and architectural decision records (ADRs). The central principle is that a mobile codebase should make business rules understandable independently of user-interface technology and should make change localized, testable, and reversible.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain why separation of concerns is essential in mobile development.
2. Compare layered architecture with clean architecture.
3. Design repository and dependency-injection abstractions.
4. Organize a React Native or Flutter application into maintainable modules.
5. Evaluate reusable packages and monorepo strategies.
6. Apply maintainability principles and recognize architectural risks.
7. Write an ADR that records a significant architectural decision.
8. Analyze a realistic architecture and justify improvements.

1. Architectural Thinking in Mobile Development

Architecture describes the significant structures of a system, the relationships among those structures, and the principles governing their evolution. It is not identical to a folder tree. A folder tree can reflect architecture, but architecture is ultimately about responsibilities and dependency direction.

A mobile application commonly contains the following concerns:

• Presentation: screens, widgets, navigation, accessibility, and visual state.
• Application coordination: use cases, workflows, and orchestration.
• Domain logic: business rules, policies, and domain models.
• Data access: repositories, network clients, local storage, caching, and synchronization.
• Platform integration: notifications, sensors, secure storage, permissions, and device APIs.
• Cross-cutting concerns: logging, analytics, configuration, error handling, and security.

A useful architectural question is: “If the user interface framework changed, which rules should remain unchanged?” Authentication policy, order totals, eligibility rules, and synchronization decisions should generally survive a migration from Flutter to React Native. This indicates that those rules belong outside the presentation layer.

1.1 Separation of Concerns

Separation of concerns assigns each responsibility to an appropriate component and limits unnecessary knowledge between components. A screen should display state and communicate user intent; it should not know how SQL queries, HTTP retries, or token refresh work. A repository should provide data capabilities; it should not format text for a particular screen.

Separation does not mean that every function must be placed in a separate file. Excessive fragmentation can create navigation overhead and obscure simple logic. The objective is cohesive components with limited, meaningful coupling.

Two related concepts are important:

• Cohesion: the degree to which the responsibilities of a module belong together. High cohesion is desirable.
• Coupling: the degree of dependence between modules. Lower unnecessary coupling is desirable.

A well-designed module may depend on an interface such as UserRepository, while the concrete implementation may use REST, GraphQL, SQLite, or a test double. This is dependency inversion: high-level policy does not depend directly on low-level technical details.

2. Layered Architecture

Layered architecture organizes an application into levels. A common mobile arrangement is:

1. Presentation layer
2. Application or use-case layer
3. Domain layer
4. Data and infrastructure layer

The presentation layer contains React components, React Native screens, Flutter widgets, controllers, view models, and UI-specific state. It translates user events into application commands and translates results into visual state.

The application layer coordinates a particular action, such as signing in, placing an order, or synchronizing tasks. It may call domain services and repositories, but it should not contain widget layout code.

The domain layer contains business concepts and rules. It should be as independent as practical from HTTP clients, database libraries, navigation libraries, and platform frameworks. Domain entities may be represented as TypeScript classes or types, Dart classes, value objects, and domain services.

The data layer implements repository contracts. It may include remote data sources, local data sources, serializers, cache policies, database adapters, and platform integrations.

2.1 Dependency Direction

In a strict layered design, dependencies normally point toward more stable policy. Presentation depends on application abstractions; application depends on domain abstractions; infrastructure implements those abstractions. If a use case imports a Flutter widget or React Native navigation object, the dependency direction has been violated.

Layering is a communication convention, not an absolute law. Some applications need shared UI components, observability, or platform services. The architectural decision should be explicit: permit a dependency when it reduces complexity and does not compromise testability or ownership boundaries.

2.2 Strengths and Limitations

Layered architecture is easy to teach and provides clear placement rules. It improves testability and reduces direct coupling between screens and infrastructure. Its limitation is that poorly designed layers can become “pass-through” layers: classes exist only to forward calls without adding a boundary or meaningful behavior. Layers should therefore be justified by responsibility, change patterns, or testability—not by a desire to create more files.

3. Clean Architecture

Clean architecture refines layered thinking around dependency inversion. Its central idea is that inner policies should not depend on outer mechanisms. A typical arrangement is:

• Entities: stable business concepts and invariants.
• Use cases: application-specific business actions.
• Interface adapters: controllers, presenters, view models, and repository implementations or translators.
• Frameworks and drivers: UI frameworks, databases, HTTP libraries, operating-system services, and external SDKs.

The dependency rule states that source-code dependencies should point inward. Outer layers may depend on inner layers; inner layers should not import outer frameworks.

In React Native, a use case should not require a React component, navigation object, or Redux store. In Flutter, a domain entity should not depend on a BuildContext, widget, or provider package. The application boundary can instead expose plain data, result types, and interfaces.

3.1 Use Cases as Application Boundaries

A use case represents a meaningful capability, such as SignIn, LoadCatalog, or SubmitExpense. It typically receives input, invokes domain or repository services, and returns success or failure. A use case should not become a procedural dump for every concern. Validation, authorization policy, persistence, and presentation formatting should remain appropriately separated.

A simple TypeScript-style contract might be expressed as:

interface AuthenticateUser {
  execute(input: Credentials): Promise<Result<Session, AuthenticationError>>
}

The notation is illustrative rather than tied to a particular library. Result makes success and expected failure explicit, while unexpected programming failures can still be handled by a global error mechanism.

3.2 Clean Architecture and Mobile Constraints

Mobile systems are often intermittently connected, resource-constrained, and lifecycle-driven. Clean architecture helps isolate policies for:

• cache-first or network-first retrieval;
• retry and backoff decisions;
• conflict resolution;
• token expiration;
• background synchronization;
• permission denial;
• cancellation when a screen is disposed.

The architecture does not automatically solve these problems. It gives them named boundaries where they can be designed and tested.

4. The Repository Pattern

A repository mediates between application or domain logic and data sources. It presents a business-oriented interface rather than exposing HTTP responses or database queries directly.

For example:

interface TaskRepository {
  getTasks(ownerId: UserId): Future<Result<List<Task>, TaskError>>
  saveTask(task: Task): Future<Result<void, TaskError>>
}

A concrete implementation may combine a REST client, local database, and cache. The use case knows only the repository contract.

4.1 Repository Responsibilities

A repository may be responsible for:

• selecting remote or local sources;
• mapping transport objects to domain objects;
• applying cache policy;
• coordinating reads and writes;
• translating technical failures into meaningful application errors;
• enforcing consistency rules at the data boundary.

It should not ordinarily decide how a screen displays a loading spinner. Nor should it silently conceal important failures merely to simplify the caller.

4.2 Data Transfer Objects and Domain Models

A data transfer object (DTO) reflects an external representation, such as JSON. A domain model reflects concepts required by business rules. Keeping them distinct protects the domain from API naming, nullability quirks, versioning, and transport-specific fields.

For a small application, direct mapping may seem unnecessary. It becomes valuable when APIs evolve, multiple data sources exist, or domain invariants differ from server representations. Mapping also provides a clear location for validation and normalization.

4.3 Offline-First Design

An offline-capable repository generally needs a source-of-truth policy. Possible policies include:

• network-first: prefer current server data, then use cache on failure;
• cache-first: show local data quickly and refresh in the background;
• local-first synchronization: write locally and upload later;
• server-authoritative: reject or reconcile conflicting local changes.

The choice depends on business risk. A note-taking application may accept local-first writes, whereas a financial transfer system may require explicit server confirmation. The repository contract should communicate whether results are cached, stale, pending synchronization, or authoritative.

5. Dependency Injection

Dependency injection (DI) supplies an object’s dependencies from outside rather than constructing them internally. Constructor injection is generally the clearest form:

class LoadTasks {
  constructor(private repository: TaskRepository) {}

  execute(ownerId: UserId) {
    return this.repository.getTasks(ownerId)
  }
}

A test can provide an in-memory fake repository; production can provide a repository backed by HTTP and SQLite.

5.1 Forms of DI

• Constructor injection: dependencies are required when an object is created. This makes requirements visible and supports immutable objects.
• Parameter injection: a dependency is passed to a particular operation. This is useful for occasional collaborators.
• Property or service-locator injection: dependencies are obtained through mutable properties or a global registry. These approaches can be convenient but hide requirements and complicate testing.

Frameworks such as Riverpod, Provider, GetIt, Inversify, or custom composition roots can manage object graphs. The framework is not the principle. The principle is that object construction and dependency choice should be controlled at an outer composition boundary.

5.2 The Composition Root

The composition root is the location where concrete implementations are assembled. It may be the application entry point, a feature bootstrapper, or a dependency container configuration. A production composition root might connect:

TaskScreen → LoadTasks → TaskRepository → ApiClient and LocalStore.

A test composition root replaces the API repository with a deterministic fake. This supports unit testing without network access and makes environment-specific configuration explicit.

6. Modularization and Feature Boundaries

Modularization divides a codebase into units with explicit ownership and dependencies. Two common strategies are technical layers and vertical feature slices.

A technical-layer structure might contain screens, services, models, and utils. It is initially familiar but can cause a single feature to be scattered across many directories.

A feature-oriented structure groups code by capability:

features/
  authentication/
    presentation/
    application/
    domain/
    data/
  tasks/
    presentation/
    application/
    domain/
    data/
shared/
  design_system/
  networking/
  analytics/

Feature-oriented organization improves locality and ownership. Shared code should be extracted only when it is genuinely stable and used by multiple features. A premature common or utils folder often becomes an unowned dependency landfill.

6.1 Module Contracts

A module contract defines what other modules may use. Public exports should be small and intentional. Internal classes, DTOs, and implementation details should not be imported by unrelated features.

A dependency graph can be evaluated for cycles. If Module A depends on B and B depends on A, changes in either module become harder to reason about. Break cycles by introducing an abstraction, moving shared policy inward, or redefining ownership.

6.2 Shared Packages

Reusable packages may contain:

• design-system components and tokens;
• authentication abstractions;
• typed API clients;
• analytics interfaces;
• validation utilities;
• platform adapters;
• domain libraries shared with web or server applications.

A package should have a clear purpose, semantic versioning policy, documentation, tests, and an owner. Reuse is beneficial when it reduces duplicated behavior; it is harmful when it forces unrelated products into the same release cycle.

7. Monorepos and Multi-Platform Codebases

A monorepo stores multiple applications and packages in one repository. A mobile organization might contain a Flutter app, a React Native app, a design-system package, shared TypeScript tooling, and documentation.

Advantages include:

• atomic changes across applications and packages;
• consistent linting, testing, and dependency policies;
• discoverability of shared code;
• easier code review for cross-product changes.

Risks include:

• long builds and test pipelines;
• unclear ownership;
• accidental dependency coupling;
• difficult platform-specific package management;
• large blast radius for shared changes.

Workspace tools such as pnpm workspaces, Yarn workspaces, Nx, Turborepo, Melos, or similar systems can coordinate tasks. The tool does not create modularity automatically. Package boundaries, dependency rules, caching, ownership, and release policies must still be designed.

React Native teams commonly share TypeScript packages, while Flutter teams may use Dart packages. Cross-language reuse is usually better achieved through stable contracts, generated clients, schemas, or design specifications than by forcing one language’s source code into another ecosystem.

8. Maintainability Principles

Maintainability is the ease with which a system can be corrected, adapted, understood, and tested. Important principles include:

8.1 Single Responsibility

A module should have one coherent reason to change. A screen that handles rendering, API calls, analytics, validation, and database migration has many reasons to change. Extracting responsibilities reduces cognitive load.

8.2 Explicitness Over Hidden Magic

Dependency containers, code generation, and state-management frameworks can reduce boilerplate, but excessive convention or reflection can make behavior difficult to trace. Prefer mechanisms that remain understandable to a new team member.

8.3 Stable Abstractions

Abstract at a boundary that is likely to vary: network access, storage, clock, random number generation, and platform services are common examples. Do not create interfaces for every class merely to satisfy a rule. An abstraction should protect a meaningful policy or variation point.

8.4 Testability

A useful testing arrangement includes:

• unit tests for domain rules and use cases;
• repository tests for mapping, caching, and persistence behavior;
• widget or component tests for presentation behavior;
• integration tests for critical workflows;
• a small number of end-to-end tests for release confidence.

Testability improves when dependencies are injected, side effects are isolated, and time, randomness, and network access are controllable.

8.5 Observability and Error Design

Production architecture should make failures diagnosable. Use structured logs, correlation identifiers where appropriate, crash reporting, meaningful error categories, and privacy-aware analytics. Avoid logging access tokens, passwords, personal data, or full payment details.

Error types should distinguish expected conditions such as validation failure, authentication failure, offline state, and authorization denial from unexpected defects. User-facing messages should be understandable without exposing internal stack traces.

9. Architectural Decision Records

An ADR is a short, version-controlled document recording an important architectural decision. It prevents teams from repeatedly reopening settled questions and preserves the reasoning that future developers otherwise infer imperfectly.

A practical ADR structure is:

Title: Use local-first synchronization for task drafts
Status: Accepted
Context: Field users frequently lose connectivity.
Decision: Save drafts locally and synchronize when connectivity returns.
Consequences: Better continuity; conflict resolution and encrypted storage are required.
Alternatives considered: Network-only persistence; manual export.

A good ADR records context, constraints, decision, consequences, alternatives, and status. It should not become a design essay or a record of every implementation detail. ADRs should be updated or superseded when assumptions change.

Examples of decisions deserving ADRs include selecting a state-management strategy, adopting a monorepo, choosing cache authority, defining package ownership, or deciding whether business logic is shared across mobile and web clients.

10. Worked Architectural Example

Consider a shopping application whose ProductScreen directly calls an HTTP client, parses JSON, writes to local storage, and navigates to checkout. Tests require a network mock and a mounted navigation tree. Product data is duplicated in three screens, and an API change has caused failures throughout the UI.

Analysis

The screen has at least five responsibilities: presentation, remote access, persistence, mapping, and navigation. It is highly coupled to infrastructure and difficult to test. The duplicated product model indicates that the external DTO has leaked into the presentation layer.

Refactoring Approach

First, define a domain model Product containing only concepts needed by business rules and display adapters. Second, define ProductRepository with operations such as findById and listFeatured. Third, implement ProductRepositoryImpl using an API data source and local cache. Fourth, create a LoadProduct use case. Finally, make the screen depend on a controller or view model that invokes the use case and exposes loading, success, and failure states.

The resulting dependency direction is:

ProductScreen → ProductController → LoadProduct → ProductRepository → ApiDataSource / LocalCache.

The screen test can supply a fake controller. The use-case test can supply a fake repository. The repository test can verify DTO mapping and cache behavior independently.

Outcome

An API field rename changes the DTO mapper rather than every screen. A cache policy can be tested without a UI. A future web client can reuse the domain and application packages if their language and runtime permit it. The refactoring may initially add files, but it reduces the cost and risk of later changes.

11. Detailed Illustrative Case: Campus Mobility App

This is a fictional illustrative case.

Background

A university operates a campus mobility app showing shuttle locations, reporting accessibility problems, and allowing students to save favorite routes. The first release was developed quickly in Flutter. Widgets call REST endpoints directly, local preferences are accessed from screens, and authentication state is held in a global singleton.

Problem

Students report stale shuttle data when connectivity is poor. A change to the authentication SDK breaks unrelated screens. Automated tests cover only widget snapshots, and the development team cannot confidently modify the global singleton. A second team is beginning a React Native version for a partner institution.

Analysis

The major risks are infrastructure leakage, hidden dependencies, and an unclear source-of-truth policy. Shuttle tracking has freshness requirements, whereas accessibility reports require durable local drafts. Treating both features identically would be inappropriate.

Approach

The teams define feature modules: tracking, reports, favorites, and identity. Each feature has presentation, application, domain, and data boundaries. Repositories expose feature-level contracts. The tracking repository uses cache-first reads followed by background refresh; the report repository uses local-first drafts with an explicit synchronization state.

Authentication is represented by an IdentityRepository interface. Platform-specific SDK code is isolated in an adapter. The composition root chooses the adapter and injects it into use cases. Shared contracts and validation rules are published as packages where the language permits; platform-specific UI remains native to Flutter or React Native.

An ADR records the synchronization policy, its rationale, encryption requirements for local drafts, and conflict-resolution behavior. Structured telemetry records synchronization success, failure categories, and latency without collecting unnecessary personal data.

Outcome

The Flutter application can test synchronization with fake clocks, repositories, and connectivity services. The React Native team can implement equivalent use cases without importing Flutter code. Product teams can change the design system without rewriting domain rules. The main remaining challenge is governance: shared packages require ownership, compatibility testing, and a release process.

Learning Points

1. Different features may require different consistency policies.
2. Platform adapters protect business logic from SDK volatility.
3. Shared behavior should be extracted around stable contracts, not around superficial code similarity.
4. Architecture must include privacy, observability, and lifecycle concerns.
5. ADRs make trade-offs visible and reviewable.

12. Challenges, Trade-offs, and Governance

Architecture introduces costs. More boundaries can mean more mapping, files, interfaces, and coordination. A clean architecture can be over-engineered for a short-lived prototype. Conversely, a prototype that becomes a product may incur substantial migration cost if boundaries were ignored entirely.

Teams should evaluate architecture against expected product lifetime, feature volatility, number of developers, regulatory exposure, offline requirements, and number of clients. A useful strategy is evolutionary architecture: establish a few high-value boundaries early, measure friction, and strengthen boundaries where change repeatedly causes defects.

Security and privacy are architectural concerns. Secure storage should be used for sensitive credentials; tokens should not be placed in ordinary preferences without justification. Permissions should be requested at the point of meaningful use, with clear explanations. Data minimization, retention limits, consent requirements, accessibility, and regional privacy law should influence repository and telemetry design.

AI-assisted coding can generate boilerplate, tests, and adapters, but it does not determine correct boundaries. Generated code must be reviewed for insecure storage, excessive permissions, dependency vulnerabilities, licensing issues, and incorrect assumptions about lifecycle or concurrency. ADRs can document when generated code or a third-party SDK becomes a material architectural dependency.

Best-Practice Checklist

Before releasing a substantial mobile feature, ask:

• Is presentation code independent of transport and storage details?
• Are business rules represented in testable use cases or domain services?
• Are repositories expressed through meaningful contracts?
• Are dependencies injected at a visible composition root?
• Can the feature be tested without a network or real device service?
• Are module exports and ownership explicit?
• Is shared code genuinely stable and reused?
• Are cache, synchronization, and failure policies documented?
• Are sensitive data and analytics governed appropriately?
• Does an ADR record decisions that future developers may question?

Chapter Summary

Scalable mobile architecture controls complexity by separating presentation, application coordination, domain policy, data access, and platform integration. Layered and clean architectures make dependency direction explicit and protect stable business rules from volatile frameworks. Repositories hide data-source details behind meaningful contracts, while dependency injection makes implementations replaceable and tests deterministic.

Feature-oriented modularization improves locality and ownership, but shared packages should be created only around stable, valuable abstractions. Monorepos support coordinated development but require package boundaries, ownership, and build governance. Maintainability depends on cohesion, controlled coupling, explicit dependencies, testability, observability, and disciplined error design. ADRs preserve the context and consequences of important decisions. Good architecture is not maximal abstraction; it is deliberate organization that makes change safer, clearer, and more economical.

Key Terms

Separation of concerns: Division of responsibilities so that each component addresses a coherent concern.

Cohesion: The degree to which a module’s responsibilities belong together.

Coupling: The degree of dependency between modules.

Layered architecture: Organization of software into levels with defined responsibilities and dependency relationships.

Clean architecture: An architecture in which dependencies point toward stable inner policies.

Domain layer: The part of an application containing business concepts and rules.

Use case: An application-specific operation representing a meaningful user or system capability.

Repository: An abstraction that mediates between application logic and data sources.

Data transfer object: A representation used to transport data across an external boundary.

Dependency injection: Supplying dependencies from outside an object rather than constructing them internally.

Composition root: The location where concrete implementations are assembled.

Module: A unit of code with a defined responsibility, interface, and dependency boundary.

Monorepo: A repository containing multiple applications and packages.

Offline-first: A strategy that treats local operation and synchronization as primary design concerns.

Cache policy: Rules determining when data is read from, written to, or refreshed in a cache.

Maintainability: The ease with which software can be understood, corrected, adapted, and tested.

Architectural decision record: A concise document recording the context, decision, and consequences of an architectural choice.

Composition: Assembly of independent components into a functioning system.

Platform adapter: A boundary component translating platform-specific APIs into application abstractions.

Dependency inversion: A principle in which high-level policy depends on abstractions rather than low-level implementation details.

Review Questions

Short Answer Questions

1. What is separation of concerns, and why is it valuable in a mobile application?
2. Define a repository and identify two responsibilities it may perform.
3. What is constructor injection?
4. Distinguish a DTO from a domain model.
5. What information should an ADR normally contain?

Long Answer Questions

1. Compare layered architecture and clean architecture, including their dependency rules, benefits, and limitations.
2. Explain how dependency injection and a composition root improve testability in React Native or Flutter.
3. Discuss the advantages and risks of organizing a codebase by vertical feature modules.
4. Explain how offline-first behavior affects repository design, synchronization, and error handling.
5. Evaluate the benefits and governance requirements of using a monorepo for several mobile applications.

Analytical / Application Questions

1. A Flutter screen directly calls an HTTP client, writes to SQLite, and formats server DTOs. Analyze the architectural problems and propose a refactoring sequence.
2. Design a repository and synchronization policy for a mobile banking application. Justify why your policy differs from that of a note-taking application.
3. A shared package is used by four products but causes every product to release together. Decide whether to retain, split, or replace the package, and justify your decision using maintainability and ownership criteria.

Multiple Choice Questions with Answers

Question 1

Which dependency direction best reflects clean architecture?

A. Domain entities depend directly on UI widgets

B. Infrastructure depends on stable inner policies and interfaces

C. Database code imports presentation controllers

D. Use cases depend on a specific navigation library

Correct Answer: B. Infrastructure depends on stable inner policies and interfaces

Question 2

What is the primary purpose of a repository?

A. To render reusable interface components

B. To replace all application error handling

C. To mediate between application logic and data sources

D. To define the mobile operating system lifecycle

Correct Answer: C. To mediate between application logic and data sources

Question 3

Which dependency-injection approach makes required dependencies most visible?

A. Constructor injection

B. A global service locator used inside every method

C. A mutable global variable

D. Hidden property lookup

Correct Answer: A. Constructor injection

Question 4

What is a composition root?

A. A database table containing root records

B. A screen displayed after application startup

C. A package containing only UI assets

D. A location where concrete dependencies are assembled

Correct Answer: D. A location where concrete dependencies are assembled

Question 5

Which is the strongest reason to keep a DTO separate from a domain model?

A. DTOs always execute faster

B. The separation protects business concepts from external representation changes

C. Domain models cannot be tested

D. DTOs eliminate the need for repositories

Correct Answer: B. The separation protects business concepts from external representation changes

Question 6

Which organization most directly groups code by business capability?

A. A single global utilities folder

B. Folders containing only models, services, and screens

C. Feature modules containing their own presentation, application, domain, and data code

D. A directory sorted alphabetically by file name

Correct Answer: C. Feature modules containing their own presentation, application, domain, and data code

Question 7

Which policy is characteristic of a local-first synchronization design?

A. All writes are rejected without a network connection

B. Local changes are saved and uploaded when connectivity returns

C. The UI is prohibited from showing cached data

D. The server is never contacted after installation

Correct Answer: B. Local changes are saved and uploaded when connectivity returns

Question 8

What is a major risk of an excessively broad shared package?

A. It prevents any code reuse

B. It makes unit testing impossible

C. It can create unnecessary release coupling among products

D. It automatically removes package ownership

Correct Answer: C. It can create unnecessary release coupling among products

Question 9

Which item is most appropriate for an ADR?

A. Every variable name in a screen

B. A significant decision to adopt cache-first synchronization

C. A temporary debugging print statement

D. A list of all buttons in the design system

Correct Answer: B. A significant decision to adopt cache-first synchronization

Question 10

Which practice most directly improves testing of time-dependent mobile logic?

A. Hard-coding the current system time in every use case

B. Reading time from an injectable clock abstraction

C. Moving all logic into widgets

D. Using a global singleton that cannot be replaced

Correct Answer: B. Reading time from an injectable clock abstraction