Carl Barton wrote: > I have spent a lot of time playing and researching (including > subscribing to the Mark Murphy’s CommonsGuy stuff...excellent by the > way) and I think I have enough info to be dangerous. > I am just having issues coming up with best practices for doing what I > need to do.
Who-hoo! I make people dangerous! > All this stuff is working at this point but I just > need to make sure it keeps itself running at all times (or will always > be available when needed at least). I'd link to my "Diamonds Are Forever, Services Are Not" post on AndroidGuys, but they're still undergoing yet another host migration... > My initial thoughts were to have a service which starts at boot handle > the sms messaging (in and out) and incorporate a content provider in it > to provide access to the collection of messages (Sqlite) to other > applications requiring it. I tried launching the service from an > activity but if someone uses a task killer to kill the activity it seems > to take the service down with it. I tried having a service that runs at > boot but had trouble getting it to launch an activity when a new message > arrives (probably my issue). > > So, after floundering back and forth with my indecisions of how best to > architect it, I figured I would ask around to get some suggestions and > then attack it from there. So, any ideas from anyone? First, services really aren't supposed to keep running. In fact, it is the fact that developers keep creating these always-running services that we're in our current war with the task killer applications. That being said, there are five main ways a service can stop running when you're expecting it to stay running: 1. You had a garden-variety crash due to a coding bug. With sufficient exception handlers, this should not be a problem. 2. You are being kicked out of memory to free up memory for something else. In principle, your service should be automatically scheduled to restart when memory space becomes available. Hence, there's nothing specifically you need to do here, other than be prepared to pick up where you left off at any time. 3. The user terminates your service via the new Services panel in the Settings application in Android 2.0. This will stop your running service, but relatively gracefully AFAIK. If your application is designed to not be in memory all of the time, but rather react to incoming events (SMS, alarms), this should not pose much of a problem. 4. The user attacks you with a task killer application. There is no defense against this, short of threatening legal action, until and unless there are changes made to Android itself. 5. The user powers down the device, removes the battery, sees if the phone can float, or otherwise causes the device to stop running altogether. There is no defense against any of this, either, unless you have some sort of USB-connected flotation device. With respect to spawning an activity on an incoming message, that should be possible, but please please please consider making it a Notification instead, or giving the user the option of a Notification or having an activity pop up in the middle of whatever they're doing. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.2 Available! -- 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
