Hello again.

You opened a little early -- at least according to my atomic clock. Too bad I only came to observe. LOL

OK

Hi, how's it going!

Thanks for the books - just bought them today - and thanks for all the Android answers I've been finding through Google searches

Geez, I am usually wiped out after a day of training.

Hi Mark

May I start with a question?

I have noticed that after you start an Activity form the onReceive() method of a BroadcastReceiver, that the application will appear in the "recent apps" list (press-hold HOME key.)

Android seems to reuse this Intent when the user selects the application from the "recent apps" list.

How might my Activity differentiate between the two senders (my onReceive method vs. the application manager?)

I like options!

Great! I needed to know that.

(I'm from the Java ME space; Android has a bazillion more tweaks and options that I'm still learning)

Cool. And how might I detect if Android has restarted a Service of mine that it killed?

(apparently there is no way to detect that you are being killed)

Right. I thought I was terminating the service after it timed out, but discovered it running again some time later "by itself". Perhaps I did not really kill it. Thanks.

I have another question but I'll let others ask theirs for a while.

I am good, go ahead.

Sean can finish up

still forming mine :)

OK then...

I've learned the hard way that Services can't run forever and TimerTasks in services sometimes are not started.

So I'm looking at using AlarmManager/BroadcastIntent/WakeLock/Service to do this

This gives me three Broadcast intents I have to deal with:

(well first let me describe the background activity - I need to send a message periodically)

The first broadcast Intent is a custom Intent from another application to start the background activity.

Basically, send a group of text messages. Sorry, I am overloading Android terminology

it's not an Activity and it is not a "background"/"foreground" thing, sorry

The second broadcast(s) will be from the AlarmManager. Planning to schedule a repeated alarm and send a group of messages each time

The third broadcast is BOOT_COMPLETED. Since the repeated alarm goes away when the phone is powered off, and I have to finish sending the messages, I use BOOT_COMPLETED to continue when the phone restarts.

I *think* I want to do the message sending from a Service - aquire a WakeLock in the BroadcastReceiver and release it when the last message is sent

I am concerned about not completing the sending task in the Service before I get the next Broadcast Intent. I am not clear about the Service lifecycle, possible reentrance????

Can you suggest a pattern? For example, the "trigger" can happen any time, even while I'm sending messages (I would just ignore it)

OK, I will check out that API

I'm ready unless Terry has something

Still good.

I have some fundamental questions regarding best practices for using LocationManager.

I have what I would think is a pretty common scenario -- I need to access the current gps location from one of my activities, which I do with getLastKnownLocation. I'd like to ensure this is not stale, so I've set up a LocationListener called w/ requestLocationUpdates.

I've noticed that when I am somewhere I cannot acquire location, the gps icon remains indefinitely as it keeps trying to acquire, killing the battery.

I could implement my own timeout mechanism and then call removeUpdates, an manage when/if I want to try again, but do not know if this is what I should be doing.

Also, potentially compounding the problem is that I don't think I am setting up th LM in the right place -- my app has several activites none of which are guaranteed to be open at a given time

yeah, that is what I thought I might be missing

that is a neat idea

Ok, I will look into that, thanks

btw, thanks for pointing me towards the IntentService API; I had completely missed that one. that will help me a LOT

If I care about how old the Intent is (if it took me a long time to get around to dealing with it), I should probably do something like store System.currentTimeMillis as an extra?

That's good to know.

So to use IntentService, does my Service class extend IntentService, and then every time my BroadcastReceiver gets an Intent I need to act on, in onReceive() I create a new Intent with my service class as the target and call startService, and in my service class, onHandleIntent will be called? (ignoring wake locks for a sec)

I was going to apologize for trying to figure out the API in 15 seconds ;-)

so "all I need to do" is make sure that I'm doing my work (and saving my work's state) in a threadsafe way, in case onHandleIntent is called while a prior onHandleIntent method is still running. Sounds like onHandleIntent is kind of like a run() method.

really! so it is automatically threadsafe? cool!

yep

will have to write a test app to confirm that, but cool

do you think I might have to worry about Android coalescing Intents or dropping any if they start building up? (I think I will need to send them at one minute intervals at the most. I don't expect them to bunch up.)

OK, if there is one thing I've learned about Android, it is to expect the unexpected. the source does come in handy

right

does Terry have any questions?

No, just watching.

After seeing Android stop services and drop TimerTasks, I am concerned that the AlarmManager might stop delivering recurring alarms at some point. Is this something you've seen?

hello

Hi, Gerardo!

Any way to detect that one of those has killed you?

Has anybody gotten "WARN/System.err(727): Can't dispatch DDM chunk 46454154: no handler defined" later? I didn't see this before, but yesterday it starting appearing when launching emulators. I can still run but I'd like to know what that is...

well, just will have to let my customer know this. I'll let Gerardo have the floor now. thanks, do have another Q but may run out of time.

thanks Sean

k, as I said it's mostly an annoyance... I'll check the versions

Here's a clue: http://groups.google.com/group/android-dev…

sounds like versioning may be the ticket

Mark, I have your three books now; which might give a good description of the Activity history and the concept of tasks? It is almost as if a Task was going to be an object but then was removed from the API? (or have I missed it?)

(Mark, great books, btw)

cool... thanks

OK, thanks. I will use the FLAGs you suggested earlier to better manage history. Thanks so much for your time.

Thanks!

bye