0

I have successfully created a list (LinearLayout) that contains multiple dynamic elements/rows. It is filled with content received by webservice. One of the elements per row is a HorizontalScrollView that contains a variable amount of EditText fields.

That means that all edittexts from all rows (including a header) can scroll with that horizontalScrollView.

A Scrollmanager will make sure that all horizontalScrollviews move simultaneously. So it is basically a scrollable column within a list.

The problem that i am experiencing is as follows.

When i select a EditText view it will show the keyboard, which is what i want it to do. But the scrollManager is triggered so it will scroll all horizontalscrollviews to the end. Instead of keeping the focussed edittext in screen, it will move out sight.

My ScrollManager OnScrollChanged

@Override
    public void onScrollChanged(View sender, int l, int t, int oldl, int oldt) {
        // avoid notifications while scroll bars are being synchronized
        if (isSyncing)
            return;

        isSyncing = true;

        // remember scroll type
        if (l != oldl)
            scrollType = SCROLL_HORIZONTAL;
        else if (t != oldt)
            scrollType = SCROLL_VERTICAL;
        else {
            // not sure why this should happen
            isSyncing = false;
            return;
        }

        // update clients
        for (ScrollNotifier client : clients) {
            View view = (View) client;

            if (view == sender) 
                continue; // don't update sender

            // scroll relevant views only
            // TODO Add support for horizontal ListViews - currently weird things happen when ListView is being scrolled horizontally
            if ((scrollType == SCROLL_HORIZONTAL && view instanceof HorizontalScrollView)
                    || (scrollType == SCROLL_VERTICAL && view instanceof ScrollView)
                    || (scrollType == SCROLL_VERTICAL && view instanceof ListView)) {
                view.scrollTo(l, t);
            }
        }

        isSyncing = false;
    }

I the end i want the keyboard to appear and the scrollview to be able to scroll, but i want to prevent the horizontal scroll event when the keyboard appears.

stackr
  • 2,742
  • 27
  • 44

1 Answers1

1

I haven't tested this yet, but you should be able to stop propogation of the touch event to the HorizontalScrollView by setting an OnTouchListener to your EditText and overriding the OnTouch method like this:

@Override
public boolean onTouch(View v, MotionEvent event) 
{
    Log.i("OnTouch", "Fired On Touch in " + v.getId());

    // Do this on the down event too so it's not getting fired before up event
    if(event.getAction() == MotionEvent.ACTION_DOWN)
    {
       // Disallow ScrollView to intercept touch events.
       v.getParent().requestDisallowInterceptTouchEvent(true);
    }   

    //only do this on the up event so you're not doing it for down too
    if(event.getAction() == MotionEvent.ACTION_UP)
    {
       // Disallow ScrollView to intercept touch events.
       v.getParent().requestDisallowInterceptTouchEvent(true);
    }   

    //Keep going with the touch event to show the keyboard        
    v.onTouchEvent(event);
    return true;
}  
airowe
  • 794
  • 2
  • 9
  • 29
  • @stackr Still scrolling? – airowe Mar 05 '15 at 16:27
  • I mean that the view stille performs the unwanted scroll to the end of the scrollview. But the scroll is done by Android itself. It happens on keyboard appearance. So it's not the touch event that does the scroll. When i put 'adjustNothing' in my manifest it works correctly, buh then it is no longer possible to scroll all the way to the bottom. – stackr Mar 06 '15 at 09:47
  • @stackr Apply my edits to make sure the scrolling isn't actually happening on the down event and to ensure that the OnTouch event is actually getting fired. If it's not, we may have other issues (easily solved). – airowe Mar 06 '15 at 15:14
  • Strangely everything is going as it should when the EditText's are not Gravity.Center. But my boss requested a different approach, so this issue is off the table now.. +1 for your effort! – stackr Mar 11 '15 at 11:36