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().
Related
On android,I am using JUnit to test the Amazon web server cognito which requires a context to access the shared preferences. I tried to mock the context, and to use android instrumentation tools but neither options worked. The context is being received, but I am unable to access shared preferences as I'm getting a null pointer.
Any suggestions?
Thank you.
If you are trying to mock, you could try Mockito. You will need to find all that call that need to be mocked.
final Context mockContext = Mockito.mock(Context.class);
final SharedPreferences preferences = Mockito.mock(SharedPreferences.class);
Mockito.when(preferences.getString("<identitypool>.<key>", null)).thenReturn("someValue");
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)
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.
I can't figure out why the context is getting passed in to this method: http://code.google.com/p/cloud-tasks-io/source/browse/trunk/CloudTasks-Android/src/com/cloudtasks/Util.java#119
The keys of the URL_MAP are the Contexts. So you need the context to get the base url.
I need to use getString() from most of the modules in my application.
But for some strange reason, it is tied to Application or Context, so that means I need to pass to each and every class in my application, the Application reference as a parameter.
This clearly violates one of the most basic principles of object oriented design.
Is there a way around this?
The 'strange reason' is that since the string resources are tied to your application, there is no way to access them without some sort of handle to it (the Context). If most of your classes that are not activities need to access string resources, you might want to rethink your design a bit. A simple way to not depend on a Context is to load the strings and pass them to your classes in the constructor.
Yes, there is a workaround - if you happen to (or can) pass a View (any View-derived class) to the constructor, and you assign it to a data member, then you can access the string resources from anywhere in your class:
String str_via_res = yourView.getContext().getString(R.string.str_via_res);
Otherwise, you will have to pass a Context to every class that needs access to these string resources.
you can extend android.app.Application class to create a static method to pass on the context across all classes in your application.
Refer : PhoneApp.java