Is it possible that my activity is not destroyed when i press the back key on my device?
It should have a button to do so. But i want it to continue running while i check my emails or something!
Yes it's possible, but you're not supposed to rely on it. Android simply leaves it in memory until it absolutely needs to be destroyed. If you want something to run in the background until it's done, then you want to use a Service.
Related
I'm new to Android development. I'v developed an android application which needs to store the connection/data even after 1 hour. Currently I have all the data and the connections(chromecast mediaplayer) in a singleton class. But, when the user puts the app into the background for about an hour, the activity is destroyed so the connections,data etc are lost causing my app to crash when re-launched.
I've read up on the android services, Can I use these services to hold the singletons so even when the activities are destroyed I can have data binded back to the views when re-launched?
Or is there a way to make sure that the activities are not destroyed when android decides to do a cleanup?
Please advise
Thanks.
I think you might misunderstand what an Android application is.
Your application is a bunch of components that run in a single Linux process. Components come and go, within that process. You have absolutely no control over the lifecycle of the process itself.
The answer to part of your question is that "yes" a Service will stick around after an invisible activity is destroyed.
When an Activity becomes invisible, it gets destroyed. If your process is not doing anything else, then the process is likely to be killed too.
If your process is also running a Service, it is less likely that it will be killed. It is just less likely, though. The process will eventually get killed. When it does, your singletons will be gone. There is nothing you can do to prevent that. So the answer to the second part of your question is "no". You cannot depend on singletons in your service to be around when the process is relaunched
You might look into using the Application object. Its lifecycle is roughly the same as that of your process. It will not live forever but it will be around whenever any other component of your application is around (except ContentProviders).
It sounds like you want to keep connectivity to a chromecast device around when your application is in the background. Obviously services can be helpful but I have a few comments that may come handy:
Services can be killed by system but based on how you have set them up (e.g. the return value of onStartCommand()), they can be restarted by the system. When that happens, you cannot expect that your dynamic data is still there (for example your singleton). You need to include logic to recreate what you need again (for example, rebuild your singleton)
Phone can go to sleep when left for a little while (or user can lock his/her phone), so when phone goes to sleep, wifi may drop after a little while, based on the phone settings and the build on your phone; some do this more aggressively and some not (even if you hold a lock, it can still happen). The point is that you have to assume that it may happen. Even if you have a service, your Cast connection will go down due to wifi loss, so the proper way to handle things is not to try to keep the connection up all the time (since you can't) but is to have logic to re-establish connection when circumstances is right. In order to do that, you need to preserve enough information to be able to bring things to the state that they were. Your logic should also be intelligent enough not to reconnect if it shouldn't.
Android O.S can destroy any activity , when it is low at resources it destroys any activities to make more space for other apps.
But you can use background service to hold your singleton
You can use this link to create your background service
For testing purposes I need to easily reproduce a situation when Android system decides to save a state of and kill a background application, in the same manner as it normally does for memory optimization purposes. In fact, I need also to test the restoration process of such a removed process when a user switches back to it.
The straighforward approach would be to open the application and then open more other tasks trying to allocate as much resources as possible. That's too complicated and unreliable.
I've found this question on SO, but the answer implies simply killing the process, which seems not an equivalent, because there seems no means for further automatic restoring of the killed process with a saved state, when a user decides to switch back to the application. If I understand correctly, after such explicit killing the application, if started, will run from very beginning, not from a saved state. Please, correct me, if I'm wrong.
According to Android documentation, what I need is performed by ActivityManager.killBackgroundProcesses(packageName), but this is the programmatic way of doing the thing. Is there an utility which already provides the same option from UI?
If I understand correctly, after such explicit killing the application, if started, will run from very beginning, not from a saved state.
That depends on how the app is launched. If you mean from the launcher icon, yes. However, the user could return to you via the BACK button, or via the recent tasks list, depending upon circumstances, and those would return the user to the spot they left, not the "very beginning".
Is there an utility which already provides the same option from UI?
On an Android 4.0+ device, with your app in the background, open up the recent tasks list (long-press HOME or press the dedicated RECENTS affordance), and swipe your app off to the right. This appears to basically call killBackgroundProcesses() on that package name.
I have not tried this in an emulator, but probably it does the same thing.
I recently launched my first iPhone app and it seems to have people in the Android community asking for it ... so I started developing w/ the SDK.
The first thing I noticed is that in my iPhone app I would store certain session wide variables in the appDelegate. As I don't have this structure in Android I'm curious how Android developers keep track of application state across the app (hopefully w/out a ton of singleton objects?)
If the singleton object approach is how most developers do this - how can I ensure the application starts at a clean state each time the user clicks the "home" button and re-clicks icon (is there something I can add to my manifest to ensure it doesn't support multitasking in this way?)
My app has a lot of session specific state and for the first iteration won't yet support multitasking :(
First, android app can consist of multiple Activities.
If you want to share state between Activities use Application class: How to declare global variables in Android?
If you only have one Activity, then you can save state there.
Beware: when activity is not Active (it's GUI not showing) it does not mean that it is killed. So if you use your app and then close it, open another app, then go back to you app, it might be still "alive" (kept in memory) and the state would be preserved.
The best way to handle this is to hook into Activity lifecycle. Then you can set/reset data at will.
If you want to close the app when the user hits the "home" key, you can call finish() into your onPause method.
See this link:
Killing android application on pause
I find Singletons to be the best way to retain application state in Android applications. You can listen for when the user leaves the application through the onPause() and onStop() methods of the currently focused Activity, and do whatever you want with your data at that point. It's not good practice to try to override the OS's lifecycle management of your application (e.g. trying to kill your process when Back is pressed). If you want the app's state to reset every time the user leaves the application (via pressing Home, or being interrupted with a phone call or notification or what have you), simply put all your session data in the Activity itself. When the user leaves it will be destroyed and recreated when the user returns.
There are obviously specifics that I don't know about your application, but once you get familiar with the lifecycle of each screen (Activity) and of the application, you'll be able to use the callbacks to manage your state however you see fit.
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
I wrote a simple app reading a page of text via text-to-speech. It works in principle but now I need to implement onPause(), onResume() etc. in a way that would make sense to the end user.
Specifically about onPause() I have 2 options:
Pause reading, with the intent to
continue exactly from point left.
Continue normally, as if the
activity is still visible.
The 2nd option looks more sensible because if it's not a visual activity, why let visual disturbances interrupt speech?
However, I am not sure whether there are other system-wide considerations ("side-effects") that I must be taking into account when implementing onPause() as a "do nothing" function.
Aside from onPause() being called when an activity is no longer visible, are there other events or side-effect that I should take into consideration when deciding whether to stop or not to stop text-to-speech?
The only thing that comes to mind is if the system runs out of memory. Activities that are out of sight can be killed by the system if it needs the memory. What I'd suggest doing is using a long running service rather than an Activity. Let the activity manage the service but let the service handle the reading of text. If you still want to use an Activity, I believe there is a setting you can set to make killing your unseen Activity a last resort.
If you were being interrupted by the phone (or anything people listen to), you wouldn't want to keep producing sound.
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