Scrolling screens and animations are bad things on e-ink screens. Their fast screen refreshes make the screen wildly flicker (first going negative, then black, then new content, repeat many times for scrolling).
One simple way to tame an e-ink screen is to change scrolling to paging. Another method would be to still do scrolling - but without showing intermediate screen updates:
Screen before scroll -> lifting the finger: update to screen after scroll
Screen before scroll -> leaving the finger + timeout: update to actual screen
Any ideas how to implement this?
Is there a way to teach/overwrite existing scroll code?
Thx
#Override
public boolean dispatchTouchEvent(MotionEvent event)
{
switch(event.getAction())
{
case MotionEvent.ACTION_DOWN:
hit_scrollx = view.getScrollX();
hit_scrolly = view.getScrollY();
hit_touchx = (int) event.getX();
hit_touchy = (int) event.getY();
break;
case MotionEvent.ACTION_UP:
int x = (int) event.getX();
int y = (int) event.getY();
if (x<hit_touchx-5 || x>hit_touchx+5 || y<hit_touchy-5 || y>hit_touchy+5)
scrollAbsolute(hit_scrollx+hit_touchx-x, hit_scrolly+hit_touchy-y);
break;
}
return(true);
}
This presumes that you have your own scrollAbsolute which does clipping for your application and uses View.scrollTo. This is designed for an activity with a main scrolling view. It captures all touch events. The "5" is to prevent unnecessary refresh on insignificant touches.
Related
I have a NestedScrollView(NSVchild), inside a horizontal RecyclerView, inside another NestedScrollView(NSVparent). Inside NSVchild is a TextView with long texts.
What I want to know now is, how can I prevent NSVchild from scrolling NSVparent, when NSVchild finishes scrolling from top or bottom?
What I tried:
I tried extending NestedScrollView, and overriding onTouchEvent, and returning false when NSVchild is at scroll 0 and user is dragging down on the screen, and when NSVchild is at it's max scroll and user is dragging up. Returning false works as expected, but problem is understanding when user is dragging up or down on the screen. here's is the code for that:
float deltaY = 0;
float oldY = 0;
#Override
public boolean onTouchEvent(MotionEvent ev) {
switch (ev.getAction()) {
case MotionEvent.ACTION_MOVE:
float y = ev.getY();
deltaY = y - oldY;
oldY = y;
Log.i("deltaY", deltaY+"");
break;
}
[...]
return super.onTouchEvent(ev);
}
in this approach, deltaY < 0 means that screen is being dragged upwards, and deltaY > 0 means vice versa. It works well as long as there's room for NSVchild to scroll inside itself. when it finishes scrolling from one side, and starts scrolling NSVparent, deltaY will become less than 0 in one frame, and in the next, more than 0, And this makes my code useless.
Is there any other way to achieve what I want? Or a better way to understand if screen is being dragged up or down?
I created a class that should be used to allow user to horizontally relocate a view by sliding his finger on a bar, the code is this
public class Dragger implements View.OnTouchListener {
private View toDrag;
private Point startDragPoint;
private int offset;
public Dragger (View bar, View toDragg){
toDrag = toDragg;
dragging = false;
bar.setOnTouchListener(this);
}
public boolean onTouch(View v, MotionEvent evt) {
switch (evt.getAction()) {
case MotionEvent.ACTION_DOWN:
startDragPoint = new Point((int) evt.getX(), (int) evt.getY());
offset = startDragPoint.x - (int) toDrag.getX();
break;
case MotionEvent.ACTION_MOVE:
int currentX = (int)evt.getX();
Log.d("LOG","currentX=" + currentX);
toDrag.setX(currentX-offset);
break;
case MotionEvent.ACTION_UP:
int difference = (startDragPoint.x-offset)-(int)toDrag.getX();
if(difference<-125){
((ViewManager) toDrag.getParent()).removeView(toDrag);
}else{
toDrag.setX(startDragPoint.x-offset);
}
dragging = false;
}
return true;
}
}
In the oncreate of the main activity i just use it by calling his constructor like this:
new Dragger(barItem,itemToDrag);
It apparently work, but it seems to tremble a lot while dragging... I tried to understand why does it work so strangely, so i added a Log instruction in the ACTION_MOVE, and the result is that... even if i only move to right pixel by pixel sometimes the currentX instead of increasing by 1 it decrease of a variable number, sometimes 10, sometimes 18 and when i go to the next pixel it turn back to normal by increasing of 1...
That really doesen't make sense...
Some ideas on how to fix it?
First guess: There are other fingers on the device which causes move to work erratically
Second guess: Right now you seem to be using the setX method more like a moveX and specifying the increment by which the function moves. This might not be what it was designed for
Third Point:
Sometimes the move function acts finicky. It is always run (as in whenever there is a pointer on the screen) and depends on the position of the finger. I would recommend changing the function to make it like a step
Suggestion
Make the action move like a step function that takes one value
case MotionEvent.ACTION_MOVE:
int currentX = (int)evt.getX();
if(abs(currentX)>10)currentX=(int) currentX/5;
toDrag.setX(currentX-offset);
In trying to tackle custom views, I'm attempting to work with touch events and partial invalidation. For this, it's just a row of numbers in squares spaced to fill the screen.
Now when I press on a single block, I get the block's rectangle using this:
private Rect getDirtyRegion(float e){
// The value is the slot number
mValue = ((int)e / mBlockSize);
// start X of the "stall"
int x1 = mValue * mBlockSize;
int y1 = 0;
int x2 = x1 + mBlockSize;
int y2 = getMeasuredHeight();
return new Rect(x1, y1, x2, y2);
}
It works as expected. When there's just a few on screen it works great. Here's my onTouchEvent:
#Override
public boolean onTouchEvent(MotionEvent e){
switch(e.getAction()){
case MotionEvent.ACTION_DOWN:
Log.d(TAG, "ActionDown");
setPaint(PinEntry.PAINT_PRESSED);
invalidate(getDirtyRegion(e.getX()));
break;
case MotionEvent.ACTION_UP:
case MotionEvent.ACTION_CANCEL:
setPaint(PinEntry.PAINT_NORMAL);
invalidate();
break;
}
return true;
}
(This has been rewritten quite a few times, so the call to invalidate without a rectangle hasn't always been the case.)
What I'm after is, when I tap on a number, it redraws to indicate a PRESSED state by whatever I do in setPaint. When I release, reset.
When I have multiple views in a ScrollView, however it breaks. When I press and release, or even drag outside the bound (triggering ACTION_CANCEL), it resets. However, going back to that row causes the whole thing to invalidate as "PRESSED".
Is this a TouchEvent logic issue, a drawing issue, or some combination of my inexperience with creating custom views?
I ended up splitting it into two different classes, one for the container (parent), and another for each individual block and using the draw(Canvas) method of the View class.
Desired effect
I have a bunch of small images that I'd like to show on a "wall" and then let the user fling this wall in any direction and select an image.
Initial Idea
as a possible implementation I was thinking a GridView that is larger than the screen can show - but all examples of using this widget indicate that the Gallery doesn't extend beyond the size of the screen.
Question
What is the best widget to use to implement the desired effect ?
A code sample would be especially beneficial.
EDIT...
if someone has example code that will let me put about 30 images on a "wall" (table would be good) then I will accept that as the answer. Note that the "wall" should look like it extends beyond the edges of the display and allow a user to use the finger to drag the "wall" up down left right. Dragging should be in "free-form" mode. A single tap on an image selects it and a callback shall be detectable. I have created a bounty for this solution.
The solution is actually quite simple, but a pain. I had to implement exactly this within a program I recently did. There are a few tricksy things you have to get around though. It must be noted that different OS versions have different experiences. Certain expertise or cludging around is required to make this work as drawing is sometimes adversely affected by this method. While I have a working copy, the code I provide is not for everyone, and is subject to whatever other changes or customizations have been made in your code.
set android:layout_width to wrap_content
set android:layout_height to wrap_content
In your code:
determine how many rows you will have.
divide number of items by the number of rows.
add gridView.setStretchMode(NO_STRETCH);
add gridView.setNumColumns( number of Columns );
add gridView.setColumnWidth( an explicit width in pixels );
To Scroll:
You may simply use gridView.scrollBy() in your onTouchEvent()
These are the steps. All are required in order to get it to work. The key is the NO_STRETCH with an explicit number of columns at a specific width. Further details can be provided, if you need clarification. You may even use a VelocityTracker or onFling to handle flinging. I have snappingToPage enabled in mine. Using this solution, there is not even a requirement to override onDraw() or onLayout(). Those three lines of code get rid of the need for a WebView or any other embedding or nesting.
Bi-directional scrolling is also quite easy to implement. Here is a simple code solution:
First, in your class begin tracking X and Y positions by making two class members. Also add State tracking;
// Holds the last position of the touch event (including movement)
int myLastX;
int myLastY;
// Tracks the state of the Touch handling
final static private int TOUCH_STATE_REST = 0;
final static private int TOUCH_STATE_SCROLLING = 1;
int myState = TOUCH_STATE_REST;
Second, make sure to check for Scrolling, that way you can still click or longclick the images themselves.
#Override public boolean onInterceptTouchEvent(final MotionEvent ev)
{//User is already scrolling something. If we haven't interrupted this already,
// then something else is handling its own scrolling and we should let this be.
// Once we return TRUE, this event no longer fires and instead all goes to
// onTouch() until the next TouchEvent begins (often beginning with ACTION_DOWN).
if ((ev.getAction() == MotionEvent.ACTION_MOVE)
&& (myState != TOUCH_STATE_REST))
return false;
// Grab the X and Y positions of the MotionEvent
final float _x = ev.getX();
final float _y = ev.getY();
switch (ev.getAction())
{ case MotionEvent.ACTION_MOVE:
final int _diffX = (int) Math.abs(_x - myLastX);
final int _diffY = (int) Math.abs(_y - myLastY);
final boolean xMoved = _diffX > 0;
final boolean yMoved = _diffY > 0;
if (xMoved || yMoved)
myState = TOUCH_STATE_SCROLLING;
break;
case MotionEvent.ACTION_DOWN:
// Remember location of down touch
myLastX = _x;
myLastY = _y;
break;
case MotionEvent.ACTION_CANCEL:
case MotionEvent.ACTION_UP:
if (myState == TOUCH_STATE_SCROLLING)
// Release the drag
myState = TOUCH_STATE_REST;
}
//If we are not At Rest, start handling in our own onTouch()
return myState != TOUCH_STATE_REST;
}
After the GridView knows that you are Scrolling, it will send all Touch Events to onTouch. Do your Scrolling here.
#Override public boolean onTouchEvent(final MotionEvent ev)
{
final int action = ev.getAction();
final float x = ev.getX();
final float y = ev.getY();
final View child;
switch (action)
{
case MotionEvent.ACTION_DOWN:
//Supplemental code, if needed
break;
case MotionEvent.ACTION_MOVE:
// This handles Scrolling only.
if (myState == TOUCH_STATE_SCROLLING)
{
// Scroll to follow the motion event
// This will update the vars as long as your finger is down.
final int deltaX = (int) (myLastX - x);
final int deltaY = (int) (myLastY - y);
myLastX = x;
myLastY = y;
scrollBy(deltaX, deltaY);
}
break;
case MotionEvent.ACTION_UP:
// If Scrolling, stop the scroll so we can scroll later.
if (myState == TOUCH_STATE_SCROLLING)
myState = TOUCH_STATE_REST;
break
case MotionEvent.ACTION_CANCEL:
// This is just a failsafe. I don't even know how to cancel a touch event
myState = TOUCH_STATE_REST;
}
return true;
}
If course, this solution moves at X and Y at the same time. If you want to move just one direction at a time, you can differentiate easily by checking the greater of the X and Y differences. (i.e. Math.abs(deltaX) > Math.abs(deltaY)) Below is a partial sample for one directional scrolling, but can switch between X or Y direction.
3b. Change this in your OnTouch() if you want to handle one direction at a time:
case MotionEvent.ACTION_MOVE:
if (myState == TOUCH_STATE_SCROLLING)
{
//This will update the vars as long as your finger is down.
final int deltaX = (int) (myLastX - x);
final int deltaY = (int) (myLastY - y);
myLastX = x;
myLastY = y;
// Check which direction is the bigger of the two
if (Math.abs(deltaX) > Math.abs(deltaY))
scrollBy(deltaX, 0);
else if (Math.abs(deltaY) > Math.abs(deltaX))
scrollBy(0, deltaY);
// We do nothing if they are equal.
}
break;
FuzzicalLogic
A GridView can have content that extends beyond the size of the screen, but only in the vertical direction.
Question: What is the best widget to use to implement the desired effect ?
The are no default widgets (at least prior to 3.0) which implement 2D scrolling. All of them implement 1D (scrolling in one direction) only. Sadly the solution to your problem is not that easy.
You could:
Place a TableLayout inside a custom ScrollView class, and handle the touch events yourself. This would allow you to do proper 2D panning, but would not be so good for large data-sets since there would be no view recycling
Modify GridView if possible to enable horizontal scrolling functionality (probably the best solution if you can do it)
Try putting a TableLayout inside a ScrollView (with layout_width="wrap_content) which you put inside a HorizontalScrollView - though this may work it wouldn't be the optimum solution
Do something with OpenGL and draw straight to a canvas - this is how the default Gallery 3D app does it's "wall of pictures"
I think that the only Android native solution for this is to have an embebed WebView in which you can have that bi-dimensional scroll (and by the way is the only thing that has this capability).
Be pressing an image you can control the behavior by a callback from JavaScript to JAva.
This is not very "pretty" but... it's the only viable way to do what you want "out of the box".
I have implemented a GridView that overrides the onInterceptTouchEvent methods. I set the OnTouchListeneras explained by Fuzzical Logic. My issue is that setting a custom OnTouchListener, the objects of my gridView are not clickable anymore. Is that because the default OnTouchListener of a GridView calls onItemClickListener ?
I would like to have a 2 directions scrollable GridView but that has still cliackable objects. Should I implement my own method to check whether a touch matches a item or is there a easier way to achieve this ?
Grodak
I have a custom Android view which overrides onTouchEvent(MotionEvent) to handle horizontal scrolling of content within the view. However, when the ScrollView in which this is contained scrolls vertically, the custom view stops receiving touch events. Ideally what I want is for the custom view to continue receiving events so it can handle its own horizontal scrolling, while the containing view hierarchy deals with vertical scrolling.
Is there any way to continue receiving those motion events on scroll? If not, is there any other way to get the touch events I need?
Use requestDisallowInterceptTouchEvent(true) in the childview to prevent from vertical scrolling if you want to continue doing horizontal scrolling and latter reset it when done.
private float downXpos = 0;
private float downYpos = 0;
private boolean touchcaptured = false;
#Override
public boolean onTouchEvent(MotionEvent event) {
switch(event.getAction()) {
case MotionEvent.ACTION_DOWN:
downXpos = event.getX();
downYpos = event.getY();
touchcaptured = false;
break;
case MotionEvent.ACTION_UP:
requestDisallowInterceptTouchEvent(false);
break;
case MotionEvent.ACTION_MOVE:
float xdisplacement = Math.abs(event.getX() - downXpos);
float ydisplacement = Math.abs(event.getY() - downYpos);
if( !touchcaptured && xdisplacement > ydisplacement && xdisplacement > 10) {
requestDisallowInterceptTouchEvent(true);
touchcaptured = true;
}
break;
}
super.onTouchEvent(event);
return true;
}
I'm answering my own question in case anyone else is as bad at Googling for the answer as I apparently was. :P
A workaround for this problem is to extend ScrollView and override the onInterceptTouchEvent method so that it only intercepts touch events where the Y movement is significant (greater than the X movement, according to one suggestion).