In my game app I would like the user to sign in to Google Play Services during the starting activity so I had it subclass BaseGameActivity. Then a separate activity is started for the game, at the end of which I want to update a leaderboard using Google Play Services, which requires calling BaseGameActivity.getApiClient().
How should I use Google Play services from a different activity than the one that subclasses BaseGameActivity?
Two options I thought of were: pass a reference to the starting activity, or use a handler and send a message to the starting activity. But I don't know which would method would be better to use (or if a third way is better) and it seems like this might be a fairly common situation.
If you want to use GameHelper with multiple activities it is best to implement it without using BaseGameActivity and then pass your GameHelper instance between activities (or keep a static instance somewhere).
You can find instructions for using GameHelper directly on this page (see the Using GameHelper without BaseGameActivity heading).
Just make sure that you place the required GameHelper calls (especially onActivityResult) in all of your activities that make use of it. As for sign-on/sign-out you will need to determine for yourself in which activity(s) to place those, depending on the flow of your app.
Related
I am writing a simple Android library. I have a couple of methods that I would like executed when certain activity events happen - like after activity got loaded or when the activity gets paused.
One way I could think of was to create a class that extends activity, and write my methods there, and then have "target" activities extend that class. This was all methods get called
But if the end user is extending some other activity already, this method won't work. Is there a better alternative?
If you need only provide support back to API 14 or higher, you might be able to make use of the application level activity lifecycle callbacks - see the Application.ActivityLifecycleCallbacks interface for details.
To make use of this you need to register an instance of this interface with an Application instance, using the registerActivityLifecycleCallbacks method. One way to get that would be to have the developer using your library initialise your library by passing their Application instance to it. This is what I do in an SDK that I maintain, and it seems to work nicely.
I want to connect to Google Play Games in my MainActivity then pass my mGoogleClientApi object to my GameActivity.
How do I go about it?
Plus! Every time I start the MainActivity is reconnects to GoogleApiClient.
Anything helps.
My suggestion would be, if you need to connect to google play games in the main activity
AND in the GameActivity, that you do exactly that thing. There is no need to hand over
a clientApi instance.
I assume that your main activity is kind of a login and afterwards you start the GameActivity?
Than use the api to connect in the first place, handle the login and start the GameActivity.
There you connect to the api again and handle the game relevant part.
Or you could use fragments and hand over the api client via a public method in your activity which
implements an interface to return the client.
Play Game Services are really made with Fragments in mind. It is almost mandatory to use Fragments instead of Activities, and to have a single Activity in your app (that you can made a subclass of GameActivity...)
I am working on a solution or code that can be embedded inside of an Android APK to track how many times the app has been launched and how long the app has ran for. I know one way to do this is using the ActivityLifecycleMethods in API 14 and in lower versions of Android having code placed in all Activity Lifecycle events or by providing a base Activity class.
1) Is there a way to hook the ActivityLifecycleMethods without the developer having to make any changes to their code outside of dropping additional code into their App?
I believe this answer is no because even with an Enum Singleton it is not loaded until it is referenced. Also the Enum Singleton will go away once the activity is changed since a different class loader is used when activities change.
If I wanted to keep the Enum Singleton around would it be possible to store a reference to the applicationContext and thus it wouldn't be removed when the Activity changes? Is that what google means by
"There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton." on http://developer.android.com/reference/android/app/Application.html
2) I am not a fan of this solution for older API versions. It seems very likely developers could forget to modify their Activity Lifecycle methods or forget to inherit from the created BaseActivity. Are there any other unique solutions for these older platforms? Is there any other approaches that can be done to determine when an activity isn't running? Could any of the following work:
a) User a class loader to ensure the base activity with the proper metrics are always used
b) Implement some type of heart beat. Will a timer stop working if the app is paused or killed? Is there some other way? Could the ActivityManager be used?
You have many Analytic Agents like Flurry to do that.
When ever you want to track an event, you will add it to flurry and inturn it syncs with server after specific time.
You may use the same logic.
Better create a library file with following features:
Start Application
End Application and report time to db.
Track a specific event count and update to db.
Sync the data to server you like to.
Call appropriate events from your app.
I'm creating an application that uses Google maps to locate and display the current location of the user and some markers.
I would like to implement a check in part that will give points to the users and unlock achievements.
But I don't know how to extend both BaseGameActivity and FragmentActivity. A few hints will be appreciated.
Aha, a classic case of Activity superclass wars. Precisely with this problem in mind, we offer GameHelper as an alternative to BaseGameActivity, for games that for one reason or another cannot (or don't want to) change their Activity's base class. All you have to do is create a GameHelper object on your Activity's onCreate method and then let it know of important Activity lifecycle events, notably onStop, onStart and onActivityResult.
Take a look at the source code for BaseGameActivity as a reference. What you'll want to do is implement that same functionality in your Activity class so that you have a working GameHelper.
Particularly, you'll notice that BaseGameActivity is actually pretty dumb -- it just forwards events to GameHelper, which is really the brains behind it.
I’ve written a library for Android, upon initialising the library I register for call backs for location updates, subscription status changes, library status changes and various other updates...
Originally, I wanted all these updates to call back to a controller in my android UI app, and then for the controller to launch activity A, pass on the messages from the controller to activity A and so on. Or launch activity B for signing up for a subscription and forward messages to this etc
However, it appears that there isn’t a way to achieve this - Because each activity is in isolation? Unless I’m mistaken?
So what are my options here? It sounds like I either have to use one activity for the whole app and swap the UI’s which after looking into it doesn’t appear to be the way to go?
I did try to subclass Application, which worked and gave me access to my library from an activity – but I want it the other way around. Is this possible? would wrapping the library in a service achieve what I want to do?
You could use broadcasts and send them from your library. Each of your activities would have to register a BroadcastReceiver in their onResume() method and unregister it in their onPause() method. This would be comparatively easy when you use a common base class for your activities. You could then send commands from your library to whatever activity is currently active.