Over the past months I have been developing a versatile real-time game engine, and I have learned a lot, but I still feel very naive when it comes to the application life cycle. Specifically, I am trying to implement an Activity which can be shuffled in to the background by the user, then properly resumed.
My current architecture is as such: I have a an XML menu launcher activity which can create a real-time Game activity using intent. Relevant data in this Game activity is referenced through static data structures and variables. The Game activity creates worker threads in the onSurfaceCreate() callback of my SurfaceView object.
When a user presses the back button, the activity is destroyed, and they are sent back to the XML menu in the launcher activity. Fine, good for now. When the user presses the home button, the Activity is sent to the background. OK, great. My problems arise when the user tries to find their way back in the Game activity once is has been sent to the background. When the user touches the launcher icon, the Game is destroyed and the menu is re-launched. Also, when the user resumes the game through the task manager, the onSurfaceCreate() callback fires and the worker threads are started, but the game is frozen.
So, I have two questions. First, how do I resume my activity through the launcher icon, instead of re-launching the game? Second, when I resume my activity, what actions are necessary to restart my worker threads while persisting the game data?
Thanks!
EDIT: By request, I am including some code below. My onSurfaceCreate is a little bit complicated, it sends a message to another thread, which then implements the callback. I have verified that this implementation function fires when the Game activity is resumed.
protected void surfaceCreate()
{
Log.e(TAG, "surfaceCreate");
Thread gameThread = createGameThread();
gameThread.start();
}
protected final void onResume()
{
super.onResume();
resume();
}
protected final void onPause()
{
super.onPause();
pause();
}
These cryptic pause() and resume() methods simply set a boolean variable which prevents some game logic from being executed, they do nothing to hinder the worker threads, which should continue looping.
EDIT: Thanks Mohammad, for solving my first (although smaller) problem. It turns out that the launcher icon behaves differently when not connected by USB to the IDE. The second problem remains unresolved.
EDIT: All working! The second problem turned out to be an issue unique to my code, I apologize for that. I hope that this question can still be useful for those dealing with the launcher and IDEs.
There are multiple possible problems/solutions listed in this post. This includes misunderstanding of activity lifecycle and launchMode settings.
First, how do I resume my activity through the launcher icon, instead
of re-launching the game?
You are most likely missing definition for your onResume() and onPause() methods. Examples are here:
http://developer.android.com/training/basics/activity-lifecycle/pausing.html
Straight from the API:
onPause() Called as part of the activity lifecycle when an
activity is going into the background, but has not (yet) been killed.
onResume() Called after onRestoreInstanceState(Bundle),
onRestart(), or onPause(), for your activity to start interacting with
the user.
Check the Android Activity Lifecycle out:
http://developer.android.com/reference/android/app/Activity.html
One theory on your issue may be is that you're most likely going to onStop() (by hitting the home button) and the Android OS is looking for your onRestart(), but can't find it hence freezing/restarting.
Second, when I resume my activity, what actions are necessary to
restart my worker threads while persisting the game data?
Careful how you use the word restart. You want to pause and resume the application (not restart). Save data in onPause() (use a database or any other save feature you'd like). Load data in onResume(). Although, the activity should resume as normal if you just fill up these methods.
Now, if you want to save state for when you restart the application, you should save states in onStop() and/or onDestroy(). You should load states in onStart(). In order to save states, you can check this out:
https://stackoverflow.com/a/151940/2498729
For those using Eclipse (or any other IDE to run/test your application):
From what have you described you probably have overridden
android:launchMode in AndroidManifest.xml or if you are testing by
"run as" from Eclipse try exiting the application after installing and
auto-starting. Then start again from the emulator and test the Home
button behavior. I suppose this is because Android does not put
Activities on the OS stack when started from Eclipse and then the Home
button behavior is not as usual. If this does not solve your problem,
try reading
http://developer.android.com/guide/topics/fundamentals.html#lmodes.
I had launchMode set in my StartupActivity. THen I removed that (it
was set to "singleTask", it behaves like I want it; the app is
"resumed" to the Activity I expect, ie not StartupActivity but
MainActivity.
Source:
https://stackoverflow.com/a/1619461/2498729
http://developer.android.com/guide/topics/manifest/activity-element.html
According to this:
https://stackoverflow.com/a/3002890/2498729
You should change your andoird:launchMode to "Standard" (or "default").
Standard: A > B > HOME > B (what you want)
SingleTask: A > B > HOME > A (what you don't want)
Related
Except being the first Activity upon the Start of the Application, is there anything else special about main activity?
From:https://developer.android.com/codelabs/android-training-create-an-activity#0
An app usually consists of multiple screens that are loosely bound to
each other. Each screen is an activity. Typically, one activity in an
app is specified as the "main" activity (MainActivity.java), which is
presented to the user when the app is launched. The main activity can
then start other activities to perform different actions.
From the quote above it seems to me that we have following hierarchy:
but then further is said:
Each time a new activity starts, the previous activity is stopped, but
the system preserves the activity in a stack (the "back stack"). When
a new activity starts, that new activity is pushed onto the back stack
and takes user focus. The back stack follows basic "last in, first
out" stack logic. When the user is done with the current activity and
presses the Back button, that activity is popped from the stack and
destroyed, and the previous activity resumes.
Does this also apply to the "MainActivity"? If the "MainActivity" is destroyed does that cause the App to crash i.e does the lifecycle of the MainActivity in any way differs from the lifecycle of any other activity? Is the MainActivity the last activity that is being stopped when the App is exited?
Why do I need this:
I would like to free some resources when the App is exited (in the onStop() Method (because post Honeycomb it is guaranteed that onStop will be called)), especially ExecutorServices, I've read here that even though App is exited there is no guarantee that an ExecutorService will be stopped and will make JVM continue working/running, even though App is closed/killed and will continue to use system resources.
Main Activity is the entry point for your app when user presses the icon for cold launch. You make any of your Activity a main activity in AndroidManifest.xml file via Intent Filter. Intent Filter tells the system which activity is main.
Although main activity is considered first entry point typically, but keep in mind, Main Activity is not always the first activity to be launched, for example there are various intent filters that can be assigned to your other Activity and that activity can be opened directly following the related action. Please read about the Intent-Filter here.
For example, your app is gallery app, typical first screen would be album list. from where you can view individual photo in PhotoActivity. This PhotoActivity can be opened directly via intent from outside apps to view a certain photo without needing to launch the main activity. (Check out google Photos app)
Regarding ExecutorServices or other services lifecycle, few options here:
implement a ownership machanism, ie the activity that starts the service is responsible for closing the service
You can monitor your app's activity stack and kill the service when your Activity stack is empty.
Leverage Application class lifecycle to monitor things.
Reasonable discussion here https://stackoverflow.com/a/5862048/593709
I want to run some code after I hit my home button and the re-open the app. How do I run code when the app is re-opened (Not After Being Killed) in android-studio?
you can use onStop() method or onDestroy() , if you will close totally that Activity use onDestroy() and if you just will put it in background you can use onStop()
Doc for onDestroy()
Perform any final cleanup before an activity is destroyed. This can
happen either because the activity is finishing (someone called
finish() on it, or because the system is temporarily destroying this
instance of the activity to save space. You can distinguish between
these two scenarios with the isFinishing() method.
Doc for onStop()
Called when you are no longer visible to the user. You will next
receive either onRestart(), onDestroy(), or nothing, depending on
later user activity.
i saw you edited your question, look at the lifecycle
Like sagar says, you can use onResume() in order to recover your current Activity
You can perform the action in onResume() method. This is the state in which the app interacts with the user. The app stays in this state until something happens to take focus away from the app. Do note that there is no differentiation between Activity coming from background to foreground or Activity created from scratch. onResume() will be called whenever app enters foreground state.
In order to differentiate it in onResume() you need to maintain a boolean flag. You can set the flag in onStop() and check it in onResume().
This approach will only work, if the OS hasn't killed the process, hosting your Activity, due to memory constraints. In this case your Activity will be recreated.
You can use onRestart() since when you left your activity to go home it goes into onStop() and after that when you launch it system will call onRestart() the onStart().
for more info refer following ans:
https://stackoverflow.com/a/35476531/7271231
I want to execute a piece of code (say, for example, display a Toast) every time that the app is opened. So far I have managed to do this every time the app is launched by putting the code into my MyApp.java file that extends Application.
However, if I press the homescreen or back out of the app and then go into it, the message doesn't reappear. It only does when I relaunch the app. Any idea how to do this?
EDIT:
basically im asking how to execute code everytime the whole APP is brought to foreground (this can be first time open, after another app was used, after user backed out of app, etc). Where would I place onResume code? It wouldn't be in a particular activity, would it, since I want it to apply when entire app appears in foreground, not just particular activity.
You can try writing that code in your activity's #Override-d onResume() method.
The only way to do this is,
Determine which app is currently in the foreground
.Follow this discussion for getting an idea for the best way to do it.
[Determining the current foreground application from a background task or service
Suppose, if the function name is 'getCurrentForgroundApp()',
You need a service to execute getCurrentForgroundApp(); every one second
(1-second interval is depending on your purpose, can be lower or higher).
Now, you can identify which app is running foreground in every second.
So, check if your app is the one running foreground. If true, then execute the toast or code you need.
This is how app-locker apps showing lock screen over selected apps, whenever they come to the foreground.
You have to use the onResume callback:
Android API
Example of use from previous SO question
In activity class:
#Override
protected void onResume() {
super.onResume();
//your code here
}
I am developing an application in Android which has several Activities and need to check some details only when application is minimized and maximized, not on Activity screens' navigation. onPause() and onResume() doesn't work. onWindowFocusChanged() also doesn't helped as that is also calling while navigating among screens. Please help in which way I can be able to get an event only when Application is minimized/maximized, not on screen navigation.
I think that this Activity callback onUserLeaveHint() could be a start.
from the doc:
Called as part of the activity lifecycle when an activity is about to
go into the background as the result of user choice. For example, when
the user presses the Home key, onUserLeaveHint() will be called, but
when an incoming phone call causes the in-call Activity to be
automatically brought to the foreground, onUserLeaveHint() will not be
called on the activity being interrupted. In cases when it is invoked,
this method is called right before the activity's onPause() callback.
This callback and onUserInteraction() are intended to help activities
manage status bar notifications intelligently; specifically, for
helping activities determine the proper time to cancel a notfication.
It's not something which is common on Android, so I would agree to CommonsWare, that you should consider a different approach.
Nevertheless, there is a (bit hacky) way to achieve this.
Override onStop() and onResume() in every of your activities, set a boolean to true in onResume() and to false in onStop(). If this is true, the application is active, if it's false it's not.
You could use a listener, which is always called after the boolean value is set, to execute your actions.
If you can add a property, let's name it isShown in your customized Application object, which means you need extend the application for this purpose. it is in your subclass of Application and it is a signleton.
Be realized the lifecycle methods for onPause and onResume, when the onPause is called, it means the activity would be going to background, invisible any more, or put into the the activity stack. onResume means the activty status is recovered and ready for the user's interaction. So if you set the isShown property to false, which is in your application object, within the activity's onPause, and set it back to true in your onResume. of cause, you can make this behavior to be extracted into a superclass for the reuse purpose.
with the composite of onPause and onResume, and a given time we can identify the min/maxmized status. Let's say, isShown is set to false for a while, we can say it is minimized. otherwise, we can explain the maximized too.
But what are you going to do with this flag? did you still have a Service running in backend ready to receive this property to do something?
My application shows an alert that the user must respond to before continuing to do other things. I'm trying to figure out the best way to implement this. Using an Activity for the alert isn't quite working.
In my current implementation, the alert is activity (A). When another activity from the same package is started and onStop is called, it starts itself again using FLAG_ACTIVITY_REORDER_TO_FRONT so that it's always at the top of the stack. This works as described, unless Activity A uses Theme.Dialog or Theme.Translucent.
Modified log:
Activity A created
Activity A started
Activity A resumed
Activity A paused
Activity B created
Activity B started
Activity B resumed
Activity B gains window focus
Activity A stopped
Top activity in stack is Activity B, so Activity A relaunches itself
Activity B paused
Activity A started
Activity A resumed
The top activity in the stack should be Activity A, however Activity B remains in the foreground.
Another implementation detail: my application is not for a phone, so I'm not concerned with a back button finishing the activity or interactions with other apps. Still, I agree that on principle I should prevent such problems anyway, so in my code I check whether the activity that has come in front is from the same package (i.e. from our code base). This should work around the theoretical problem of interfering with other apps.
Is there a way to bring Activity A into focus? I understand that this is unusual behavior, but it is necessary for Activity A to remain in the foreground until it is deliberately finished.
I'm also open to suggestions about a completely different and better approach!
FWIW, I'm running 2.2.
(Cross-posted from http://groups.google.com/group/android-developers/browse_thread/thread/d46fd7d59abe15a0, where we got no response.)
You can't do this. Please don't do this. The activity at the top of the stack is the one that has input focus. What you are trying to do fundamentally breaks the user interaction that is supposed to happen.
What you are doing is generally considered by the platform to be an abuse of it, and Android has increasingly been doing things to prevent applications like this from causing harm.
Well, here's what I had in mind:
public class ActivityA extends Activity
{
...
public void onStop() {
super.onStop();
finish();
Intent i = new Intent();
i.setClass(getApplicationContext(), ActivityA.class);
startActivity(i);
}
}
ActivityA is finished in onStop() and started again right away. You might have to check issues regarding device rotation, but this approach should work.
Having window focus means that activity B is still in its visible lifetime, since it has on top the activity A which has a translucent bg or is dialog-like.
Having the window focus doesn't mean that activity B is on the foreground. They are different things.
If you don't want this, then don't use those two themes.