-
Notifications
You must be signed in to change notification settings - Fork 638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated Transformer's generic parameters #46
Conversation
Updated Transformer's generic parameters
Thanks! Also, if you want to submit a PR to upgrade |
I actually don't know how to correctly change it. Looks like onAttach(Context) appeared in 23 SDK. If I change it for both RxFragment and support.RxFragment, the former one doesn't pass the test. When fragment.onAttach((Context) null) is called from within the test, it fails with NoSuchMethod exception. |
Yeah, back-compat can be tricky. I doubt that it's strictly necessary here, but for correctness' sake probably worth it. I'll make an issue. |
Unhappy with that as compiler can't infer type now, have to write it every time :( myTypeObservable.compose(RxLifecycle.<MyType>bindView(view)); vs. myTypeObservable.compose(RxLifecycle.bindView(view)); |
You could write a wrapper around the current |
To be honest, the 0.3.1 seems like a step backwards for what I suspect is the predominant platform -- Java 7 + Retrolambda -- because of the fact that it won't infer types properly with these updated signatures. The change may have made Kotlin support cleaner, but it seems to be at the expense of standard Java which is likely to have many more users. But yes, a wrapper is easy enough to write but the same could be said for Kotlin users, no? |
This change also broke the existing code in our applications. |
Because I'm obsessed to use the newest rev of every library, I'm working on this alternative bind wrapper function in my base activity. Here's what I've come up with -- any comments as to whether this is the best possible? @SuppressWarnings("unchecked")
@Nonnull
public final <T> Observable.Transformer<T, T> localBindToLifecycle() {
return (Observable.Transformer<T, T> )this.<T>bindToLifecycle();
} |
I reverted back to 0.3.0. Currently I don't have the time to deal with those changes. |
Another fix is to use the Java 8 compiler, since it can infer the types correctly. It's perfectly safe to use Java 8 on Android (just avoid using any newer constructs like lambdas unless you're using something like retrolambda). |
I am using the Java 8 compiler + Retrolambda to rehost onto Android/Java 7 and it's not inferring properly for me. The 0.3.0 works fine, but 0.3.1 forces me to use the |
I've made #58 to discuss this further, instead of polluting an old PR. |
Return type
Transformer<T, T>
was updated toTransformer<? super T, ? extends T>
to support Kotlin type inference.This should fix #44 issue.