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.
Related
I am working a android sdk. I ask user input activity as a parameter, although I think "Context" is enough for my case, also from sdk's user's view, "Context" will be easer for coding. But I see some other sdk ask user pass the "Activity" as in-parameter, Is there any specific reason for "Activity"?
Context is base class of all Application, services and Activities , three main components of Android application. Most of work can be done via Context object. So if your sdk is OK with context, it is better to use Context. For ,more details check this thread. Passing Activity or Context to other instance
You should ask for a Context unless there's some function on Activity that you absolutely need to call (for example a permissions check). This will allow your library to be used in a Service or BroadcastReceiver as well.
I want to store the application context in a static member, like this, so I can access it, the shared preferences, resources etc. everywhere.
My question is whether the context can change itself during the application lifetime, so the stored context won't work in a proper way and I can't access shared preferences etc.
Or is the context immutable, so I can use it without any doubt?
Thanks for you answers!
Application context stays unaltered during application lifetime.
Context is immutable during all work of app. And you can use it in static way to get resources, shared preferences, etc.
When you look at the accepted answer of this post, you will find that it is Ok to do this, but handle with care...
There are a couple of potential problems with this approach,
though in a lot of circumstances (such as your example) it will work well.
In particular you should be careful when dealing with anything that deals with the GUI
that requires a Context. For example, if you pass the application Context into the
LayoutInflator you will get an Exception. Generally speaking, your approach is excellent:
it's good practice to use an Activity's Context within that Activity, and the Application
Context when passing a context beyond the scope of an Activity to avoid memory leaks.
Yep, you can use it with shared preferences and get resources etc.
getApplicationContext() function should do it. It shouldn't matter if its mutable.
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 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.