In an Android app, is there anything wrong with the following approach:
public class MyApp extends android.app.Application {
private static MyApp instance;
public MyApp() {
instance = this;
}
public static Context getContext() {
return instance;
}
}
and pass it everywhere (e.g. SQLiteOpenHelper) where context is required (and not leaking of course)?
Source: Tips4all
There are a couple of potential problems with this approach, though in a lot of circumstances (such as your example) it will work well.
ReplyDeleteIn particular you should be careful when dealing with anything that deals with the GUI that requires a Context. For example, if you pass the application Context into the LayoutInflator you will get an Exception. Generally speaking, your approach is excellent: it's good practice to use an Activity's Context within that Activity, and the Application Context when passing a context beyond the scope of an Activity to avoid memory leaks.
Also, as an alternative to your pattern you can use the shortcut of calling getApplicationContext() on a Context object (such as an Activity) to get the Application Context.
In my experience this approach shouldn't be necessary. If you need the context for anything you can usually get it via a call to View.getContext() and using the Context obtained there you can call Context.getApplicationContext() to get the Application context. If you are trying to get the Appication context this from an Activity you can always call Activity.getApplication() which should be able to be passed as the Context needed for a call to SQLiteOpenHelper()
ReplyDeleteOverall there doesn't seem to be a problem with your approach for this situation, but when dealing with Context just make sure you are not leaking memory anywhere as described on the official Google Android Developers blog
You are trying to create a wrapper to get Application Context and there is a possibility that it might return "null" pointer.
ReplyDeleteAs per my understanding, I guess its better approach to call- any of the 2
Context.getApplicationContext() or Activity.getApplication().
I like it, but I would suggest a singleton instead:
ReplyDeletepackage com.mobidrone;
import android.app.Application;
import android.content.Context;
public class ApplicationContext extends Application
{
private static ApplicationContext instance = null;
private ApplicationContext()
{
instance = this;
}
public static Context getInstance()
{
if (null == instance)
{
instance = new ApplicationContext();
}
return instance;
}
}
Try
ReplyDeleteprivate OnClickListener OutrosListener = new OnClickListener() {
public void onClick(View v){
Context context = v.getContext();
Activity act = (Activity)context;
((LinearLayout) act.findViewById(R.id.llyComodosOutros)).setVisibility(View.VISIBLE);
}
};
What context does these actually give you, the "actual"/"real"/"live" one the runtime
ReplyDeletewould give you (if referenced from the this pointer within a lifecycle override, ie)
or some empty context object holding nothing but null members ?
That's all I got when instantiating these classes from OnCreate. However I did it from
Mono, so that could be the difference.
Thanks.