This topic seems to have become re-relevant with the 4.0 release. I'm
seeing Application.onCreate being called multiple times. It looks like
what Diane described above with multiple processes getting their own
instance of Application is being more aggressively adhered to.
Would that be correct Diane?
This goes with the recommended design approach of storing global state in
shared preferences and databases and not relying on static members.
Thoughts?
I have a case where I need to set up a global logging instance, and using
an Application object to store that global logger seems to be problematic.
For example, with this type of class we can get issues (see inline
comments):
public class MyApplication extends Application(){
public static MyApplication APP;
private Logger logger;
public void onCreate(){
super.onCreate();
APP = this;
getLogger().logp(Level.WARNING, "classname", "method",
"message"); // can cause an exception to be thrown....
}
public Logger getLogger(){
if (logger == null){
logger = //// create your logger here.
}
return logger;
}
}
It seems preferable to use this somewhere in your activity:
((MyApplication)context.getApplication()).getLogger().logp(evel.WARNING,
"classname", "method", "message");
Or, perhaps just define a static factory object might be preferred and
avoid the use of an Application object alltogether ...
Thoughts?
Richard
--
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
