implement scroll and page turn using gestures

[bardo84]

Page turns result in much lower flicker on e-ink devices than scrolling, yet scrolling is necessary to align pages.

The handling of hardware buttons for page turns is quite devices dependent, so why not do the entire navigation using gestures:

A vertical swipe would scroll, as already implemented.
A horizontal swipe would turn the page back or forth.
Just takes a little checking and thresholds for x and y.

What is the coordinate system used in e.g. the Scrollto function? How can a delta x or delta y be detected?

[bardo84]

Coding idea:

//where to get the actual view with visual positions x and y?
// probably the code below should make it into a new function
private void scrollTo(int x, int y) {
saveScrollPos = false; // should this be used only before scrolling?
Log.d(TAG, "Scroll to " + x + ", " + y);
// distinguish horizontal and vertical swipes
if (Math.abs(view.getX() - x) > (Math.abs(view.getY() - y))) { // page turning
if (x > view.getX()) {
if (!articleView.pageDown(false))
nextArticle();
} else
if (!articleView.pageUp(false))
goBack();
} else // scrolling
articleView.scrollTo(x, y);
saveScrollPos = true; // should this be used only after scrolling?
}

[bardo84]

working code for paging by horizontal swipe

dispatchTouchEvent catches all touch events, so also the vertical scroll, need help to integrate.
Would make other scroll code obsolete.

Advantage: no buttons needed, full flicker-free page turns and (flickering) sub-page scroll by gestures.

float x,y;
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
    switch (event.getAction()) {
        case MotionEvent.ACTION_DOWN:
            x = event.getX();
            y = event.getY();
            break;
        case MotionEvent.ACTION_UP:
            if (Math.abs(event.getX() - x) >= Math.abs(event.getY() - y))
                if (event.getX() >= x)
                    if (!articleView.pageDown(false)) {
                        nextArticle();
                    }
                else
                    if (!articleView.pageUp(false)) {
                        goBack();
                    }
            else
                // does not work with this x, y
                // articleView.scrollTo(x, y);
            break;
    }
    return false;
}

[bardo84]

previous code should read
if (event.getX() <= x) for correct page turn direction.

[bardo84]

"final" version
add the snippet below in /aarddict-android/src/aarddict/android/ArticleViewActivity.java

• stroke left/right turns the page without flashing
• stroke up/down scrolls without flashing

float x,y;
@OverRide
public boolean dispatchTouchEvent(MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
x = event.getX();
y = event.getY();
break;
case MotionEvent.ACTION_UP:
if (Math.abs(event.getX() - x) >= Math.abs(event.getY() - y))
if (event.getX() <= x)
articleView.pageDown(false);
else
articleView.pageUp(false);
else
articleView.scrollBy(0,(int)(y - event.getY()));
break;
}
return false;
}

[itkach]

Horizontal swipes turning "pages" - a concept that does not exist in the application - is very confusing in presence of multiple articles of the same title. Why would a right-to-left swipe, for example, turn "page" instead of going back? Also, swiping gestures where present in one of early versions, implemented with Adroid's gesture API, but that proved to be brittle and broke down completely in Android 2.2 and was removed. Also, there's no real difference between horizontal and vertical direction, even if horizontal scrolling shows up a lot less often because article text can usually be re-flowed to avoid it. Swipe gestures don't interact very well with regular scrolling, which is probably why they are not implemented in the standard Android Browser. Article viewing in aarddict is very much like viewing a web page. I think trying to implementn book-style navigation on it is a bad idea.

[bardo84]

Horizontal swipes turning "pages" - a concept that does not exist in the application
Which application do you mean? Its the general way ebook pages are turned (Sony reader, Cool Reader, FB Reader, ..)

• is very confusing in presence of multiple articles of the same title.
  I do not understand. Do you have an example?

The big advantage I see is to get rid of the hardware button discussion, which comes with the e-readers. They are originally conceived as market channels and have a proprietariy hardware as well as their shops.

If there are pictures or other content which does not reflow - you are right, a gesture which takes the horizontal scroll away and uses it for page turn would be counterproductive. But I have not met any examples.

Personally, I like the proposed navigation very much. Most of the time I can proceed pagewise with a little horizontal gesture like reading a book, if a table or other context needs alignment, I can tear it to where I want it.

So I actually like the book-style navigation. Probably a question of taste. But anyway, there is a need to implement full page turns, using scrolling had the two drawbacks:

• it flickered on e-ink (having 3-5 page refreshes turning the pages shortly to black and back)
• it needed a large gesture to move along.

Thanks again

[itkach]

I mean, of course, the application whose issue tracker this is - Aard Dictionary. I have nothing against the concept of pages and page turning in e-book readers, but Aard Dictionary is not an e-book reader, never had such ambitions or design goals. It is cool that it happens to run on a variety of devices including those I never thought of, but let's not get carried away, it doesn't change the fact that Wikipedia, Wiktionary and other similar data sources for which Aard Dictionary is made are not really books.

As for examples of horizontal scrolling, they are certainly not hard to come by: open any Wikipedia article with tables, such as "Periodic Table" or large formulas like "Table of Integrals".

[bardo84]

OK, got me. I will think about other methods to combine/distinguish scrolls and full page turns, like speed of swipe.

One drawback of the dispatchTouchEvent command is that it also swallows the links.
Do you have an idea how to allow following a link on touching it within dispatchTouchEvent?