In my application, i have in game helper(i want log in on button click):
// Whether to automatically try to sign in on onStart(). We only set this
// to true when the sign-in process fails or the user explicitly signs out.
// We set it back to false when the user initiates the sign in process.
boolean mConnectOnStart = false;
In my MainActivity (extends BaseGameActivity), after login button click i call:
beginUserInitiatedSignIn();
Of course now isSignedIn() returns true.
But when I go to next Activity (aslo extends BaseGameActivity):
isSignedIn() return false.
I can of course call beginUserInitiatedSignIn() on my next Activity, but i don' t want it.
In my app user can be logged in, but not have to. So if user not logged in at my mainActivity i don' t want show login form on next activity.
Edit: For this moment my solution is to create static variable and set it when i leave my main activity for ture if isSignedIn() and call beginUserInitiatedSignIn() on next activity only when this variable is true. Is it any better, automatic solution ?
There's two types of sign in:
The user initiated sign in which shows the Google Play Games logo and requires the user to approve access, etc.
Silent sign in (which BaseGameActivity does in its onStart call) - this automatically attempts to sign in and, if the user has already signed in, does the same callback as if you had gone through the user initiated sign in flow.
Therefore you do need to wait for the sign in callback before attempting any Google Play Games related calls in each and every activity.
Note that recently (4 days ago on Feb 18, 2014), the BaseGameUtils library for Android was updated to use the new Google Api Client model, which allows you to do read calls before being signed in (where they will automatically wait until sign in before attempting to process). As the Google Api Client gives a number of other benefits (such as improved sign in reliability), you should update to the latest BaseGameUtils if you haven't already.
Related
I am going to start implementing the In-App-Review feature in my app. But I would like to know what rating is given by the user after showing a Review dialog. It is possible? And What is the time bound set by Google play to show the InAppReview popup next time
Not at the moment.
The documentation over here states that the callback after the launchReviewFlow is completed returns nothing.
flow.addOnCompleteListener(task -> {
// The flow has finished. The API does not indicate whether the user
// reviewed or not, or even whether the review dialog was shown. Thus, no
// matter the result, we continue our app flow.
});
If you feel that the information is important to you, consider raising a feature request.
I am writing an Espresso test for an Activity which contains a button used for authenticating using a Google account and a button used for authenticating using a Facebook account. In my test I would like to simulate clicks on each of these buttons and ensure that it launches the correct component provided by these third parties.
It seems that there are two possible options:
Simulate a click on the appropriate button and ensure the UI contains the expected views.
Simulate a click on the appropriate button and ensure the correct Intent was fired.
I've initially opted for option #2, as I have found that it is difficult to test the UI with components outside of the Activity under test.
To start, I created a test for the Google button. The code is below:
#Test
public void testGoogleAuthButton() {
// Start the Activity under test.
activityRule.launchActivity(new Intent());
// Click the Google button.
onView(withId(R.id.googleSignUpButton)).perform(click());
// Ensure the `SignInHubActivity`, an `Activity` provided by the Google APIs, was launched.
intended(hasComponent(SignInHubActivity.class.getName()), times(1));
// Simulate a press on the back button to close the account chooser.
UiDevice.getInstance(getInstrumentation()).pressBack();
}
This test passes, however I am unsure as to whether or not this is the correct way to perform this test. Next, I tried a similar technique for the Facebook button:
#Test
public void testFacebookAuthButton() {
// Start the Activity under test.
activityRule.launchActivity(intent);
// Simulate a click on the Facebook button.
onView(withId(R.id.facebookSignUpButton)).perform(click());
// Ensure the `FacebookActivity`, an `Activity` provided by the Facebook APIs, was launched.
intended(hasComponent(FacebookActivity.class.getName()), times(1));
// Simulate a press on the back button to close the current Activity.
UiDevice.getInstance(getInstrumentation()).pressBack();
}
Strangely, this test fails, and notes that no Intents were matched and that none were recorded.
My questions:
Does the code shown above represent the correct way to test these flows?
Why does the Facebook version of the test shown above fail, while the Google version does not?
I have a problem with a activity where onStop breaks my OAuth authentication process.
First a small explanation about the context of my app:
I have this activity (lets call it the receiveSharedDataActivity) which handles incoming data which is being send from other apps. This activity is made using the following example from the Android Developer site: http://developer.android.com/training/sharing/receive.html.
My app requires the user to be logged in using a E-mail and a password or using the Facebook or Twitter OAuth login. It is possible that the user has never opened the app and thus is not logged in yet. (The possibility is small, but it can still occur.)
The problem (challenge):
So when the user decides to share some data to my app but is not logged in yet, I show him the 3 login options (E-mail, Facebook, and Twitter) in the receiveSharedDataActivity using fragments. This way he can first authenticate himself and after that the data can be handled. When the user chooses to login with Facebook the Twitter OAuth login option he is redirected to a new activity from Facebook or Twitter where he needs to login and give my app permission to access his user data. All goes well up to this point. Because when the user is redirected to this new activity, the receiveSharedDataActivity is automatically being stopped using onStop because it is no longer visible to the user. When the user then logs in at the Facebook or Twitter activity and is being send back to the receiveSharedDataActivity, there is no receiveSharedDataActivity anymore because it has stopped. So the user ends up at another app where the user decided to share data from.
The question:
How can I prevent the receiveSharedDataActivity from being stopped when the user is login in at the Facebook or Twitter activity?
I am looking forward to your solutions because I am pretty stuck with this problem.
Good news! I was able to solve this issue. All this time I thought that it had to do with passing the correct Intent flags when starting the receiveSharedDataActivity. Silly me...
The problem was that my receiveSharedDataActivity had the noHistory:true parameter set in the AndroidManifest.xml. I needed this because obviously I did not want this activity to be added to the backstack. But the noHistory parameter made my activity destroy itself directly after the activity was no longer visible to the user. Which happend when the OAuth login activity started. So of course there was no activity to return to after the OAuth login activity was completed because the receiveSharedDataActivity was simply destroyed.
When I removed the noHistory parameter, the activity did not destory itself anymore and nicely called the onRestart method where I could now handle the rest of the Oauth process. And I was able to prevent the activity from being added to the backstack just by calling finish() right after starting a new activity. This way the activity destroys itself and does not get added to the backstack.
I followed Google's tutorial on implementing the google+ api but it doesn't say anything about that dialog with the user's name that shows up at the top of your screen after signing in to your google+ account like many other games have. I can't find any information about different layouts either, like the loading screen that shows up sometimes after you've pressed sign-in.
You can use the API to request the users profile:
Person me = Plus.PeopleApi.getCurrentPerson(mGoogleApiClient);
if (me != null) {
//me.getDisplayName();
}
It seems like what is displayed during the login process really depends on the speed of the device, the load on the device, and perhaps the network connection. In my case, most of the time the activity starts and disappears before I have a chance to read what it says (when user has already been authorized).
I think you can always count on your activity being paused then resumed if you call mGoogleApiClient.connect() when !mGoogleApiClient.isConnected(). I do not believe you can brand their Activity other than with your application logo.
I have followed : https://developers.facebook.com/docs/howtos/androidsdk/3.0/login-with-facebook/
I have created a separate page as in the example and works perfectly fine.
My issue is now I want to add the Login button to my home page and the publish button on a different page. Is it possible to convert this into a separate class that I can call from anywhere?
Has anyone done this and can point my in the right direction.
Sorry if this has been asked before. I am very new to Facebook SDK
Thanks for your time
Yes, if you use the Active Session, you should be able to call Session.getActiveSession() from any activity, and it should return you the right thing. So the page with the login button would create the active session, and the page with the publish button would get the active session, and call requestNewPublishPermission and do the publish.
There are 2 outstanding issues:
You need to ensure that the page with the login button appears in your app before the page with the publish button (at least the first time, when the user initially logs in).
In subsequent restarts of your app (after the user has already logged in), you can use the UiLifecycleHelper to manage, restore, and auto-open the active session for you.