In some of the other files in this diff, you're importing a static function directly and then composing over it. Can you do that here?
This comment could be more clear:
// Allocate local variables once and recycle the same memory across all invocations
static variables sound scary because they share state across invocations. This comment should allay that fear. :)
Can you please add a comment?
// Saves transformation matrices from view into matrix and inverse
The side effects here are implicit, which makes the code harder to read.
Isn't it the x value from the centroid (and similarly for y)? I know you're not paying attn to docs yet, but this is worth remembering to fix when you get there.
Should rewrite and rewriteRange be in separate files?
Similarly, should threshold and thresholdRange be in separate files?
Another place you could consider importing and using the function directly (rather than the classes).
Unfortunately can't in this case. The <Boolean> type inference hint is necessary for type safety, and requires a Class.<Type>method() syntax.
Standard practice in java is to document the method definition so you don't have to document every method invocation. The IDE for android devs makes that documentation very accessible, which is not very clear if you are just reading this sans-IDE.
can you clarify what you want me to change here? Using the term fooX and fooY is a reasonable shorthand for x from foo and y from foo in android-land, as the practice comes from the framework code.
Hm, part of the motivation for creating these separate operator classes is so I can group related operators. Some foo and fooRange operators may share common logic as well.
Generally I avoid doing extra cosmetic work in tests (3 extra keystrokes per operator you want to beautify), but I'll do it here since you pointed it out :)
Another thing you could consider, inspired by the JS mixin pattern:
Have one of your foundation operators extend IndefiniteObservable and each other operator extend the one before it, with MotionObservable extending the final operator. I realize it feels a bit weird architecturally, but it would allow you to skip compose for most operations and chain like we do in JS and Swift:
number$().normalize().rubberBand() vs number$.compose(Normalize.normalize(), RubberBand.rubberBand())
Just the docstrings.
Thanks for review. The "rabbit hole" mixin approach is interesting but a non-starter for reasons I'm sure you already know. Luckily, the new default interface methods in Java 8 are mixin-like and extension-like. So I'll have a nicer solution soon.