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 <[email protected]> wrote: > On Fri, Mar 15, 2013 at 8:56 AM, Kostya Vasilyev <[email protected]> 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 [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 --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
