Re: [android-developers] Re: Can this variable become null?

[Piren]

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?

[Piren]

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?

[Lew]

> 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?

[Kristopher Micinski]

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
 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  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.

Re: [android-developers] Re: Can this variable become null?

[Kristopher Micinski]

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  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?

[Kristopher Micinski]

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  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?

[G. Blake Meike]

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?

[Piren]

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  
>> wrote: 
>> > On Thu, Mar 14, 2013 at 7:00 PM, user123  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?

[Kristopher Micinski]

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
 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?

[William Ferguson]

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?

[Kristopher Micinski]

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
 wrote:
> On Fri, Mar 15, 2013 at 8:56 AM, Kostya Vasilyev  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 ar

Re: [android-developers] Re: Can this variable become null?

[Kristopher Micinski]

On Fri, Mar 15, 2013 at 8:56 AM, Kostya Vasilyev  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?

[Kristopher Micinski]

On Fri, Mar 15, 2013 at 5:50 AM, user123  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?

[Indicator Veritatis]

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 
> 
> > 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  - 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?

[TreKing]

On Fri, Mar 15, 2013 at 7:56 AM, Kostya Vasilyev  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  - 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?

[Kostya Vasilyev]

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?

[user123]

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 
> > 
> wrote: 
> > On Thu, Mar 14, 2013 at 7:00 PM, user123 > 
> 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.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]

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 
> > 
> wrote: 
> > On Thu, Mar 14, 2013 at 7:00 PM, user123 > 
> 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?

[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  wrote:
> On Thu, Mar 14, 2013 at 7:00 PM, user123  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?

[Kostya Vasilyev]

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.



-- K

2013/3/15 user123 :
> 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?

[Mark Murphy]

On Thu, Mar 14, 2013 at 7:00 PM, user123  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.