Re: [android-developers] Re: Can this variable become null?
Not at random ... only when needed. On Sunday, March 17, 2013 6:33:01 PM UTC+2, G. Blake Meike wrote: On Sunday, March 17, 2013 9:09:54 AM UTC-7, Piren wrote: If your application has a singleton that takes 200MB of memory and takes a minute to load (dont ask why :-) ), but is only needed if you use a specific part of the app, why load it on the app load? Can you suggest a better time? Why is loading it at some random time, better? -blake -- -- 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.
Re: [android-developers] Re: Can this variable become null?
Generalizing is bad, which is why i didnt agree with the Singletons are bad, m'kay mentality here :) But yeah, i agree with all your points. In some cases lazy loading makes sense, in some it doesn't. Though i'm not sure how concurrency is an issue, Pill Pugh's implementation is probably the easiest implementation there is, not sure why some people here recommended the error-prone instance == null methods. On Sunday, March 17, 2013 9:08:34 PM UTC+2, Lew wrote: Lew wrote: The biggest problem I have with singletons is that everyone for some god-awful reason insists on lazily instantiating them. Why? Lazy instantiation is lazy. What's wrong with non-lazy instantiation? Then you can use a 'final' reference to the singleton instance that exists without effort or overhead. -- Lew Piren wrote: If your application has a singleton that takes 200MB of memory and takes a minute to load (dont ask why :-) ), but is only needed if you use a specific part of the app, why load it on the app load? I couldn't agree more. But that is far more likely to be a local variable to that specific part of the app than a singleton. Unless, of course, you are absolutely certain to hit that specific part of the app, and app-load is a time when people expect delay, and the time they hit that specific part of the app is not such a time, in which case you are far better off taking the performance hit at app load and not during the specific part of the app. Then I disagree. However, if it truly is a singleton, or whatever, then yeah, sure, lazy load, if the circumstances are right, like not in that counter-scenario I just outlined, but then you have extra work to do it right, at least of concurrency is involved. But that isn't a general policy of insisting on using a singleton and insisting on using lazy load, which is that against which I rail against. Never generalize. -- Lew -- -- 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.
Re: [android-developers] Re: Can this variable become null?
If your application has a singleton that takes 200MB of memory and takes a minute to load (dont ask why :-) ), but is only needed if you use a specific part of the app, why load it on the app load? On Friday, March 15, 2013 3:29:03 AM UTC+2, Lew wrote: Kristopher Micinski wrote: I guess the bigger problem that in Android static data members cannot be statically checked to be alive. By this I mean: you should try to get as much static checking as possible, and if you're using statics you don't have any ability to properly check this. 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. This really *is* a pretty frequent problem when people get UI elements stuck into static variables and then users rotate the screen :-) Kris On Thu, Mar 14, 2013 at 7:11 PM, Mark Murphy mmu...@commonsware.com wrote: On Thu, Mar 14, 2013 at 7:00 PM, user123 ivans...@gmail.com wrote: What is the problem with singleton? http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons And, since they don't seem to emphasize the point quite enough for my taste: static data members are, by definition, memory leaks. How *bad* of a memory leak they are depends on what they are and how they are used. Like many programming techniques, singletons can be used as a scalpel or a sledgehammer. The general advice against singletons is because most people reading that advice are inexperienced and are likely to do damage with either a scalpel or a sledgehammer. On the whole, AFAICT, tolerance for singletons decreases with increased production Java development experience, based on the conversations that I have had on the topic over the past few years. I've been using Java professionally for fourteen years. The biggest problem I have with singletons is that everyone for some god-awful reason insists on lazily instantiating them. Why? Lazy instantiation is lazy. What's wrong with non-lazy instantiation? Then you can use a 'final' reference to the singleton instance that exists without effort or overhead. -- Lew -- -- 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.
Re: [android-developers] Re: Can this variable become null?
On Sunday, March 17, 2013 9:09:54 AM UTC-7, Piren wrote: If your application has a singleton that takes 200MB of memory and takes a minute to load (dont ask why :-) ), but is only needed if you use a specific part of the app, why load it on the app load? Can you suggest a better time? Why is loading it at some random time, better? -blake -- -- 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.
Re: [android-developers] Re: Can this variable become null?
Because if the user doesn't use part of the app then they never pay the penalty. Kris On Sun, Mar 17, 2013 at 12:33 PM, G. Blake Meike blake.me...@gmail.com wrote: On Sunday, March 17, 2013 9:09:54 AM UTC-7, Piren wrote: If your application has a singleton that takes 200MB of memory and takes a minute to load (dont ask why :-) ), but is only needed if you use a specific part of the app, why load it on the app load? Can you suggest a better time? Why is loading it at some random time, better? -blake -- -- 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. -- -- 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.
Re: [android-developers] Re: Can this variable become null?
I agree with your assessment, but I've never said singletons are evil. I've just said that Java statics require more careful use and are frequently misused by beginners. For experienced programmers, this advice is obviously insufficient: since there are times when statics really do help. I think Blake's example of a static final being a singleton seems strange, because that use of the static keyword is just a Java implementation of a constant. While there are multiple Using statics is not universally horrible, in the same way that using statics lets you get more control over the memory behavior of your system. There are also times when it's good to write native code too, and that's also something that should be handled very carefully. Statics essentially give you finer grained memory control, and like most things, more power is more responsibility. Unfortunately I'm afraid this topic has grown too big, and it looks like a another big argument about don't do this versus, it has some use.. Kris On Sun, Mar 17, 2013 at 12:04 PM, Piren gpi...@gmail.com wrote: Honestly i don't get some of the comments here. Yeah, a bad programmer that doesn't understand how Java works will fuck up with Singletons .. but that doesn't mean Singletons are evil. As was already stated - if they are so evil, why is the Android API using them for pretty much anything that makes sense as a Singleton? In the article you posted, he gave a bad example... a bad programmer would do what he did (since that is obviously prone to errors).. what's the point of finding a way to make something look bad and thus deduce it is bad? Eating cement is bad for you, thus cement is evil? If i have an app that has some class that does heavy calculations and to do those faster, it can pre-calculate what it can (which still takes time)... why not do it as a singleton? Would you rather have the user wait again and again rather than keep a singleton with those pre-calculations to speed everything up? Same applies for Lazy loading... if that Singleton is only used for some part of the app that might not be used frequently, why not lazy load it? (especially if it has a fat memory footprint) P.S - His example is even funnier since i do the exact opposite - i use a static variable to see when Android did in fact close my app (since it is being a bastard and not telling me it did) On Sunday, March 17, 2013 5:28:47 PM UTC+2, G. Blake Meike wrote: @Lew on 3/14: +many Why, oh why, do people insist on lazy initialization? A lot of the debate about singletons ignores specifics. I bet nobody has a problem with: public static final String MY_CONSTANT = CONSTANT; That's a singleton. Singletons that are mutable are weirder. Lazily initialized singletons that are mutable are the devil's tools. Further, as I point out here: http://portabledroid.wordpress.com/2012/05/04/singletons-in-android/ Singleton is a relative term. There is nearly no such thing as a singleton (well, maybe the earth, or the sun, or something like that). There are only singletons in context. I have come to see many of the problem devs have with singletons not as a discussion of singletons themselves, but as a misunderstanding of the context in which they are singletons. -blake -- -- 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. -- -- 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.
Re: [android-developers] Re: Can this variable become null?
Delete that run on sentence in the end of the second paragraph, apologies :-) Kris On Sun, Mar 17, 2013 at 2:16 PM, Kristopher Micinski krismicin...@gmail.com wrote: I agree with your assessment, but I've never said singletons are evil. I've just said that Java statics require more careful use and are frequently misused by beginners. For experienced programmers, this advice is obviously insufficient: since there are times when statics really do help. I think Blake's example of a static final being a singleton seems strange, because that use of the static keyword is just a Java implementation of a constant. While there are multiple Using statics is not universally horrible, in the same way that using statics lets you get more control over the memory behavior of your system. There are also times when it's good to write native code too, and that's also something that should be handled very carefully. Statics essentially give you finer grained memory control, and like most things, more power is more responsibility. Unfortunately I'm afraid this topic has grown too big, and it looks like a another big argument about don't do this versus, it has some use.. Kris On Sun, Mar 17, 2013 at 12:04 PM, Piren gpi...@gmail.com wrote: Honestly i don't get some of the comments here. Yeah, a bad programmer that doesn't understand how Java works will fuck up with Singletons .. but that doesn't mean Singletons are evil. As was already stated - if they are so evil, why is the Android API using them for pretty much anything that makes sense as a Singleton? In the article you posted, he gave a bad example... a bad programmer would do what he did (since that is obviously prone to errors).. what's the point of finding a way to make something look bad and thus deduce it is bad? Eating cement is bad for you, thus cement is evil? If i have an app that has some class that does heavy calculations and to do those faster, it can pre-calculate what it can (which still takes time)... why not do it as a singleton? Would you rather have the user wait again and again rather than keep a singleton with those pre-calculations to speed everything up? Same applies for Lazy loading... if that Singleton is only used for some part of the app that might not be used frequently, why not lazy load it? (especially if it has a fat memory footprint) P.S - His example is even funnier since i do the exact opposite - i use a static variable to see when Android did in fact close my app (since it is being a bastard and not telling me it did) On Sunday, March 17, 2013 5:28:47 PM UTC+2, G. Blake Meike wrote: @Lew on 3/14: +many Why, oh why, do people insist on lazy initialization? A lot of the debate about singletons ignores specifics. I bet nobody has a problem with: public static final String MY_CONSTANT = CONSTANT; That's a singleton. Singletons that are mutable are weirder. Lazily initialized singletons that are mutable are the devil's tools. Further, as I point out here: http://portabledroid.wordpress.com/2012/05/04/singletons-in-android/ Singleton is a relative term. There is nearly no such thing as a singleton (well, maybe the earth, or the sun, or something like that). There are only singletons in context. I have come to see many of the problem devs have with singletons not as a discussion of singletons themselves, but as a misunderstanding of the context in which they are singletons. -blake -- -- 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. -- -- 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.
Re: [android-developers] Re: Can this variable become null?
Lew wrote: The biggest problem I have with singletons is that everyone for some god-awful reason insists on lazily instantiating them. Why? Lazy instantiation is lazy. What's wrong with non-lazy instantiation? Then you can use a 'final' reference to the singleton instance that exists without effort or overhead. -- Lew Piren wrote: If your application has a singleton that takes 200MB of memory and takes a minute to load (dont ask why :-) ), but is only needed if you use a specific part of the app, why load it on the app load? I couldn't agree more. But that is far more likely to be a local variable to that specific part of the app than a singleton. Unless, of course, you are absolutely certain to hit that specific part of the app, and app-load is a time when people expect delay, and the time they hit that specific part of the app is not such a time, in which case you are far better off taking the performance hit at app load and not during the specific part of the app. Then I disagree. However, if it truly is a singleton, or whatever, then yeah, sure, lazy load, if the circumstances are right, like not in that counter-scenario I just outlined, but then you have extra work to do it right, at least of concurrency is involved. But that isn't a general policy of insisting on using a singleton and insisting on using lazy load, which is that against which I rail against. Never generalize. -- Lew -- -- 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.
Re: [android-developers] Re: Can this variable become null?
Statics? The state of the singleton is instance, not class based. Besides
of the singleton itself. But it's private. And you access it using
public static void getInstance() {
if (instance == null) {
intance = new Whatever();
}
return instance;
}
If the system destroys the app, it will be initialized in the next access -
safe.
And the possibility that someone can do bad things with the singletons,
like storing views or other things which can lead to memory leaks is not a
reason to stop using them. You can do this with any class.
Am Freitag, 15. März 2013 00:45:49 UTC+1 schrieb Kristopher Micinski:
I guess the bigger problem that in Android static data members cannot
be statically checked to be alive. By this I mean: you should try
to get as much static checking as possible, and if you're using
statics you don't have any ability to properly check this.
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.
This really *is* a pretty frequent problem when people get UI elements
stuck into static variables and then users rotate the screen :-)
Kris
On Thu, Mar 14, 2013 at 7:11 PM, Mark Murphy
mmu...@commonsware.comjavascript:
wrote:
On Thu, Mar 14, 2013 at 7:00 PM, user123 ivans...@gmail.comjavascript:
wrote:
What is the problem with singleton?
http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil
http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons
And, since they don't seem to emphasize the point quite enough for my
taste: static data members are, by definition, memory leaks. How *bad*
of a memory leak they are depends on what they are and how they are
used.
Like many programming techniques, singletons can be used as a scalpel
or a sledgehammer. The general advice against singletons is because
most people reading that advice are inexperienced and are likely to do
damage with either a scalpel or a sledgehammer.
On the whole, AFAICT, tolerance for singletons decreases with
increased production Java development experience, based on the
conversations that I have had on the topic over the past few years.
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
_The Busy Coder's Guide to Android Development_ Version 4.6 Available!
--
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
android-d...@googlegroups.comjavascript:
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com javascript:
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 javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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.
Re: [android-developers] Re: Can this variable become null?
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? 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. 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. 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. Just my 2 kopeyka's. -- K Lazy instantiation is lazy. What's wrong with non-lazy instantiation? Then you can use a 'final' reference to the singleton instance that exists without effort or overhead. -- Lew -- -- 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.
Re: [android-developers] Re: Can this variable become null?
On Fri, Mar 15, 2013 at 7:56 AM, Kostya Vasilyev kmans...@gmail.com wrote: 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. Word. The Singletons are evil, if you use them you're doing something wrong mentality is just as bad as the Singletons are so awesome I'm going to use them for every goddamn thing mentality. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- -- 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.
Re: [android-developers] Re: Can this variable become null?
Both mentalities are bad. I would actually venture to say that the singletons are evil mentality is worse, since enthusiasts tend to grow out of the singletons are awesome phase. But if someone believes that all singletons are always evil, how do you persuade them of the depth of their error? This is a much harder problem: it is a complete failure to understand what a 'pattern' even is, and why the 'forces' are so important for understanding the pattern. On Friday, March 15, 2013 12:22:05 PM UTC-7, TreKing wrote: On Fri, Mar 15, 2013 at 7:56 AM, Kostya Vasilyev kman...@gmail.comjavascript: wrote: 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. Word. The Singletons are evil, if you use them you're doing something wrong mentality is just as bad as the Singletons are so awesome I'm going to use them for every goddamn thing mentality. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- -- 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.
Re: [android-developers] Re: Can this variable become null?
On Fri, Mar 15, 2013 at 5:50 AM, user123 ivanschu...@gmail.com wrote: And the possibility that someone can do bad things with the singletons, like storing views or other things which can lead to memory leaks is not a reason to stop using them. You can do this with any class. Let's take a minute to dissect what you said: You can do this with any class This sounds a lot like: You shouldn't wear a life vest while swimming, you can drown while wearing them. To me, the fact that you are much more likely to accidentally miss explicitly deallocating a static reference sounds like a pretty good reason. 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.
Re: [android-developers] Re: Can this variable become null?
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.
Re: [android-developers] Re: Can this variable become null?
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
Re: [android-developers] Re: Can this variable become null?
I wasn't going to enter back into this discussion because it's one of those that polarises like checked Exceptions. I also use singletons, but on a rare and very precise basis. And if you have mentored as many developers as I have then you will understand why the default mantra of don't use a singleton is valid. Junior developers seem to become infatuated with them, overuse them, lose all perspective of the OO nature of the language and start treating them as global functions. Encapsulation and responsibility go out the window. And on top of that you get all the attendant problems of objects with indefinite life spans. If you know what you are doing, fine. But it's similar to the mantra we give kids don't run with scissors. William -- -- 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.
Re: [android-developers] Re: Can this variable become null?
This is basically my point: I don't believe you should never use them, it's just that many people present them as an easy obvious solution to something that comes with lots of overhead. Many times they *can* be replaced by specific components. Sure, there are counterexamples and optimizations (e.g., many apps hold sockets in an application context), but these (in my experience) tend to be the exception rather than the norm. Kris On Fri, Mar 15, 2013 at 11:04 PM, William Ferguson william.fergu...@xandar.com.au wrote: I wasn't going to enter back into this discussion because it's one of those that polarises like checked Exceptions. I also use singletons, but on a rare and very precise basis. And if you have mentored as many developers as I have then you will understand why the default mantra of don't use a singleton is valid. Junior developers seem to become infatuated with them, overuse them, lose all perspective of the OO nature of the language and start treating them as global functions. Encapsulation and responsibility go out the window. And on top of that you get all the attendant problems of objects with indefinite life spans. If you know what you are doing, fine. But it's similar to the mantra we give kids don't run with scissors. William -- -- 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. -- -- 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.
Re: [android-developers] Re: Can this variable become null?
On Thu, Mar 14, 2013 at 7:00 PM, user123 ivanschu...@gmail.com wrote: What is the problem with singleton? http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons And, since they don't seem to emphasize the point quite enough for my taste: static data members are, by definition, memory leaks. How *bad* of a memory leak they are depends on what they are and how they are used. Like many programming techniques, singletons can be used as a scalpel or a sledgehammer. The general advice against singletons is because most people reading that advice are inexperienced and are likely to do damage with either a scalpel or a sledgehammer. On the whole, AFAICT, tolerance for singletons decreases with increased production Java development experience, based on the conversations that I have had on the topic over the past few years. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 4.6 Available! -- -- 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.
Re: [android-developers] Re: Can this variable become null?
I really think everyone should stop using the Android Framework, since it has more than a handful of singletons. http://developer.android.com/develop/index.html#q=singleton This is despite research that conclusively proves singletons causing baldness in males and infertility in women. Oh the dangers of working with Android. /irony -- K 2013/3/15 user123 ivanschu...@gmail.com: What is the problem with singleton? It works very well. I use it to hold global state, for example, translations. They are fetched at the start of the app, and updated each screen launch (if necessary). This holds the translations in memory and I can get them from any activity using simple methods. I can control everything there - reinitialize if destroyed, etc. There's also a very popular image loading library, which works very well for me, which also uses the singleton pattern. It initializes in application's onCreate() and after that everytime you load an image, just use ~1 line of code. Which better approach would you suggest for these use cases, and why? Am Dienstag, 26. Februar 2013 06:19:24 UTC+1 schrieb William Ferguson: You should access it with a getInstance method which will initialize it if it is null. You should initialize the variable in the class initialization and declare it 'final'. There are times when you cannot do this, in which case probably Singleton is the wrong choice. For the rest of the times, Singleton probably is the wrong choice. :-) +1 to that -- -- 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. -- -- 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.
Re: [android-developers] Re: Can this variable become null?
I guess the bigger problem that in Android static data members cannot be statically checked to be alive. By this I mean: you should try to get as much static checking as possible, and if you're using statics you don't have any ability to properly check this. 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. This really *is* a pretty frequent problem when people get UI elements stuck into static variables and then users rotate the screen :-) Kris On Thu, Mar 14, 2013 at 7:11 PM, Mark Murphy mmur...@commonsware.com wrote: On Thu, Mar 14, 2013 at 7:00 PM, user123 ivanschu...@gmail.com wrote: What is the problem with singleton? http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons And, since they don't seem to emphasize the point quite enough for my taste: static data members are, by definition, memory leaks. How *bad* of a memory leak they are depends on what they are and how they are used. Like many programming techniques, singletons can be used as a scalpel or a sledgehammer. The general advice against singletons is because most people reading that advice are inexperienced and are likely to do damage with either a scalpel or a sledgehammer. On the whole, AFAICT, tolerance for singletons decreases with increased production Java development experience, based on the conversations that I have had on the topic over the past few years. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 4.6 Available! -- -- 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. -- -- 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.
Re: [android-developers] Re: Can this variable become null?
Kristopher Micinski wrote: I guess the bigger problem that in Android static data members cannot be statically checked to be alive. By this I mean: you should try to get as much static checking as possible, and if you're using statics you don't have any ability to properly check this. 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. This really *is* a pretty frequent problem when people get UI elements stuck into static variables and then users rotate the screen :-) Kris On Thu, Mar 14, 2013 at 7:11 PM, Mark Murphy mmu...@commonsware.comjavascript: wrote: On Thu, Mar 14, 2013 at 7:00 PM, user123 ivans...@gmail.comjavascript: wrote: What is the problem with singleton? http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons And, since they don't seem to emphasize the point quite enough for my taste: static data members are, by definition, memory leaks. How *bad* of a memory leak they are depends on what they are and how they are used. Like many programming techniques, singletons can be used as a scalpel or a sledgehammer. The general advice against singletons is because most people reading that advice are inexperienced and are likely to do damage with either a scalpel or a sledgehammer. On the whole, AFAICT, tolerance for singletons decreases with increased production Java development experience, based on the conversations that I have had on the topic over the past few years. I've been using Java professionally for fourteen years. The biggest problem I have with singletons is that everyone for some god-awful reason insists on lazily instantiating them. Why? Lazy instantiation is lazy. What's wrong with non-lazy instantiation? Then you can use a 'final' reference to the singleton instance that exists without effort or overhead. -- Lew -- -- 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.
