On Thu, Aug 11, 2011 at 4:58 PM, Mikael Kuisma <kui...@ping.se> wrote: > System.exit()?
No, a regular stopSelf() / IntentService should be fine. > Since Android keeps the DVM around even after I terminate my > services and activities, I thought it would be a nice place to store the > state via a singelton object to save flash writes. As a cache, sure. Don't count on it though -- save your data before onHandleIntent() returns or you call stopSelf(). Static data members are *only* to be used as a cache. >> Users don't like sloppy developers who keep services in RAM for no >> good reason. Guess what? Users win. > > A good reason is to save unnecessary flash writes, wouldn't you say? Users don't notice "unnecessary flash writes", assuming that they are done on a background thread. They do notice services running 24x7. Developers who create such everlasting services have harmed Android's reputation and spawned the creation of task killers and equivalent capabilities within the OS itself. You are welcome to write daemon processes that run forever on your 8GB RAM Web server. Please don't do it on a 192MB RAM phone. >> You have to know "how long the next sleep will be", by definition. >> After all, you have to tell Android when to resume operation of your >> code, regardless of how you accomplish it (AlarmManager, >> Thread.sleep(), postDelayed(), etc.). > > I don't control the user, I'm sorry. Then who is calling set() on AlarmManager to trigger your PendingIntent? -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in Oslo: http://bit.ly/fjBo24 -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
