howdy, Kevin!

Hi There

hi everyone

howdy, Scott!

Kevin, you got in first...do you have a question?

Just going to listen for now

OK

Scott, do you have a question?

struggling with screen lock, but i think i just figured it out

howdy, NetApex!

i really planned to just listen - let you know i enjoy your books

thanks!

Hello there

NetApex, do you have a question?

I don't at the moment.. because I forgot what it was. Give me a couple it will come back.

Um, OK

if anyone has a question, chime in

So how come we don't have the honeycomb sdk yet?

well, we have the preview SDK

It's not that complete though is it?

it's a mixed bag

in terms of new stuff, it is over-complete -- I suspect they are still deciding what is baked enough that they're leaving in

however, the preview SDK appears to be missing Google Maps and such

but the ways of Google are mysterious

Strange that 3.0 is coming and not many people have 2.3

oh, that's not surprising

Since no one has a question, I'll ask one

I'm still having problems with Activities and the singleTop, singleTask settings

I did a test with 3 activities and switched back and forth. Seems like a lot of activities can get created

It would be nice to have an activity stay around a bit longer

that's not necessarily a problem

why?

(btw, howdy, David!)

Hi

I'm working on a project that someone else wrote that has a lot of initialization stuff in the main activity and they expect it to stay around

A lot of global static variables

if they're caches, that's not a big deal

So if that activity get's recycled then the variable will always be there?

so long as the process is around, yes

static data members are static

they live outside any given instance of any class

semantically, they're globals

now, if the process goes away (e.g., user presses HOME and hours elapse), the statics go away as well

which is why they're fine for caches

but they are no substitute for a persistent data model

Should an activity be just a light-weight container for a view?

I'm thinking about putting code into an application object

from an MVC standpoint, the activity is more or less the controller

(boom, thanks Kevin! That reminded me of my question!)

Application objects are more or less equivalent to static data members, in terms of lifetime

Go ahead NetApex

a bit more awkward to access, but you get the benefit that they're a Context

I have an app that I was working on that did a swipe to get to the next/previous activity. Would it be less process intensive to make the swipe go to another view instead?

that's not possible to answer in the abstract

Consider the activity just has text and an image

tactically, yes, it will be less CPU intensive to flip to another view (e.g., my ViewSwiper component)

strategically, there may be reasons for having them as separate activities

I just blogged a bit in this area: http://commonsware.com/blog/2011/02/14/nat…

Ahh nice timing

Ok going to go have a read really fast

meanwhile...

Kevin, do you have a question?

So many questions....

oh, wai, sorry

mixed names up

trying to get the newcomers

David, do you have a question?

I have a question on PushEndpointDemo. I found out that onMessage()in C2DMBaseReceiver.java doesn't call onMessage() in C2DMReceiver.java

C2DMReceiver is a subclass of C2DMBaseReceiver

Yes.

onHandleIntent() of C2DMBaseReceiver dispatches to the various abstract methods, such as onMessage()

there is no onMessage() of C2DMBaseReceiver, except as an abstract method declaration

hence, onMessage() in C2DMBaseReceiver is not supposed to call onMessage() in C2DMReceiver

How can I make onMessage() in C2DMReceiver.java is called?

follow the overall C2DM recipe

Chapter 20 of _The Busy Coder's Guide to Advanced Android Development_ IIRC

Thanks

Mike, do you have a question?

OK, Kevin, back to you, for real this time :-)

I have a service component lifecycle question. What happens to a service which does not respond to ondestroy (if called) when the component is in its own process? I'm finding little information on the full dirty lifecycle :-)

there is no such concept as "does not respond to onDestroy()"

if you do not override it, the implementation in Service gets called

if it takes too long, Android nukes the component anyway

In regards to Services, what's the best way to implement a service that you want to stick around after an activity finishes but that you can still interact with?

you have to use startService()

either use the command pattern (i.e., send data via startService())

or use both startService() *and* the binding pattern

the latter is a bit unusual

Problem with startService is that the service doesn't end unless you end it, right? Then how do you know when your app is done?

to stop the service

you don't

do not start services without a clear picture of concretely when you will end them

hence, this goes back to your "you want to stick around after an activity finishes"

We have a service (old code) that waits on an object (suspending itself) and so it lasts forever

My machine into hibernate mode. I didn't see your response. :-)

Kevin: you really need to rewrite that

I'm in the process of doing that. That's why I need to know the best way to do it

(Mike: scroll up in the chat log -- the messages should be there, no?)

Kevin: it is impossible to advise you in the abstract

it went to sleep before your response

either the service needs to know when to shut down based on work (e.g., a downloader IntentService)

We have a downloading/uploading service

OK

It waits in a thread for more files

ick

you're better served having something tell it "here's what to upload/download" via startService()

If it didn't, it would shut down. I guess we could have a combination of IntentService and binding?

then, it can shut down safely when there are no more outstanding requests

no, you can't use that combination

just pass the upload/download details in extras on the startService() Intent

IntentServices will start and end when finished, which is good

and it already has a background thread, which simplifies matters

