Hey, > There's a well-established animations framework called NineOldAndroids > (https://github.com/JakeWharton/NineOldAndroids/) by Jake Wharton that > allows us to use Android's animations API on pre-HC devices. > > We have our own animations framework, but it's more limited. Arbitrary > example: it doesn't support PropertyValuesHolder to build animations, > which is what the "jiggle" animation uses in bug 1011712. In the past, > we've sometimes worked around this by simply omitting these animations > on older devices, but since there's a library that gives full > backwards-compatibility for the animations API, it seems like it would > be a good idea to use it. Aside from being able to support older > devices, using a well-established API would also give us access to > other libraries that rely on it (e.g., we might want to use > https://github.com/nhaarman/supertooltips for bug 1011712).
For the curious: our little animation framework uses the exact same technique to support 'property' animations on pre-HC devices i.e. Animation instances with setFillAfter(true). So, under the hood, NOA and our animation framework are essentially 'the same'. > Any objections to transitioning from our existing animations framework > to NineOldAndroids? NOA = proven/widely tested code with tons of users + standard Android animation API. Go for it. Given that we'll do a gradual transition to NOA, my only suggestion would be to file a meta bug for general migration with some initial sub-bugs for parts of our code that are currently using our own PropertyAnimator. Set mentors for all of these bugs as they are pretty good bugs for new contributors with some Android experience. --lucasr _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
