Hey there Mark :-)

howdy, Justin!

how can I help you today?

Well, let's see...

So I've mentioned how I'm working on try to recreate functionality that already exists on Android for my client because of restrictions that don't allow us to use Google services...

And then need to make Android do things that it really wasn't intended to do...

(howdy, Benjamin! I'll take a question from you shortly, once Justin has a chance)

So that's the context that I'm asking these questions from. I know there are better ways to do these things, but I have these constraints I can't avoid..

So anyways....

I have a service that I need to keep running "indefinitely"

Obviously, Android kills services when it's running out of memory and needs to free it up for other apps...

I've gotten the service to run in the foreground which keeps it alive longer, but it's still not indefinitely...

I was thinking of having a second service that watches for "heartbeats" to see if the first service has been killed and restart it if it's not present....

But that would need to run in a separate process because I think it's the process that gets killed, not the service...

Is something like this even possible to do across process boundaries, or am I really going about this the hard way? Not sure if my explanation has made any sense at all or not?

your second service is as likely, if not more likely, to be killed

you could use AlarmManager to *send* a heartbeat (via a getService() PendingIntent) to your primary service

thereby restarting it if it was shut down

however, this will not help if the user force-stops your app

and, too-frequent invocations of AlarmManager (e.g., every millisecond) will be impractical

Ahh, OK. I think that would be acceptable to not be able to handle a user force-closing the app. Yeah, the heartbeat would be once every few seconds, so that wouldn't tax the OS too much, would it?

let me take a question from Benjamin, and I'll circle back to you for any followup

Sure, fair enough :-)

(Justin: every few seconds will hopefully be manageable)

Benjamin: do you have a question?

Sorry, I have just been call away.

oh, OK

chime in if you have a question later on

Justin: I guess we can continue with your questions

OK, so with the AlarmManager, wondering if it would make sense to initiate that from a process that's separate from the app so if the process that initiated it gets killed, it wouldn't affect the alarm?...

no

AlarmManager itself runs in its own process

it does not matter from what process you register the alarms

OK, so once I initiate it, if the process from which I registered it gets killed, it will still be running until I stop it?

um, too many "it"s in that sentence...

could you try again with more concrete nouns? :-)

Sorry about that, lemme try again :-)...

So once I initiate the Alarm, if the process from which I registered the alarm gets killed, will the Alarm still be running until I stop it explicitly again?

it will run until you cancel it, or the user force-stops your app, or the device is rebooted

it might also stop if your app is upgraded in place, though I am not sure about that

OK, so that's what I was wondering. Let's say I create a second app (that runs in a different process) that, when the alarm is triggered, the intent that's called from the pending intent sends a broadcast message out that the main app will receive to restart the service, would that work? (that sounds really crazy and convoluted, but just trying to see if I can make this more fool-proof)

that seems like overkill and less reliable than what I suggested

Fair enough. OK, this is great, thanks a bunch. I'm going to mull this all over and see what I can come up with :-)

the only thing that might help would be with the force-stop scenario, and I'm not even sure it will help there

So I'm good for now, might be back for another question before the end of the hour :-)

OK

if anyone has a question, chime in

howdy, Ben!

how can I help you today?

Hello

I was on last week, I have a handler that I pass to a background thread from an activity. When I press back, the activity is destroyed. When I re-enter the activity, I don't know how to use the handler.

the Handler is probably gone

I was previously using a broadcast receiver to update the activity's progress bar but it would broadcast after the background thread's operations were done

ideally, your activity doesn't leak a thread in the first place

first, if you plan on having a thread that will live longer than the life of the activity, please manage it with a Service (or just use an IntentService)

I'm using a binder with a service

OK

you can always then register some sort of listener object with the service when your activity is bound, and unregister the listener when your activity is going away

and have the service/thread notify the activity via the listener

Ok

if anyone has any questions, chime in

I'm using the State class from the Busy Coder's guide

I presume that you mean the WeatherAPI demo

Yes

that demonstrates passing a listener on a request, which is another approach to letting the activity know of results, but it does not handle multiple activities

(or even the same activity if the use BACKs out of it and re-launches it)

How can I implement a listener that is usable by the same activity upon re-launch?

as I wrote, you can always then register some sort of listener object with the service when your activity is bound, and unregister the listener when your activity is going away

Hey Mark, quick question when Ben is finished: Where do you archive the Campfire chats?

Justin: right now, links to them are emailed to the cw-android Google Group

I'll be replacing that with an RSS or Atom feed in the next month or so

OK, I'll rejoin that group to get them for the time being, thanks :-)

Ben: your service would hold onto the listener and call methods on it as needed

and, if needed, you'd work out some sort of queue mechanism, if you need to handle the case where events occur and there is no activity of yours in the foreground to receive them

Ok

Is there an example of registering a listener with a service?

no, because that implies binding, and I really don't like binding

Oh I seee

see

what binding examples I do have all use the listener-per-request model, to minimize potential GC issues

Is there a bette way to handle receiving updates from a background thread in this situation?

what are your criteria for "better"?

I guess I am wondering if it is the correct way.

Because of binding

I avoid binding because it tends to introduce too much state -- hence the complexity in that WeatherAPI sample

that complexity gets a bit better with retained dynamic fragments, but not by a ton

so, your first question should be "is binding worth the pain for my use case?"

and that is for you alone to decide

Ok

Thanks!

if you are going to use the command pattern, either local or ordered broadcasts would be my preferred service->activity communications path

both are covered in _The Busy Coder's Guide to Advanced Android Development_, in the chapter on broadcasts

Ok

Hey Mark, one last quick question....

Do you know a good source of information for doing Java NIO?

not off the top of my head, no

OK, that's fine, are you much familiar with NIO, in terms of doing non-blocking I/O on sockets (in a thread) (will probably have questions about that next office hour if you do)?

it's not my area of expertise, sorry

No worries at all :-)

Thanks for your help today, as always :-)

you are very welcome

that's a wrap for today's chat

Take care, see you next office hour!

next one is Tuesday, 4pm Eastern

have a pleasant day!