DEV Community

Cover image for Calling onResume() from your ViewModel in Android.
Tristan Elliott
Tristan Elliott

Posted on • Updated on

Calling onResume() from your ViewModel in Android.

Table of contents

  1. The problem I am solving
  2. Solution
  3. Lifecycle observer
  4. LifecycleOwner
  5. Making it work
  6. Removing the observer

My app on the Google Playstore

GitHub code

The problem I am trying to solve

  • So as I am integrating a subscription into my Android app, there is a particular line of the documentation that stands out when talking about Fetching Purchases:

To handle these situations, be sure that your app calls BillingClient.queryPurchasesAsync() in your onResume() method to ensure that all purchases are successfully processed as described in processing purchases.

  • Which brings up the problem of , how and where do I call the onResume() method.

The solution

  • The two main ways I have discovered to handle this are:

1) Side-effect : using DisposableEffect to call onResume() in your compose code

2) Lifecycle observer : creating a DefaultLifecycleObserver to call onResume() inside of my ViewModel (I chose this version)

2) Lifecycle observer

  • Now when we say we are going to create a Lifecycle observer, we are saying we are creating a class that will observe the Android lifecycle of a certain component(like Activity of Fragment). There are two parts to a lifecycle observer, 1) the lifecycle observer and 2) the lifecycle owner.

  • In order to create a Lifecycle observer we need to have a class implement the DefaultLifecycleObserver interface, like so:

class BillingViewModel(): ViewModel(),DefaultLifecycleObserver {

 override fun onResume(owner: LifecycleOwner) {
       // do whatever you want
       refreshPurchases()
    }
}

Enter fullscreen mode Exit fullscreen mode
  • By implementing the DefaultLifecycleObserver we have given our ViewModel access to a LifecycleOwner's methods like onResume() and the Android library will now recognize instances of BillingViewModel as a Lifecycle observer.

  • But now we need to attach our Lifecycle observer to a LifecycleOwner

LifecycleOwner

  • A class is considered a LifecycleOwner if it implements the LifecycleOwner interface. In my code I am using Fragments and according to the documentation Fragment implements a LifecycleOwner interface.

  • So now that we have a LifecycleOwner (Fragment) and a LifecycleObserver(BillingViewmodel) we need to attach them.

Making it work

  • So inside my Fragment looks something like this:
class SubscriptionFragment : Fragment() {

    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {



        val billingViewModel:BillingViewModel by viewModels()

        // THIS IS WHERE WE ARE CONNECTING THE TWO
        lifecycle.addObserver(billingViewModel)

   }

Enter fullscreen mode Exit fullscreen mode
  • The code that adds the observer to the owner is lifecycle.addObserver(billingViewModel). Which now gives our ViewModel access to the Fragment's lifecycle methods

  • I would also like to point out, viewModels() means that this particular ViewModel will be scoped to the closes ViewModelStoreOwner which in my case is the fragment. If you want to read more about ViewModel scoping I would recommend THIS resource

  • The term scoped/scoping means that the ViewModel will live as long as the item it is scoped to

Removing the observer

  • You might of noticed that I have not removed the observer... curious right? I have even read tutorials like, this one HERE, removing the observer. However, I found This section of documentation stating:

An observer added with a Lifecycle will be automatically removed if the corresponding Lifecycle moves to DESTROYED state.

  • So I have decided to not remove the observer manually and let the Android system handle it.

Conclusion

  • Thank you for taking the time out of your day to read this blog post of mine. If you have any questions or concerns please comment below or reach out to me on Twitter.

Top comments (0)