I was wondering is there a way of getting a list with all running activities ?
As far as I understand there will only one activity running at a time that will be your active activity on screen, other activities will be in paused or Stopped state if any.
No, as far as I know there is no built in way to get a list of running activities (assuming running - means non-destroyed activities).
If you only need a list of activities in your application, you can create some kind of "registrar" mechanism, so each activity registers in onCreate() and unregisters in onDestroy(). This should be some singleton class, because it should automatically be "cleared" if application is killed (as opposed to storing list of active activities in DB).
Related
Let's say we have an Android app that consists of a MainActivity, and also a bound intent service (or any other background service that continues to run while MainActivity is paused).
Lets say we have some variables belonging to MainActivity, MainAcitivity.variable1, and MainActivity.variable2.
Is it safe/normal to update these variables from the background service while MainActivity is paused? I know that it works without errors, but it seems strange to me that it is possible to interact with a class/thread that is "asleep." If you send multiple updates while Main is paused, do they all end up in a buffer that gets dealt with when Main is resumed? or do the updates happen immediately?
What technical subject to these questions have to do with?
Thankyou!!
You shouldn't get used to this. simply because your Service will not be able to see your Activity's variable when the app is closed.
A very good solution is to cache the changes made by the Service in local storage, and use BroadcastReciever to update the Activity if it is running. In addition to that, the Activity should get data from the storage in the onResume() method and update the UI accordingly.
Scenario:
An Android app has an Activity with a Fragment.
The user sends the app to the background by pressing the home key.
Two hours pass, the Android OS kills the process to free up resources.
The user switches back to the app through the Recent Apps List.
The onCreate method of the Activity will now find the existing Fragment by using fragmentManager.findFragmentByTag()* as best practice cites. Yet, adding this old fragment to the activity will not make the fragment render. I'm unsure if I'm doing something wrong, or this is simply not a supported use case for reusing old fragments.
Must I implement special handling of this scenario (i.e. new up the Fragment instead of reusing the old)? If so, what is the best practice of detecting that the process has been killed and relaunched in onCreate?
edit 1: *) I am testing this by using DDMS to kill the process. This might not emulate the OS' way terminating a process correctly, as for instance onDestroy() is not called. Does anoyone know if the old fragments are disposed from the FragmentManager when onDestroy() is invoked by the OS? If this is the case, this question is moot.
No, You can't reuse a Fragment once the process is killed. Once the process is killed, you app no longer exists on Android main thread, hence a new instance of the activity has to be launched.
Your app starts with an your main activity as in Manifest file, and loads corresponding views and fragments. Please go through the Activity Lifecycle of the Android, to know more about it.
This teaches you how to maintain your activity run in background and when not in use:http://developer.android.com/training/basics/activity-lifecycle/index.html
Trying to found some information about Android app life cycle. So imagine the situation: I open app and than lock screen, and in a few hours phone kill my app process. What will happen when I will unlock screen ? What I will see at the screen ? Android home screen ? or App will restar automatically for me ? Will stack of activities will restore too ? I'll be glad for any help. Thanks...
There is a Life-cycle for the android application BUT the applications have limited control over their own life-cycle, instead the components must listen for changes in the application state and react accordingly, the changes are as the following
onCreate
onLowMemory
onTrimMemory
onConfigurationChanged
and these method are accessed by extending the application class and override them to react accordingly.
regards,
Activity lifecycle is what your looking for.
There is no such thing as Application lifecycle or lifecircle. Every Activity has it's own lifecycle. If the system needs more ram it will be killed if in onPause() or onStop() state. If all your Activities are killed, the app is no longer visible. If you want data to persist you have to Override onPause() and onResume() and save/restore your data there.
Your Application will never restore on its own, if there is an activity killed. You have to keep track of your activities manually if you want to "resume" after kill of your activities.
To make it even more precise: One Activity can be killed and the others can remain paused. If you then return to your app you get the last activity in your activity stack which wasn't killed.
If your app was killed by the system then I don't think it will show up when you unlock the screen. If below your app the main screen was there then I assume it will show up since your app has been killed by the system.
In some cases you can subclass application class:
Base class for those who need to maintain global application state.
You can provide your own implementation by specifying its name in your
AndroidManifest.xml's tag, which will cause that class
to be instantiated for you when the process for your
application/package is created.
and then use app callback methods.
http://developer.android.com/reference/android/app/Application.html
This doesn't appear to be well documented or I missed it, so before I run a bunch of my own tests I was wondering if anyone already knows the answers to some of these questions.
First off, when I say "Application" I am referring to extending the Application class. http://developer.android.com/reference/android/app/Application.html
The questions I have are as follows, some are related.
When an a user leaves an Activity from within the Application, and goes to the Activity of another application, does the Application somehow get paused as well, even though it doesn't have an onPause()? Or does it continue to live unpaused until all of it's activities are destroyed?
when does the Application stop? When all of it's Activities are destroyed?
Is there ever a chance that one of the Applications Activities could be running without an instance of the Application, or will the Application class always exist if one of the Activities does?
If there is some process running on the Application, and it's Activities are all paused, will that process continue to run?
Is the Application effected by rotation in any way or does rotation only change Activities?
Thanks
As you say the application does not have onPause so nothing happens to the application. When onPause gets called in your Activity nothing special happens, your Activity continues to run and can do whatever it wants including run new threads, timers can go off, whatever.
I believe what you are asking is: when is an Application destroyed and when the onTerminate method in an Application called? The answer is hard to pinpoint and is up to the system, it does not necessarily happen when all activities get onDestroyed called. In fact even when onDestroy is called, your Activities aren't necessarily garbage collected. When the system gets low on memory the process that your Application lives in can be killed, meaning your Application will disappear; onTerminate may or may not be called. At that time all the Activities, Services, etc, are killed too.
The Application is always instantiated first, an Activity must have an associated Application, just like how you define it in the AndroidManifest.xml.
Processes never pause in Android, the onPause method does not actually really do anything other than tell you to pause things in your app. Other than that the process keeps chugging away, your threads keep running, even the main thread receive Intents with a BroadcastReceiver.
The Application gets rotation callbacks in the Application's onConfigurationChanged(). I'm not sure if you can disable that since there is no configChanges attributes supported by application tags in the AndroidManifest.xml.
A good comparison to Application is static field in any of your classes. The static fields will live as long the process is not destroyed, just like the Application. Static fields can be accessed by all Activities, Services, etc (assume the static fields are public), just like your Application.
Good Luck!
Jacob
The easiest way to understand this is to just forget that Application exists. Application has nothing to do with the application lifecycle. It is just a global on a process, that can be useful for some things, but is not needed for anything. Everything about how an application runs revolves around the Activity, BroadcastReceiver, Service, and ContentProvider components declared in its .apk.
An instance of Application can continue to exist after your last Activity is destroyed. Even if ALL activities are gone (ie. have all had their onDestroy methods called), the Application instance could still exist.
This application instance could be "re-used" for what you might otherwise think are two separate runs of your application.
This is all explained in detail here: http://developer.android.com/reference/android/app/Activity.html. If you read through it, you should understand everything.
Real quick:
Every activity has an onPause. You can choose not to override it, but it'll get called nonetheless. As soon as you switch away, onPause will be called.
Define "stop". Define "Application". The process may linger around forever, but it'll simply sleep and wait until one of its activities is started.
It's impossible for an activity to exist without being instantiated.
Every code executed runs in a process, so there's always one process for your app. The process will continue to exist after you switch to a different app, but it'll be in sleeping state. Android could at any time kill the process if system resources run low.
Every time you rotate the screen, your activity will be destroyed and recreated, unless you specifically disable that.
I have an application with many forms implemented as separate activities. The form variables are dynamically built based on a database, and there are a ton of variables in the C++ side of the application (accessed via JNI). I don't see how saving out all of this data to persistent storage each time the onPause() or the onSaveInstanceState() of one of these many activities goes into the background is a smart use of processor time. And I don't see how even if I save the local variables for each activity during that time I'd be able to restore a single activity within the context of all the others.
I have set up a service that auto saves the files when I detect that the app has gone into the background. (I set a time stamp when onPause() is called in any activity and then clear the time stamp when onResume() is called on any other activity. If the time elapsed is more than a few seconds, I know I'm not the top activity any longer and the service saves the files).
What I'd like to do is continue on as normal unless the OS kills one of my activities. Since we don't always get notified of this, I thought it would be nice if there were a way to tell the OS that I'd rather you kill the whole app than just one activity.
Thanks in advance!
Setting clearTaskOnLaunch="true" in the manifest's <activity> tag for the root Activity combined with settingnoHistory="true"` in all the activities's tag should do what you are looking for.
http://developer.android.com/guide/topics/manifest/activity-element.html#clear
http://developer.android.com/guide/topics/manifest/activity-element.html#nohist