Hey there Mark!

howdy, Justin!

how can I help you today?

Hey there, I don't think anything too complex today, just a question about Services and onStartCommand()

fire away

So when I have a Service (not an IntentService but a regular Service) and I receive a command in onStartCommand(), if I return Service.START_STICKY, if the process hosting the service is killed in a low-memory situation, it should restart the service automatically with the same intent that I last called startService() with, right?

no, that's START_REDELIVER_INTENT

START_STICKY will restart you but will probably supply a null Intent

Ahhhh, that's the problem then :-)

Yes, exactly!

That's the answer I was looking for :-)

There was something else I was going to ask too, but it's slipped my mind right now. I'll see if it comes back before the end of the hour :-)

OK

Actually, let me make sure I understand something correctly. So if I use START_REDELIVER_INTENT, if the OS kills the process, it will always try to restart it with the last intent that was delivered to it? (like maybe after a 5 second delay? I think I've seen that in the device logs when a process hosting a service is killed?)

I think it will redeliver all Intents you did not mark as having been processed

and, AFAIK, it will always try to restart it

no, I guess you're right -- you only get the last one

Ahh, OK, great to know. I had originally thought that I would need something to monitor the service to see if it was still alive, like registering a repeating alarm with the AlarmManager as a heartbeat mechanism...

But I think that's not necessary at all with this, because the service will be restarted.

that's the theory

That works for now...

I think I remember the second question too

I avoid long-running services like the plague, so I don't have any hands-on experience with this scenario

Yeah, it's not ideal, but it's definitely a requirement for this project :-/

So I remember the second question now...

Where is a good source of NFC tags? I want to start playing with that, do you have any places you'd recommend that are a good source?

I bought a bunch from a variety of itty-bitty online shops

that was a year or so ago

not sure if anyone more substantial has entered the market

So it's just random people selling them then?

well, I suspect they're more than "random people", but not any name you'd recognize

hold on while I find my NFC tag envelope...

OK great

I used BuyNFCStickers.com and Smartcardfocus.us with success

I think I also bought from another little NFC firm, but I don't have the name handy

OK great, I'll check then out. I was at a mobile mondays talk last night where the presenter talked about NFC. They said the tags have gotten cheaper recently, maybe around 50 cents/tag now. Looked on amazon, they're more expensive there still

I also bought from Touchatag, but that was before I understood some of the nuances (e.g., whether a tag is rewriteable), and their tags aren't that useful for me

Oh, OK, good to know. I'll look at those two sources you mentioned earlier as a starting point, thanks for the info

Howdy tunneling!

does tunneling often refer to tunneling in the third person? :-)

yes :)

How are things?

sorry -- there's no beep on this thing when somebody enters the room, so if my eyes meander, I don't always notice

Not a problem.

some things are fine, other things are less fine

how can I help you today?

In Advanced Android, when talking about Remote Services (AIDL), you do a piece on a CallBack object... ring a bell?

yes

I found this tutorial that does a typical Observer pattern by defining a listner aidl

do you know of any pitfalls to either method? I realize that could be a broad stroke question...

well, "callback" and "listener" are largely interchangeable nouns, IMHO

what specifically is different?

well.. good question.

oh, well.. in the "listener" tutorial, he has methods for adding and removing listeners

ah

ok

whereas my callback was on a per-request basis, IIRC

yea

the benefit of the per-request basis is that there is no GC risk

you don't hold onto the callback very long in the service

ic

explicit add/remove saves you a parameter, but if you forget to remove...

right...

hence, I tend to prefer the per-request semantics, if there is a clear transactional feel to the API

if, however, this is more of a true listener (i.e., may get notified about lots of events happening over time), then that per-request approach doesn't fly

yea, it would be asynchronous, sometimes often, and sometimes never

that sounds like more of a listener pattern, or using something else (e.g., broadcast Intents)

personally, I avoid binding where I can

so the Service will sometimes need to respond to a Client's request, and at other times .. the Service would just need to tell the Client that something happened.

Yea, I'm concerned with the Service getting killed and the Client not really knowing about it.

unless the client also has a service, the client is more likely to die off than is the service, outside of task-killing/force-stopping

Oh? I'm not sure I understand..

processes with a running service, on the whole, are less likely to be killed off in the face of low memory than are processes that only have activities

makes sense

the "Service" I've been discussing is a "Plugin", and is a different app.. using your Remote Views example as a starting point

ah

sorry to throw this in the middle, had one last quick question that I wanted to get in the queue for if there's time after tunneling is finished

oh, go ahead

thanks Mark.. ttyl

Question is about Parcelable types

I know on the surface they look like a way to pass objects around in Intents, but I think you said that isn't a good idea, right?

well, there are a few things here

And also that serializing objects is costly and not recommended either?

first, it's pass-by-value, not pass-by-reference

(as is serializing, which is slower and adds no value for the Intent scenario)

second, there are some occasions, particularly with PendingIntents, where the OS seems like it wants to convert the Parcelable back into an object for no good reason, and you crash

third, it smacks of "I don't have a real data model, so I'll just keep passing my model around"

So best to stick with primitive types in intents then, right?

Or store complex objects as records in a database and pass the ID of that record around?

yes and yes

now, sometimes Parcelable is difficult to avoid

Someone on my team is trying to use binding with the service and pass around object instances. That really limits our options, I don't want to do that

my CWAC-Update module, for self-updating apps, needed to use Parceable to have an abstract strategy concept

Is there a good place to read about Parcelable and when it's a good place to use it?

(then I'm done :-) )

not off the top of my head

I haven't found anything either myself...

OK, I'm set, thanks!

no problem

next chat is Thursday, 7:30pm Eastern

have a pleasant day, all!

You too!