Android in-depth study adapter redraw

All along the use of adapter is just flow on the surface, only know to implement a few abstract methods, the adapter set to some kind of listview, you can work very well. The so-called understanding is only based on subjective conjecture, think it should be so, yes, OK, so, yes, understand. But in fact, I don't really understand it. This can be said that the Android design mode is really good, do not need to understand the implementation can be very good use, but always feel that there is no in-depth investigation or a little something. Then take a look at some of its details. Especially to see what I've been wondering why call notifydatasetchanged notifydatasetinvalidated to redraw the view.

First of all, from the limited clues I mastered, how did the notifydatasetchanged approach come true?

According to experience, almost all of the adapter we use is inherited from Baseadapter, and with Eclipse's type Hierarchy View you can also confirm that this is the case, OK, let's look at its implementation:

    /**     * Notifies the attached observers that the underlying data have been changed     * and any View reflecting the data Set should refresh itself.     *    /public void notifydatasetchanged () {        mdatasetobservable.notifychanged ();    }    /**     * Notifies the attached observers that the underlying data is no longer valid     * or available. Once invoked this adapter are no longer valid and should     * Not report further data set changes.     *    /public void notifydatasetinvalidated () {        mdatasetobservable.notifyinvalidated ();    }

It turned out to be a observer, and it was similar to what I had guessed before.

    public void notifychanged () {        synchronized (mobservers) {            //since onChanged () are implemented by the app, it could Do anything, including            //removing itself from {@link Mobservers}-and that could cause problems if            //an Iterato R is used on the ArrayList {@link mobservers}.            To avoid such problems, just March thru the list in the reverse order.            for (int i = Mobservers.size ()-1; I >= 0; i--) {                mobservers.get (i). onChanged ();}}    }

It seems that can hang a lot of observer, continue to see the onchanged realize when the discovery of an abstract, how to do, who is it? It seems to be a concrete realization. Look at the more familiar ListView

And more familiar with the listadapter, found in the Setadapter of the ListView

            Mdatasetobserver = new Adapterdatasetobserver ();            Madapter.registerdatasetobserver (Mdatasetobserver);

The implementation of Adapterdatasetobserver in Adapterview:

 Class Adapterdatasetobserver extends Datasetobserver {private parcelable minstancestate = null;            @Override public void onChanged () {mdatachanged = true;            Molditemcount = Mitemcount;            Mitemcount = Getadapter (). GetCount ();            Detect the case where a cursor is previously invalidated have//been repopulated with new data. if (AdapterView.this.getAdapter (). Hasstableids () && minstancestate! = null && mOl                Ditemcount = = 0 && mitemcount > 0) {AdapterView.this.onRestoreInstanceState (minstancestate);            Minstancestate = null;            } else {remembersyncstate ();            } checkfocus ();        Requestlayout ();            } @Override public void oninvalidated () {mdatachanged = true; if (AdapterView.this.getAdapter (). Hasstableids ()) {//Remember the CURrent state for the case where we hosting activity is being//stopped and later restarted            Minstancestate = AdapterView.this.onSaveInstanceState ();            }//Data is invalid so we should reset our state molditemcount = Mitemcount;            Mitemcount = 0;            Mselectedposition = invalid_position;            Mselectedrowid = invalid_row_id;            Mnextselectedposition = invalid_position;            Mnextselectedrowid = invalid_row_id;            Mneedsync = false;            Checkfocus ();        Requestlayout ();        } public void Clearsavedstate () {minstancestate = null; }    }

OK, the original is so to update, understand.

To sum up, all adapter are baseadapter subclasses, and all view with adapter is a subclass of Adapterview. Abslistview is also a subclass of Adapterview.

When the view is associated with the adapter, the view's oberver is registered on the adapter, so when the adapter data changes. View can be learned through observer so that it can be updated in a timely manner.

It seems that the implementation of the adapter mode with the Oberver mode, vaguely still use the bridge mode, do not know if I know the correct.

Android in-depth study adapter redraw