This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is Context in Android?
I would like to know what exactly Android's Context is, and why it is needed. I know it's related to class and each class has a unique context. I have seen in some code which passes a Context when calling methods of another class. I don't understand why it is needed. Please help.
a Context is:
Interface to global information about
an application environment. This is an
abstract class whose implementation is
provided by the Android system. It
allows access to application-specific
resources and classes, as well as
up-calls for application-level
operations such as launching
activities, broadcasting and receiving
intents, etc.
Ref: http://developer.android.com/reference/android/content/Context.html
All classes does not have an android context. Their is an application context, and activity c contexts. A context is used for a lot of things, but most often it is just to load and access resources.
See: http://developer.android.com/reference/android/content/Context.html for more info.
The android context holds information about your application's environment.
You might want to take a look at the official reference in order to understand which information is being held by your context and what operations you can do with it.
Related
This question already has answers here:
What is 'Context' on Android?
(31 answers)
Closed 6 years ago.
As a newbie I am trying to make an app thorough watching some tutorials. I am approaching further and getting more and more confused about "Context". About its definition as well as its contribution. Most puzzling part is when to put the "context" as a parameter.
Which types of classes take "context" as parameter?
What can/should I suppose to do with it?
Couldnt explain it better:
"Context allows access to application-specific resources and classes, as well as calls for application-level operations such as launching activities, broadcasting and receiving intents, etc. Context in Android is an interface to global information about an application environment." - From one of the thread in stack overflow".
"Context is context of current state of the application/object.Its an entity that represents various environment data . Context helps the current activity to interact with out side android environment like local files, databases, class loaders associated to the environment, services including system-level services, and more.
A Context is a handle to the system . It provides services like resolving resources, obtaining access to databases and preferences, and so on. An android app has activities. It’s like a handle to the environment your application is currently running in. The activity object inherits the Context object."
Just wondering on why the implementors decided for the developers to pass the context (even though the system services seem more like a singleton for the developers, and we mostly don't even care):
LayoutInflater inflater = LayoutInflater.from(context);
inflater.inflate(layout);
I am asking this more because of an implicit fear of leaking memory/context whenever I play with context. Is there a possibility of mis-handling context here ?
In Android, your app's Context is essentially like a pipe connecting it to the system services. A lot of the system services are singletons, but you cannot arbitrarily access them. The Context class acts as a middleman to receive and pass the service you need to you.
LayoutInflater.from(context); simply goes and calls context.getSystemService() using the supplied context, which is your application's.
In essence, you app and Android are two separate things running simultaneously and Context adds as a pipe to connect them.
Because every android service needs context. LayoutInflater is android service. Another declaretion about this;
LayoutInflater inflater = (LayoutInflater)getSystemService(Context.LAYOUT_INFLATER_SERVICE);
As per android documentation:
Context:
Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.
So "context" holds different environment parameter. These parameters are very much application and system dependents.
"why the implementors decided for the developers to pass the context"
When you creates any activity or creates any dialog or service or anything then it needs several different environment properties in Android. So there should be something which can provides all these information and can perform different task internally according to your operation. In Android, context does it.
Example: If you send Broadcast in Android then it will be received by all broadcast receiver in different activities and application also. These things you does not manages but you can use, everything is already managed by Android that is the reason we mostly don't even care.
Context is provided by system So we don't really need to take much care of memory leaks. If you will look different public parameters(http://developer.android.com/reference/android/content/Context.html ) then you will find that most of the things you can set or simply get. Functionality also are at application level not much system levels. So leaking you need to take care for you code not actually for context.
I've been rereading this and can't make a sense of it, could you, probably explain it to me?
There is normally no need to subclass Application. In most situation,
static singletons can provide the same functionality in a more modular
way. If your singleton needs a global context (for example to register
broadcast receivers), the function to retrieve it can be given a
Context which internally uses Context.getApplicationContext() when
first constructing the singleton.
From http://developer.android.com/reference/android/app/Application.html
I fail to see why there's no need to subclass Application. I often subclass it so I can access application context from everywhere. So, what shall be the proper way according to this document?
I think the idea is to avoid overloading the Application class but instead having multiple small singleton classes focused on different concerns.
That's probably what they mean by "more modular way".
Normally people make the "Application" class so that they can store objects in it to persist the entire lifetime of the app or transfer between activities. I think what that line is saying that simply making it static would achieve the same purpose, in a more "modular" way.
As for application context, did you already know about getApplicationContext()?
I've got a quick question on the best way to handle Android contexts. A lot of things (e.g. Service) require that you pass a context as a parameter. At the present time, I have a public static variable that is set to point to getApplication() and I just refer to this throughout my application where a context is required.
Is this ok to do? Or is there a better method to handle this? A lot of my classes don't extend Activity or service and as such, don't have access to this.getApplication().
Everything seems to work ok when I just pass in my static variable.
Is this ok to do?
The Application object, in some cases, will fail to work. For example, it sucks for UI-related stuff.
Dianne Hackborn, a leading Android engineer, has stated her regret at Application existing in the first place.
My general advice is to use Application only when you know specifically why it is superior to using your Activity, Service, etc. There are cases when it is the better answer (e.g., binding to services).
A lot of my classes don't extend Activity or service and as such, dont have access to this.getApplication().
Pass a suitable Context as a parameter, as the Android SDK does.
At the present time, I have a public static variable that is set to
point to getApplication() and I just refer to this throughout my
application where a context is required.
Is this ok to do?
No.
A context applies to the context in which it was obtained. That is, an activity has context for that activity, a service has context for the service, and so on. Now, a lot of folks do what you are doing, and as you observe, it seems to work. That doesn't mean it will continue to work or that it's good design. If that was the proper pattern, Android would have been designed with Context.INSTANCE that is available statically.
An activity, service, and application are contexts (isA). Receivers are passed a context to their onHandlerIntent() method. For all other classes you write, just get used to constructing them with a context. Out of habit, whenever I create a new class, I automatically add a constructor that accepts a context and add a private field to hold it.
When you need a context in a static method, you should pass it in directly as a parameter.
I have a question regarding the term 'context' in Android. I see that the context provides information about the environment the application runs in, however what is the difference between Application Context and Activity Context?
AND why do I do things like this:
AlertDialog.Builder dialog = new AlertDialog.Builder(mContext);
Why do I pass the context into the constructor? Can anyone provide please help me understand what a context is, and what the context object is?
I do not want copy/paste from android Reference since I already have read it.....too many times without understanding.
They are both instances of Context, but the application instance is tied to the lifecycle of the application, while the Activity instance is tied to the lifecycle of an Activity. Thus, they have access to different information about the application environment.
If you read the docs at getApplicationContext it notes that you should only use this if you need a context whose lifecycle is separate from the current context. This doesn't apply in either of your examples.
The Activity context presumably has some information about the current activity that is necessary to complete those calls. If you show the exact error message, might be able to point to what exactly it needs.
But in general, use the activity context unless you have a good reason not to.
In simple word ill try to explain. Lets take your example
If you are using AlertDialog Builder how will that AlertDialog will understand where he will get displayed??? (If you are not in that activity)
Here context comes in picture. We pass Activity Context to the AlertDialog.In short AlertDialog will will appear in provided context.
This is what my understanding is correct me if I am wrong.
Class Overview
Interface to global information about an application environment. This
is an abstract class whose implementation is provided by the Android
system. It allows access to application-specific resources and
classes, as well as up-calls for application-level operations such as
launching activities, broadcasting and receiving intents, etc.
anddev website said it very clearly .
you must pass it to some other class so they can access global
information among other things.