I have a SyncAdapter overloading onPerformSync. In that method, I'd like to access sharedpreferences to get and put settings. As I understand it, for that I need access to a context. The SyncAdapter onPerformSync has a bundle argument, and maybe I could send the context that way.
In a similar problem, I have another base class (not a service or activity) for which I'm also interested in using sharedPreferences. For this, I would either need to pass the context to a method in the class, or instantiate it with the context that is then saved as a private member.
In both of these cases, I understand that keeping and using a context beyond the lifecycle of the activity or service associated with the context can lead to memory leaks.
In my case, my application can begin with either a broadcastreceiver or the main activity. The broadcast receiver starts a background process, and the main activity just starts the main activity. Whichever opens first registers periodic SyncAdapter updates and opens the other class. So if I were to pass the context of the calling activity or service, what happens if either one of them then closes? The SyncAdapter or base class would use an outdated context, and...memory leak? Or would the context revert to whatever remains running?
I also saw the solution to this: (Static way to get 'Context' on Android?), but would that fix anything? I'd then have an activity context, an application context, and a service context. Same problem right? The SyncAdapter may end up holding on to a context that has closed, no?
Based on the first answer here (SharedPreferences application context vs activity context) I'm tempted to go with the application singleton listed in the previous link, but I want to make sure. Thanks
I think what you want to do is to create a Service to manage the SyncAdapter like mentioned here. That way, the Context passed to the Service should be valid while the SyncAdapter is running.
The link shows that you would pass Service.getApplicationContext() to the SyncAdapter constructor. Then you could store that Context as a field in the SyncAdapter and use it when you need to. That Context should be valid for as long as you need it.
When the app and / or the SyncAdapter get GC'd, they should build a new SyncAdapter with a new Context the next time you need it.
Related
I have a method, that request permission from user. I placed it in the ViewModel to make it in background, but in order to run it, I have to pass the Activity to the shouldShowRequestPermissionRationale method. How I may do it?
Putting code in ViewModel that somehow requires an android context is not a good idea. The purpose of ViewModel is too separate itself from all the android components. If you will try to force your way by passing activity's context in your viewModel to somehow make it work, then you will leak context if you are not careful.
A good solution would be to realize which code should relies in Activity and which should go in a viewModel. If we are talking about granting permissions, that sounds like something that should definitely reside in the Activity class, as an Activity has API to deal with requesting for permissions and managing the response from the users, i.e. either permission is denied or not.
I have an Activity StaggeredPrenotaTour starting a second Activity Details through an Intent, the class Details contains an AsyncTask class ReservationTask, and after some operations to the network, it has to pass a Java Object back go the StaggeredPrenotaTour class.
StaggeredPrenotaTour at the point where it starts Details:
Intent message = new Intent(staggeredPrenotaTour, Details.class);
message.putExtras(bundle);
getContext().startActivity(message);
Basically I need pass my Object to the current context of StaggeredPrenotaTour, so that I don't have to create a new instance of it but update the contents of the current one!
Unfortunately I've read that there is no way you can get a Context from an Intent, so how is another way to get the working instance of StaggeredPrenotaTour inside Details class?
so how is another way to get the working instance of StaggeredPrenotaTour inside Details class?
You don't.
so that I don't have to create a new instance of it but update the contents of the current one!
It sounds like these two activities should share a common data model, perhaps implemented via a singleton manager. StaggeredPrenotaTour can use the revised data in its onResume() method, which will be called as part of it coming back into the foreground after Details is destroyed (e.g., user presses BACK).
Or, use an event bus (LocalBroadcastManager, greenrobot's EventBus, Square's Otto, etc.). Have ReservationTask raise a ReservationResultsEvent that StaggeredPrenotaTour subscribes to, so StaggeredPrenotaTour can find out the results of the work.
Starting another activity doesn't have to be one-way. You can also
start another activity and receive a result back. To receive a result,
call startActivityForResult() (instead of startActivity()).
For details, read the guide on developer.android.com
I save to SharedPreferences within a single Activity several times. Each time I do reads or writes, I pass the Context. Following are the two options I am thinking about - which one is better (or is there a better way)
Everytime I need to pass context to a function in another class (for ex a class writing to my SharedPreferences), I am passing the this getActivity().getApplicationContext().
Should I just save a variable once in the onCreate() of the Activity (i.e. Context ctxt = getActivity().getApplicationContext()) and then use the variable ctxt throughout the Activity whenever I need to pass context.
Which way is technically better? Key is - should I be accessing getApplicationContext() each time. I am guessing that is slow (& unnecessary) and also probably causes crashes (I've been seeing some logs from my users that I am unable to reproduce but the stack traces always point to lines containing getApplicationContext())
The Activity itself can be used as the Context. Simply pass this. You can pass ActivityName.this inside an inner class.
getApplicationContext() returns "the context of the single, global Application object of the current process."
check this post its what you want, and you just use the Activity as Context and there is no problem calling getApplicationContext() anytime you want, you just might need to find alternatives to that and maybe use getBaseContext() or the activity itself
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Difference between Activity Context and Application Context
When to use Context and Activity.
I have read code that uses both Context and Activity as parameters in Constructor like below,please clear me on this
public AmazedView(Context context, Activity activity) {
super(context);
mActivity = activity;
// init paint and make is look "nice" with anti-aliasing.
mPaint = new Paint();
mPaint.setTextSize(14);
mPaint.setTypeface(mFont);
mPaint.setAntiAlias(true);
// setup accelerometer sensor manager.
mSensorManager = (SensorManager) activity.getSystemService(Context.SENSOR_SERVICE);
// register our accelerometer so we can receive values.
// SENSOR_DELAY_GAME is the recommended rate for games
mSensorManager.registerListener(mSensorAccelerometer, SensorManager.SENSOR_ACCELEROMETER,
SensorManager.SENSOR_DELAY_GAME);
// setup our maze and marble.
mMaze = new Maze(mActivity);
mMarble = new Marble(this);
// load array from /res/values/strings.xml
mStrings = getResources().getStringArray(R.array.gameStrings);
// set the starting state of the game.
switchGameState(GAME_INIT);
}
Context: is a handle to the system. Context contains environment data such as local files, database, ... Context also include many system services. For example, Context will provide access to Location Service,... Also, with context, you can use resources, access to databases and preferences, local data ...
Activity: extends from Context. And not only Activity, many others extends Context, and each has its own purpose such as: FragmentActivity, Service, WallpaperService. More detail in Activity, "normal" android app has activity. It's like a handle to the environment your application is currently running in. Activity can create UI (User Interface)
In your above code, depends on other constructor, you should put context or activity object into. And as you see, if activity takes from the same context, you can use one parameter in the constructor
public AmazedView(Context context) {
Activity activity = (Activity) context;
}
But you can see, it's not clear, and "hide" real object behind. Because Activity is the subclass of context, so in an informal way, Activity has some "additional things" that context doesn't have. If you put it as a context object, no one knows that fact and will make the code seems obscure. Moreover, context might become from Service for example, and you will don't sure when typecasting to Activity. So, make two parameters is suitable here.
More importantly, you should carefully to use Activity as the context object because it might cause a memory leak.
Application context refers to the application environment and the process within which
all its components are running. It allows applications to share the data and resources
between various building blocks.An application context gets created whenever the first component of this application is started up regardless of whether that component is an activity, service, or something else.Application context lives as long as your application is alive. As such, it is independent of the activities life cycle. You can easily obtain a reference to the context by
calling
Context.getApplicationContext() or Activity.getApplication()
keep in mind that activities and services are already subclasses of context, and as such they inherit
all its methods.
An activity is usually a single screen that the user sees on the device at one time. An
application typically has multiple activities, and the user flips back and forth among
them. As such, activities are the most visible part of your application.
you can also take a look at this : What is 'Context' on Android?
On the developer page of android:
http://developer.android.com/reference/android/content/Context.html
it states:
"[A context is an] 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. "
An Activity is an indirect subclass of Context, as mentioned on the page.
I am following some tutorials for learning android but the problem is they do not contain all the details.
Specifically, it would be great if some light could be shed upon the use cases for getApplicationContext().
You can think of a Context as a handle to your application's resources (i.e. everything in the res folder) and to the Android runtime. Classes like Activity, Service, Application inherit from Context, among others.
Typically, you'll pass in the current Activity whenever a Context is required, since Activity inherits from Context.
You'll also find information about using getApplicationContext() instead of your activities when a Context is required. This usually is to prevent whatever code that needs the Context from unnecessarily holding a reference to your Activity, which in the worst case might preventing it from being garbage collected (passing in the Application isn't really a huge problem in that scenario, because it's expected to be around for a long time).
However, there are certain scenarios where an argument of a method is of type Context, but an Activity is actually required. Using startActivity() is one example of this I believe (correct me if I'm wrong).