Ever since I added a new Class to my Android app (specifically, a sqlite helper class) may app wants to relaunch after I press the home button. Before adding the class, the app would multitask as expected.
I am stumped. It seems onDestroy is called every time the app goes into the background.
Any tips or thoughts as to why this would happen?
This is by design. Please refer to Android activity lifecycle for more info when/how your activity could be destroyed. Basically, as soon as your app goes into background, your activity can be killed at any moment.
If you want to continue execution, you need to create a Service that represents a long-running components in Android architecture.
It turned out I had android:finishOnCloseSystemDialogs="true" in the manifest file.
Related
I have an Android app with 2 primary activities. When the app starts from scratch, both activities start and run just fine. Something like: A -> B. Activity A does all of the initialization needed for both A & B. All of my local testing on real hardware and emulator, A is always created (onCreate) before B is created.
However, on my app's crash report, I see an exception which can only be explained by B being started without or before A. Is this possible? Will Android create an internal Activity without creating the other activities for my app (B without A)? Is the order of Activity creation guaranteed (A then B)? How would I re-create either of these scenarios using the emulator or real hardware?
I can easily move my initialization code to work regardless of which Activity is started first, BUT I wanted to learn how to reproduce and test before making changes. I looked through the documentation but it didn't really help.
Here is the code that starts task B when user presses "play" button:
private void handlePlayTouch()
{
Intent intent = new Intent(getApplicationContext(), PlayActivity.class);
startActivity(intent);
}
After you started Activity B, you press home button and make your application in the background. The system would kill your application if the free memory is very low. If you tried to switch to your application after your application killed, the system would try to restore your application and activity B without create A first.
You can use DDMMS's Devices view to manually stop your application, there's a red "stop process" button.Make sure that you should make your application in the background.
In your case, I suggest you using a single activity. In the on create, you can prepare everything and then do what you need. If you would like to be sure that something will be executed only when something else is finished, use AsyncTasks.
In doInBackground => do the initialisation and onPostExecute, do what you have to do after.
The onPostExecute will bee executed only when the doInBackground has finished.
http://developer.android.com/reference/android/os/AsyncTask.html
EDIT:
Your structure is not respecting a good programming practice in Android, but if it is mandatory for you to keep this structure, you should at least use "unkillable" services for the activity A. This will make your code harder to destroy as a simple activity when your app will be put on the background, but there is still a chance to be destroyed.
To understand your problem, see the android activity life cycle:
For the services using, see:
http://developer.android.com/reference/android/app/Service.html
http://www.androidguys.com/2009/09/09/diamonds-are-forever-services-are-not/
I write application on android which will be runnig all the time on background. There will be only one starting view on first run. I want to user run instance of my app only once, and cant run any other instance at the time. When he try to run this app when one instance of this app is running already he sould see some warning notification. My problem is I dont know how to prevent user from multiple start of my app. Is this possible? If it is possible, how can I do it? Thanks for any help.
For background processing I would recommend to consider Services. Services are created to deal with longterm background tasks. I think foreground service(like Skype) may be interesting for you.
As Phil suggested you can you launch mode to control your activity behaviour. Consider using launchMode = "singleTop"
You need to pick a launchmode that will best fit your needs (probably singleInstance or singleTask). As for popping a notification, you can handle that in onCreate or onResume, however it doesn't have anything to do directly with how many instances are running.
We know that when the system runs out of resources, an activity in background serializes its state and gets killed by the OS. When we resume it, the OS recovers the activity state by savedInstanceState passed to onCreate method. Considering we are responsible for handling what is going to be serialized/recovered, I'd like to have my activity killed in order to test the code I created for recovering. How can I achieve that? Forcing the application to be killed through the applications menu doesn't help.
Rotate your device (or emulator). Android saves, destroys, and re-creates the activity in the new orientation.
Download a task manager that kills the process in a less destructive way than "Force stop" in "Manage applications" settings. Example: GO task manager.
The task manager will kill the app (and the debug) but somehow not the activity stack (don't know why).
When you'll relaunch the app again, onCreate will be invoked with the last saved bundle/state.
The disadvantage of this solution, compared to Darrell's, is that you cannot debug it.
The advantage of this solution, compared to Darrell's, is that it is more close to real life scenario.
You can kill it from Eclipse also.
Go to the Android view. YOu should see the list of processes in the Devices tab.
Click on your process and then click the little "STOP" button.
Instant death!
FYI you can also attach the debugger this way by clicking on the little green bug
Some Android application restarts automatically when i kill process manually.
How this can be possible?
Is there anyone who know how to do like this on Android platform?
Are you sure these applications are restarted automatically?
I suspect that they actually have a few activities on top of each other. When you kill a process in Android, only the top activity will be destroyed, other activities are still on the activity stack. In other words, when you return from the "process killer activity" another of the application's activity becomes visible, and the process is restarted.
This is not something that you need to implement in your application, it is just how Android works.
i am working on an application that send and get data from internet each 5 min
if i press home key and my app goes to background... it will still continue sending/getting data from internet? or i have to do something special?
thanks
"If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere. If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state."
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
No. Activities shouldn't be depended on to process tasks in the background.
The following link illustrates the fundamentals of different Android components and what they do, i.e. the "parts" of an app.
You should be using a Service for background processing.
From what you're saying, I'd suggest an IntentService fired by an Alarm.
Application Fundamentals