difference between this, Class.this and getApplicationContext

[ibrahim yener]

Hello guys
I want to know what is the difference between this, ClassName.this, getApplicationContext, getBaseContext and getContext.

Why there is so many type. What is their specific tasks.
When to use?
How to use?
Why to use? :)

Thanks for any information

Regards

[Steve Luke]

ibrahim yener wrote:Hello guys
I want to know what is the difference between this, ClassName.this, getApplicationContext, getBaseContext and getContext.

The this keyword and the context methods aren't really related, except that they both sort of define scopes of where things could be.

this is a Java Keyword is a reference to the current object. Since you can have nested classes, you can use Class.this to disambiguate which this you are referencing. For example, lets say we have this code:

public class MyActivity extends Activity {
    private final int someValue;

    public MyActivity(int someValue) {
        this.someValue = someValue;
    }

    public class MyClickListener implements View.OnClickListener {
        public void onClick(View view) {
            Log.v(MyActivity.this.someValue);
        }
    }
}

Line 5 of that code uses this to identify that the someValue being assigned to is the member variable. The MyClickListener is an inner class, it exists in the context of an instance of MyActivity. Part of what it wants to do is access the someValue instance variable inside the activity. So it uses MyActivity.this to make it clear that is where the someValue variable should come from.

The contexts are Android specific scoping objects that extend the android.content.Context class. There is a sort of global context - the Application Context - which can be used to get global state, and then there are usually one or more smaller-scoped contexts which hold more specific state information (like the Activity). In general, you don't really need to worry about all the different levels and methods, you just need to get a Context somehow, usually the smallest scoped one, and use it. And that is usually by calling the Activity's getContext() method. The context itself will handle delegating or searching broader contexts if it doesn't have the information you need. So you generally don't need getBaseContext() (though if you were to write a Context implementation yourself, you might).

The ApplicationContext is used when you might need access to a context but you need to make sure it has a long enough life. For example, the Activity is a Context, and its getContext() method usually returns itself. But if you have a class which uses the context but sticks around for longer than the life of the Activity (for example it might be used in a Service or is something that gets passed from one Activity to the next) then using the Activity as a context isn't the best idea, it could cause memory leaks or unexpected behavior. So in those cases you need a context that lasts the lifetime of the application, and that would be what getApplicationContext() returns.

Why there is so many type. What is their specific tasks.
When to use?
How to use?
Why to use? :)

Thanks for any information

Regards

[ibrahim yener]

Dear Steve
Thank you so much for this valuable information and taking your time.
Much appreciated.

So far, what did i understand is that Context holds the Activity objects and tells to another activity Where is it in the memory.

Bigger context cover more information about Application.

Using getApplicationContext for onClickListener or inner class is unnecessary isn't it?

It's more like filling bathtub for brushing teeth.

Hope i understood correct.

Thank you so much again.

[Steve Luke]

ibrahim yener wrote:Dear Steve
Thank you so much for this valuable information and taking your time.
Much appreciated.

So far, what did i understand is that Context holds the Activity objects and tells to another activity Where is it in the memory.

Not quite. An Activity is a Context. And a Context holds information about the application's state, access, permissions, databases, file system, assets, and things like that.

Bigger context cover more information about Application.

Depends on what you mean about 'bigger'. Broader contexts, like Application, usually have access to less information, or the same information but in a harder-to-access manner. As you get to narrower contexts like the Activity, the Context knows a bit more about what is currently happening, so it might hold more information about the specific task, or make it easier to access information more pertinent to the current activity. It is called 'narrower' because it has a shorter life span and covers a smaller range of possibilities. But it usually has access to all the information that broader contexts have.

For example, the Application context might have information about what databases are defined for the application, and what assets are available. It doesn't necessarily know about the current displayed layout. But the Activity context does know about the currently displayed layout, so it can be used to create views that are properly initialized. The Activity context usually knows all the stuff the Application does, and if it doesn't know it itself, it delegates to the Application to get it.

Using getApplicationContext for onClickListener or inner class is unnecessary isn't it?
It's more like filling bathtub for brushing teeth.

Not sure about 'necessary' or not... but most likely you want the Activity's context, because the narrower scope gives you access to what is more likely to be needed. I don't think the analogy to the excessive waste in water is applicable - the Application context exists, has information, and you using it doesn't change its size or content. Nor does it give you access to an excess of information. It just might not be the right scope to look at... or it might be depending on needs.

[ibrahim yener]

Thank you again.
Now i have better information what it is and when and where to use it.

This small problem was like splinter in my mind and finally i have answer for it.
Thank you much again.

Have a great day