-
Notifications
You must be signed in to change notification settings - Fork 226
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
Arch components lifecycle support #71
Conversation
|
||
@OnLifecycleEvent(Lifecycle.Event.ON_ANY) void onStateChange() { | ||
if (!isDisposed()) { | ||
observer.onNext(lifecycle.getCurrentState()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this could result in duplicate state emissions since this fires on events. Will find out
autodispose-android/build.gradle
Outdated
@@ -49,6 +49,7 @@ dependencies { | |||
compile deps.rx.java | |||
compile deps.rx.android | |||
compile deps.support.annotations | |||
compile "android.arch.lifecycle:extensions:1.0.0-alpha1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for a separate module approach
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. at least until we call it beta (which means stable api)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup moved it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, you don't need extensions, you should only need lifecycle:common
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool, I'll remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I remember now why I added it, I need LifecycleRegistry
for the TestAndroidLifecycleScopeProvider
implementation. Added back in 1c06bef
switch (lastEvent) { | ||
case INITIALIZED: | ||
throw new LifecycleNotStartedException(); | ||
case CREATED: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the lifecycle intentionally not 1-1? It seems very strange to have multiple start events map to the same stop event.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's only one stop event, not sure why
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are confusing states vs events.
https://developer.android.com/topic/libraries/architecture/lifecycle.html
e.g. both onStart and onPause brings you to the STARTED state. I'm not sure where you are using these but this seems wrong.
I think |
Yep event is the right way to go. Sorry for the lag on this, kind of mentally put it on the backburner since it was still in alpha. Will jump on it this coming week |
So I'm a little stuck on this right now. I've switched the implementation to events, but I'm not sure how to test this. I tried writing this as an espresso test (similar to how the |
fyi, you don't need to keep this as a separate artifact, Lifecycle's core libs will be a dependency of support Fragments so all apps will have them. |
yeah I was just making it separate for while it was in alpha, but maybe you'll beat me to it :) |
Will handle rebasing before merging later. Going to figure out testing for this now |
Ok, things should be ready to go here. Going to do a rebase |
2d5bfc2
to
c98b639
Compare
Rebased. Requesting review from @tonycosentini and @jbarr21, also welcome feedback from anyone else on the thread :) |
subject.onNext(2); | ||
o.assertNoMoreEvents(); | ||
|
||
d.dispose(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dumb question - why is this needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t remember (this test is largely a copy of the viewscopeprovidertest), I think it’s not and I just did it out of habit or something. Will try removing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
@SuppressWarnings("CheckReturnValue") LifecycleEventsObservable(Lifecycle lifecycle) { | ||
this.lifecycle = lifecycle; | ||
// Backfill if already created for boundary checking |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: doesn't seem like it matters with today's implementation - but would it ever be beneficial to replay all the previous events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you mean. Like having that be a use case of the library?
@Override protected void subscribeActual(Observer<? super Event> observer) { | ||
if (!isMainThread()) { | ||
observer.onError( | ||
new IllegalStateException("Lifecycles can only be bound to on the main thread!")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a strict requirement with the new architecture library?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessarily but it's always emitted on the main thread and you could have a race condition if you don't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checked with @yigit, answer is yes otherwise no guarantees
This is a first pass of support for Android Architecture Components' `Lifecycle` support. This works fairly similarly to `ViewScopeProvider` from a structural standpoint. `LifecycleOwner` or `Lifecycle` can be passed in, an inner observer is passed in and removed upon disposal. Thoughts for discussion: - Name is up for grabs. This one's a bit long :) - Should it be its own artifact? I'm leaning toward this, then we could also do an alpha release of it separately. - Things get a bit convoluted for me around `State` vs. `Event`. I'm not sure which one we should watch for, but all the querying APIs revolve around `State` so I went with that. - Does it matter if it's on the main thread? If this looks good - I'll take a pass at tests.
WIP still as I don't really know how to test this nicely
DESTROY is _before_ INITIALIZED apparently
d5eff71
to
653e1a6
Compare
Rebased and ran UI tests locally |
This is a first pass of support for Android Architecture Components'
Lifecycle
support. This works fairly similarly toViewScopeProvider
from a structural standpoint.LifecycleOwner
orLifecycle
can be passed in, an inner observer is passed in and removed upon disposal.Thoughts for discussion:
State
vs.Event
. I'm not sure which one we should watch for, but all the querying APIs revolve aroundState
so I went with that.If this looks good - I'll take a pass at tests.
I think this would also resolve #36 and #37 by just supporting them (in the support lib anyway)