Detailed explanation of adapter mode and application scenarios of Android design pattern

[[417879]]

Preface

Design patterns are sometimes a hurdle, but they are also very useful. Once you pass this hurdle, it can help you improve your skills to a higher level. In Android development, it is necessary to understand some design patterns, because design patterns are everywhere in the Android source code.

Today we will explain the adapter mode

1. Definition and Problem Solving of Adapter Pattern

1. The adapter pattern transforms the interface of a class into another interface expected by the client, so that two classes that could not work together due to interface mismatch can work together

2. It serves as a bridge between two incompatible interfaces. This type of design pattern belongs to the structural pattern, which combines the functions of two independent interfaces.

3. Convert the interface of a class into another interface that the client wants. The adapter pattern enables classes that originally could not work together due to incompatible interfaces to work together.

4. This pattern involves a single class that is responsible for joining independent or incompatible interface functions. For example, a card reader is an adapter between a memory card and a laptop. You insert the memory card into the card reader and then insert the card reader into the laptop, so that the memory card can be read through the laptop;

5. Mainly solve the problem that in software systems, some "existing objects" often need to be placed in a new environment, and the interface required by the new environment cannot be met by the existing objects;

2. Applicable scenarios and advantages and disadvantages

1. Usage scenarios

• The system needs to use an existing class, but the interface of this class does not meet the needs of the system, that is, the interface is incompatible;
• Want to build a reusable class that works with some classes that are not closely related to each other, including some classes that may be introduced in the future;
• A unified output interface is required, while the input interface is unpredictable;

2. Advantages

• Decouple the target class and the adapter class, and reuse the existing adapter class by introducing an adapter class without modifying the original structure.
• The transparency and reusability of the class are increased, and the specific business implementation process is encapsulated in the adapter class, which is transparent to the client class and improves the reusability of the adapter. The same adapter class can be reused in multiple different systems.
• The flexibility and scalability are very good. By using configuration files, you can easily replace the adapter, or add a new adapter without modifying the original code, which is in full compliance with the open-closed principle.

3. Disadvantages

• Using too many adapters will make the system very messy and difficult to grasp as a whole. For example, although you see that the call is to interface A, it is actually adapted to the implementation of interface B. If this happens too much in a system, it is tantamount to a disaster. Therefore, if it is not necessary, you can directly reconstruct the system without using adapters.
• Since JAVA can inherit at most one class, at most one adapter class can be adapted, and the target class must be an abstract class.
• At most one adapter class can be adapted at a time, and multiple adapters cannot be adapted at the same time.
• The target abstract class can only be an interface, not a class, and its use has certain limitations;

3. Two modes of adapter

There are two types of adapter modes:

• Class Adapter
• Object Adapter

The roles involved in the model are:

• Target role: This is the interface that is expected. Note: Since we are discussing the class adapter pattern here, the target cannot be a class.
• Source (Adapee) role: now requires an adapter interface.
• Adapter role: The adapter class is the core of this pattern. The adapter converts the source interface into the target interface. Obviously, this role cannot be an interface, but must be a concrete class.

Scenario:

If class A wants to use method M, class X has method M, but the result of method M may not fully meet the needs of class A.

Then class X is hard-coded and difficult to use. This is a bad design.

Then replace class X with an interface, create some intermediate classes such as B, C, D, E, etc., let them all have a method to handle the things of method M, and then give class A a method to handle the things of method M.

1. Class adapter:

Design an interface I, so that it also has M methods

Then design a class B and write a specialM method that meets the requirements of class A.

Then let class A inherit class B and implement the M method of interface I

Finally, in the M method of class A, the specialM method of class B is called in a super manner.

2. Object adapter: (more often use object adapter)

Design an interface I, so that it also has M methods

Then design a class B and write a specialM method that meets the requirements of class A.

Then declare a class B variable in class A, and class A implements the I interface, so class A also has the M method

Finally, in the M method of class A, if necessary, you can choose to call the specialM method of class B.

Or design a class B to implement the M method of the I interface

Then declare a class I variable in class A, and then directly call the M method of the I interface

Before calling the M method of class A, set class B to be a member variable of class A through methods such as setAdapter(I Adapter)

This ensures that class A and interface I remain unchanged. When adapting to different situations, you can write an intermediate class similar to class B for adaptation.

In short, the two ends remain unchanged, and different intermediate classes are selected through different selection methods, that is, the adapter mode.

3. Real-world adapter examples

accomplish

Here we use an example to simulate the adapter mode. The requirement is this: the headphone jack of iPhone 12 is cancelled, how can we ensure that the previous headphones can still be used? Of course, an adapter is needed, which is actually similar to our adapter.

The interface required by the headset is our target role, the interface provided by the mobile phone is our source role, and the adapter is of course the adapter role.

