Frank, yes.. in short, badly behaved (coded?) applications that are not shut down can drain battery life. I agree with Streets tho.. don't use System.exit, just call finish() on the activity, and make sure to implement the onPause and onDestroy correctly, cleaning up all threads, etc. Try teaching an end user that an app may have threads left over which is eating up your battery tho. That is why I think one of the most often posted end user threads is about battery life. When I use Advanced Task Killer to kill all apps before I sleep my phone, my batter will last all day easily, that includes surfing the net, checking email several times, doing several phone calls, using the maps, etc. Yet, my dad, who today I talked into buying an Eris since he doesn't need the keyboard of the droid, said he did some searching and found tons of posts on users complaining of horrible battery life. Why is this? I can't imagine those users simply leave their phone on all the time. The only thing I can think of is bad battery or rogue apps that are not properly cleaning up things that consume battery life. If you sleep your phone... does the front most activity/app pause? Or if it spawns a thread (or more), do those still run even with the phone sleeping? I know sometimes I've had the maps app going and press the power button to sleep my phone.. come back a couple hours later and my batter is drained (or some sort of drainage did occur). I can't say for sure it was the maps, but I thought sleeping the phone would only allow background services to run, and even thought perhaps only phone specific things like sms, emails and phone calls would continue to run and most other things would be paused... with the exception of timer services that wake up the phone on some condition.
On Thu, Jan 21, 2010 at 7:30 PM, Streets Of Boston <[email protected]>wrote: > If you want to make sure that your app shuts down completely: > - Implement onPause to pause any threads running in the background (if > you have any) > - Implement onDestroy to clean up any other resources (stop threads, > if any, for example) > > Short of the user pulling the battery, the onPause is guaranteed to be > called. > If the onDestroy is not called, your process has been killed > forcefully by Android --> resources are cleanup anyway. > > It is absolutely not necessary to do a System.exit() and can result in > the behavior described by Pink444 (restarting of the process and > activity). Even the Anrdroid apps that do implement a 'Quit' or 'Exit' > button, most (i hope all) of them just do a call to 'finish()' and > clean up stuff in the onDestroy. They should not ever call System.exit > (). > > For apps that behave badly and leave threads actively running when > their activities are in the background: They indeed will drain the > battery. The user can figure this out, though (Battery info) and kill > or even uninstall the app. For your app, just make sure your app > behaves gracefully :-) ... it's in your control. > > It's just another model of programming model (although very close to > regular event-driven programming) and that's actually the best part > about it. I'm learning something new! > > In general, you can write activities that can be called by other > activities. Your activity can be called within the process of another > activity that is not yours. Doing a System.exit() may adversely affect > the calling (parent) activity. > > On Jan 21, 5:27 pm, Kevin Duffey <[email protected]> wrote: > > I don't know if I like this model. :D I'll give you one reason that I > don't > > know if it comes up or exists often, but I think it's one of the most > > confusing issues for non-techie (and even techie peeps that don't know > about > > programming and threads and such) users for android devices. The problem > to > > me is.. I am a developer that will without a doubt make mistakes. As > such, > > if I am writing an app that otherwise seems to run fine on devices, but > I've > > forgotten to stop threads when my app is paused (either by user hitting > > home/back, phone call, etc).. to the users, my app may be finished. The > > notion of not closing down an app and users getting used to that idea > means > > that they need to trust every app they ever get that it wont leave some > > battery draining possibility running behind. Now, Mark I know will > correct > > me if I am wrong here, I've read his first book mostly and other books on > > Android. It is up to us in every Activity to handle the pause/resume, > > create(bundle) to resume properly if the app was actually shut down and > > bundle info saved, etc. But I still can't help to think that there are > thos > > eapps that have "bugs" in them that have either a thread left behind > > (assuming android doesn't completely shut it down) that may end up > draining > > the battery. I don't know for sure, but a few times now, I've come back > to > > my phone a couple hours later to find it dead, from a completely charged > > state prior. And I don't know why. My only guess is that I left something > > running, like google maps with wifi that I thought was stopped/shut down > > cause I hit the home/back button. Being a developer I know it's probably > in > > a paused state, but this battery drain thing has happened a few times. > > > > Thus, my thought is.. to avoid my app possibly draining the battery, I'd > > rather have a quit option to exit the app completely.. it's done, > unloaded, > > no threads, etc. Now on iPhone, it's well known that presently pressing > the > > one button kills the apps. The apps have the option to save state info > > before shutting down, and some apps make good use of this to make it look > > like it never shut down.. restoring the user to where they were > previously > > at. Most iPhone apps dont do this tho. So the thing is, this not shutting > > apps down completely is a different mind set that I honestly am surprised > we > > would want to program to as developers concerned about battery drainage. > I > > would think since one of the most important things when writting android > > apps is to consider battery life, would be to do everything we can to > shut > > our app down if the user hits the exit button. Sure, if they hit > back/home, > > or a call comes in or they go to status bar and select something, the > > pause/resume notion kicks in. But I am having a hard time understand why > you > > would not want to put in an exit/quit option and cleanly shut down > > everything if they choose this? I do see some games on Android doing > this. > > > > So Mark et all, I understand the basics of what you are saying and for > some > > apps this makes perfect sense. But some, like games or those that may > spawn > > threads or do other cpu intensive things that could drain battery > especially > > if done in threads, it seems to me to be safe and keep our ratings of our > > apps form going down to 1 star, we'd want to program defensively and make > > sure our app shuts down completely. > > > > Just my .02 on the matter. > > > > On Thu, Jan 21, 2010 at 8:52 AM, Vladimir <[email protected] > >wrote: > > > > > > > > > "But my question is "Why does user has to wait till android closes > > > particular application, Instead why doesn't user do this"?" > > > > > Because this is how it is done in Android. If you change it, users > > > will get confused and eventually annoyed. > > > > > On Jan 21, 3:58 pm, pink 444 <[email protected]> wrote: > > > > Thanks for your replay. > > > > > > And i went through the link , which you specified. > > > > > > As i understood process will be killed by android only. > > > > > > But my question is "Why does user has to wait till android closes > > > > particular application, Instead why doesn't user do this"? > > > > > > Instead of waiting till android system cleans all the resources used > > > > by the application , It is more efficient if user able to clean all > > > > the resources used by the application. Especially it is useful in > > > > embedded environment like mobiles. > > > > > > If you take any game and user does not have any option to close the > > > > game . Then the application has to wait for android system to clean > > > > resources , which are owned by the application. But these type of > > > > applications are not used by the user regularly(Generally Once in a > > > > day or week). > > > > > > On Jan 21, 3:06 pm, "Mark Murphy" <[email protected]> wrote: > > > > > > > > In my application i have to close the application. > > > > > > > No, you don't. > > > > > > > > Hence i am using System.exit(1). > > > > > > > Please do not do this. > > > > > > > > But some times it is trying to restart entire application. > > > > > > > > What is the problem? > > > > > > > You are trying to close the application. Please do not do this. > > > > > > > If you want to simply close up an activity, the activity can call > > > finish(). > > > > > > > > How can i close an application safely? > > > > > > > You do not need to: > > > > > > > > http://stackoverflow.com/questions/2033914/quitting-an-application-is. > > > .. > > > > > > > -- > > > > > Mark Murphy (a Commons Guy)http://commonsware.com > > > > > Android App Developer Books:http://commonsware.com/books.html > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to > [email protected] > > > To unsubscribe from this group, send email to > > > [email protected]<android-developers%[email protected]> > <android-developers%2bunsubs[email protected]> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en- Hide quoted > text - > > > > - Show quoted text - > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
