When we are doing application development, an activity may be combined with viewpager (or other container) and multiple fragments. If each fragment needs to load data, load locally, or load from the network, then when this activity is first created, it will require a large number of resources to be initialized. Of course we will not be satisfied with such a result. So, can it be done when switching to this fragment before it is initialized?
The answer lies in the setUserVisibleHint method in Fragment. Please see the API documentation about this method in Fragment (domestic mirror address:/YrpKlu）：
Set a hint to the system about whether this fragment's UI is currently visible to the user. This hint defaults to true and is persistent across fragment instance state save and restore. An app may set this to false to indicate that the fragment's UI is scrolled out of visibility or is otherwise not directly visible to the user. This may be used by the system to prioritize operations such as fragment lifecycle updates or loader ordering behavior. Parameters isVisibleToUser true if this fragment's UI is currently visible to the user (default), false if it is not.
This method is used to tell the system whether the UI of this Fragment is visible. So we only need to inherit the Fragment and override the method to realize the data loading operation when the fragment is visible, that is, the lazy loading of the Fragment.
The code is as follows:
/*
* Date: 14-7-17
* Project: Access-Control-V2
*/
package .access_control_v2.common;
import .;
/**
* Author: msdx (645079761@)
* Time: 14-7-17 5:46 pm
*/
public abstract class LazyFragment extends Fragment {
protected boolean isVisible;
/**
* Implement the slow loading of Fragment data here.
* @param isVisibleToUser
*/
@Override
public void setUserVisibleHint(boolean isVisibleToUser) {
(isVisibleToUser);
if(getUserVisibleHint()) {
isVisible = true;
onVisible();
} else {
isVisible = false;
onInvisible();
}
}
protected void onVisible(){
lazyLoad();
}
protected abstract void lazyLoad();
protected void onInvisible(){}
}
In LazyFragment, I added three methods, one is onVisable, that is, called when the fragment is set to be visible, and the other is onInvisible, that is, when the fragment is set to be invisible. In addition, I wrote an abstract method of lazyLoad, which is called in onVisible. You may wonder, why not just call it directly in getUserVisibleHint?
I wrote this for reuse of the code. Because in fragment, we also need to create a view (onCreateView() method), and may also need to perform small amounts of initialization operations when it is invisible (such as initializing a remote service that needs to be called through AIDL), etc. setUserVisibleHint is called before onCreateView. If it is used in lazyLoad when the view is not initialized, there will be an exception of the null pointer. If lazyLoad is extracted into a method, its subclass can do this:
public class OpenResultFragment extends LazyFragment{
// Flag bit, the flag has been initialized. private boolean isPrepared;
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
(LOG_TAG, "onCreateView");
View view = (.fragment_open_result, container, false);
//XXX initializes the various controls of the view isPrepared = true;
lazyLoad();
return view;
}
@Override
protected void lazyLoad() {
if(!isPrepared || !isVisible) {
return;
}
//Fill in the data of each control }
}
In the above class, we added a flag bit isPrepared to mark whether the initialization is completed. Then call it after the initialization operation we need. As in the example above, after initializing the view, set isPrepared to true, and call the lazyLoad() method. In lazyLoad(), it is determined that isPrepared and isVisible will not be executed as long as there is not true. That is, it will only continue to load when the initialization is completed and visible, which avoids the problem of using it before the initialization is completed.
This is the end of my introduction to the lazy loading implementation of fragments. If you are interested, you can explore it further based on this, such as writing a fragment with features such as slow initialization and visible refresh.
The above is the preloading problem of fragments in Android development introduced to you by the editor. I hope it will be helpful to you. If you have any questions, please leave me a message and the editor will reply to you in time!