View-model

So the business logic is implemented inside a ViewModel (see Example 2-3). The view-model requires a BillingClient instance to be constructor-injected ³ by some other component - as you’ll see shortly. BillingClient is a dependency of the ViewModel, and PurchaseProvider is a dependency of BillingClient.

The view which interacts with this ViewModel triggers the getUserPurchases method (which we haven’t implemented yet) in the getter of the purchasesLiveData property. You may have noticed that type of purchasesLiveData property is LiveData while the private backing property, _purchases, is a MutableLiveData. This is because the ViewModel should be the sole component to change the value of the LiveData. So the exposed type to clients of this ViewModel is only LiveData.

class PurchasesViewModel internal constructor(
    private val billingClient: BillingClient,
    private val user: String
) : ViewModel() {
    private var _purchases = MutableLiveData<UserPurchases>()

    private fun getUserPurchases(user: String) {
        // TODO: implement
    }

    val purchasesLiveData: LiveData<UserPurchases>
        get() {
            getUserPurchases(user)
            return _purchases
        }

    interface BillingClient { /* removed for brevity*/ }

    interface PurchasesProvider { /* removed for brevity*/ }
}

We’re almost done - now all we’re missing is the view.

View

class PurchasesFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        /* Create a ViewModel the first time this Fragment is created.
         * Re-created Fragment receives the same ViewModel instance after
         * device rotation. */
        val factory: ViewModelProvider.Factory = PurchaseViewModelFactory() 
        val model by viewModels<PurchasesViewModel> { factory }             
        model.purchasesLiveData.observe(this) { (_, purchases) ->           
            // update UI
            println(purchases)
        }
    }
}

Every time the fragment is created, it subscribes to updates of UserPurchases by following three steps:

Create a factory for the ViewModel (remember, the ViewModel has dependencies, and it’s certainly not the responsibility of the Fragment to supply them). Strictly speaking, this factory shouldn’t be created inside the fragment, as the factory is now tightly coupled with your fragment - a PurchasesFragment always uses a PurchaseViewModelFactory. In a test environment, where you should test the view independently, this would be a problem. So this factory should be injected inside the Fragment using either a dependency injection framework or manually injected. For the sake of simplicity, we’ve decided to create it here inside the fragment. For the record, ViewModel factory as shown in Example 2-5.

An instance of PurchasesViewModel is obtained from the viewModels function. This is the recommended way to get a ViewModel instance.

Finally, a LiveData instance is retrieved from the ViewModel, and observed by an Observable instance using the method of the same name (“observe”). In this example, the observer is only a lambda function which prints the list of purchases into the console. In a production application, you would typically trigger an update of all the related views inside the fragment.

A ViewModel also has its own lifecycle. It depends on whether the ViewModel is bound to a fragment or an activity. In this example, it’s bound to a fragment. You can tell that by the use of by viewModels<..>. If we had used by activityViewModels<..> instead, the view-model would have been bound to the activity.

When bound to the fragment, the ViewModel survives device rotations but is destroyed when it isn’t used anymore (e.g when all fragments that were bound to it are destroyed except for device rotation). On the other hand, if the ViewModel had been bound to the activity, the idea would be the same: it would outlive the activity on device rotation but would be destroyed in every other scenario where the activity is destroyed.

If you look at the code of the actual BillingClient of the framework, creating a BillingClient.Builder requires that you supply a context. It can be an activity context, because internally the builder calls context.getApplicationContext() and this is the only context reference kept by the BillingClient. An ApplicationContext remains the same during the whole Application lifetime. Therefore, you won’t create a memory leak by referencing the ApplicationContext somewhere in your app. This is the reason why BillingClient is safe to be referenced inside a ViewModel.

The dependencies of the ViewModel are created inside of PurchaseViewModelFactory:

class PurchaseViewModelFactory : ViewModelProvider.Factory {
    private val provider: PurchasesProvider = PurchasesProviderImpl()
    private val billingClient: BillingClient = BillingClientImpl(provider)
    private val user = "user" // Get in from registration service

    override fun <T : ViewModel?> create(modelClass: Class<T>): T {
        if (modelClass.isAssignableFrom(PurchasesViewModel::class.java)) {
            return PurchasesViewModel(billingClient, user) as T
        }
        throw IllegalArgumentException("Unknown ViewModel class")
    }
}

BillingClientImpl is the real implementation of the previously shown BillingClient interface - see Example 2-6 and Example 2-7.

class BillingClientImpl(private val purchasesProvider: PurchasesProvider) : BillingClient {
    private val executor =
        Executors.newSingleThreadExecutor()

    override fun init(callback: BillingCallback) {
        /* perform asynchronous work here */
        executor.submit {
            try {
                Thread.sleep(1000)
                callback.onInitDone(purchasesProvider)
            } catch (e: InterruptedException) {
                e.printStackTrace()
            }
        }
    }
}

class PurchasesProviderImpl : PurchasesProvider {
    private val executor =
        Executors.newSingleThreadExecutor()

    override fun fetchPurchases(
        user: String,
        callback: PurchaseFetchCallback
    ) {
        /* perform asynchronous work */
        executor.submit {
            try {
                // Simulate blocking IO
                Thread.sleep(1000)
                callback.onPurchaseFetchDone(
                    listOf("Purchase1", "Purchase2")
                )
            } catch (e: InterruptedException) {
                e.printStackTrace()
            }
        }
    }
}

