JavaDoc about gravitas HOT 6 OPEN

Yes! I totally agree. FWIW the JavaScript stuff I did for the UI physics writeup has basically the same interface and there are a bunch of examples for that: http://iamralpht.github.io/physics code: https://github.com/iamralpht/iamralpht.github.io/tree/master/physics

I should wrap that up into a GravitasJS library, too. I haven't had time recently to do Gravitas justice on Android. I'd love to figure out if I could use a Gravitas physics model to drive one of the new structural transitions (activity->activity preserving some structure, like that music animation that keeps popping up, or like the new dialer) since it would be a good match for those that can be gesturally driven...

from gravitas.

Well I was looking at using it in Flow (by Square), But would require
callbacks to when movements have finished etc..

On Tue Dec 02 2014 at 6:27:02 PM Ralph Thomas [email protected]
wrote:

Yes! I totally agree. FWIW the JavaScript stuff I did for the UI physics
writeup has basically the same interface and there are a bunch of examples
for that: http://iamralpht.github.io/physics

I should wrap that up into a GravitasJS library, too. I haven't had time
recently to do Gravitas justice on Android. I'd love to figure out if I
could use a Gravitas physics model to drive one of the new structural
transitions (activity->activity preserving some structure, like that music
animation that keeps popping up, or like the new dialer) since it would be
a good match for those that can be gesturally driven...

—
Reply to this email directly or view it on GitHub
#2 (comment).

from gravitas.

Oh, that's easy enough to add; I'll try and schedule some time to put an example together. With some extra math we can figure out the duration of the simulations and make something that works as a TimeInterpolator in Android (it's a bit unnatural since for a spring you have to do a numerical analysis to find the duration, but it converges fast enough for typical UI animations [i.e.: not incredibly underdamped!]).

The advantage is that it's then just a quick integration to whatever you're already doing and doesn't require replacing the whole animation system (ala rebound).

from gravitas.

That would be cool.
My biggest gripe with rebound is it does `is a isAtRest which can take a
long time if there is an odd amount of friction.

On Tue, 2 Dec 2014 18:56 Ralph Thomas [email protected] wrote:

Oh, that's easy enough to add; I'll try and schedule some time to put an
example together. With some extra math we can figure out the duration of
the simulations and make something that works as a TimeInterpolator in
Android (it's a bit unnatural since for a spring you have to do a numerical
analysis to find the duration, but it converges fast enough for typical UI
animations [i.e.: not incredibly underdamped!]).

The advantage is that it's then just a quick integration to whatever
you're already doing and doesn't require replacing the whole animation
system (ala rebound).

—
Reply to this email directly or view it on GitHub
#2 (comment).

from gravitas.

You mean you have a spring configuration where it takes ages to do the last pixel (or whatever you've mapped the spring to)? So it seems like the UI should be usable to the user, but they're still locked out because you're actually still transitioning the screen?

I hit that in Letterplex in a few places (because it's endemic to springs) and "solved" it by saying "when the value is this close to the target, just make the next screen/whatever interactive already".

So in Flow, you'd want to call onTraversalComplete earlier than removeView (sorry if I'm muddled, just looking at the example code)?

from gravitas.

This is currently what we do:

 @Override
    public void createSegue(final ViewGroup container, @Nullable final View from, final View to, final Flow.Direction direction, final Flow.Callback callback) {

        if (from == null) return;

        final boolean backward = direction == Flow.Direction.BACKWARD;

        mSpringFrom.addListener(new SimpleSpringListener() {
            @Override
            public void onSpringUpdate(final Spring spring) {
                from.setTranslationX((float) spring.getCurrentValue());
            }

            @Override
            public void onSpringAtRest(final Spring spring) {
                container.removeView(from);
                mSpringFrom.removeListener(this);
                // We complete here as it's most important that the old ScopedView is removed.
                callback.onComplete();
            }
        });
        mSpringTo.addListener(new SimpleSpringListener() {
            @Override
            public void onSpringUpdate(final Spring spring) {
                to.setTranslationX((float) spring.getCurrentValue());
            }

            @Override
            public void onSpringAtRest(final Spring spring) {
                mSpringTo.removeListener(this);
            }
        });
        // Will always be on Screen
        mSpringFrom.setCurrentValue(0);
        // if backwards come from off screen left
        mSpringTo.setCurrentValue(backward ? -to.getWidth() : to.getWidth());

        // Move off screen
        mSpringFrom.setEndValue(backward ? from.getWidth() : -from.getWidth());
        // Move to on screen
        mSpringTo.setEndValue(0);
    }

Alot to be desired.
Yeah the resting period is all but absolute, and yeah we lock the screen until it's resting otherwise if the user presses a button in may skip and drop the screen which is still animating. Flow does help with this by queueing up Screen changes, but just feels weird as the UI feels unresponsive.

It needs to be a close to target, "resting" state.

from gravitas.