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.
Related
When my singleton is initialized, it is passed a Context (as advised in Android docs). I use that Context to get the ConnectivityManager.
Later I want to access ConnectivityManager again, but this time I don't have a Context (because saving a Context is bad etc).
Is it ok if during the singleton initialization I keep the ConnectivityManager (or any other system service, for that matter)?
I doubt that the reasons to avoid saving app contexts statically apply to system services as well, but I could be wrong.
EDIT the answer to the "duplicate" question ignored the core of my question, which is I don't have a reference to the app context when I need that service.
And the question itself only asks about leaks.
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.
It annoys me when I need to pass the context reference around all over my code. So I am thinking to create a static method to return a reference to the application instance. I am not sure if it is safe to assume there is only one instance of the Application in one application. Apparently, the Application class in Android SDK doesn't provide such method to return the instance reference. So I suspect there must be a reason?
It's probably safe, assuming that your android app lives within a single os process (most do, but this isn't a guarantee on android), but I advise against it.
If you need access to the context/application outside of the places where it's already available (activities, services, broadcast receivers, applications, views, etc), you're probably letting details related to the android environment creep into code that shouldn't know so much about it.
The big exception is static utility methods (e.g. to display a canned dialog that you reuse in your app or similar), in which case passing your context is kind of a convention in the android world (for example, ProgressDialog.show takes a Context as its first argument).
While you can do this, my feeling is that it's probably a band-aid to work around the fact that you have too many components in your code that are unnecessarily tightly coupled to the android environment.
I'm quite new to Android development.
When is it a good idea to create an Android Service instead of just using a simple Singleton class?
Take, for example, the data layer downloading information feeds from the internet.
Using a Service seems too much for some cases but sometimes I might need access to a Context so I'm a little unsure about how to design the app.
If it is okay for your process to be killed (along with the singleton) immediately after the user leaves its activities, then use a singleton. If you need it to continue running for some duration after that, use a service. If you would like to continue running after the user leaves it, but can live with it not because the user is now on to something else where memory is needed more, then use a singleton.
The decision between these two only comes down to the lifecycle of your app. For this purpose, that is all a service does -- ask the platform to modify its management of your process. If you need a context in a singleton, just use Context.getApplicationContext() to retrieve the global context for your process.