Kostya Vasilyev wrote: > Lew wrote: > >> >> Use what makes the most sense *in the code* to express the logic. >> In your case this sounds like using inner classes instead of >> static nested classes. >> >> The rule of thumb is that inner classes are for when the inner >> instance needs access to the outer instance's state, which you >> say you do. Ergo, use inner classes. >> >> The rule of thumb is that static nested classes are for when >> the nested-class instance doesn't need access to the enclosing >> type's instance state, but its semantics are highly local to >> the enclosing type's needs. >> > > Two more cents on this: > > A non-static inner class, nested in an Activity, can be a bad thing if > it's somehow carried over the activity being recreated (i.e. configuration > change), causing GC for the old activity instance to be delayed until it > (the inner class) goes away, presumably with the new Activity instance. On > a platform with limited memory resources this can be undesirable. > > I recall seeing some code on this list that did this with AsyncTask, there > may be other cases. >
Lifetime is important to manage. Inner class instances should not outlive the outer instance to which they're tied, and in general probably should not be visible outside the outer instance. I know I took a risk with that generalization, but Kostya's point is generally true for any class or instance member. If you leak a reference out of the context where it makes sense, you risk packratting instances that should go into the GC hopper. Scope and lifetime are related but different things. If you don't manage the lifetime of each object you risk memory issues. -- Lew -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
