Sliding panel header can appear fully transparent/untouchable

[barbeau]

For develop branch: Now master branch:

Occasionally when you tap on the stop and the bottom sliding panel appears, the header can turn fully transparent and isn't touchable - all tap/touch events are passed to the map. You can only see the shadow of the header on the map:

This only seems to happen when going from a stop with a single arrival in the header, to selecting no stops (i.e., tapping on the map away from a stop), to selecting a stop that has two arrivals to be shown in the header. I think it's related to the header resizing itself and the sliding panel reacting to this and collapsing itself - as a result nothing fills the space.

[barbeau]

A different symptom which I believe is related to the same problem is shown below, where the header/sliding panel fails to properly resize itself when changing from a stop with two arrivals in the header, to one with only one arrival in the header. The result is the panel collapsed to the "bottom" of the screen, but it doesn't actually make it all the way to the bottom:

In this case, you can actually touch and drag the panel and it will properly settle down to the bottom of the screen, and then resume normal sliding behavior.

[barbeau]

When the sliding panel header disappears, I'll see ADB output with negative slide offsets, like:

09-18 17:01:39.891  12220-12220/com.joulespersecond.seattlebusbot D/BubblePopupHelper﹕ isShowingBubblePopup : false
09-18 17:01:39.891  12220-12220/com.joulespersecond.seattlebusbot D/HomeActivity﹕ onPanelSlide, offset -0.00729927
09-18 17:01:39.901  12220-12220/com.joulespersecond.seattlebusbot D/HomeActivity﹕ onPanelSlide, offset -0.00486618
09-18 17:01:39.921  12220-12220/com.joulespersecond.seattlebusbot D/HomeActivity﹕ onPanelSlide, offset -0.0030413626
09-18 17:01:39.941  12220-12220/com.joulespersecond.seattlebusbot D/HomeActivity﹕ onPanelSlide, offset -0.001216545
09-18 17:01:39.951  12220-12220/com.joulespersecond.seattlebusbot D/HomeActivity﹕ onPanelSlide, offset -6.082725E-4
09-18 17:01:39.981  12220-12220/com.joulespersecond.seattlebusbot D/HomeActivity﹕ onPanelSlide, offset 0.0

A negative offset means the header has been removed from the screen (same as when the user clicks on the map away from the stop, and the header disappears).

EDIT

I'm also seeing occasional negative offsets when everything works correctly, so the negative offset by itself doesn't seem to be an issue.

[barbeau]

After some debugging, when tapping on a stop and the sliding panel header disappears, onPanelHidden() is being called within the SlidingUpPanelLayout.PanelSlideListener set up in HomeActivity. This shouldn't be happening - the only time we're hiding the sliding panel (mSlidingPanel.setPanelState(SlidingUpPanelLayout.PanelState.HIDDEN)) while the map is in view is when the user taps on the map away from the stop. So, seems like something internal to the SlidingPanel is triggering the HIDDEN state.

[barbeau]

Past attempt at fixing this that was unsuccessful: https://github.com/OneBusAway/onebusaway-android/commit/fb0ae445a5b4177a633bccac29d51aa902726db1

[barbeau]

I just pushed another commit to try and help with this issue - it doesn't fix it, but it seems to happen far less frequently.

I think this issue is triggered when the header is fully resized before it completely makes the transition from HIDDEN to COLLAPSED.

[barbeau]

Well, even if I move all the header resize execution into the slide panel controller so it only executes after the panel is in the COLLAPSED state, the issue still happens:

            @Override
            public void setPanelHeightPixels(int heightInPixels) {
                if (mSlidingPanel != null) {
                    if (mSlidingPanel.getPanelState() == SlidingUpPanelLayout.PanelState.DRAGGING ||
                            mSlidingPanel.getPanelState() == SlidingUpPanelLayout.PanelState.HIDDEN) {
                        // Don't resize header yet - see #294 - header size will be refreshed on state change
                        return;
                    }
                    mSlidingPanel.setPanelHeight(heightInPixels);
                    mArrivalsListHeaderView.getLayoutParams().height = heightInPixels;
                    View mMainContainerView = mArrivalsListHeaderView.findViewById(R.id.main_header_content);
                    mMainContainerView.getLayoutParams().height = heightInPixels;
                    Log.d(TAG, "Panel state on resize - " + mSlidingPanel.getPanelState().toString());
                }
            }

So something in the view resize seems to be pushing it below the bottom of the screen (even after the panel transition is finished), which triggers the panel to hide itself.

[barbeau]

It looks like the header is also disappearing when trying to edit the bus stop name and the keyboard is expanded/collapsed - see video here: https://www.youtube.com/watch?v=0Q7osS8SQuE&feature=youtu.be

I commented here on the AndroidSlidingUpPanel project with the exact steps to reproduce, to see if we can get some traction there: https://github.com/umano/AndroidSlidingUpPanel/issues/538#issuecomment-143052931

I've opened a separate issue for the disappearance when editing the bus stop name - https://github.com/OneBusAway/onebusaway-android/issues/314.

[barbeau]

A workaround for this is to keep the panel the same size and don't resize it when the number of arrivals changes. This workaround has the negative side effect of the header taking up more space than it needs to, which looks somewhat awkward and blocks some of the map that should otherwise be visible behind it. If using a shortcut, it takes up more room that could be occupied by more arrival info rows.

[barbeau]

It seems I can only reproduce this when on fast WiFi, which is usually the case at USF - on LTE and 3G I can't seem to reproduce it. So it seems like it's triggered by the API response returning prior to some of the other initialization being complete.

[barbeau]

I can't seem to reproduce this even on USF's fast WiFi anymore. I'm going to cautiously call this fixed, but will re-open if I see it again.

[barbeau]

We've seen this rarely recently, so I'm going to re-open just so we have record of this. I'm still not sure how to consistently reproduce or fix.

[barbeau]

Moving to v2.1 milestone - it's not bad enough to justify blocking v2.0 release, and I'm not sure we can fix this (seems to be library issue), but I want to keep it open just for a record of what's going on.

[caiiiycuk]

Hi! I have same issue with sliding panel in my project. I found that problem in my case is in GlSurfaceView I used it in main view. When I replace surface view with texture view, problem is disappeared. May be this also helps in your case.

[barbeau]

@caiiiycuk Thanks for the tip! So you weren't using the sliding panel with a map, but something else rendered by OpenGL ES?

[caiiiycuk]

No, we also use sliding panel with map.

[barbeau]

Ok - so where exactly do you define GLSurfaceView vs. TextureView? We're using the SupportMapFragment.

[caiiiycuk]

Finally I understand you question. We use own map implementation, so we directly create GLSurfaceView or GLTextureView.

[barbeau]

Ah, ok, that makes sense. Unfortunately to my knowledge we can't set this ourselves in the SupportMapFragment. But, it's good to know that this resolves the issue.

[barbeau]

I haven't seen this issue in quite a while personally, but a user just reported it:

When I open the app and select a stop on the map, the bottom frame that shows buses, times, etc. Is "invisible". I see the outline of the frame, but no data. Usually self corrects after I select a different stop, then go back to the one I wanted.

App Version: 2.5.6 Model: Pixel 2 OS Version: 10 / 29 Google Play Services App: 19.6.29 (120400-278422107) Google Play Services Library: 12451000 Region/API: Puget Sound (selected automatically) Loc: gps , 1 second(s) ago