Class Adapter

Target Role

 public interface ITarget {
 //Get the required interface
    String getRightInterface();
 }

Source Role

 public class IPhoneSeven {
 //Get the interface provided by iPhone7
 public String getInterface(){
 return   "iphone7 interface" ;
 }
 }

adapter

 public class CAdapter extends IPhoneSeven implements ITarget{
 @Override
 public String getRightInterface() {
        String newInterface = getInterface();
 return suit(newInterface);
 }
 /**
 * Conversion operation
 * @param newInterface
 * @return  
 */
    private String suit(String newInterface) {
 return   "3.5mm interface" ;
 }
 }

Object Adapter

The target role of the object adapter is the same as the source role, so we will not write it again.

adapter

 public class Adapter implements ITarget {
    private IPhoneSeven mIPhoneSeven;
 public Adapter(IPhoneSeven IPhoneSeven) {
        mIPhoneSeven = IPhoneSeven;
 }
 @Override
 public String getRightInterface() {
        String newInterface = mIPhoneSeven.getInterface();
 return suit(newInterface);
 }
 /**
 * Conversion operation
 * @param newInterface
 * @return  
 */
    private String suit(String newInterface) {
 return   "3.5mm interface" ;
 }
 }

IV. Application scenarios in Android

The adapter pattern is widely used in Android, the most common ones are ListView, GridView, RecyclerView, etc. And the ListView we often use is a typical example.

When using ListView, the layout and data of each item are different, but the final output can be regarded as a View, which corresponds to the third application scenario of the adapter pattern above: a unified output interface is required, while the input interface is unpredictable. Let's take a look at the adapter pattern in ListView.

First, let's take a look at the general structure of our Adapter class

 class Adapter extends BaseAdapter {
    private List<String> mDatas;
 public Adapter(List<String> datas) {
 mDatas = datas;
 }
 @Override
 public   int getCount() {
 return mDatas.size () ;
 }
 @Override
 public long getItemId( int position) { return position; }
 @Override
 public Object getItem( int position) { return mDatas.get(position);}
 @Override
 public   View getView( int position, View convertView, ViewGroup parent) {
        if (convertView == null ) {
 //Initialize View  
 }
 // Initialize data
 return convertView;
 }
 }

It can be seen that the interfaces in the Adapter are mainly getCount() to return the number of child Views, and getView() to return the View we have filled with data. ListView uses these interfaces to perform specific layout, caching and other tasks. Let's take a brief look at the implementation of ListView.

First of all, these getCount() and other interfaces are all in an interface class Adapter

 public interface Adapter {
 //Omit other interfaces
 int getCount();
    Object getItem( int position);
    long getItemId( int position);
 View getView( int position, View convertView, ViewGroup parent);
 //Omit other interfaces
 }
 A transition interface ListAdapter is added in the middle
 public interface ListAdapter extends Adapter {
 //Interface omitted
 }

When we write our own Adapter, we will inherit a BaseAdapter. Let's take a look at BaseAdapter

 public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {
 //BaseAdapter implements the interface of ListAdapter and some interfaces in Adapter
 //Interfaces like getCount() and getView() need to be implemented by ourselves
 }
 ListView's parent class AbsListView has a ListAdapter interface, which is used to call methods such as getCount() to obtain the number of Views .
 public abstract class AbsListView extends AdapterView<ListAdapter> implements TextWatcher,
        ViewTreeObserver.OnGlobalLayoutListener, Filter.FilterListener,
        ViewTreeObserver.OnTouchModeChangeListener,
        RemoteViewsAdapter.RemoteAdapterConnectionCallback {
 /**
     * The adapter containing the data to be displayed by this view  
 */
 ListAdapter mAdapter;
 @Override
    protected void onAttachedToWindow() {
        super.onAttachedToWindow();
        final ViewTreeObserver treeObserver = getViewTreeObserver();
        treeObserver.addOnTouchModeChangeListener(this);
        if (mTextFilterEnabled && mPopup != null && !mGlobalLayoutListenerAddedFilter) {
            treeObserver.addOnGlobalLayoutListener(this);
 }
        if (mAdapter != null && mDataSetObserver == null ) {
            mDataSetObserver = new AdapterDataSetObserver();
            mAdapter.registerDataSetObserver(mDataSetObserver);
            // Data may have changed while we were detached. Refresh.
            mDataChanged = true ;
            mOldItemCount = mItemCount;
 //Get the number of View elements through getCount()
            mItemCount = mAdapter.getCount();
 }
 }
 }

