Added getter for spring looper

[knappador]

Straightforward use case:

1. Activity with springs.
2. Pause activity.
3. NPE's everywhere :'-(

Use to pause springs that shouldn't be running when Activity is paused. Simply use onPause and onResume from Activity lifecycle to calls start/stop on looper. No more tears.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks!

[willbailey]

Usually I avoid this problem by cleaning up springs when the view they are associated with is detached from the window. Is there a reason this approach won't work for you?

[knappador]

I typically use a Model-View-Presenter style or one where the logic is
mostly housed in Fragments to keep state and associated logic in a more
persistent lifecycle, especially where data needs to be coordinated across
multiple Views and Fragments via an Rx bus etc. Springs are very
lightweight objects, so rather than adding and removing them, especially
when one spring's state needs to be persisted in case another Fragment
subscribes, simply stop/starting the Looper seems highly desirable compared to requiring a lot of boilerplate lifecycle management scattered all over the application.

Handling construction in a nearly Singleton style inside of Subscription
logic would allow me to only create Springs as needed in the case that the
desired Spring is not currently instantiated, but for instance, if I needed
to pause all springs while showing a dialogue, you can see where this
quickly gets out of hand and requires tons of coordination to stop the
SpringLooper. In addition, my first impression of the API was that the
Android-specific loopers were going to be purposefully designed to not send
events while an Activity is paused, a common source of things running when
not intended that resulted in my NPE's going off as I was coordinating some
other resources with my Activity's lifecycle to avoid holding onto old
Activity contexts for instance.

Changes to the available Loopers to allow for binding to the Activity would
be of great convenience. For now, the public API's on the Loopers did not
seem prone to breakage except the likely unnecessary setSpringSystem method.

On Sat, Aug 8, 2015 at 2:00 AM, Will Bailey [email protected]
wrote:

Usually I avoid this problem by cleaning up springs when the view they are
associated with is detached from the window. Is there a reason this
approach won't work for you?

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

[willbailey]

I see your point about making the Android Looper more friendly toward Activity/Fragment lifecycle. What if we take an approach similar to RxAndroid and provide a way to bind a SpringSystem to an Activity/Fragment context. You'd then automatically get the pausing behavior your looking for without exposing the internals of the SpringSystem. I'd like to see this added to Rebound. Are you interested in working on something like this?

[knappador]

Sadly I need to get an application into Facebook and other companies before I can presently afford the time to contribute #startuplife. My quick and dirty solution was to extend BaseSpringSystem slightly differently.