To conform to the application design that we established, the init and fetchPurchases methods should be non-blocking. This can be achieved with a background thread. For efficiency reasons (see the upcoming section), you may not want to create a new thread every time you connect to the BillingClient. So you can use a thread pool, which can be created using ThreadPoolExecutor instances directly, or many common configurations are available via the java.util.concurrent.Executors’s factory methods. Using Executors.newSingleThreadExecutor(), you have a single dedicated thread at your disposal which can be reused for each asynchronous calls. You might think that BillingClientImpl and PurchasesProviderImpl should share the same thread pool. It’s up to you - though we didn’t do it for brevity. For a production app, you may have a multiple ThreadPoolExecutors that service different parts of your app.

If you look at how callbacks are used in those implementations, you can see that they’re called right after Thread.sleep() (which simulates a blocking IO call). Unless explicitly posted to the main thread (generally through an instance of the Handler class, or through a LiveData instance’s postValue method), callbacks are invoked within the context of the background thread. This is critical and it’s very important to be aware of how to communicate between thread contexts, as you’ll see in the next section.

Implement the logic

Now that all necessary components are set in place, the logic can be implemented. The steps are:

private fun getUserPurchases(user: String) {
   billingClient.init { provider ->                   
       // this is called from a background thread
       provider?.fetchPurchases(user) { purchases ->  
           _purchases.postValue(UserPurchases(user, purchases))
       }
   }
}

Call BillingClient.init and supply a callback which will be called whenever the client’s initialization process finishes. Only if the client supplies a non-null PurchasesProvider instance, proceed with the next step.

At this point you have PurchasesProvider instance ready for use. Then call fetchPurchases, providing the current user as the first parameter, and the callback that should be executed once the provider has done its job. Look carefully the content of the callback:

_purchases.postValue(UserPurchases(user, purchases))

On a MutableLiveData instance, you either use the setValue or the postValue method. The difference between the two is that you’re only allowed to use setValue if you’re calling it from the main thread. When this isn’t the case, using postValue adds the new value into a queue that the MutableLiveData will process on the next frame of the main thread. This is an implementation of the work queue pattern (see chapter #), and a thread-safe way to assign a new value to a MutableLiveData.

Discussion

So this is it. It works - or at least, it fulfills the specifications. Now, we invite you to step back a little and look at the big picture. What is the structure of getUserPurchases? It’s made of a function call, which is provided another function which itself calls a function which is provided another function… It’s like russian dolls. Already a little hard to follow, after add exception handling this can quickly become “nesting hell”. In order to keep our example logic simple and easy to follow, we’ve obmited corner cases where some api calls fail; for example, networking issues or authorization errors make some I/O background work brittle and prone to failure, and production code should be able to handle this.

Figure 2-2. Callback usage

The code which specifies what happens upon a response of the BillingClient (callback 2) is included in the code of the first callback. If you decide to inline all this code, like we did in Example 2-8, you have several levels of indentations, which rapidly grows as the problem to solve becomes more complex. On the other hand, if you decide to encapsulate the first callback into its own function, you will indeed reduce the indentation level of getUserPurchases and its apparent complexity. At the same time, you would increase the number of directions to follow to fully understand the business logic.

This is the first drawback of code using callbacks. It rapidly becomes complex, and may become hard to maintain, if not administered with caution and thoughtful design. Some would consider that even with careful precautions this path is dangerous. As developers, we strive to create a system that we and our coworkers can handle.

private void getUserPurchases(String user) {
    billingClient.initAsync()
    .thenCompose { provider ->
        fetchPurchasesAsync(provider, user)
    }
    .thenAccept { purchases ->
        this.purchases.postValue(...)
    }
}

Structured concurrency

Imagine now that some API calls are quite expensive computationally. For example, a user of your app navigates to a view which triggers some of those API calls, but as the content isn’t loading instantly they lose patience and tap back, and starts some new series of operations in another part of the app. In this situation, you don’t want your expensive API calls to continue running, as they may put unnecessary load on your backend servers, or even on the application itself. Further, what happens if a UI that should be updated when a callback fires no longer exists? A NullPointerException is probably your best case, and a memory leak your worst. Instead, let’s cancel the procedure initialized inside the view-model. How would you do that? You would have to listen to a particular lifecycle event of the fragment lifecycle termination events: onStop, onPause, or onDestroy. In this specific case, you’d probably want to do that inside onStop, which would be fired just before resources are reclaimed. onPause would fire each time the application was background in favor of an incoming call or when switching between apps, and onDestroy happens a little later than we need. When onStop event fires, you should notify the view-model that it should stop any background processing. This requires a thread-safe way of interrupting threads. A volatile isCancelled boolean would be checked inside the callbacks to decide whether they should proceed or not. So it’s definitely possible, but cumbersome and fragile.

What if this cancellation was done automatically? Imagine that the background processing was tied to the lifecycle of the view-model. The moment that the view-model is destroyed, all background processing gets cancelled. It’s not a fairy tale - it even has a name: structured concurrency.

Memory leaks

Automatically cancelling dangling background threads also has another benefit: reducing the risk of memory leak. A callback might hold a reference on a component which either has a lifecycle, or is a child of a component which has one. If this component is eligible to garbage collection, while a reference of that component exists in some running thread, the memory can’t be reclaimed, and you have a memory leak. Using LiveData like in the previous example is safe even if you don’t cancel background tasks. Nevertheless, more generally speaking, it’s never good to let tasks running for nothing.

Cancellation isn’t the only possible thing that can go wrong. There are other pitfalls to using threads as primitives for asynchronous computations (which we’ll refer to as the threading model), which we’ll cover into the next section.