On RecyclerView addOnScrollListener the property SCROLL_STATE_IDLE takes time to get called at end of the item size and when scrolled up to the top of the RecyclerView. But it works fine in middle of the scrolling.
The root view of the layout is CoordinatorLayout.
Having the same issue, the only workaround I've found is to send a stopScroll() whenever the RecyclerView gets a SCROLL_STATE_SETTLING, though not the ideal solution. Probably would be better to detect if it has reached the top or bottom edge, taking into account the scrolling direction, and then call stopScroll():
#Override
public void onScrollStateChanged(final int state)
{
super.onScrollStateChanged(state);
if (state == RecyclerView.SCROLL_STATE_SETTLING)
{
this.stopScroll();
}
}
Update
This issue seems to be a bug in the support library, though it was reported as fixed its clear that the problem still exists, so hopefully we should see an adequate solution in the future:
https://issuetracker.google.com/issues/66996774
Invoke stopScroll() when your recyclerview has been reached to to bottom.
I think Since it's support library version up, velocity is calulated and it makes delay a little.
Related
I have a GXT LiveGridView grid - works great, loading fine, but will not scroll all the way to the bottom record using the scroll bar. The only way to see the last record is to select the last visible record and use the down arrow key to force the display down, one record at a time.
By overriding the 'getCalculatedRowHeight' method, since it was returning a wrong value (compared with the Firebug analysis) the issue was resolved.
private class MyLiveGridView<T> extends LiveGridView<T> {
// deal with wrong value of 22 from this method currently.
#Override
protected int getCalculatedRowHeight(){
return 28;
}
}
(A real fix would be to dynamically acquire the correct row height. For now this will suffice since I'm on the hook for a lot of code still).
We're currently developing an Xbox One and a Windows 8.1 app, which share the same codebase, and I'm running into an issue with the 'pointerover' (or hover-state) in of a listView item in the WinJS.UI.ListView.
The listview item has an eventListener, pointerover. However, this only seems to work on the first 10 items in the WinJS.UI.ListView although I see 16 items on screen, and the WinJS.UI.ListView gives me:
indexOfFirstVisible = 0
indexOfLastVisible = 15
The eventListener my listItem has, is:
mediaTile.element.addEventListener("pointerover", function (that) {
that._allItemsListView.currentItem = { hasFocus: true, index: this.tileIndex };
}.bind(mediaTile, this));
When I add a breakpoint, it get's hit but only for the first 10 items although there are 16 items on screen.
Does anyone know what I'm missing here?
Thanks in advance!
My guess is you're getting bitten by ListView visualization. Perhaps tiles higher than 10 don't yet exist when you bind your event listener, but they appear on screen quickly enough that it isn't obvious.
I'm not expert enough to advise a concrete way around this. Conceptually you could listen for an event when new items are added to the list (on the list itself) and then add your pointerover event to the new items.
Yes, that seemed to be the case when you look at it from a distance; another developer took over, and we also migrated from WinJS 1.0 to WinJS 2.0, which seems to solve a lot of these problems.
Up until today I'm not sure what the exact problem was; we also played with the fetch limit of the datasource and this also seem to have played a part in solving the problem.
I'm sorry I can't be more thorough in my answer; I would have to ask the developer (if he still remembers) what the problem was, but afaik the major improvement was moving to WinJS 2.0.
I want to know how to move a view from top to bottom continuously without animation. I am asking this because I want to get the position of the view at every step so that I can check that if there is any collision between that view and any other view.
With animation you can move (not exactly move) a view from one position to another position (Animator class), but animation produces an illusion to the user that it is moving but it's position is fixed all the time. So this can't be done using animation?
Second approach is incrementing position of view. I applied this method in onCreate(). If I used it without Thread.sleep(50) then the activity doesn't show the view, if I applied it with Thread.sleep(50) then activity doesn't start for some period.
Property animation (subclasses of Animator class) actually move the view, as they update the actual property of the view. It is the view animations (subclasses of Animation class) that don't move the actual view and instead just where it appears to the user.
Source:http://developer.android.com/guide/topics/graphics/prop-animation.html
Quote: With the property animation system, these constraints are completely removed, and you can animate any property of any object (Views and non-Views) and the object itself is actually modified.
You also shouldn't start moving things around in the onCreate method as things are still initializing (onwindowfocuschanged is recommened). Also if you call thread.sleep, you are going the sleep the main UI thread, hence freezing the application for a time.
Solved the problem using ValueAnimator :-
CodeSnippet :-
va=ValueAnimator.ofFloat(0.0f,size.y);
va.setDuration(5000);
va.setRepeatCount(va.INFINITE);
va.setRepeatMode(va.REVERSE);
va.start();
va.addUpdateListener(new AnimatorUpdateListener() {
#Override
public void onAnimationUpdate(ValueAnimator animation) {
// TODO Auto-generated method stub
bullet[0].setTranslationY((Float) va.getAnimatedValue());
Rect R11=new Rect(bullet[0].getLeft(),bullet[0].getTop()+(int)bullet[0].getTranslationY(),bullet[0].getRight(),bullet[0].getBottom()+(int)bullet[0].getTranslationY());
Rect R21=new Rect(ball.getLeft(), ball.getTop(), ball.getRight(), ball.getBottom());
if(R11.intersect(R21))
va.cancel();
}
});
NOTE: There are two similar SO questions (1) (2), but neither of them provides an answer.
TL;DR: How can one dismiss the keyboard in a MonoTouch.Dialog by letting the user touch any empty space in the view?
I'm writing an app using MonoTouch.Dialog and a UITabBarController. One of my tabs is "Settings"...
When the user starts typing, the keyboard obstructs the tabbar...
Using MonoTouch.Dialog, the only way to dismiss the keyboard is to go to the last field and press the "return" key. Considering the fact that the user cannot press any tab until the keyboard is gone, I would like a better way to do it. Namely, to dismiss if the user taps anywhere else on the screen.
Without MonoTouch.Dialog, it's a snap: simply override TouchesBegan and call EndEditing. But this doesn't work with MT.D. I've tried subclassing DialogViewController and overriding TouchesBegan there, but it doesn't work. I'm currently at a loss.
Or, I wonder, would I be better off ditching the tabbar so I can use a UINavigationController with a "Back" button on top, which won't be hidden by the keyboard?
I suggest you use a tap gesture recognizer that will not cause interference with the TableView event handlers:
var tap = new UITapGestureRecognizer ();
tap.AddTarget (() => dvc.View.EndEditing (true));
dvc.View.AddGestureRecognizer (tap);
tap.CancelsTouchesInView = false;
You missed my question about it also: Can the keyboard be dismissed by touching outside of the cell in MonoTouch.Dialog?
:-)
This is my #1 feature request for MonoTouch.Dialog.
To answer your question: No. It is not possible. I have searched and asked around and have not found any answers.
I assume because it is just a sectioned (grouped) table and if it wasn't sectioned, there wouldn't be any spot to click. However, that is just my speculation.
I wish that miguel or someone that works on monotouch would answer this and say if it is even possible. Possibly a future enhancement?
I figured out a workaround that satisfies me well enough, so I'm answering my own question.
// I already had this code to set up the dialog view controller.
var bc = new BindingContext (this, settings, "Settings");
var dvc = new DialogViewController (bc.Root, false);
// **** ADD THIS ****
dvc.TableView.DraggingStarted += (sender, e) => {
dvc.View.EndEditing (true);
};
This will dismiss the keyboard whenever the user drags the view a little bit. There's no touch event I could find associated with the tableview, so this is the next best thing. I'd welcome any other ideas. Cheers!
One workaround to use the dragging gesture instead of the tap as proposed (that do not interfere with the table view gestures) is to override MonoTouch.Dialog.DialogViewController.SizingSource (or MonoTouch.Dialog.DialogViewController.Source if you don't want uneven rows) and give it to the DialogViewController. I don't know if it is very clean or safe.
public class CustomTableViewSource : MonoTouch.Dialog.DialogViewController.SizingSource
{
public CustomTableViewSource(MonoTouch.Dialog.DialogViewController dvc) : base(dvc)
{
}
public override void DraggingStarted(UIScrollView scrollView)
{
base.DraggingStarted(scrollView);
if (scrollView != null)
{
scrollView.EndEditing(true);
}
}
}
According to the documentation, Display.setCurrent doesn't work if the current displayable is an alert. This is a problem as I would like to pop up another alert when the user selects a command. Does anyone know how to work around this so that we can go from one alert to another? I am using CLDC 1.0 and MIDP 2.0.
Additional Information
The spec does allow us to edit an alert while it is on screen, but some Nokia phones don't handle it well at all. So I am now trying to go from the alert to a blank canvas, then back to the alert. Of course I don't want the user to interact with the previous canvas, so it seems that I am forced to create a new blank canvas. As a sidenote, this has the slight disadvantage of looking worse on phones which still have the previous screen when an alert is shown.
The bigger problem is how to transition from the blank canvas back to an alert once the canvas is loaded. Testing on the Motorola emulator revealed that showNotify is not called after returning from an alert to the previous screen. I guess I could create the next alert in the paint method, but this seems like a ugly hack.
OK, so your problem is that you can't set it up to do:
Display.setCurrent(alert1, alert2);
and
Display.setCurrent(alert2);
is also not possible if the current Displayable is already alert1.
So how about put an intermediate Displayable item that is blank and that immediately changes to the next alert? Assuming the current Displayable is alert1, like this in your alert1's command block:
Display.setCurrent(blankForm);
Display.setCurrent(alert2);
That should work assuming you are not using the default 'Dismiss' command. So basically it goes from alert1->(blankForm->alert2).
I couldn't find a way around this, so I just used the paint hack.
public class AlertPage extends Canvas{
MIDlet midlet;
Alert alert;
private AlertPage(MIDlet midlet){
this.midlet=midlet;
}
protected void paint(Graphics arg0){
//Yep, this is a hack, but showNotify doesn't seem to work well for Motorola
if(alert!=null){
Display d=Display.getDisplay(midlet);
d.setCurrent(alert);
alert=null;
}
}
public static void showAlert(MIDlet m, Alert a){
AlertPage page=new AlertPage(m);
Display d=Display.getDisplay(m);
page.alert=a;
d.setCurrent(page);
}
}