reactivex / rxandroid Goto Github PK

I think I was a little too optimistic when I wrote ViewObservable.text() to emit the view itself, because it doesn't capture any value in it's original state, which is problematic when using transformations like .delay(). Here's one example:

ViewObservable.text(myTextView)
        .map(TextView::getText)
        .delay(500, TimeUnit.MILLISECONDS)
        .filter(delayedText -> TextUtils.equals(delayedText, myTextView.getText())
        .subscribe(delayedText -> Log.d(TAG, "TextView paused editting at: " + delayedText);

This block is attempting to find when the user has not typed a new character in a .5 second window, but it doesn't work because the .map() also gets delayed and the call to TextView.getText() returns the most recently updated text, not the text .5 seconds ago. Using ViewObservable.input() instead of the first two lines does work.

My goal when I wrote ReactiveX/RxJava#1545 was to provide flexibility to get a CharSequence as opposed to just a String from ViewObservable.input(TextView) but I figured just emitting the TextView itself was more flexible. This is likely problematic for lots of Rx operations where you want to emit immutable values, especially when they are shared across multiple threads.

I tried looking at #5 but I'm not sure this works for all cases. I think it's probably good to have a different solution that captures the text change value immediately and also emits a CharSequence. Anyone have any suggestions on the best way to ideally avoid breaking changes?

Now that the samples module is back, it's clear this needs working on. There should be structure to the samples app instead of being a bunch of unrelated classes. Any suggestions for how this should look like?

For instance:

• have a landing activity that let's you navigate samples a la Android SDK samples (can keep it simple for now)
• organize samples by functional group (view bindings such as text observables, scroll observables etc., basic functionality such as life-cycle binding, working with cache/replay, ...)

I would also like to propose that every PR introducing new functionality to the library or a sub module should include a sample demonstrating use and doubling as documentation of the added feature.

RxAndroid is supposed to be an Android-specific library. Should not it be packaged as an AAR in such case? It would allow to do Android-specific things: include proguard config or Lint rules to the library package. I understand it might be not relevant at this point of time. But still, shouldn't we?

I'm using Android Studio. How can I include RxAndroid in my project as a subproject? I want to build it from the sourcecode.
What I've tried:
-Include it as a git submodule.
-included it in my projects settings.gradle file, "include ':rxandroid', ':app'"

Then I get: Error:Unable to find module with Gradle path ':rxandroid'.

I read RxAndroid sources a bit and when I reached this classes (https://github.com/ReactiveX/RxAndroid/blob/0.x/library/src/main/java/rx/android/functions/ViewAction1.java) I start worried about how using WeakReferences can afect application on real device and production application. Also weak refereces used in more important place like this (https://github.com/ReactiveX/RxAndroid/blob/0.x/library/src/main/java/rx/android/operators/OperatorViewClick.java)

Here is a reason (http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html#memory-cache, note section).

It takes Object and uses ugly instanceof and runtime API checks. Why not just have two overloads?

As I said in #25 I think we should discuss naming convention and code organization question.

Currently most of library functions is some kind of wrappers of native android components to lift them to use with Rx.
Some of them are using from prefix and name of wrapped component (fromBroadcast, fromSharedPreferences, etc). I think this is more verbose but it clear to the user what component is using under the hood.
Other wrappers just use simple form (like clicks, input). This is more pretty, but can confuse user for the first time.

Should we rename some of them to one kind?

I am not sure if this is in the scope of the project, but the ViewObservable clicks, text, and input methods are pretty nice convenience methods. Today I found myself wanting an Observable for item clicks on a view with an adapter -- ie an AutoCompleteTextView with some autocomplete suggestions.

It is pretty straightforward to add make a method to do this in my app, but would this be something worth adding to the project?

This is not a new question though. While one-way binding can be done easily, how do you guys implement two-way binding?

For example, I have a Search model (searchModel) having a query text (searchModel.query). After two-way binding this query to an EditText, I expect that whenever searchModel.query changes, the EditText should reflect its new value. Also, whenever users type a new text on the EditText, searchModel.query should be set that new text.

Generally, given a modelA.propertyA and a modelB.propertyB. propertyA changes, propertyB changes accordingly. propertyB changes, propertyA changes accordingly. There must not be any endless update loops. propertyA and propertyB can be different types.

Thoughts?

The gradle wrapper jar seems to be missing so the wrapper doesn't work.

This is an issue for people with local gradle distribution version incompatible with this project.

Currently, using Observables in Android components that have access to Context (or are themselves) requires one to carefully think about detaching from these sequences as part of the component life-cycle, since otherwise a closure the sequence holds a (strong) reference to might leak the current context until the time the sequence finishes and releases all subscribers.

A good example are configuration changes, where Android first destroys, then recreates an Activity, but observables might still be holding on to a subscriber created within the scope of that Activity. Even with retained fragments that detach from their host activity, it's easy enough to leak the attached context indirectly by holding on to a view first created through that context (every view in Android has a strong reference to the Activity context it was first created in.)

This ticket aims to find solutions to improve this situation, potentially by leveraging newer Android API levels where available, and/or add first class support for newer Java language levels (Java 8/Retrolambda)

Some suggestions that have been made already follow.

Android 14+ APIs

One option would be to make use of Activity life cycle callbacks:
http://developer.android.com/reference/android/app/Application.ActivityLifecycleCallbacks.html

This might allows us to unsubscribe once Android is about to destroy an activity.

Java 8 lambdas and Retrolambda

Part of the problem is that every "lambda" in Java 7 or below is an anonymous inner class that will hold a strong reference to the outer class, even if it's a pure function that does not access state outside the lambda. Java 8 + Retrolambda could help here, since pure functions will be materialized as static methods that hold no reference back to their owner.

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-translation.html
https://github.com/orfjackal/retrolambda

Weak subscribers

We've taken several stabs at this and always dismissed the solution. The idea was to use WeakReferences to bind subscribers and lambdas. The problem with his approach is that it doesn't work with lambdas, since the only incoming reference would be weak, and they are eligible for GC the instant they're created. There might still be other ways to achieve this, however, I'll leave it open for discussion.

Right now it seems like the "what does RxAndroid want to be when it grows up" question is very vague. It would be beneficial to define a few universally agreed upon features that we would want in RxAndroid and track them as issues. This would make contributing much easier for everyone since it would help answer the "what do I work on?" question.

To get the ball rolling here are a few things that I personally think would be nice:

• More operators and ways to create observables.
• Expanded sample app and documentation.
• Simple, easy-to-use-and-understand subscription management. It should be trivially easy to tie subscriptions to various parts of the activity/fragment/etc lifecycle.

Thoughts?

Should the Jar be named rxjava-android-x.y.z.jar or rxandroid-x.y.z.jar ?

• JLS modifier order, redundant modifiers
• Private ctor in utility classes
• No trailing spaces
• Trailing newline
• No tabs
• No star imports
• Unused/redundant imports
• Redundant throw
• Whitespace rules (curly braces, if/for, etc.)

@benjchristensen could you release 0.23 for us? There were some breaking API changes in core 1.0-rc.9 that we had to reflect here, so we should probably ship these changes.

I had to revert to an older RC in our project because of this incompatibility between 0.22 and 1.0-rc.9

Thanks!

With multiple discussions forming around various things, I quickly wanted to gauge if people would prefer a mailing list? Personally I'm fine with using GH even for questions/discussions, not least because it makes it easy to cross reference code.

Alternatively we could establish an rxandroid mailing list on Google Groups?

Hi,

We were looking to leverage the reactive model using hystrix for one of our use cases. The scenario is that we poll an API, which basically returns a List of hasmaps of events of sports. An event is something which takes place every season, so in case of tennis, a US Open would be an event.

Once we get that list, we iterate over that List of hashmap of events, take an individual event and invoke another API to fetch the matches within that event. So, all the 128 matches to be played in the US Open would be returned here. Eventually, we want to persist the Event object with the List of competitions in our Mongo Datastore/.

Now, we have created a separate HystrixCommand for each of the API calls and also for the persist part. So, we are trying to keep things in as asynchronous a manner as possible.

But, this is where the problem starts.The fixtures API expects an eventId as part of its url. Now, the problem is, that how can I send that List of Competition object back to the original callee event in a non-blocking manner? I found one way : .toBlockingObservable().single(), which basically is able to return the emitted the List from this observable to the callee. But, this makes the call blocking which also seems to stall the original iteration of the event for loop.

Is there any non-blocking way of doing this? I read some of the examples and found a groovy based one for Videos using map(). Is that the only way or would some tweak in my original approach suffice?

Should be:

private Foo() {
  throw new AssertionError("No instances");
}

I am interested to know if there are any plans to create operators similar to ViewObservable.clicks() and ViewObservable.itemClicks() but for ViewPager, i.e. page changes, page scrolls etc.

Or is RxAndroid focused on core android libs and not trying to create ViewObservable helpers for all the stuff that might exist? :)

This is more a question than it is an issue. If this isn't the scope of RxAndroid please excuse me.
I have :

Observable<Bitmap> bitmapObservable = Observable.create(new Observable.OnSubscribe<Bitmap> () {
            @Override
            public void call(final Subscriber<? super Bitmap> subscriber) {
                if(subscriber.isUnsubscribed()){
                    subscriber.onCompleted();
                    return;
                }
                if(Looper.myLooper() == Looper.getMainLooper()){
                    Log.i("ISSUE5", " call - main thread ");
                }
                Target target = new Target() {
                    @Override
                    public void onBitmapLoaded(Bitmap bitmap, Picasso.LoadedFrom from) {
                        Log.i("picasso", " onBitmapLoaded ");
                        if(Looper.myLooper() == Looper.getMainLooper()){
                            Log.i("ISSUE5", " Target - onBitmapLoaded - main thread ");
                        }
                        subscriber.onNext(bitmap);
                        subscriber.onCompleted();
                    }

                    @Override
                    public void onBitmapFailed(Drawable errorDrawable) {
                        subscriber.onError(new Exception(" Failed to load bitmap"));
                    }
                    @Override
                    public void onPrepareLoad(Drawable placeHolderDrawable) {  
                    }
                };
                mPicasso.load(url)
                        .resize(384, 384)
                        .tag(builder.getX() + "-" + builder.getY() + "-" + builder.getZoomLevel())
                        .into(target);
            }
        });
        bitmapObservable.subscribeOn(Schedulers.newThread());
        bitmapObservable.observeOn(AndroidSchedulers.mainThread());
        return bitmapObservable;
    }

and i always get a log with :
I/ISSUE5﹕ call - on main thread
I/ISSUE5﹕ Target - onBitmapLoaded - main thread

isn't subscribeOn(Schedulers.newThread()); enough to run call body in a new thread ?
is there an alternative so that creation of Target and call to Picasso.load doesnt happen on the main thread.
My main problem with this is that i'm creating many observables (thus i have many Target objects) so when Target objects are gc'ed it blocks my application for a while, any advice ?

From: #57

We can clean up a lot of the event classes using auto.

Hello all,

I just wanted to say that this is a great project which is on the right track for the future of software development generally. Dependency driven change propagation is the essential feature of adaptive, A.I. systems and modelling, and therefore of robotics. I am designing this feature into my project at BitBucket: keith78201 / XComponents, which you are all welcome to take a look at. I will be seriously studying integrating ReactiveX into XComponents and other projects I work on. Please contact me if you want to be added as a team member on XComponents.

Thanks!,
Keith Watson
Software Developer at modelSoftTech.

Need to check if Travis has the latest SDK available.

If onError() is called and you don't have an onError() defined, OnErrorNotImplementedException should get thrown and crash your program. However, there's one case in Android where this doesn't seem to happen, and I'm having a hard time figuring out why that's the case.

Here's some short example code which should cause an app to crash, but doesn't:

Observable.just(null)
    .delay(1, TimeUnit.SECONDS)
    .observeOn(Schedulers.io())
    .subscribe(__ -> someView.setBackgroundColor(Color.RED));

I've been trying to figure out why this exception gets consumed; normally if the Subscriber throws an Exception but has no error handling it will crash the app. But in this case, CalledFromWrongThreadException gets thrown and ignored. This leads to a lot of sadness because it can cause all sorts of weird interactions (since normally this is a fatal, unrecoverable issue on Android).

It may ultimately be an RxJava based problem, but I can't reproduce it outside of the context of CalledFromWrongThreadException. Any ideas on what's going on?

This is a proposal to implement an Observable that emits a Cursor while the Cursor has next and then closes the Cursor upon completion or failure.

This sounds like something useful that I can contribute with and I would like to hear thoughts before putting something together?

Something like:

ContentObservables.query(PROJECTION, SELECTION, ...).subscribe(
...
onNext(Cursor c) { // Calls once for each position in the cursor };
...
);

to follow suit with RxJava core. Many / all of these are called Operator* now. Only classes implementing Operator<R,T> should be called operators.

I was curious if RxAndroid has an official stance on the minimum supported SDK

I noticed recently that View.addOnAttachStateChangeListener() was used, which was added in 12. If we're allowing that, I propose that we might as well go to 15 (since no one is on honeycomb anyways).

Somebody tested this observable?
First time i used it, and it never been called.

Seems like a known issue: http://stackoverflow.com/questions/2542938/sharedpreferences-onsharedpreferencechangelistener-not-being-called-consistently/3104265#3104265

Possible solution: move listener field from method to Operator class.

I have a method similar to loadGallery in https://github.com/JakeWharton/u2020/blob/master/src/main/java/com/jakewharton/u2020/data/GalleryDatabase.java.

I am passing it a ReplaySubject and calling toBlocking on the subject, in an attempt to make calling this function a blocking call.

Similar to something like this.

public static void main(String[] args) {
    System.out.println("start");
    Subject<Integer, Integer> subject = ReplaySubject.create();
    doWork(subject);
    Integer first = subject.take(1).toBlocking().first();
    System.out.println("First " + first);
  }

  private static void doWork(Observer<Integer> observer) {
    Observable.just(1, 2, 3, 4, 5, 6)
        .filter(new Func1<Integer, Boolean>() {
          @Override public Boolean call(Integer integer) {
            try {
              TimeUnit.SECONDS.sleep(10);
            } catch (InterruptedException e) {
              throw new RuntimeException(e);
            }
            return true;
          }
        })
        .subscribeOn(Schedulers.computation())
        .subscribe(observer);
  }

The code provided above completes fine, but when using .observeOn(AndroidSchedulers.mainThread()) (in an Android Project of course) as in the loadGallery method, it never completes and just hangs. I'm guessing it's because the mainThread is blocking and therefore can not call onComplete.

Is this a bug with the main thread scheduler or is there a different approach I should be taking?

With the discussion in #18 pretty much being aligned on keeping RxAndroid a nuts & bolts style library, how would you feel about starting a project on top if it which adds more beef, such as self-contained UI components are other app building blocks (call it reactive-android if you will?)

The Novoda contributions seem to be more in line with that. I would also like to open source the event bus we've built, since it added so much value to our app, but it seems to go beyond the scope of RxAndroid. Another thing is an operator we wrote that can be used to page content emitted by an Observable. We also use it everywhere to simplify pagination in the UI and keeping it decoupled from the underlying data source (we use the same operator for paging both database and network content, so it's widely applicable)

Can you chime in real quick if you see merit in a more exhaustive framework style project on top of RxAndroid, and what you think should go in that other project?

Quick poll: anyone here who requires RxAndroid to support Java 6? It would be ideal if we could make a cut and drop Java 6 support. Any JARs built with language level 7 will NOT work with Android apps that are compiled against level 6, since Java 7 introduces new byte code instructions so is not backwards compatible.

The problem is that it's easy to miss that when juggling multiple SDKs and JVMs on your dev machine. I'm using jEnv right now to do that, but we already encountered an issue where a Nebula plugin was compiled and deployed under Java 7 and would fail the RxAndroid build.

Considering that Java 6 has reached end of life, should we support it or not? It's difficult to say, since it definitely took us a while to make the switch to Java 7 on Android.

What if we have rx.android.views, rx.android.context... instead of r.a.observables r.a.observables, etc?

Currently we are forced to make some internal classes public just because they are under separate packages. If we have r.a.views for example, ViewObservable and depending operators can fit into the single package. This allows those internal classes to have package-local visibility, without blowing up the number of classes in a single package.

Also, I feel this is more scalable than existing package structure. As we turn various Android APIs into reactive style, each package will become more crowded and less structured. The Android-centric package hierarchy doesn’t have that problem. After all, what RxAndroid care is about Android, not generic Rx abstraction.

We can move some major classes including AndroidObservables to the top level packages (rx.android) for convenience. The class can be a facade to more focused classes. For example, bindActivity() could just wrap (hypothetical) ActivityObservable#bind().

Although I’m not that confident this works well, some variations of package structure is probably worth considering before 1.0 release. I’d like to hear what you think.

Can we get a 1.x-RCX build in jcenter/maven central? Thanks.

With out that, I can't build against the 1.x-RC version of rxjava-core.

This came out of #12 and #15

There's two discussions forming around project scope, aka "what should be in the library". I think maybe it's time to carve out a mission statement / goal that people agree on? I'll start.

I'm more on the conservative side I guess, by which I mean I don't think that RxAndroid should become anything framework-y. I think RxAndroid should provide the minimal set of classes required to lift existing building blocks that Android provides for object messaging, concurrency, and error handling into "Rx language". For example: HandlerThreadScheduler makes sense, because it is able to take one Android concept (Handler/Message) and adapt it to blend seamlessly into Rx concepts (Schedulers/Observables.) But it accomplishes the same thing. The same can be said for things such as Intent/Broadcasts, view listeners, etc.

In short: allow to express Android things in terms of Rx, but don't introduce new concepts or make assumptions about non-Rx questions, such as application structure. That's framework land. I'm not saying that this is not useful; it can be useful, but I would vote to have it in a separate project.

I also have a few things that I'm currently struggling to decide whether they would be a good fit for this library, or whether they should live elsewhere, things we apply to our entire codebase but which go beyond Rx (the two most important ones for us being an event bus based on Subjects, and an operator that supports paging of observables.)

Opinions?

Are people still interested in ReactiveX/RxJava#1584? If so, I can bring it back to work with the new separate RxAndroid repo.

Should add these methods to ViewActions to subscribe a text view (which also includes EditText and buttons) to a source of the text:

public static Action1<? super CharSequence> setText(TextView view)
public static Action1<? super Integer> setTextResource(TextView view)

This was first reported here: ReactiveX/RxJava#1590

Opening a new issue here since RxAndroid is now separated out of core.

Potential solutions so far:

1. Always use bindFragment when subscribing Subscribers in fragments that access views in onNext (defensive programming style)
2. Provides a safe UI subscriber class that only propagates notifications if not isUnsubscribed
3. ... ?

• Every public class should be exposed for a deliberate reason. Public is an exception to the rule, not the norm.
• Every non-final public class should be non-final for a deliberate reasons. Non-final public classes are an exception to the rule, not the norm.
• Every public constructor on a class should be exposed for a deliberate reason. Static factory methods are always preferred. Public constructors should be an exception to the rule, not the norm.

These rules are a subset of the well-defined, proven ways to minimize the overhead in evolving the API of a library as well as preventing people from trying to do too many dumb things.

There are a lot of other things to look at as part of the public API (public methods, fields, package names, whether things are serializable, etc.) but the above three are the most critical in my opinion.

Taking off from this discussion, it would be nice if this lib supported Android's support annotations.

At this point, though, we don't actually depend on any of the local repositories that the SDK uses; it's just using the few Android libs floating around in jcenter (which are rather out of date). This keeps the library simpler but limits our ability to add more recent support libraries.

Thoughts? Should we just embrace the local m2 repo?

java.lang.IllegalStateException: Exception thrown on Scheduler.Worker thread. Add `onError` handling.

use Rxjava 1.0.0 and RxAndroid lastest version.

I only noticed this now. Everything under rx.android.functions is sitting in src/main/java/rx/functions, so IntelliJ complains and can't compile the project anymore. For some reason it builds fine on CI and command line.

I guess this was pulled in with #27 . @ronshapiro I suppose these should simply be moved under the rx/android src path as anything else?

Removal of things like old ViewObservable methods and moving stuff around is cool and all, but doing so makes all library users (myself included) rewrite lots of code for what amounts to someone's deep self-satisfaction and ~3Kb of code size benefit (with later being nullified by Proguard anyway). I know, that RxAndroid is still a pre-release software, but please at least keep things deprecated for couple of releases before throwing them out of window, especially, when there is a little reason for change besides aesthetics.

Sample codes below:

EditText editText = ...
ViewObservable.text(editText)
    .delay(1000, TimeUnit.MILLISECONDS)
    .subscribe(new Action1<EditText>() {
      @Override
      public void call(EditText editText) {
        Log.d("TAG", editText.getText().toString());
      }
    });

Nothing printed out as I type in the editText. But if I comment out the delay line, everything works fine. am I missing something?

There are possibly improvements that need to be made specific to Android related to CompositeException.

History of the discussion and work on this can be found at ReactiveX/RxJava#1405

I think it'd be great if we had a formal changelog.

I made this as an issue in case anyone wanted to discuss the format. For reference, this is what the RxJava changelog looks like.

Lots of non-@code and non-@link types mentioned. Lots of multi-paragraph comments without <p> between them. Lots of useless @param and @return declarations.

RxAndroid has been extracted from RxJava prior to 1.0 as per ReactiveX/RxJava#589

I have done this with a simply copy/paste/commit for now. Commit history remains in the 0.20.x branch of RxJava: https://github.com/ReactiveX/RxJava/tree/0.20.x

If anyone wishes to replace the code in this project with files that retain commit history, go ahead and make the changes.

Over the coming weeks the build and release process will be updated.

This project does not need to release immediately as 1.0. It can continue with 0.x releases until it makes sense to hit 1.0. Its lifecycle is now decoupled from RxJava.

I noticed that one can find different versions of the library at different places such as on Maven Central, in the version mentioned in the README.md and in the tags. Can you please keep these in sync?!