Proxy & Facade: Cache Gates and Thin ViewModels

Part 3 of 8 GoF Patterns That Decide If Your Android App Scales

Proxy — Cache + Retry, Invisible to Callers

The Proxy pattern provides a substitute for another object, controlling access to it. In Android: your Repository is a Proxy. The ViewModel asks for data; the Repository decides whether to return it from memory, disk, or the network.

The caller never knows which one.

Without Proxy — ViewModels Doing Too Much

1
// ViewModel shouldn't know about caching, retries, or network state
2
class UserProfileViewModel(private val api: UserApi) : ViewModel() {
3

4
    fun loadUser(id: String) {
5
        viewModelScope.launch {
6
            // Cache logic in ViewModel? Retry logic? No.
7
            if (memoryCache.contains(id)) {
8
                _uiState.value = UiState.Content(memoryCache[id]!!)
9
                return@launch
10
            }
11
            try {
12
                val user = api.getUser(id)
13
                memoryCache[id] = user
14
                _uiState.value = UiState.Content(user)
15
            } catch (e: Exception) {
16
                // Do we retry? How many times? The ViewModel shouldn't decide.
17
                _uiState.value = UiState.Error(e.message)
18
            }
19
        }
20
    }
21
}

This ViewModel knows about caching, retry policy, and network errors. Change any infrastructure detail and you edit business logic.

Proxy: Repository as Cache Gate

1
interface UserRepository {
2
    suspend fun getUser(id: String): Result<User>
3
}

1
class UserRepositoryImpl(
2
    private val api: UserApi,
3
    private val cache: UserCache,
4
    private val dispatcher: CoroutineDispatcher = Dispatchers.IO
5
) : UserRepository {
6

7
    override suspend fun getUser(id: String): Result<User> =
8
        withContext(dispatcher) {
9
            // 1. Memory hit — instant return
10
            cache.get(id)?.let { return@withContext Result.success(it) }
11

12
            // 2. Network with retry — caller never sees this
13
            retry(times = 3, delayMs = 1000) {
14
                api.getUser(id)
15
            }.also { result ->
16
                result.getOrNull()?.let { cache.put(id, it, ttlMs = 300_000) }
17
            }
18
        }
19
}

1
// Retry helper — pure function, easy to test
2
suspend fun <T> retry(
3
    times: Int,
4
    delayMs: Long = 500,
5
    block: suspend () -> T
6
): Result<T> {
7
    repeat(times - 1) { attempt ->
8
        runCatching { block() }
9
            .onSuccess { return Result.success(it) }
10
        delay(delayMs * (attempt + 1))  // Exponential backoff
11
    }
12
    return runCatching { block() }
13
}

1
// ViewModel is now clean
2
class UserProfileViewModel(private val repo: UserRepository) : ViewModel() {
3

4
    fun loadUser(id: String) {
5
        viewModelScope.launch {
6
            _uiState.value = UiState.Loading
7
            repo.getUser(id)
8
                .onSuccess { _uiState.value = UiState.Content(it) }
9
                .onFailure { _uiState.value = UiState.Error(it.message) }
10
        }
11
    }
12
}

The ViewModel has no idea about cache, retry, or network state. Swap UserRepositoryImpl for an offline-first Room-backed version — the ViewModel changes nothing.

Offline-First Proxy with Room + Network

1
class UserRepositoryImpl(
2
    private val api: UserApi,
3
    private val dao: UserDao
4
) : UserRepository {
5

6
    override suspend fun getUser(id: String): Result<User> =
7
        withContext(Dispatchers.IO) {
8
            runCatching {
9
                // Try local DB first
10
                dao.getUser(id)?.let { return@runCatching it }
11

12
                // Hit network, persist result
13
                api.getUser(id).also { dao.upsert(it) }
14
            }
15
        }
16

17
    // Room Flow — auto-updates when DB changes
18
    fun observeUser(id: String): Flow<User?> = dao.observeUser(id)
19
}

Facade — One Call Hides Five Use Cases

