问题
I have a custom View that runs a Thread operation which sits around making calls to the interwebs periodically. I would like to know if there's a way for me to not have to kill that thread from the parent Activity (onPause) so that the Thread isn't milling about in the background after the Activity has been backgrounded (and/or killed).
The intention here is for the custom View to be self sufficient and not need additional handling from the Activity. The way to do that would be for it to listen for when its parent was backgrounded and for it to then let the infinite sleep loop in the Thread expire. I'm not seeing a way to do that, but am hoping that I'm overlooking something.
回答1:
Not unless you notify it directly.
For your purpose, override View.onDetachedFromWindow()
and relinquish your Thread there. Then, when the view is visible again, spin the Thread back up in View.onAttachedToWindow()
. The problem with onPause() and onResume() is that you can still have a view that's visible on screen, but is attached to a paused Activity. An example of when this can happen is if you have one Activity in a window that overlays another.
Or, as william gouvea suggests, a Fragment might be better suited for your purpose since it already has the life-cycle hooks for pause and resume, and anything that talks to the network really falls in the controller realm anyway.
回答2:
Yes you can using below code,
@Override
protected void onVisibilityChanged(@NonNull View changedView, int visibility) {
super.onVisibilityChanged(changedView, visibility);
if (visibility == View.VISIBLE) //onResume called
else // onPause() called
}
@Override
public void onWindowFocusChanged(boolean hasWindowFocus) {
super.onWindowFocusChanged(hasWindowFocus);
if (hasWindowFocus) //onresume() called
else // onPause() called
}
@Override
protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
// onDestroy() called
}
@Override
protected void onAttachedToWindow() {
super.onAttachedToWindow();
// onCreate() called
}
回答3:
Yes you can. All that you need is to have a field of LifecycleOwner type. More about it in official documentation. In my case i created a custom view with another view from 3rd party library - CameraView.
At first, custom view needs to implement LifecycleOberver interface
public class MakePhotoView extends ConstraintLayout implements LifecycleObserver
So, i have a field in my custom view:
private LifecycleOwner mLifecycleOwner;
I pass it in the constructor as one of parameters:
public MakePhotoView(Context context, OnPhotoMadeListener onPhotoMadeListener, LifecycleOwner lifecycleOwner) {
super(context);
mOnPhotoMadeListener = onPhotoMadeListener;
mLifecycleOwner = lifecycleOwner;
init();
}
After that i register my custom view as observer for lifecycle events in LifecycleOwner:
private void init() {
//other code
mLifecycleOwner.getLifecycle().addObserver(this);
}
And finally i can listen for lifecycle events:
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
public void startCamera() {
AppLog.logObject(this, "On Resume called for MakeCameraView");
mCameraView.start();
}
@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
public void stopCamera() {
AppLog.logObject(this, "On Pause called for MakeCameraView");
mCameraView.stop();
}
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
public void destroyCamera() {
AppLog.logObject(this, "On Destroy called for MakeCameraView");
mCameraView.destroy();
}
回答4:
Either you have to let your view know that the owning Activity is not in the foreground any more, or poll the system with some method to query about which task is currently in the foreground, which seems highly inefficient.
Here are two links that have addressed this issue:
- How to check if activity is in foreground or in visible background?
- Checking if an Android application is running in the background
(This might not really be an answer, but it was too large for a comment)
回答5:
If you simply override the View class and create your own CustomView you could create a interface to act as a listener, which should be implemented by you parent activity, so when something happens you trigger the event and establish the communication between those components back and forth.
Depending on what you want to achieve, Fragments could be useful since this component has your own lifecycle similar to activity (onPause/onResume for instance) , holds your own state, either has or not a view and could retain their state between configuration chamges.
See more in: http://developer.android.com/reference/android/app/Fragment.html http://developer.android.com/guide/components/fragments.html
来源:https://stackoverflow.com/questions/22368720/can-a-custom-view-know-that-onpause-has-been-called