PanelSlideListener called too often about androidslidinguppanel HOT 6 CLOSED

Until this is fixed, you can do the following to prevent this behaviour:

final SlidingUpPanelLayout layout = (SlidingUpPanelLayout) findViewById(R.id.sliding_layout);
layout.setPanelSlideListener(new SlidingUpPanelLayout.PanelSlideListener() {

            private AtomicBoolean mPanelCollapsed = new AtomicBoolean(true);

            @Override
            public void onPanelSlide(final View panel, final float slideOffset) {
            }

            @Override
            public void onPanelExpanded(final View panel) {
                if (mPanelCollapsed.compareAndSet(true, false)) {
                    LOG.trace("onPanelExpanded");
                }
            }

            @Override
            public void onPanelCollapsed(final View panel) {
                if (mPanelCollapsed.compareAndSet(false, true)) {
                    LOG.trace("onPanelCollapsed");
                }
            }
        });

from androidslidinguppanel.

Good call! I implemented your solution in my personal dev branch.

from androidslidinguppanel.

The first thing you mention is actually working as intended. onPanelExpanded is supposed to get called every time the panel is full expanded (i.e. even after it snaps back). The second thing is probably a bug.

from androidslidinguppanel.

About the second problem (with the two calls initialState -> finalState), from what I've seen in the debugger, I think what happens is:

public boolean onTouchEvent(MotionEvent ev) {
       ....
       mDragHelper.processTouchEvent(ev);
       ..... 

       case MotionEvent.ACTION_UP: {
       // if isDragViewHit, expand/anchor/collapse the panel
}

The ACTION_UP part is OK, leading to the desired final state. I guess the mDragHelper.processTouchEvent triggers onViewDragStateChanged with STATE_IDLE for the initial state, this dispatching the associated callback for the initial state. I've tried not calling mDragHelper.processTouchEvent(ev) for the ACTION_UP + isDragViewHit case (since it's a case the library gets to handle explicitly) and, at first sight, it seems to work. Yet, I'm not completely sure if it's OK not to let the DragHelper process that event. Maybe it needs to for some specific case in dragging that I might have missed while testing.

from androidslidinguppanel.

Hi Irina, thanks for having a look. I'll check it out myself this week, when I have time. But this definitely helps!

from androidslidinguppanel.

Fixed in 532a926

from androidslidinguppanel.