The Facade pattern provides a simplified interface to a complex subsystem. In Android: your feature API is a Facade. The ViewModel calls one method; the Facade coordinates multiple services underneath.

The Problem: Fat ViewModels

1
// ViewModel orchestrating everything — a common anti-pattern
2
class CheckoutViewModel(
3
    private val cartRepo: CartRepository,
4
    private val paymentService: PaymentService,
5
    private val inventoryService: InventoryService,
6
    private val analyticsService: AnalyticsService,
7
    private val notificationService: NotificationService
8
) : ViewModel() {
9

10
    fun checkout(userId: String) {
11
        viewModelScope.launch {
12
            val cart = cartRepo.getCart(userId)
13
            val reserved = inventoryService.reserve(cart.items)
14
            if (!reserved) { /* handle */ return@launch }
15
            val result = paymentService.charge(cart.total, userId)
16
            analyticsService.track("checkout_completed", mapOf("total" to cart.total))
17
            notificationService.sendConfirmation(userId)
18
            // ... and it keeps growing
19
        }
20
    }
21
}

This ViewModel has 5 dependencies and knows the entire checkout choreography. Every new business rule adds a line here.

Facade: Feature API

1
// The Facade — one interface, one responsibility
2
interface CheckoutFacade {
3
    suspend fun checkout(userId: String): Result<CheckoutReceipt>
4
}

1
class CheckoutFacadeImpl(
2
    private val cartRepo: CartRepository,
3
    private val paymentService: PaymentService,
4
    private val inventoryService: InventoryService,
5
    private val analyticsService: AnalyticsService,
6
    private val notificationService: NotificationService
7
) : CheckoutFacade {
8

9
    override suspend fun checkout(userId: String): Result<CheckoutReceipt> =
10
        runCatching {
11
            val cart = cartRepo.getCart(userId)
12

13
            check(inventoryService.reserve(cart.items)) {
14
                "Items not available"
15
            }
16

17
            val receipt = paymentService.charge(cart.total, userId)
18

19
            // Fire-and-forget side effects
20
            coroutineScope {
21
                launch { analyticsService.track("checkout_completed", cart.toMap()) }
22
                launch { notificationService.sendConfirmation(userId, receipt) }
23
            }
24

25
            receipt
26
        }
27
}

1
// ViewModel has ONE dependency — stays thin
2
class CheckoutViewModel(private val checkout: CheckoutFacade) : ViewModel() {
3

4
    fun checkout(userId: String) {
5
        viewModelScope.launch {
6
            _uiState.value = CheckoutUiState.Processing
7
            checkout.checkout(userId)
8
                .onSuccess { _uiState.value = CheckoutUiState.Success(it) }
9
                .onFailure { _uiState.value = CheckoutUiState.Error(it.message) }
10
        }
11
    }
12
}

New business rule (loyalty points, fraud check, referral tracking)? Add it to CheckoutFacadeImpl. The ViewModel never changes.

Testing the Facade

1
@Test
2
fun `checkout success updates state to Success`() = runTest {
3
    val fakeFacade = object : CheckoutFacade {
4
        override suspend fun checkout(userId: String) =
5
            Result.success(CheckoutReceipt(id = "receipt_123", total = 99.0))
6
    }
7

8
    val viewModel = CheckoutViewModel(checkout = fakeFacade)
9
    viewModel.checkout("user_1")
10

11
    assertThat(viewModel.uiState.value).isInstanceOf(CheckoutUiState.Success::class.java)
12
}

One-line fake, no mocking framework needed. That’s the payoff.

Proxy + Facade in the Same Architecture

1
ViewModel
2
   │
3
   └── CheckoutFacade          ← Facade: hides complexity
4
         │
5
         ├── CartRepository    ← Proxy: cache gate
6
         ├── PaymentService
7
         ├── InventoryService  ← Proxy: cache gate
8
         └── AnalyticsService

The ViewModel talks to the Facade. The Facade orchestrates Proxies. Neither layer knows the other’s implementation details.

Next Up

Part 4: Adapter & Factory → — how to swap any SDK in a single file, and how to build sources that are mockable from day one.