Doing PurchasingManager.registerObserver in multiple activities? Possible
Hi, The way I've setup my app is that I call the: PurchasingManager.registerObserver in the Splash activity of my app, where all the Paid Items are validated (using: initiateItemDataRequest) and user's purchases are restored using: onPurchaseUpdatesResponseSuccess and then the Splash activity finishes and loads the Home activity. There inside the Home activity I call PurchasingManager.registerObserver again as in this activity user will carry out the purchases. I've a few questions regarding this setup: 1. Is it valid? Since no where in the documentation it's mentioned that you should do PurchasingManager.registerObserver multiple times. But since my Splash activity finishes -- am I fine? 2. Using the above setup, sometimes the app would crash in the Home activity as the currentUser becomes NULL. Could it be due to this reason? 3. Any alternatives if I want to validate the items + restore users purchases in the Splash activity? Thanks.
Could it be due to this reason that while Home starts, the Splash activity is still not stopped completely And, upon calling the initiateGetUserIdRequest() from the Home activity -- it's response is directed to the old receiver which is about to die and hence I get a NULL currentUser in the new activity? Thanks.
Thank you for your post and sorry for taking time to answer your query. You should not have multiple observer in your app. In fact, only one observer is referred always in IAP SDK. So when you re register SDK with other observer, the first one is gone. Solutions: 1. Register the observer in the activity which represents the IAP catalog. 2. We know there is an Application class in the Android api and according to the class name it's used for global settings or running entrance. In the Android reference it describes the Application class: "Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created." So if you adopt Application class in your app then there is no harm of having a single PurchasingObserver at the application level. Having that, you could always call IAP methods to PurchasingManager from a storefront activity and after getting response in observer you should be able to broadcast events to notify the target activity to take UI actions. This way you should be able to avoid race condition as you mentioned above. This is true that there is no unregister call available to deregister the current observer from ParchasingManager. But you could call register with a null value to effect a deregister of the listener. After you do it, there will be no reference to that object from IAP SDK. So in next GC cycle it is supposed to be garbage collected.