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.