but it only works well when told what to do via startService() vs. some sort of internal monitoring (e.g., thread watching for changes in a directory)

One of the problems is we need to communication progress so the service sends info back

broadcast an Intent, or use a Messenger

Ah

Someone else can go

In the isolated process / service not responding case to ondestroy - does the framework just spin up another service component?

No

it just terminates the component

if it was already being destroyed, it will not create a new one

ok. What happens? process gets yanked?

the component is terminated

if there are no running components in the process, eventually the process will be killed

ok. if you have threads lingering when that happens?

first, don't have threads lingering

and all threads go away when the process hosting those threads is killed

ok. how would you build something using JNI that monitors file change notifications then that can shut down?

well, I wouldn't, because I don't use JNI, outside of book examples

it's been 11 years since I did any serious C/C++ work

regardless, it should not be in its own process, anyway

ok. Am I kind of stepping outside the design paradigm to want a long running service that can interface with the lower level system in this way?

long-running services themselves are "outside the design paradigm"

except in rather unusual circumstances (e.g., VOIP client)

JNI doesn't really influence that one way or another

checking periodically, ideally with a configurable period, is more in line with Android development models

fitz: do you have a question?

ok. Is there something else you'd recommend on android to build a long running service or really, i'm just in for trouble

not - reading discussion and on conference (yawn) call

Mike: that's impossible to answer in the abstract

avoiding long-running services is very important

well, my example is i want to build a file monitor that starts with the phone, but i don't want it to run when the phone is powered off

by definition, it can't run when the phone is powered off

off is off

well, yes

i mean, i wouldn't take a wake lock, etc

your problem is "build a file monitor"

correct

why do you want to "build a file monitor"?

I have an application on the market that sends photos once they are dropped from the camera application

then poll

AlarmManager, wake up every so often, look for images

let the user choose the polling period via a PreferenceActivity

ok. so you'd drop the monitor and do a periodic poll instead?

absolutely

sure. That's easy enough

gives the user more control, keeps the service out of RAM except when it is actually delivering value

if you don't use a _WAKEUP alarm, it won't occur when the device is asleep

ok. That helps a lot Mark. The reliability was pushing me this way already :-)

OK

anyone else have a question?

What are the pluses/minues to using a Messenger vs Broadcasting?

No, but thanks for that blog post!

NetApex: you're welcome!

Kevin: broadcasting is nice -- works across multiple activities, you can use an ordered broadcast to put up a Notification if no activities are visible, etc.

however, for Android 1.5, it is always a true broadcast, to the whole device

API level 4 introduced setPackage(), which lets you control the scope to keep it within your app

We're going to only be supporting 2.0 and above

Messenger is nice for very tightly-scoped communications (i.e., for this operation, always let this specific Messenger know, so it can communicate back to this specific activity)

however, Messenger is a pain with configuration changes

(e.g., screen rotations)

Ah, I started trying to use it but it was a bit complex

I'd lean towards broadcasts

if you don't need 1.5 compatibility

Right now I'm trying a regular binding service with a thread that does broadcasts

I'm waiting in the thread to keep from recreating the thread

Not sure if that's a good idea or not

you lost me

you mean that the thread is blocking on a LinkedBlockingQueue or something?

Sorry, I have a regular Service that I bind to so that I can set another object to facilitate communication

No, the thread is just using the wait() method

all else being equal, I'm a fan of java.util.concurrent vs. arbitrary objects and wait()

I figure they did a lot more debugging that I can skip... :-)

Do you think I should forgo the thread and just use and IntentService?

so, for example, you'll see in the Advanced Services chapter a service that uses a LinkedBlockingQueue for asynchronously executing Beanshell scripts

well, IntentService certainly simplifies a lot of stuff

if you do not need a multiple-thread pool, and it otherwise fits, I'd use IntentService

ok

if you need lower-level control, rolling your own thread pool is certainly doable, but, again, I'd use the java.util.concurrent classes if they fit your needs

Problem is that I'm sending a lot of information back and forth

that violates the "and it otherwise fits", so IntentService is out

IntentService is best for throw-it-over-the-wall stuff, with light feedback

not a rich two-way API

I guess that's why I did the binding

binding is the only way to achieve that, painful as it is

and so rolling your own threads for background processing is probably the right answer

anybody else have a question?

yes, I do

fire away!

just noticed that you were speaking at the AnDevConf in March. Do you think this conference has a lot of value for an intermediate level developer?

will there be good content for the intermediate level developer? yes

is it worth the entrance fee? depends on whose money it is... :-)

it's put on by a professional media firm, and so it is pricier than I|O or a droidcon

ok, that's helpful. Hope to see you there!

sounds good!

any other questions?

quick one - do you know how to programatically turn off "screen lock" ?

or delay its timeout ?

I think there's something in Settings.System or Settings.Secure for that

if the latter, ordinary SDK apps can't change it

both of those are in the android.provider package

i don't want to unlock the phone, but my talking app gets terminated by the screen lock timeout

talk faster

:-)

it can wait for next time

anyway, that's it for today's chat

next one is Thursday, 8pm Eastern / 5pm Pacific

have a pleasant day!