While integrating 1.0 in real use case, I found that the following changes were very useful:
First, based on our use case, RxGroups is useful to manage observables even if you never intend to resubscribe. This is because RxGroup offers the ability to:
Check in flight status
Cancel
Automatically unsubscribe on lifecycles
In our real use, we did in fact use RxGroups with observables that we had no intent to resubscribe to. This PR moves some logic into RxGroups to make this use case more explicit. Noticeably, RxGroups accepts plain observers for most methods now. If the observable does not implement TaggedObserver then we use a identifiable variant of hashcode. However, with plain Observer's resubscribing does not make sense, thus resubscribe will remain TaggedObserver. To cut down on memory leaks, we can clear out "NonResubscribable" Observers on a non-finishing destroy.
Another use case we need is the ability to separate AutoResubscribing from AutoTagging. We have a handful of cases were we want to have a auto generated tag, but we cannot resubscribe the observable onCreate. This PR allows this cases to be solved by using the AutoTag annotation, which will set the unique tag on the observer, but will require the user to explicitly call Resubscribe.
~Finally, this adds a 'safeInitialize' method for group creation, and uses it for onCreate. I see the value in a "Butterknife throw if class not generated style code" but this causes problems for architectures that rely on call init in a base class and where the derived class may have no AutoResubscribe listeners, and thus no generated code (our arch). Currently leaving the old method in, but wonder if we should just standardize on no error for simplicity.~
Todo:
[x] Now that generated code is more complex, we should have real code-gen -> gen file tests
While integrating 1.0 in real use case, I found that the following changes were very useful:
First, based on our use case, RxGroups is useful to manage observables even if you never intend to resubscribe. This is because RxGroup offers the ability to:
In our real use, we did in fact use RxGroups with observables that we had no intent to resubscribe to. This PR moves some logic into RxGroups to make this use case more explicit. Noticeably, RxGroups accepts plain observers for most methods now. If the observable does not implement
TaggedObserver
then we use a identifiable variant of hashcode. However, with plain Observer's resubscribing does not make sense, thus resubscribe will remainTaggedObserver
. To cut down on memory leaks, we can clear out "NonResubscribable" Observers on a non-finishing destroy.Another use case we need is the ability to separate AutoResubscribing from AutoTagging. We have a handful of cases were we want to have a auto generated tag, but we cannot resubscribe the observable onCreate. This PR allows this cases to be solved by using the
AutoTag
annotation, which will set the unique tag on the observer, but will require the user to explicitly callResubscribe
.~Finally, this adds a 'safeInitialize' method for group creation, and uses it for onCreate. I see the value in a "Butterknife throw if class not generated style code" but this causes problems for architectures that rely on call init in a base class and where the derived class may have no AutoResubscribe listeners, and thus no generated code (our arch). Currently leaving the old method in, but wonder if we should just standardize on no error for simplicity.~
Todo: