Develop Reference

What is context in PreferenceManager.getDefaultSharedPreferences used for?

Given that any non-null context passed to PreferenceManager.getDefaultSharedPreferences will return the same result,
what is context used for by PreferenceManager and what's the point of passing in different context?

what is context used for by PreferenceManager
To get at the locations of internal storage and, IIRC, the package name of the app.
what's the point of passing in different context?
In general, any Context will do for this method call. In principle, you could pass in some ContextWrapper that overrides something that would be used by getDefaultSharedPreferences().

Android DataBinding where to get context?

I have TextView for showing time. I want to use Android's DataBinding plugin.
For formatting time I am using DateUtils.formatDateTime(context, int, int) method which takes Context instance. Is it possible to get context include element? Or do I have to use old school way?
Thanks

Also you can do something like this in your view using the current view context as parameter.
...
android:text="#{yourModelHere.yourModelMethodHere(context)}"
...

Thought I should answer instead of putting in a comment. You'll have more options when rc2 is released. In rc1, you can pass the context in a variable to the Binding, then pass it as a parameter to the method. Alternatively, you can create a custom attribute for data binding:
#BindingAdapter({"timeMillis", "dateFlags"})
public static void setDateText(TextView view, int timeMillis, int dateFlags) {
view.setText(DateUtils.formatDateTime(view.getContext(), timeMillis,
dateFlags));
}
And then use it in your TextView:
<TextView ... app:timeMillis="#{timeVar}" app:dateFlags="#{dateFlags}"/>

A special variable named context is generated for use in binding
expressions as needed. The value for context is the Context from the
root View's getContext(). The context variable will be overridden by
an explicit variable declaration with that name.
In other words, every time you need to pass the context just use "context" as in #{Object.method(context)}.

To used string resources use this
this.yourView.getRoot().getResources().getString(R.string.your_string)

Is it required to initialize context twice in Android ?

I have seen in many places android context is initialized twice ? Why is it required ?
For Example :
Context context;
context = null;
again they will initialize it to some values in onCreate, onReceive or in some other Method
context = myContext;
If anyway we have to initialize it to value, why then initializing it to null ?
Anything specific to Android ?
Thanks

compiler never assigns a default value to an uninitialized local variable.
If you cannot initialize your local variable where it is declared, make sure to assign it
a value before you attempt to use it. Accessing an uninitialized local variable will result
in a compile-time error.
Example:
someMethod(Context myContext){
Context context;
context = null; //Have to be done to avoid compile-time error
context = myContext;
}
Example 2:
private Context context;
someMethod(Context myContext){
context = myContext; //No initialization required, because context variable is not local
}
To Answer your question:
We are initializing variable to null to keep consistency intact
No, this is not Android specific, but rather Java specific

I would guess this is done of old habits only. Java should by default set field object references to null. I doubt Android handle this differently.
Setting them to null might even result in duplicate operations on byte code level. For further information refer to this page.

Error when trying to load bitmaps

Why do I get the error message The method getResources() is undefined for the type ColorObjectManager?
I use this line to load a Bitmap image:
orange = BitmapFactory.decodeResource(getResources(), R.drawable.pearl_orange);
It's working fine if I'm doing this in another class that I call GameLoop which I make an object of inside the MainActivity class. But it's not working when I trying to do this in the class ColorObjectManager which I make an object of inside the GameLoop class. Do you follow?
Why am I limited to just use this loading part in the GameLoop class and not in the ColorObjectManager class? I thought it would help if I passed the Context to the constructor of ColorObjectManager, but it didn't! I guess I'm missing some knowledge here where I can create objects and not. Can I get some help to sort this out? Thanks!

getResource needs a Context object. If you pass the context to ColorObjectManager you can retrieve resources with context.getResources()

I agree with the answer posted by blackbelt. Pass the activity context to the constructor of ColorObjectManager from your activity class.
new ColorObjectManger(ActivityName.this);
Constructor
Context mContext;
public ColorObjectManager(Context context)
{
this.mContext= context;
}
Then use the context to get resources.
Edit:
If you want to use the context only in your load method
public ColorObjectManager(Context context)
{
load(context);
}

To get access getResources() , Activity context is required. Your ColorObjectManager is not an Activity. So you need to pass the Activity context to this class.

Getting context from getContext() or from constructor as a field

Let's use custom or extending View as an example.
Is it more effective to save Context parameter from constructor as a field, than calling getContext() everywhere (supposing there are, let's say, 10 or more places where it is needed)?

Instead of using getContext() every where, it is better to pass current context as argument in constructor where you wanna to use.

View#getContext() is
class View {
protected Context mContext;
public final Context getContext() {
return mContext;
}
}
and a locally cached implementation:
class X {
private final Context mLocalContext;
public X(Context ctx) {
mLocalContext = ctx;
}
}
Now there is a very small difference when you use mLocalContext instead of getContext(). The JVM can get to the required reference of the context object without having to execute the method (which takes a tiny bit of extra time). That call can't be optimized away since View#mContext is mutable (can change). In the local example it can assume that mLocalContext can't change and optimize the code a little better. [Note: I am not 100% sure about what optimizations are / can be done]
The difference might be measurable if you use the context a lot but in this case it does not matter much. It's still a good idea to cache Objects locally if you need them often. Especially when their (re)construction takes time (e.g. when getContext() would create a new Context() or so).

It looks like, from the source code, the View's constructor stores the context parameter and that's what getContext() returns:
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2_r1.1/android/view/View.java#View.getContext%28%29
So, my instinct would be that storing the parameter yourself would be redundant, since the super class is already doing it for you.