Is there a way to check if a standard ScrollView is currently being scrolled?
Doesn't matter if the direction is upwards or downwards, i only need to check whether it's currently being scrolled at all.
ScrollView in its current form does not provide a callback for detecting scroll events. There are two workarounds available:
1. Use a ListView and implement OnScrollListener.
2. Derive a custom class from the existing ScrollView implementation and extend it to provide callbacks for scroll events.
Related
I have a use case were a user can create own buttons and give each button a label.
To display the buttons correctly i use Recyclerview with StaggeredGridLayoutManager. This works like a charm.
Unfortunately Recyclerview is not supported on Android Widget.
What do you think is the best solution to display an arbitrary amount of buttons (each button can be of different sizes) on a widget? Should I use a GridLayout?
You can find here all the layouts that are supported to use in android widgets.
Of all the supported layouts listed the one that is closer in appearance to StaggeredGridLayout is the GridLayout. So, I would pick GridLayout to start with and then depending on my design needs I would combine it with what fits my needs best. Most probably, if you want to keep StaggeredGridLayout's default appearance, maybe you can combine it with some LinearLayouts wherever needed.
How to make that the faster you swipe, the faster the list scrolls? I've noticed this behavior in Instagram's list and in lists of some other applications.
Also, the scroll dash bubbles vertically a bit, while it scrolls - a common behavior in those apps, which suggests that their lists are not of a custom implementation.
I couldn't achieve it with Recycler View.
How do they make it?
I'm not familiar with Instagram's scroll behaviour and if it's the same to my proposed solution, but you can give following snippet a shot:
listView.setFriction(ViewConfiguration.getScrollFriction() * 0.5);
In RecyclerView friction param is hidden in LayoutManager somewhere, if I remember correctly. Edit: This may help with ReyclerView
I have a ScrollView which contains several RelativeLayouts and LinearLayouts like this:
<ScrollView
xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/scroll"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fillViewport="true" >
<RelativeLayout >
</RelativeLayout>
<LinearLayout >
</LinearLayout>
</ScrollView>
Now, when I click on one of those layouts, I want it to expand and reveal more information. I have managed to do this by scaling the layout I want vertically with a PropertyAnimator:
relativeLayout.animate().scaleY(100).setDuration(duration).start();
At the same time, I use another PropertyAnimator to move any Views below the one I expanded vertically so that there's enough space for the expanded layout. So far it is working.
Unfortunately, the Views that move somehow end up outside of the viewport of the ScrollView, so I'm unable to scroll down and see the information in those Views. Essentially, the vertical translation of those views renders their lower part unreachable, since the viewport does not expand too.
I have set android:fillViewPort="true" on the ScrollView. And I have also tried to do it programmatically with setFillViewPort() but neither has had any effect.
What's wrong? Why is it not working?
When you perform translation animations on Views then those Views don't really move inside the layout. Its just visual for the User, but when it comes to layouting and/or measuring than any translation values are ignored. It is always as if the Views are not translated at all.
What I am guessing you are doing right now is this:
You react to the click event and expand the View you want to expand.
You calculate how much the other Views need to move to accommodate the expanded View.
Then you perform translate animations on those Views by much they need to move.
And then as a result suddenly a few Views move off screen.
This approach can actually never work. You always need to remember that a Views position in the layout is determined just by the layout. All your translations are essentially just for show. So this is what's actually happening when you try to do the above:
You react the to the click event and expand the View.
This expansion causes Android to start a layouting and measuring process. The positions and sizes of all Views is calculated and they are positioned at their new location with their new size.
Since now the Views are already at the location they are going to be after the expansion you translation animation just moves the Views further down, beyond the point they are supposed to be.
As a side effect of this the Views seem to move off screen for no apparent reason.
So what can you do about this? Essentially you need to tackle this problem the other way around. As I mentioned above Android already calculates the new sizes and positions of all Views for you, and you can use that to your advantage.
There are two basic solutions for your problem. Either you let Android perform the animations for you with LayoutTransitions or you perform your animations manually. Both ways use something called the ViewTreeObserver. It can be used to listen for changes in the layout or new drawing processes.
But first and foremost: ScrollView is supposed to work with only one child. So to prevent any future bugs or problems put all your items in the ScrollView inside of another LinearLayout with vertical orientation.
1) Using LayoutTransition
This would only work from API Level 16 and above. Below API Level 16 visibility animations and translation animations would be handled automatically, but to get height changes animated you need to have API level 16.
One important thing I have to mention is that:
LayoutTransition animates changes for you. So you can remove all you custom animations if you use it. If you leave your own animations in you are just going to create conflicts with the animations performed by LayoutTransition.
If you don't like the animations performed by LayoutTransition you can customise them! I will explain how to do that further down below.
I usually use a helper method like this to setup a LayoutTransition.
public static void animateLayoutChanges(ViewGroup container) {
final LayoutTransition transition = new LayoutTransition();
transition.setDuration(300);
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
transition.enableTransitionType(LayoutTransition.CHANGING);
transition.enableTransitionType(LayoutTransition.APPEARING);
transition.enableTransitionType(LayoutTransition.CHANGE_APPEARING);
transition.enableTransitionType(LayoutTransition.DISAPPEARING);
transition.enableTransitionType(LayoutTransition.CHANGE_DISAPPEARING);
}
container.setLayoutTransition(transition);
}
This will enable all possible automatic transitions on API Level 16 and above and just use the by default enabled transitions below that. Just use it like this:
AnimatorUtils.animateLayoutChanges(linearLayout);
If you call this method on the LinearLayout in your ScrollView then all changes to height/width/visibility of the LinearLayout and its direct children will be animated for you. Also item add/remove animations are taken care of for you.
To enable all kinds of transitions like resize animations you need to set the LayoutTransitions in code, but you can enable basic transitions like item add/remove animations by setting the property
android:animateLayoutChanges="true"
on a ViewGroup in your xml layout.
There exists only minimal documentation on LayoutTransitions, but the basics are covered here.
If you want you can customise the animations for each event like adding/removing a View or changing something about the View like this:
// APPEARING handles items being added to the ViewGroup
transition.setAnimator(LayoutTransition.APPEARING, someAnimator);
// CHANGING handles among other things height or width changes of items in the ViewGroup
transition.setAnimator(LayoutTransition.CHANGING, someOtherAnimator);
Here is a DevByte video which explains LayoutTransitions in greater detail:
LayoutTransitions enable easy fade/move/resize animations
Also note that container views can essentially cut off parts of the animations when the height of a parent changes. This won't happen in your case since your ScrollView has a fixed size and does not resize based on the children inside the ScrollView, but if you implement something like this in a ViewGroup with wrap_content then you need to set android:clipChildren="false" on all containers above the Views you are trying to animate. You can alternatively also use setClipChildren() in code.
2) Animating all items manually.
This is a much more difficult than using LayoutTransitions, mainly because you have to know a lot about the layouting and measuring process, otherwise you are going to cause problems. Nevertheless once you get the hang of it you can perform all kinds of custom animations.
The basic process is like this:
Record current View state.
Change layout to the state after the animations are finished
After Android is done layouting and measuring everything record the new values.
Now animate the Views from their old position to their new one
The core of this process is listening for changes in the view hierarchy. This is done using the ViewTreeObserver. There are multiple possible callbacks you can use, for example OnPreDrawListener or OnGlobalLayoutListener. Generally you would implement them like this:
final Animator animator = setupAnimator();
animator.setTarget(view);
// Record the current state
animator.setupStartValues();
modifyChildrenOfLinearLayout();
linearLayout.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
// Remove the callback immediately we only need to catch it this one time.
linearLayout.getViewTreeObserver().removeOnGlobalLayoutListener(this);
// Record the new state
animator.setupEndValues();
// Start the animation
animator.start();
}
});
OnGlobalLayoutListener is better at catching layout changes since it is called after a layouting process has finished. OnPreDrawListener is called before the next frame is drawn, but their is no guarantee that the layouting process has already finished. But in practice this difference is negligible. Much more important is that on older slower devices there might be a short flash of the layout in its new state because they need some time to process each step. You can prevent that by using an OnPreDrawListener and returning false once. Since OnGlobalLayoutListener is also only completely available on newer API levels you should in most cases use OnPreDrawListener.
If LayoutTransitions does not provide you with an adequate solution to your problem and you have/want to implement the animations manually than learning how to perform animations efficiently is important. You can look at the source code of LayoutTransition here. The implementation of LayoutTransition essentially does exactly what I have been explaining here and it is a best practice implementation. I often find myself looking through the source code of the android.animation package to learn new things about how to animate efficiently and if you want to understand animations on Android I suggest you do the same!
You can also watch a few Android DevBytes videos about animations like this one:
ListView Expanding Cells Animation
In this video he explains how to animate an expanding cell in ListView by using an OnPreDrawListener.
Just always remember, the Layouting Engine is your friend. Don't try to reinvent the wheel and do stuff manually a layouting process would already do for you. And never call requestLayout() while performing animations!
From Android Developer site :
A ScrollView is a FrameLayout, meaning you should place one child in it containing the entire contents to scroll; this child may itself be a layout manager with a complex hierarchy of objects. A child that is often used is a LinearLayout in a vertical orientation, presenting a vertical array of top-level items that the user can scroll through.
I can see that you have added multiple layouts as child in Scroll View, please add one linear layout and add rest of layout in that LinearLayout.
Hope it will solve your problem
Try this.
<ScrollView
xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/scroll"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fillViewport="true" >
<LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical" >
<RelativeLayout >
</RelativeLayout>
<LinearLayout >
</LinearLayout>
</LinearLayout>
</ScrollView>
Scrollview must have only one child to it. So I created only one LinearLayout child and add your rest code in it.
just add android:clipChildren="false"to your parent animated view and animation works outside of view.
I'd like to implement a UI experience in Android where a user can view a single item (for example, an item in my case is a collection of texts), and swipe left or right on the item to go to the previous or next item.
From my research, ListView does not implement horizontal scrolling. Potential candidates seem to be HorizontalScrollView and GridView, but I haven't seen any examples that can do this simply - only seemingly complicated libraries that need to be included.
My question is, is there a way to use ListView, HorizontalScrollView, GridView, or a combination of them to implement a horizontal scroll that shows one item at a time and snaps to the item being displayed?
The highlighted area in the picture below shows where I'm trying to implement this logic.
It looks like the best option to achieve this experience is a ViewPager, which requires the android support library.
http://developer.android.com/reference/android/support/v4/view/ViewPager.html
Overview
I'm using a listfield class to display a set of information vertically. Each row of that listfield takes up 2/5th's of the screen height.
As such, when scrolling to the next item (especially when displaying an item partially obscured by the constraints of the screen height), the whole scroll/focus action is very jumpy.
I would like to fix this jumpiness by implementing smooth scrolling between scroll/focus actions. Is this possible with the ListField class?
Example
Below is a screenshot displaying the issue at hand.
(source: perkmobile.com)
Once the user scrolls down to ListFieldTHREE row, this row is "scrolled" into view in a very jumpy manner, no smooth scrolling. I know making the row height smaller will mitigate this issue, but I don't wan to go that way.
Main Question
How do I do smooth scrolling in a ListField?
There isn't an official API way of doing this, as far as I know, but it can probably be fudged through a clever use of NullField(Field.FOCUSABLE), which is how many custom BlackBerry UIs implement forced focus behavior.
One approach would be to derive each "list item" from a class that interlaces focusable NullFields with the visible contents of the list item itself -- this would essentially force the scrolling system to "jump" at smaller intervals rather than the large intervals dictated by the natural divisions between the list items, and would have the side benefit of not modifying the visible positioning of the contents of the list item.
Assuming you want the behavior that the user scrolls down 1 'click' of the trackball, and the next item is then highlighted but instead of an immediate scroll jump you get a smooth scroll to make the new item visible (like in Google's Gmail app for BlackBerry), you'll have to roll your own component.
The basic idea is to subclass VerticalFieldManager, then on a scroll (key off the moveFocus method) you have a separate Thread update a vertical position variable, and invalidate the manager multiple times.
The thread is necessary because if you think about it you're driving an animation off of a user event - the smooth scroll is really an animation on the BlackBerry, as it lasts longer than the event that triggered it.
I've been a bit vague on details, and this isn't a really easy thing to do, so hopefully this helps a bit.
unless you want to override the how the listfield paints or create your own wrapper, you will always have this issue, this is because each line is always visible when scrolling. Try using labelfield instead.