After correctly configuring the BillingClient as in the documentation onBillingSetupFinished is not called.
//...
billingClient = BillingClient.newBuilder(this)
.setListener(purchaseUpdateListener)
.enablePendingPurchases()
.build();
//billingClient != null
billingClient.startConnection(new BillingClientStateListener() {
#Override
public void onBillingSetupFinished(BillingResult billingResult) {
//This is not called
}
#Override
public void onBillingServiceDisconnected() {
//This is not called
}
});
//...
It only happens on some devices.
Some Chinese devices, like the one I have (BV9900). They have a clean button when you press and hold home that not only closes all apps, but also completely closes all apps and services, including Google's.
By preventing any app from running in the background, this disables in-app purchases. The solution in this case is to open the Play Store in Intent to start the services again.
Related
I was wondering could you help. I followed the instructions at https://developer.android.com/google/play/billing/integrate, but I cannot seem to get the purchase flow working. The billing seems to setup ok, but when I try to query for my in-app products, the list is always returning empty. Can someone please help?
In my app level build.gradle file, I have included the Google Billing SDK:
implementation 'com.android.billingclient:billing:3.0.0'
Then I have created an activity to test out the code. It first initialises the BillingClient and starts the connection. The connection seems to finish the setup correctly. Once setup correctly, I then try to query the products that I have available in my Google Play Console under 'Store presence' > 'In-app products' > 'Manage products'
The following is then the code in the Activity that should kick off the process and return the SkuDetails list, but unfortunately it is returning back empty.
private BillingClient billingClient;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_billing);
this.billingClient = BillingClient.newBuilder(this)
.enablePendingPurchases()
.setListener(this.purchaseUpdateListener)
.build();
this.billingClient.startConnection(billingClientStateListener);
}
private PurchasesUpdatedListener purchaseUpdateListener = new PurchasesUpdatedListener() {
#Override
public void onPurchasesUpdated(#NonNull BillingResult billingResult, #Nullable List<Purchase> list) {
Log.d("Billing", "onPurchasesUpdated - List Size: " + list.size());
}
};
private BillingClientStateListener billingClientStateListener = new BillingClientStateListener() {
#Override
public void onBillingSetupFinished(#NonNull BillingResult billingResult) {
if (billingResult.getResponseCode() == BillingClient.BillingResponseCode.OK) {
Log.d("Billing", "onBillingSetupFinished - OK");
queryProducts();
} else {
Log.d("Billing", "onBillingSetupFinished - Something wrong response Code: " + billingResult.getResponseCode());
}
}
#Override
public void onBillingServiceDisconnected() {
Log.d("Billing", "Service disconnected");
}
};
private void queryProducts() {
List<String> productIdsList = new ArrayList<>();
productIdsList.add("test.billing.001");
SkuDetailsParams.Builder params = SkuDetailsParams.newBuilder();
params.setSkusList(productIdsList).setType(BillingClient.SkuType.INAPP);
this.billingClient.querySkuDetailsAsync(params.build(), new SkuDetailsResponseListener() {
#Override
public void onSkuDetailsResponse(#NonNull BillingResult billingResult, #Nullable List< SkuDetails > list) {
Log.d("Billing", "onSkuDetailsResponse - List Size: " + list.size());
}
});
}
So for anyone who is having similar issues, it seems that (well in my case anyways) that my app needed to be successfully published before I could retrieve the in-app products from the app. Once my app was published, I was then able to query and use the in-app products.
According to Maxim Alov comment for Billing 5.0.0, the problem is in invitations for testers.
My steps to fix this problem:
Open tester's invitation link and accept
Open app via link from previous step
After two these steps (in my case second helped) all products started to come
I'm using billing-lib-5.0.0 and also had the same issue -
queryProductDetails() was always empty on my release builds, let alone
debug builds. I'd actually added all my test gmail emails to list of
testers for Closed Testing, and also LICENSED all of them. No effect.
Eventually, I recognized that the link to my test app is not generated
on Play Console Closed Testing track page. I recreated the track, this
time for Internal Testing, and the link has appeared. Then I logged in
to each of my gmails and accepted to be a tester from that link. After
doing that, products started to come, in IDE
I am using google play subscription services for my app.But when any use or customer tries to pay for my subscription with any given payment method.It shows -
Unavailable for this purchase.
Only I can pay with Google play account money.
I tried all method on different mobiles. But problem is same.
I am using standard code given on google developers site.
private BillingClient billingClient=BillingClient.newBuilder(activity)
.setListener(this).build();
billingClient.startConnection(new BillingClientStateListener() {
#Override
public void onBillingSetupFinished(BillingResult billingResult) {
if (billingResult.getResponseCode() == BillingResponse.OK) {
}
}
#Override
public void onBillingServiceDisconnected() {
}
});
I want to enable all payment methods for my app.
Try to add enablePendingPurchases(), so
private BillingClient billing_client = BillingClient.newBuilder( this ).enablePendingPurchases().setListener(...
I am developing an application which will allow user to purchase using In App Purchase and I want to remove ads after purchase. I can purchase succesfully with code below
BillingFlowParams flowParams = BillingFlowParams.newBuilder()
.setSku("android.test.purchased")
.setType(BillingClient.SkuType.INAPP)
.build();
mBillingClient.launchBillingFlow(getActivity(), flowParams);
But I cannot see the result from queryPurchaseHistoryAsync when I open app again and call this method below.
mBillingClient.queryPurchaseHistoryAsync(BillingClient.SkuType.INAPP, new PurchaseHistoryResponseListener() {
#Override
public void onPurchaseHistoryResponse(int responseCode, List<Purchase> purchasesList) {
purchasesList.size();
}
});
purchasesList.size() == 0
Is "queryPurchaseHistoryAsync" method cannot show test purchase or Am I doing something wrong?
Edit: Is queryPurchaseHistoryAsync method check purchase after delete and install app again.
Yes queryPurchaseHistoryAsync method check purchase after deleting and installing the app again against particular user
mBillingClient.queryPurchaseHistoryAsync(BillingClient.SkuType.INAPP, new PurchaseHistoryResponseListener() {
#Override
public void onPurchaseHistoryResponse(#NonNull BillingResult billingResult, #Nullable List<PurchaseHistoryRecord> list) {
}
});
Try this it will give all purchase items.
mBillingClient.querySkuDetailsAsync(params.build(),
new SkuDetailsResponseListener() {
#Override
public void onSkuDetailsResponse(int responseCode, List<SkuDetails> skuDetailsList) {
listener.onSkuDetailsResponse(responseCode, skuDetailsList);
}
});
mBillingClient.queryPurchases() is all you need. Call it at every app start and, for example, every time your main activity resumes. This way your (reinstalled) app will eventually detect all user's purchases.
What would be a good/recommended way of tying up the Google+ api client life cycle with the flow of a multi-activity app? Make the activities depend on the onConnected api client method to trigger its functionality, use it as a one-time only "activation" thing, or maybe something else entirely?
I am currently struggling to understand how to correctly use the Google+ sign in in my Android app, which has more than one activity.
The idea is, in a first phase, to use the G+ sign in just to authenticate the user and be able to get her email, to send notifications and stuff like that. Eventually I plan to roll out other Google functionality like maybe Maps or other Google Play services, so I think it's useful to implement it already.
However, my app is not behaving as expected, and I have narrowed down the issue to the fact that I have not yet understood the G+ sign in app cycle when more than one activity is present.
What is the correct or recommended way to implement this auth method? is there maybe a pattern of sorts that could guide me in the right direction?
For example, I have found a very simple diagram of the life cycle of the api client, but how does this relate to the app flow?
Initially I have a Login Activity, where I put the sign in button. Following Google's guide I am able to sign in, and when the onConnected method is called, I start the Home Activity (kinda like the dashboard or main screen of the app).
This works somewhat. For example, what would be a good way of handling the onStart and onStop for each activity? should I re-connect and re-authenticate the api client every time for every activity? So maybe its a good idea to have a BaseActivity to implement all this.
Another issue is, should I use the same api client object and pass it around somehow, or maybe store it in the Base Activity class? or should I be creating and initializing a new api client object every time?
How about just using the Login Activity to authenticate with G+ and then just get the email and store it in a local database, and flag the user as "authenticated" or "active" or something. That would prevent me from having to re-authenticate every time the app is closed or connection is suspended, even allowing for some battery savings.
The app is not really using G+ posting or any other functionality like that. Ideally it should work well offline, and only need connection for stuff like initial authentication or other one-time only things.
Any suggestions or pointers in the right direction are very much appreciated.
Edit: I have read every guide and tutorial I could find, that uses Google+, and every one of them addresses this from a single activity perspective. I would think this is a common enough problem that it would benefit from a pattern or at least a general guideline.
Reconnecting for each activity is absolutely fine. Broadly there are 3 ways I've seen of people implementing this:
Implement mostly in a baseactivity, and have the others extend that. This is connect/disconnect in each activity, but with code in only one place.
Implement connect/disconnect in a fragment, and include that in activities where auth is needed. This is helpful if you already have a baseactivity you can't extend (e.g. some games cases).
Implement a service to connect/disconnect. This can fire a broadcastintent or similar if sign in is required.
All of these work, and I've seen them all used in real world apps. The main thing to remember is to separate the 99% logic (user is either signed in or signed out, and you are being informed of that) from the relatively rare "signing in at this present moment" use-case. So for example, you might have onConnected/onConnection failed firing a lot, but mostly you are ignoring or just flipping a bit as to the state of the application. Only on a screen with a login button do you need the connection result resolution and onActivityResult stuff. Think of the google play services connection as being mostly about asking for the state of the user, rather than signing them in, and you should be fine.
I agree with Ian Barber's answer but to explain a little further, your Activitys should be considered in two types - Activitys that resolve sign in, and Activitys that require sign in.
Most Activitys do not concern themselves with authenticating the user and will have the same logic in your app. They will create a GoogleApiClient, which connects to the Google Play services process running on the device and reads the cached sign-in state of the user - returning onConnected() if the user is signed in, and onConnectionFailed() if not. Most of your Activitys will want to reset your application state and start your LoginActivity if the user was not signed in. Each Activity should maintain its own instance of GoogleApiClient since it is a lightweight object used to access the shared state held by the Google Play services process. This behaviour could, for example, be encapsulated in a shared BaseActivity class or a shared SignInFragment class, but each instance should have its own GoogleApiClient instance.
Your LoginActivity needs to be implemented differently however. It should also create a GoogleApiClient, but when it receives onConnected() indicating the user is signed in, it should start an appropriate Activity for the user and finish(). When your LoginActivity receives onConnectionFailed() indicating the user is not signed in, you should attempt to resolve sign in issues with startResolutionForResult().
0. TL;DR
For the impatient coder, a working version of the following implementation can be found on GitHub.
After rewriting the login activity code several times in many different apps, the easy (and not so elegant) solution was create the Google API client as a Application class object. But, since the connection state affect the UX flow, I never was happy about with this approach.
Reducing our problem only to the connection concept, we may consider that:
It hides the Google API client.
It has finite states.
It is a (rather) unique.
The current state affect the behavior of the app.
1. Proxy Pattern
Since the Connection encapsulates the GoogleApiClient, it will implement the ConnectionCallbacks and OnConnectionFailedListener:
#Override
public void onConnected(Bundle hint) {
changeState(State.OPENED);
}
#Override
public void onConnectionSuspended(int cause) {
changeState(State.CLOSED);
connect();
}
#Override
public void onConnectionFailed(ConnectionResult result) {
if (currentState.equals(State.CLOSED) && result.hasResolution()) {
changeState(State.CREATED);
connectionResult = result;
} else {
connect();
}
}
Activities can communicate to the Connection class through the methods connect, disconnect, and revoke, but their behaviors are decided by the current state. The following methods are required by the state machine:
protected void onSignIn() {
if (!googleApiClient.isConnected() && !googleApiClient.isConnecting()) {
googleApiClient.connect();
}
}
protected void onSignOut() {
if (googleApiClient.isConnected()) {
Plus.AccountApi.clearDefaultAccount(googleApiClient);
googleApiClient.disconnect();
googleApiClient.connect();
changeState(State.CLOSED);
}
}
protected void onSignUp() {
Activity activity = activityWeakReference.get();
try {
changeState(State.OPENING);
connectionResult.startResolutionForResult(activity, REQUEST_CODE);
} catch (IntentSender.SendIntentException e) {
changeState(State.CREATED);
googleApiClient.connect();
}
}
protected void onRevoke() {
Plus.AccountApi.clearDefaultAccount(googleApiClient);
Plus.AccountApi.revokeAccessAndDisconnect(googleApiClient);
googleApiClient = googleApiClientBuilder.build();
googleApiClient.connect();
changeState(State.CLOSED);
}
2. State Pattern
This is a behavioral pattern the allow an object to alter its behavior when its internal state changes. The GoF Design Patterns book describes how a TCP connection can be represent by this pattern (which is also our case).
A state from a state machine should be a singleton, and the easiest away of doing it in Java was to create Enum named State as follows:
public enum State {
CREATED {
#Override
void connect(Connection connection) {
connection.onSignUp();
}
#Override
void disconnect(Connection connection) {
connection.onSignOut();
}
},
OPENING {},
OPENED {
#Override
void disconnect(Connection connection) {
connection.onSignOut();
}
#Override
void revoke(Connection connection) {
connection.onRevoke();
}
},
CLOSED {
#Override
void connect(Connection connection) {
connection.onSignIn();
}
};
void connect(Connection connection) {}
void disconnect(Connection connection) {}
void revoke(Connection connection) {}
The Connection class holds the context, i.e. the current state, which defines how the Connection methods connect, disconnect, and revoke will behave:
public void connect() {
currentState.connect(this);
}
public void disconnect() {
currentState.disconnect(this);
}
public void revoke() {
currentState.revoke(this);
}
private void changeState(State state) {
currentState = state;
setChanged();
notifyObservers(state);
}
3. Singleton Pattern
Since there is not need to recreate this class repeatedly, we provide it as a singleton:
public static Connection getInstance(Activity activity) {
if (null == sConnection) {
sConnection = new Connection(activity);
}
return sConnection;
}
public void onActivityResult(int result) {
if (result == Activity.RESULT_OK) {
changeState(State.CREATED);
} else {
changeState(State.CLOSED);
}
onSignIn();
}
private Connection(Activity activity) {
activityWeakReference = new WeakReference<>(activity);
googleApiClientBuilder = new GoogleApiClient
.Builder(activity)
.addConnectionCallbacks(this)
.addOnConnectionFailedListener(this)
.addApi(Plus.API, Plus.PlusOptions.builder().build())
.addScope(new Scope("email"));
googleApiClient = googleApiClientBuilder.build();
currentState = State.CLOSED;
}
4. Observable Pattern
The Connection class extends Java Observable, so 1 or more activities can observe the state changes:
#Override
protected void onCreate(Bundle bundle) {
connection = Connection.getInstance(this);
connection.addObserver(this);
}
#Override
protected void onStart() {
connection.connect();
}
#Override
protected void onDestroy() {
connection.deleteObserver(this);
connection.disconnect();
}
#Override
protected void onActivityResult(int request, int result, Intent data) {
if (Connection.REQUEST_CODE == request) {
connection.onActivityResult(result);
}
}
#Override
public void update(Observable observable, Object data) {
if (observable != connection) {
return;
}
// Your presentation logic goes here...
}
I'm developing an application in which i have integrated google plus. So far Its working fine, I am able to retrieve the user profile.
But now i want to do the following:
1)I have two activity signInActivity and shareActivity.
2)If user is already signin using signInActivity then it should not ask for signin again in
shareActivity and should directly share the content.
3)If user is not signedin in the signInActivity and try to share data using shareActivitythen app should signin the user and then only share the data. In this case if user goes back to the signInActivity then app should show that "you have already signedin"
In short i want user signin to be Central within application so that if it is alrady signedin it should be accessible from any activity.
I have heard about the access token but i dont know how to use it and document says that it expires in an hour which is not what i want.
How can i make central google plus signin? is it possible? or i need to authenticate user in each activity?
Managing a separate instance of GoogleApiClient in each activity will not result in the user being asked to sign in multiple times.
Google+ Sign-in (ie. GoogleApiClient) provides an interface to the Google accounts on the device and the Google Play services core service - it doesn't have state per GoogleApiClient instance. So once a device account has been authenticated for your app, new instances of GoogleApiClient will access the same state. GoogleApiClient is specifically designed to be a lightweight way to access the central state managed by Google Play services.
You're in luck regarding access tokens! Google Play services takes care of all token management for you. So although access tokens only last for one hour, as you say, if you try to use your PlusClient to access a Google API and your access token has expired, Google Play services will transparently request a new access token for you and complete the call.
Take a look at the first part of this Google I/O talk for more details:
http://www.youtube.com/watch?v=_KBHf1EODuk
0. TL;DR
For the impatient coder, a working version of the following implementation can be found on GitHub. This is the same answer written on another Stack Overflow post.
After rewriting the login activity code several times in many different apps, the easy (and not so elegant) solution was create the Google API client as a Application class object. But, since the connection state affect the UX flow, I never was happy about with this approach.
Reducing our problem only to the connection concept, we may consider that:
It hides the Google API client.
It has finite states.
It is a (rather) unique.
The current state affect the behavior of the app.
1. Proxy Pattern
Since the Connection encapsulates the GoogleApiClient, it will implement the ConnectionCallbacks and OnConnectionFailedListener:
#Override
public void onConnected(Bundle hint) {
changeState(State.OPENED);
}
#Override
public void onConnectionSuspended(int cause) {
changeState(State.CLOSED);
connect();
}
#Override
public void onConnectionFailed(ConnectionResult result) {
if (currentState.equals(State.CLOSED) && result.hasResolution()) {
changeState(State.CREATED);
connectionResult = result;
} else {
connect();
}
}
Activities can communicate to the Connection class through the methods connect, disconnect, and revoke, but their behaviors are decided by the current state. The following methods are required by the state machine:
protected void onSignIn() {
if (!googleApiClient.isConnected() && !googleApiClient.isConnecting()) {
googleApiClient.connect();
}
}
protected void onSignOut() {
if (googleApiClient.isConnected()) {
Plus.AccountApi.clearDefaultAccount(googleApiClient);
googleApiClient.disconnect();
googleApiClient.connect();
changeState(State.CLOSED);
}
}
protected void onSignUp() {
Activity activity = activityWeakReference.get();
try {
changeState(State.OPENING);
connectionResult.startResolutionForResult(activity, REQUEST_CODE);
} catch (IntentSender.SendIntentException e) {
changeState(State.CREATED);
googleApiClient.connect();
}
}
protected void onRevoke() {
Plus.AccountApi.clearDefaultAccount(googleApiClient);
Plus.AccountApi.revokeAccessAndDisconnect(googleApiClient);
googleApiClient = googleApiClientBuilder.build();
googleApiClient.connect();
changeState(State.CLOSED);
}
2. State Pattern
This is a behavioral pattern the allow an object to alter its behavior when its internal state changes. The GoF Design Patterns book describes how a TCP connection can be represent by this pattern (which is also our case).
A state from a state machine should be a singleton, and the easiest away of doing it in Java was to create Enum named State as follows:
public enum State {
CREATED {
#Override
void connect(Connection connection) {
connection.onSignUp();
}
#Override
void disconnect(Connection connection) {
connection.onSignOut();
}
},
OPENING {},
OPENED {
#Override
void disconnect(Connection connection) {
connection.onSignOut();
}
#Override
void revoke(Connection connection) {
connection.onRevoke();
}
},
CLOSED {
#Override
void connect(Connection connection) {
connection.onSignIn();
}
};
void connect(Connection connection) {}
void disconnect(Connection connection) {}
void revoke(Connection connection) {}
The Connection class holds the context, i.e. the current state, which defines how the Connection methods connect, disconnect, and revoke will behave:
public void connect() {
currentState.connect(this);
}
public void disconnect() {
currentState.disconnect(this);
}
public void revoke() {
currentState.revoke(this);
}
private void changeState(State state) {
currentState = state;
setChanged();
notifyObservers(state);
}
3. Singleton Pattern
Since there is not need to recreate this class repeatedly, we provide it as a singleton:
public static Connection getInstance(Activity activity) {
if (null == sConnection) {
sConnection = new Connection(activity);
}
return sConnection;
}
public void onActivityResult(int result) {
if (result == Activity.RESULT_OK) {
changeState(State.CREATED);
} else {
changeState(State.CLOSED);
}
onSignIn();
}
private Connection(Activity activity) {
activityWeakReference = new WeakReference<>(activity);
googleApiClientBuilder = new GoogleApiClient
.Builder(activity)
.addConnectionCallbacks(this)
.addOnConnectionFailedListener(this)
.addApi(Plus.API, Plus.PlusOptions.builder().build())
.addScope(new Scope("email"));
googleApiClient = googleApiClientBuilder.build();
currentState = State.CLOSED;
}
4. Observable Pattern
The Connection class extends Java Observable, so 1 or more activities can observe the state changes:
#Override
protected void onCreate(Bundle bundle) {
connection = Connection.getInstance(this);
connection.addObserver(this);
}
#Override
protected void onStart() {
connection.connect();
}
#Override
protected void onDestroy() {
connection.deleteObserver(this);
connection.disconnect();
}
#Override
protected void onActivityResult(int request, int result, Intent data) {
if (Connection.REQUEST_CODE == request) {
connection.onActivityResult(result);
}
}
#Override
public void update(Observable observable, Object data) {
if (observable != connection) {
return;
}
// Your presentation logic goes here...
}
For anyone reading this question you can also check this answer by Ian Barber and also the one below, answered by Lee, that explains three broad ways of working with Google plus login and multiple activies which I found very useful actually.