From the above, we can see that AbsListView is an abstract class, which encapsulates some fixed logic, such as the application logic of the Adapter mode, the reuse logic of the layout, and the logic of the layout sub-element. The specific implementation is in the subclass ListView. Let's take a look at how each sub-element View is handled in ListView.

 @Override
 protected void layoutChildren() {
 //Omit other codes
 case LAYOUT_FORCE_BOTTOM:
        sel = fillUp(mItemCount - 1, childrenBottom);
        adjustViewsUpOrDown();
 break;
 case LAYOUT_FORCE_TOP:
 mFirstPosition = 0;
        sel = fillFromTop(childrenTop);
        adjustViewsUpOrDown();
 break;
 //Omit other codes
 }

In ListView, the layoutChildren() function in AbsListView is overwritten. In layoutChildren(), layout is performed according to different situations, such as from top to bottom or from bottom to top. Let's take a look at the specific layout method fillUp method.

 private View fillUp( int pos, int nextBottom) {
 //Omit other codes
    while (nextBottom > end && pos >= 0) {
        // is this the selected item?
        boolean selected = pos == mSelectedPosition;
 View child = makeAndAddView(pos, nextBottom, false , mListPadding. left , selected);
        nextBottom = child.getTop() - mDividerHeight;
 if (selected) {
            selectedView = child;
 }
 pos --;  
 }
 mFirstPosition = pos + 1;
    setVisibleRangeHint(mFirstPosition, mFirstPosition + getChildCount() - 1);
 return selectedView;
 }

Here we can see that the fillUp method uses the makeAndAddView() method to get the View. Let's take a look at the implementation of the makeAndAddView() method.

 private View makeAndAddView( int position, int y, boolean flow, int childrenLeft,
            boolean selected) {
 if (!mDataChanged) {
        // Try to use an existing view   for this position.
        final View activeView = mRecycler.getActiveView(position);
        if (activeView != null ) {
            // Found it. We're reusing an existing child, so it just needs
            // to be positioned like a scrap view .
            setupChild(activeView, position, y, flow, childrenLeft, selected, true );
 return activeView;
 }
 }
 // Make a new view   for this position, or   convert an unused view if
 // possible.
    final View child = obtainView(position, mIsScrap);
    // This needs to be positioned and measured.
    setupChild(child, position, y, flow, childrenLeft, selected, mIsScrap[0]);
 return child;
 }

I wonder what you think when you see this?

The cache mechanism appears in the makeAndAddView() method, which is the key method to improve the loading efficiency of ListView. We can see that when getting the child View, it will first look in the cache, that is, it will look in mRecycler. mRecycler is a RecycleBin class used for caching in AbsListView. Let's take a look at the implementation of the cache.

 class RecycleBin {
    private View [] mActiveViews = new View [0];
 /**
     * Get the view corresponding to the specified position. The view will be removed from  
     * mActiveViews if it is found.
 *
     * @param position The position to look up in mActiveViews
     * @ return The view if it is found, null otherwise
 */
 View getActiveView( int position) {
 int   index = position - mFirstActivePosition;
        final View [] activeViews = mActiveViews;
        if ( index >=0 && index < activeViews.length) {
            final View match = activeViews[ index ];
            activeViews[ index ] = null ;
 return match;
 }
 return   null ;
 }
 }

As can be seen above, the cached View is stored in a View array. Then let's see how ListView obtains the child View if the cached View is not found, that is, the obtainView() method above. It should be noted that the obtainView() method is in AbsListView.

 View obtainView( int position, boolean[] outMetadata) {
 //Omit other codes
    final View scrapView = mRecycler.getScrapView(position);
    final View child = mAdapter.getView(position, scrapView, this);
 if (scrapView != null ) {
        if (child != scrapView) {
            // Failed to re-bind the data, return scrap to the heap.
            mRecycler.addScrapView(scrapView, position);
        } else if (child.isTemporarilyDetached()) {
            outMetadata[0] = true ;
            // Finish the temporary detach started in addScrapView().
            child.dispatchFinishTemporaryDetach();
 }
 }
 //Omit other codes
 return child;
 }

You can see that the uncached View is directly obtained from the getView() method of the Adapter we wrote.

Above we have briefly seen the application of the adapter pattern in ListView. From this we can see that ListView introduces the Adapter class to hand over the changing layout and data to the user, and then obtains the required data through the interface in the adapter to complete its own functions, thus achieving good flexibility. The most important interface here is the getView() interface, which returns a View object, and the ever-changing UI views are all subclasses of View. Through such a process, the changes of the sub-Views are isolated, ensuring the high customizability of the AbsListView class family.

Summarize:

• Better reusability: If the system needs to use an existing class, but the interface of this class does not meet the needs of the system, then the adapter pattern can make these functions better reused.
• Better scalability: When implementing the adapter function, you can call your own developed functions to naturally expand the system's functionality.

This article is reproduced from the WeChat public account "Android Development Programming"