During my exploration of Activity Transitions I've have encountered problem with ListView (unfortunately I've not migrated to RecyclerView yet :( )
ListView default dividers are visible for really short time (see video https://www.youtube.com/watch?v=nHZCzQF3XOg&spfreload=10 ) during transition.
I've no idea why it is happening and how to make it stop doing this. Or maybe it is time to migrate to RecyclerView ;-)?
If you want the ListView to animate together, set transitionGroup="true" on the ListView. It will then move and animate as one. Otherwise the elements of the LIstView will animate separately. ViewGroups typically default to false, but when there is a background will switch to true so that you don't see a background turd left in the scene after the transition.
Related
I draw a View that is not attached to any parent.
It's a decoration for a RecyclerView. The view sticks to the bottom and disappears when its counter part comes up in the list.
All this works fine but:
When i leave the activity the View doesn't fade with the rest of the
views in the activity's transition.
It stays until the end of the animation and then disappears
immediately.
( see large green view in the demo )
How do i include this unattached View in the activity's exit transition?
I've create a minimal Android Studio Project to replicate the issue:
https://github.com/Ostkontentitan/transition-issue-demo
(To better see the issue possibly set your phones animation scale to >= 5)
Here is a demo:
Add transitionName to xml layout for the RecyclerView.
The transition animation you see is because of ActivityOptions.makeSceneTransitionAnimation(this#ItemListActivity) and if you add transitionName to the view, it works fine.
Not-too-educated guess
(because I haven't tried and I haven't used Transition Framework in a few months)
The way TF (Transition Framework) works is by computing the start/end values of the transition and performing the animations needed to achieve this.
RecyclerView decorations are not "views" that are part of the layout, so TF has no idea that thing exists. It does know about your RecyclerView of course, because it's contained in the ViewGroup that is animated.
You may have already know this, but in any case, what I think I'd try to do here, is create a custom transition framework transition (they are not hard to do, you can even check TransitionEverywhere and look at how that library implements some missing transitions in the framework); in your CustomTransition, you can then try to interpolate the animation values so the recycler view can redecorate as the animation progresses (like an alpha value that is animated, your custom decorator would "paint" using said alpha).
Now... in truth, I've had to do something similar once, where a custom transition was "driving" a few external views (for reasons at the time) :) but... it was not a RecyclerView item decoration, mine were just "views", so I'm not sure if you can do this this way w/a decoration.
I think it's worth trying.
This is a question regarding the use of Android Transition API.
I am trying to animate the height change of a list, just like a dropdown menu.
I tried 2 approaches
Use a RecyclerView and animates its height change
Use a ScrollView > LinearLayout hierarchy and animates ScrollView's height.
The 2nd approach works perfectly.
But the 1st approach has a serious glitch - when the collapse transition starts, items disappear immediately.
By looking at the below GIF you can observe clearly the difference:
To be exact, items' visibility changes at the moment I change RecyclerView's LayoutParams, without waiting for the transition to finish, whatever it is expanding or collapsing
Code
I have created a minimal project on Github.
If you just want to look at the code, here is the MainActivity.
Question
Is it possible to achieve ScrollView's effect with a RecyclerView?
If yes, how?
My Idea is to do the transition of all the recycler view rows individual rather than the whole RecyclerView:
So when collapsing iterate through each ROW of a RecyclerView and do a transition. Remember to check for null if some rows are recycled they may return null. So after that collapse the whole recyclerView.
And like wise for the expanding do the same for the views.
This issue is cause by RecyclerView has many views with it but Scroll View has only one View nested in it.
I have a simple view containing a scene root FrameLayout, ListView and a couple of buttons on the bottom.
scene root is used to load and show different scenes, the size changes dynamically depending on the current scene. ListView is set to match_parent in both directions and is positioned behind scene root.
Here's the issue:
If I start a transition using the buttons on the bottom everything works ok, no problem, magic. However, if I transition (✝) to a different scene while scrolling (✝✝) the transition seems to flicker before starting.
It almost looks like the rendering engine fails to load the first frame of the animation before the ListView invalidates the hierarchy due to scrolling.
Thanks for the help ;)
✝ TransitionManager.go(Scene, Transition)
✝✝ I've added a couple of methods to the ListView to allow that
All the Google apps that use Scene Transition that I've seen transit from some item in a ListView to its detail Activity. Since ListView has the convenient behavior of immediately stop the scrolling when touched, such a transition doesn't produce flickering.
So it appears the best thing to do may be to programmatically stop the scrolling before transiting to the new Activity, which is accomplished by the code here.
I need a component that works like the picture below but I'm having trouble coming up with some kind of decent solution that works.
I want the list to have a center locked selection but being scrollable with the d-pad. This is for an application running on a TV so no need for touch scroll. So when pressing down on the remote d-pad the list will scroll and a new item will size up and the current selected one will size down and the new selection will still be in the middle.
I've tried doing this using a ListView that I extended and programmatically scrolling when pressing down or up. On scroll finished I called notifyDatasetChanged() on the ListView for re-inflating of the childs and in the ListViews adapters getView() I made the animation of the view located at the current selected position.
This is not optimal since I need to call notifyDatasetChanged(), which re-inflates all visible views, for the animation to apply. The UI becomes laggy when doing this and scrolling fast. It's also not possible to make som kind of compress animation when current selected item goes out of selection. There is also some trouble with the end items (read views) such the first or last in the list when doing animation of them, the may sometimes go out of screen.
I think that his must have been done before and maybe I'm missing it when searching for an answer.
Have anyone done something similar or do you have some suggestions of how this can be achieved? Maybe I'm just starting of with the wrong component here..
Regards,
Kristoffer
I would like to change the default behaviour of my listview, so when im scrolling to the last item, the list will keep scrolling untill the last item is at the top of the list.
default behaviour stops scrolling when the last item is fully in view.
Any ideas on how i can go about this pre 2.3?
Thanks,
Totem.
In case anyone is interested in the solutions available it either:
1) add to the list view padding, that solution forces you to play around with the fading edge property since it gets sifted because of thee padding. also this method might not work well if your using a transparent background because items will be rendered and visible under the padding area. Although this could be fixed by entering the list into a relative layout and making sure to draw something over that area.
2) add transparent items to the listview for offset and not set them as enabled to avoid dividers, just need to make sure to change getItemCount and getItemTypeCount and so on if your if your item isn't really inside your adapter as per my case.
I went with option two.
Thanks,
Totem.