hello, EGHDK

how can I help you today?

Hey Mark, if you're free. Some more "Java" questions mostly revolving around the lifecycle of objects and memory and such. So basically, when I say String myName; Does that create an object? (Take up memory)?

no

I know that an object variable is just a reference to a spot in memory.

correct

But I was talking to someone today, and we weren't sure if having an if statement that loops isn't "good" if you are constantly creating variables "inside" of the if statement.

So I'm trying to figure out... what is bad java practice in a loop.

what is bad is doing the same thing over and over unnecessarily

declaring a local variable does not actually do anything

(and, if the variable is unused, it should get optimized out anyway)

okay, so saying String one, two, three, four, five; won't actually create 5 string objects at all (it doesn't take up any memory), because theres nothing assigned to them?

correct

not really

after all, if() will evaluate the block either zero or one times

I guess basically, how does java know to throw out my object once I'm done with it, in the loop?

first, you do not have a loop -- if() is a branch, not a loop

second, the local variable will not be "thrown out" once you leave the if() block in the second example -- it will be "thrown out" when you leave whatever block the local variable is declared in

sorry... for loop.

It's getting late hahaha

Basically, I'm just trying to figure out if I have ever done this in my code "what is bad is doing the same thing over and over unnecessarily"

well, I don't have an example handy for you

But, I'm not necessarily sure what constitutes as bad. Any easy examples having to do with variables?

I mean I may be over thinking this, so it's not a big deal. I think my first question cleared this up. The whole String myname; doesn't do anything cleared up the current question. heh.

pick up a copy of _Effective Java_ by Joshua Bloch

sorry -- Ubuntu froze on me, and I had to reboot

Not a problem. Looking up the book now!

if you search Google (java optimize loops), you'll get various pages discussing the topic

such as http://www.precisejava.com/javaperf/j2se/Loops.htm

and http://www.appperfect.com/support/java-coding-r...

Okay, so my last question is about how an object get's put up for garbage collection.

So, I had this conversation about you before, and I was saying that "Hey I should NULL out everything after I'm done with it right!?"

and my response should have been "that's rarely necessary"

Yeah, so now, I'm trying to figure out how they actually get put up for GC.

In Android... especially.

I am not completely clear on your "get put up for" phrasing

an object can be garbage collected when it is no longer reachable

(or http://goo.gl/MpEjH for that second one, as the parentheses seem to have fouled up Campfire's URL linking)

I will read those two. But, in respect to Android, an object won't exist anymore if the activity is closed?

well, that depends on what the object is and if it is reachable

ideally, when an activity is destroyed, it and its widgets, and their listeners, etc. are all eligible to be garbage collected

I feel like there's a "gotcha" coming with that

Since you said "ideally"...

well, not every developer does things in an ideal fashion

static data members, for example, are "permanent" references to an object

if I have static EditText transcript; somewhere, and I assign an EditText to that transcript static data member, that EditText object cannot be garbage collected

Yeah, I've used those before, so I make sure to null those out when I'm done.

the issue is not only the immediate object referenced by the static data member, but all the objects that can be reached by the object referenced by the static data member

for example, an EditText has a data member that references the Activity that hosts the EditText

so not only will a static EditText fail to be GC'd, but the Activity will fail to be GC'd, because you can map a path from the static data member to the Activity

this, in turn, means that all the other widgets in the Activity cannot be GC'd

this, in turn, means that the listeners associated with those other widgets cannot be GC'd

and so on down the pike

EditText has a data member that references the Activity or references the context?

well, in any sensible use of an EditText, those are the same thing

Context is a class; Activity inherits from Context

zgotcha, just wanted to make sure.

Activity is a subclass of context?

there's a couple of other class layers in between, so Activity indirectly inherits from Context

Gotcha

Let's say I have two activities, Activity A and B. On activity A there is a button that takes you to Activity B. If I make a bunch of objects in A in onCreate, and then I press the button to go to activity B do all of those objects I just created stay in memory?

sure, because activity A has not been destroyed

So technically I can have an application that goes from A to B to C to D to E and in each activity leading up to E I can create a TON of objects, and they are all taking up memory?

yes

And if I press the back button all the way back to A, the back button calls finish on each activity all the way back to A. So if all the activities are finished, any objects they held should be (barring any static variables) all freed up by GC?

correct

Great.

note that Android's GC engine is optimized to minimize CPU usage

hence, it is not the fastest at plowing through a lot of garbage

but, eventually, it will all get freed

Gotcha.

Does it save stuff to be Garbage collected? and then do it when it needs more memory?

not really

it gets more aggressive about finding and clearing garbage if available heap space gets low

though that sort of behavior tends to vary by Android OS version

gotcha.

So in general, if an object (activity) creates more objects, when the parent "dies" so do the children?

well, that depends on the objects and whether or not they are reachable by something

Alright, I think I have a little more of a grasp on it now.

Thanks Mark

This is the stack overflow question that sparked the interest for objects and GC again: http://stackoverflow.com/questions/271526/avoid...

OK

All done for tonight. Thanks again. Have a good night

you too!