What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You can build an Android repository that fetches data from a server without using Room, DataStore, or files on the device. Keep the repository as the app’s data-access boundary, delegate HTTP work to a network data source, and expose app-facing results to the ViewModel. The tradeoff is direct: without local persistence, previously fetched data is unavailable after process death and cannot serve as durable offline content.
What “remote-only” means
Here, remote-only means the Android app does not persist the feature’s data in a local database, DataStore, or files. It does not mean the server has no stored data. It also does not automatically rule out short-lived in-memory state or an HTTP client cache; decide explicitly whether either is permitted by the product requirement.
A repository is an architectural boundary, not a database. Android’s data-layer guidance describes repositories as coordinating zero or more data sources and directs other layers to access data through repositories. For an online-only feature, the repository can depend on a network source alone.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →What you give up without local persistence
- Offline reads: when the device cannot reach the server, the app cannot show previously fetched data from durable local storage.
- Content after process death: in-memory screen state is lost when the app process ends; it is not a persisted cache.
- Durable queued writes: if a user submits a change while offline, the app cannot promise to save it locally and deliver it later without persistent storage.
- Network-independent cold starts: uncached reads require a successful remote request.
Android’s offline-first guidance states: “A repository with network access in an offline-first app must always have a local data source.” That requirement applies when the goal is offline-first behavior. A deliberately online-only feature is a different product choice.
#1 Best Overall
How to structure the repository
Keep transport details in the network source
Put request construction and response handling in a network data source or service. Have the repository depend on that abstraction, map wire models to application models, and translate failures into outcomes the rest of the app can handle. The UI and domain layer should not call the transport directly.
Choose an API that matches the operation
Use a Kotlin suspend function for a one-shot fetch. Use Flow when the source genuinely emits ongoing updates; Flow is an asynchronous stream, not a persistence mechanism, and does not guarantee offline values. Avoid presenting a database-style stream when the only source is a request that completes once.
Rank #2
interface ItemsRepository {
suspend fun fetchItems(): ItemsResult
}
class RemoteItemsRepository(
private val service: ItemsService,
) : ItemsRepository {
override suspend fun fetchItems(): ItemsResult = try {
ItemsResult.Success(service.fetchItems().map(NetworkItem::toDomain))
} catch (error: IOException) {
ItemsResult.NetworkFailure
}
}This is an illustrative shape, not tested, drop-in code. Define an error taxonomy suited to the app, including HTTP and authentication failures. Do not catch coroutine cancellation as an ordinary network error: allow cancellation to propagate so lifecycle-driven cancellation works correctly.
Let the ViewModel own screen state
The ViewModel can expose loading, loaded content, an empty result, and an actionable error with a retry action. Keep this screen state in memory unless the product explicitly permits persistence; do not call it a durable cache.
For refreshable data, make refresh behavior deliberate: decide whether every screen visit triggers a request, whether concurrent requests are deduplicated, and what happens if an older request completes after a newer one. Inject the repository at the app’s composition boundary so tests can supply a fake network source. The architecture does not require a particular dependency-injection framework.
Handle failures and retries deliberately
Present a useful error and retry action when a request fails. Retry transient connectivity or server failures only under bounded conditions. An authorization failure generally needs corrected credentials or user action, not repeated requests. Android’s offline-first guidance identifies error type and maximum retries as considerations; the exact policy depends on the API and feature.
Without local storage, retrying after the app process ends cannot recover a pending write from a durable queue. If reliable eventual delivery of offline writes is a requirement, the strict no-persistence design does not meet it.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhen another storage design is a better fit
| Design | Good fit | Cost or limitation |
|---|---|---|
| Remote-only repository | The feature is intentionally online-only, data is inexpensive to fetch, and local persistence is unnecessary or disallowed. | Uncached reads depend on network access; no durable offline content. |
| In-memory screen state | Reusing a response during the current process or screen session is enough. | State disappears when the process ends and is not a durable cache. |
| Room-backed local source | Data is large, relational, queryable, needs partial updates, or must be available offline. | Requires schema, migration, freshness, and synchronization decisions. |
| DataStore | The requirement is to persist small preferences or settings-like values. | Not intended for large datasets, partial updates, or referential integrity. |
| Paging with network and database | A large paged list needs cached browsing as pages arrive. | Android’s documented pattern relies on a local database cache. |
Android’s data-layer guidance discusses choosing storage by data needs; its DataStore documentation describes an asynchronous coroutine and Flow API for small datasets, while its Room documentation covers local database storage. The network-plus-database Paging pattern is not a fit when local persistence is prohibited.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Make caching and consistency part of the decision
Some network clients can use HTTP caching, but the repository architecture alone does not establish that a client is configured to cache responses. If “no local persistence” also forbids HTTP cache files, configure the networking stack accordingly and verify its behavior. If short-lived memory reuse is allowed, describe its lifetime and invalidation rules honestly.
Authentication behavior, rate limits, backend consistency, and request idempotency are specific to the app and server. Define them in the feature’s request and error-handling policy rather than assuming the repository boundary resolves them.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
