I have a game, at the end i show a "Game Over" if the player does not follow some instructions.... the problem is android seems to stay on that state, when i go back to the menu and come back in.. i still dont have a way to play again, the game is coded in the main activity and has Runnables and OnTouch events, also I have a splash screen that when click it goes to the other activity where the game starts.... I am new to Android, what is the best way to terminate the Thread and then send them to the first Activity or splash screen?
Thank you in advance
It's very difficult to help without seeing any code. However, an Activity can self-terminate by calling finish(), if that's what you're asking.
If you use static variables they will be 'remembered' unless explicitly set in the View constructor or onSizeChanged etc. For example x = x + 5, can increase x every time you start the same game if x is static, because it 'remembers' x from the previous play - one needs to be aware of this.
Related
I have a multi-activity application. Say I set up a listener for some type of event in activity A, but then switch to a different activity B (within the same app) before the event has triggered the listener. What is the status of that listener? Does it always get destroyed? Or does it depend on the type of event? Or does it depend on whether the listener was set up within the main UI thread of activity A? Or some other conditions?
EDIT: The reason I ask is that I wish to interrogate the purchase states of a variety of in-app purchase items right at the start of my app's splash screen. This involves instigating some code and setting up a listener for "ok_here_is_the_answer()".. the problem is I'm worried that it may take longer to get the answer than the duration of the splash-screen activity. In that case do I have to start all over again in my application's second activity?
If your listener is created within Activity A and is tight to its context, then it would be destroyed when the activity pause i.e. go to the background.
If you want to do operation that should survive across activities, you can define it within the application context or in a dedicated service.
This might not be the answer to your question but you shouldn't use a splash activity (or even a splash) for many good reasons. I'd recommend you to use a full screen dialog instead which also would solve your problem.
But about your question it depend on what kind of listener we are talking about? Anything involving the context is over and done. Handlers, threads etc. is still running though (afaik).
As my app (game) is getting larger and larger, I've started to encounter a problem.
I have a menu activity with a 'start game' button - when the user presses this button, it starts the main game activity - now in this activity, I'm creating bitmaps etc in the constructor but there are so many that now when the activity starts, there is a slight delay - about 2 seconds - before the game actually starts.
I'm clearly doing something wrong - please could someone advise how to get around this so the delay (which clearly, has to happen) - isn't noticed by the user.
Load the ones you need immediately right away. Load the rest on a background thread (probably an AsyncTask). If you need one before it may be loaded, either pause or put up a loading screen as needed.
You could start loading the bitmaps in the background of your menu activity, or even when your app is created using a background thread or AsyncTask. You'll still need a loading screen of some sort in case the user navigates to the main game activity before you're done loading all of the bitmaps though.
You can also kick off an IntentService to load the bitmap. When the bitmap is loaded the IntentService can send a broadcast using LocalBroadcastManager. Then each component that cares about a result can register a BroadcastReceiver with LocalBroadcastManager.
I would like to run some action when all activities of certain type X are closed. The first idea is to have some global counter, that is decremented each time activity X is closed, and once the counter is 0, run some action. Assuming that process can be killed, the counter have to be persisted. But one more issue remains - imagine that activity X can crash (due to some bug in code), and in this case I'll not decrement the counter.
Any idea how to implement it in robust way?
I am not sure what you mean by 'closed', but you should be able to use the Activity Lifecycle callbacks to accomplish what you are asking.
There is a diagram on the following page that shows how the Activity Lifecycle is implemented:
http://developer.android.com/reference/android/app/Activity.html
As you said, you can have a global counter for this.
Maybe the good place for it is in the Application class?
Or u just save you counter in a file and reset it every time you start your application (in a very first activity).
You can also try to save it in shared preferences.
But there is still the problem with crashes. I have just an idea. There is ACRA-library for crash-logging. Take a look in it, how do they catch the crashes.
So you can just write a method for decrementing your counter. And call it from onDestroy() or if a crash occurs.
I'm developing an Activity that does some of its own state management. I'm trying to differentiate the following onResume cases:
New launch
task switch (home button long-click)
resume after other activity in the same application
wake-up after sleep
orientation change
Is there something in the Activity's intent, or elsewhere, that can help me differentiate these?
For the curious and some context... I'd like to preserve my internal history stack on 4 & 5. On cases 2 & 3, I would preserve the same current page, but erase the history (allow the normal back button functionality to take over at that point). Case 1 would initialize to the activity's internal start page (and can be detected easily enough with some help from onCreate).
Is there something in the Activity's intent, or elsewhere, that can help me differentiate these?
Item #4 has nothing to do with onResume(), AFAIK.
Item #5 would be better handled via android:configChanges and onConfigurationChange() though you could "detect" it by returning something from onRetainNonConfigurationInstance() and seeing if it is there in onResume() via getLastNonConfigurationInstance().
The others aren't just three cases, but probably twice that, once you start taking into account things like "being kicked out of memory to free up RAM" as a possibility.
Off the cuff, it feels like you made some unfortunate architectural decisions ("internal history stack...erase the history...allow the normal back button functionality to take over at that point"). Android is designed around lots of cheap activities, and you appear to be violating that precept. You are welcome to do so, but bear in mind that Android support for your chosen pattern may be limited.
I have Two activities One splash screen, Player screen.
When user clicks on my app icon first splash screen is displayed and then player screen
When player activity is running, if user returns to the home screen
and then again clicks on app icon, the application is starting from the splash screen again.
can any one please help me out how to do any one of below
1) I need to close current running activity and reload application.
or
2) I need to resume to the player screen directly.
Please give me an example or reference to follow, Im beginner in android programing
Thanks In advance
You may want to overrive the onRestart() method - it will be invoked if your Activity has been stopped previously; while it won't if it's the first time it runs (or if it has effectively been killed in the meantime).
Be sure to read the Activity life cycle there: http://developer.android.com/guide/topics/fundamentals.html#lcycles to understand what happens when.
Check out the order in which the life cycle states appear. You could override onStart, onPause, onResume, onStop, onCreate, onDestroy etc functions by adding Toasts to see the sequence. Then you can override them as per your programming requirements.