What is the best way to handle a service that needs to live forever? Or is there a better way of doing it...

Question

I have an activity that looks up telephone numbers inputted from the UI out of a local sqlite database that shows the originating city/state of the number. Part of the activity also consists of a service that listens for incoming and outgoing calls on the phone. When a call is made, or a call comes in, it displays a Toast message at the bottom of the screen with that number's city/state from the database. As far as I am aware, there is no way to achieve this functionality without making the service live forever. Right now I have an alarm setup to run every hour and restart the service if it has been killed. I remember an old app that worked this way called "missed call" which changed the notification LED color based on the message received (missed call, sms, email etc.). My question is, is there a better way to go about doing this? I know keeping services running forever is extremely frowned upon, but I don't see any other method unless I'm missing something.

Thanks!

Answer 1

Can't you just use an intent to launch your notifier when a call arrives? It shouldn't be difficult to write something to retrieve and display a database record quickly.

Answer 2

What you describe in your comment to Evan above is exactly how I did it in my own app that listened for incoming and outgoing calls (a little app called MinuteWatch that no one bought).

There's no broadcast intent for incoming calls, so how else are you supposed to do it? I imagine it's so you can't delay or otherwise mess with incoming calls because they're crucially important, but I think it condemns you to an infinite service. It's the only thing I can think of that's specifically un-hookable. Even things like checking-for-tweets-every-15-minutes, you could do that with a recurring alarm, and not have a service hang around.

Even if the Android team doesn't want a INCOMING_CALL event, I think the they should consider putting in broadcast Intents named CALL_RECEIVED and CALL_ENDED and CALL_HELD, that will at least notify you right after the fact. How else are you supposed to build an alternate call log tool?