I am using a RecyclerView to display data that gets polled from a website (=> completely changes at once).
I already created an ItemAnimator class that has the animation I want but I need to know what is the best way to time the animations to wait for the previous one to finish.
This is what I'm trying to achieve: http://www.google.com/design/spec/animation/meaningful-transitions.html#meaningful-transitions-hierarchical-timing
We've had a lot of success using setStartDelay (or setStartOffset, depending on which animators you are using). Have a delay variable that starts at 0, and as you walk through your children creating their animations, set the start delay to the current value and add some increment, such as 100 ms.
I've been working on the exact same animation. I've put it to the side for the time being, but got a pretty good effect at normal speed. When I slowed it down for debugging, I've got a strange bug that causes certain items to be animated multiple times. Also, scrolling up doesn't quite work if the animation hasn't completed, but that isn't a bug likely to be run into at normal speed.
Here's my code: https://github.com/halfjew22/AnimateRecyclerGrid
Essentially, what I did was I looked at the pattern in the Material Animation. Based off of that pattern, I put together a for loop that spawns a runnable that is given coordinates (based off the value in the for loop) and told to animate the view with those coordinates.
Like I said, I didn't quite finish the project, but it works fairly well as an alpha or proof of concept. I know it's been a while since you asked this question, but let me know if you'd like to work on finishing this up together.
Let me know if that helps you out.
I've created a custom RecyclerView adapter class which does more or less what OP wanted to achieve i.e. animates RecyclerView's items sequentially (in order, one after the other).
The adapter class is shared publicly on github as a gist here.
From the description:
"This adapter aims to create a sequential RecyclerView items' animation.
They're appearing in order, top to bottom. The animation works when the RecyclerView is first created and does NOT work when items are scrolled down."
Related
I wrote a fade in fade out method for views. It works perfectly, but, as I understand, each view's animation is handled by a separate thread in the background, tackled by the android system.
That is a problem, because, I want to blink and the same pace.
Is it possible to do that? I tried to put my blinking method in a runnable and restart it every time a new View starts its animation, but it is not working because 1. you cannot simply restart a thread, 2. even if you can, the Animation will be handled by the system with different threads each running independently anyway.
How should I do this?
Let me narrate my goal again: I tap on a view, it starts blinking, fade in fade out style, using a method I wrote. Then I tap on another, both blinking at the same pace, with the first one perhaps noticeably changes its original blinking pace to be in sync with the 2nd one. Then I tap on another, another... no matter how many I enable blinking animation on, these views all fade in and fade out at the same pace.
Can you offer any advice? Either a specific one or a general one.
It is bad practice to do big jobs on the UI thread as if you do, those big jobs will cause the program to hang (not accept user input or render any new data) until that job is finished.
I am looking to add a widget to our code base that will indicate to developers when they have committed this taboo. My idea, and one I've seen on a number of other applications, is to have some component that is constantly moving at a constant speed, such as a bar that is constantly twirling on the screen. With such a tool, if a developer is working and accidentally does something that is more computationally difficult than he expected on the UI thread, this spinning bar will become choppy, indicating to him, when he does functional testing, that he needs to implement mechanisms that will cause this job to be executed elsewhere.
One odd requirement on this code is that it should be completely non-existent in production builds, and only present in dev builds, since it is a widget not for users, but for developers.
I jumped into the Canvas objects and wrote up a quick component that simply spins a teal bar. The idea is that if a big job is dumped on the UI thread, the bar will stop spinning (since the FX job queue wont continue dispatching) and the bar will jump forward, rather than rotate smoothly (as it does when the program is at rest).
Below is a screen-shot of this first implementation:
(notice the teal bars, which, if you saw our application running, would be rotating slowly but steadily --hopefully anyways)
The issue here (as you might notice) is that our layout's been screwed up. This is because I'm modifying the scene graph from this:
Scene
RootComponent
Content
to
Scene
obnoxiousPane
Canvas
Spinner(s)
RootComponent
Content
Modifying the scene graph in such a way has things like preferred height, mouse events and (presumably) any number of other events getting dispatched to the spinners rather than the content components.
Of course, when we go to production, I would like to have the original scene graph in the version that we give to our users.
So my question is this: How should I go about correcting these problems?
I could go after each of them individually as they come up, writing a lot of custom code to do things like
obnoxiousPane.prefHeightProperty().bind(content.prefHeightProperty)
obnoxiousPane.prefWidthProperty()//...
spinner.setMouseTransparent(true)
spinner.setOtherEventsIProbablyCantEnumerateWithoutSeriousResearchTransparent(true)
Or I could try to go after this problem with reflection, attempting to bind every property in the content pane to the corresponding obnoxiousPane property, but this seems like a bug breeding ground.
Or... what? I'm hoping there's some LightWeight component or ImNotReallyHereProperty that I can leverage to add this development aid.
Thanks for any help!
Your approach seems fundamentally flawed. You shouldn't be stalling the JavaFX application thread.
Instead you should have a concurrent process and update the UI as appropriate as the process starts, progresses and completes.
See this java2s sample for using the JavaFX concurrency and progress indicator facilities for an example of such an alternate approach.
If you want to disable some portion of the UI for a time, nodes have a disabled property which you can set. You can use CSS to style a disabled node so the user has some indication that the thing hasn't just hung and is deliberately disabled.
Is there a way to create an onChildAdded or onItemAdded listener to a GridView in android? I can't seem to find one online. Right now my approach is lacking, I feel that it should be improved. I have a worker thread running that remembers the number of children that the GridView has, then if it has more it calls a method that handles the event and if there are less then it calls another method. I'm sure there has to be a better way, but I don't know of one.
Any suggestions are welcome.
You should write your own Adapter, extending BaseAdapter. Check this out.
I'm currently in the process of making one of my first android games and have come into some difficulty understanding how to make the transitions between screens.. for example:
My game starts its main activity, which then loads TitleScreen surface view which initializes its own thread
on tap I start a new intent which loads a new activity which loads GameView surface view which initializes its own thread
This all works fine when testing on my device (Evo 3d) but crashes on tap on my test bed, I'm using android x86 in virtual box for quick testing. Is this likely to be a problem in my code or a problem with the simulator?
Also I'm wanting to add a level select screen in between the title screen and the game screen and figured i could do this by creating another activity/surface view/thread combo, Is this acceptable coding practice or is this a wasteful/process heavy method?
You could create a variety of methods that you call from your onDraw method. Each method would draw one screen (game, level, score). To start simple a switch case in the onDraw checks the screen and then calls the right thing to draw.
If you want to have different layers, you should use different acitvities so that the background (game) is being paused while the scoreboard is active. This only makes sense if you want the background to be still visible or need the acitivites for other reasons.
But you should never have more than one surface view active at the same time, android doesnt like that.
I think its not good to use more activities for single application. Try to use ViewFlipper with number of xml layout files. Here you can apply transition effects very easily.
I am suggesting you it for transition effects, but you also check it once. I am also thinking which one is good.
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.