Ah, I also apologize for my previous (perhaps misleading) line > I guess the bigger problem that in Android static data members cannot > be statically checked to be "alive".
By this, I mean that in the standard toolchain (i.e., without static analysis) you can't statically validate your code uses statics in a good way. Because of this, you have to manually insert code which deals with this, but you also (without a static analyzer) can't have confidence that your dynamic checks are sufficient to avoid problems. I should have separated "static" (the Java keyword) from "static" (compile time) Kris On Fri, Mar 15, 2013 at 5:21 PM, Kristopher Micinski <krismicin...@gmail.com> wrote: > On Fri, Mar 15, 2013 at 8:56 AM, Kostya Vasilyev <kmans...@gmail.com> wrote: >> >> >> On Friday, March 15, 2013 5:29:03 AM UTC+4, Lew wrote: >>> >>> Kristopher Micinski wrote: >>>> >>>> I guess the bigger problem that in Android static data members cannot >>>> be statically checked to be "alive". [...] >> >> >> if (gInstance != null) not working in Android for some reason? >> > > This isn't static (compile time) checking. It's a dynamic check you > have to remember to manually insert. > >>>> >>>> >>>> Moreover, in Android it's a fact of life that your app will die and >>>> restart. You can really only use statics for "caching" type purposes, >>>> but working with them in a safe way quickly becomes extremely >>>> complicated. Instead of doing this, you can typically replace >>>> singletons with some Android specific utility (a Service or >>>> ContentProvider, say..) that allows you to implement the "singleton" >>>> type pattern. >> >> >> How do you replace SharedPreferences or MimeMap or SqliteDatabase with a >> service? >> >> How do you put ViewCompat.IMPL into a content provider? >> >> https://android.googlesource.com/platform/frameworks/support/+/refs/heads/master/v4/java/android/support/v4/view/ViewCompat.java >> >> ( lines 339 - 355, horrible, absolutely horrible... ;P ) >> >> The code above shows one good reason to use singletons: to reduce memory >> allocations. >> > > I agree that that's a completely valid use case for them, have I ever > said that you should never use statics? (Perhaps you didn't entirely > read my previous posts in this thread...) > > My main objection is that *many times* people think they can use > statics when they indeed cannot. Furthermore, because of all the > issues relating to them, it's always good to keep them in mind when > working with them. When you do need to work with them, it's useful to > use some sort of static (lint like) tool to warn you about strange > usage patterns. > >> >>>> >>>> >>>> This really *is* a pretty frequent problem when people get UI elements >>>> stuck into static variables and then users rotate the screen :-) >> >> >> It really *is* a pretty frequent problem when people smash their fingers >> with hammers. >> > > I think the condescending tone here is trying to say this doesn't > happen to apps. I guess I've just had unusual experiences. > >>> >>> >>> The biggest problem I have with singletons is that everyone for some >>> god-awful reason >>> insists on lazily instantiating them. Why? >> >> >> In the context of Android, that god-awful reason is often called "Context". >> >> And speaking for myself, I've had a lot more trouble with Android specific >> issues (bugs and weird stuff in stock and manufacturer firmwares, >> inaccessible stuff in the framework) or with various other external factors >> affecting my apps, than with singletons in my code (or "for" loops, for that >> matter...) >> >> So, don't really understand what all the bashing is about. It's a tool, use >> it correctly, and you'll be fine; use it wrong, and you could end up with a >> sore finger. > > For me, the bashing is because: > - Many times people find statics and use them to simplify their code > at first, which ultimately ends up wrong because they don't understand > their behavior. > - Statics cause problems with memory leaks much more easily. When > you do use them, you have to consciously note it in documentation and > you don't get compile time checking (unless you use a static analyzer > in your toolchain). > > By the way, saying "this is not always a bad thing!" does not at all > mean something should be avoided and used carefully. I've *never* > said you should blatantly forbid them. I'm not a fan of these > "blanket rule" coding styles. But at the same time, I do (honestly) > believe that most programmers (including myself) do not understand and > reason about their effects as well as normal data. > > FYI, I do use singletons in a good amount of my code, so I'm not > saying they are completely useless. I view them as something that has > a specific use case, and that many people use them outside of that use > case. (I also completely agree with you --- and never tried to say > otherwise --- that there are times when using them really does make > sense.) > > Kris -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
