Why does Android use multiple contexts and every one is different?

Question

I know that there are many contexts in android like those

1. Application
2. Activity
3. Service
4. ContentProvider
5. BroadcastReceiver

So when I create a new TextView i have to pass the context in the constructor like this

TextView textView = new TextView(this);

I know it is needed BUT why not just be created and android handle the context for me ?

Answer 1

I like to think of context visually, as I'm an avid user of Fragments so most of the time I pass a context, or inherit a context instance it would generally be from an Activity.

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.

as described on Android Developers. It basically gives you a help in hand from ensuring you can perform "up-calls for application-level operations", so let's detail this into your case.

I know it is needed BUT why not just be created and android handle the context for me ?

The new instance of your TextView, when created without a Context instance. So it'll look something like TextView tv = new TextView(); will confuse Android in regards to where that TextView is being generated. How will they know if this is application level or activity level? what characteristics would the TextView need before an instance is created? when you head over to the TextView's constructor you'll notice how it'll need some vital information before it generates a new instance of said TextView. For example: final Resources.Theme theme = context.getTheme(); is just one line where they gather information through the Context instance, now they know where the information is coming from, they can then apply the corresponding theme.

How will Android know where you have called that class from and what theme you would like to be applied to it unless you have told them?

Finally to answer your question, "why not just be created android handle the context for me?" this IS android handling things for you, but it needs to know where you're coming from and where in the life-cycle you're at.

Edit: added from comments.

why not that theme initialized in the application context and used in the code of the textview without my interference

because again it boils down to where you want that widget to be based. So let's say I want a TextView inside of my activity but we're calling the application level context, the theme that would be applied automatically would be @style/apptheme. But if I want that TextView to follow the same style guidelines at the current activity, instead of manually changing the theme for every widget I want to create (me the developer) android handles it for you, regardless of where you are in the app. it makes styles simpler, creating new instances of the TextView simple etc etc

you know i remember a scenario from .NET platform when i create new button on the form and without any thing passed to the constructor it inherits its theme for the parent form automatically .. you think .NET design is better on this or what?

Unfortunately I have no experience to say with .NET but i think in regards to the ever changing state of activities, services and receivers during the use of an application which could be closed and opened at anytime. It's a nice feature being able ensure Android knows where you're at, and what you're creating.

Answer 2

I think it's all about the lifecycle of the Context. An Activity for example can be terminated and garbage collected, which would make its Context be null. This can also work the other way around. Referencing the Activity's context can cause a memory leak in some cases and the Activity would never be garbage collected.

Check out this answer as well