> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
