-
Notifications
You must be signed in to change notification settings - Fork 906
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
Expose ribActionEvents stream #599
Conversation
2bb5dde
to
6e1018b
Compare
6e1018b
to
8587e79
Compare
9b2f281
to
2ac48ff
Compare
android/demos/rib-workers/src/main/kotlin/com/uber/rib/workers/root/logger/RibEventLogger.kt
Outdated
Show resolved
Hide resolved
c7674d8
to
60a8308
Compare
29c7d6d
to
715defd
Compare
715defd
to
66eac33
Compare
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Show resolved
Hide resolved
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Outdated
Show resolved
Hide resolved
As discussed offline, we could have a DSL like: inline fun record(startEvent: StartEvent, endEvent: EndEvent, block: () -> Unit) {
// emit start event
block()
// emit end event
} And in interactors (e.g.) we could have fun didBecomeActive() {
record(Interactor.Start, Interactor.Stop) {
// code for didBecomeActive
}
} If we don't do the calculation on the Also, we could have an atomic identifier for each |
...rib-workers/src/main/kotlin/com/uber/rib/workers/root/logger/ApplicationLevelWorkerLogger.kt
Outdated
Show resolved
Hide resolved
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Show resolved
Hide resolved
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Show resolved
Hide resolved
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/Router.kt
Outdated
Show resolved
Hide resolved
- Use MainScope for ApplicationLevelWorkerLogger demo - Add thread name to always keep track of original caller thread name
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Show resolved
Hide resolved
...rib-workers/src/main/kotlin/com/uber/rib/workers/root/logger/ApplicationLevelWorkerLogger.kt
Outdated
Show resolved
Hide resolved
...rib-workers/src/main/kotlin/com/uber/rib/workers/root/logger/ApplicationLevelWorkerLogger.kt
Outdated
Show resolved
Hide resolved
...rib-workers/src/main/kotlin/com/uber/rib/workers/root/logger/ApplicationLevelWorkerLogger.kt
Outdated
Show resolved
Hide resolved
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Outdated
Show resolved
Hide resolved
|
||
fun interface BackendReporter { | ||
fun report(genericMessage: String) | ||
public enum class RibComponentType { |
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.
Coroutine Worker? Why reserve for next release?
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.
We may need to tweak a bit more RibCoroutine worker in order to provide accurate monitoring as mentioned by @psteiger earlier
Given there are barely any users internally of RibCoroutineWorker, I'm not concerned to leave these changes to be implemented on a separate PR
* @param ribEventType RIB event type (e.g. ATTACH/DETACH) | ||
*/ | ||
internal inline fun <T : Any> triggerRibActionAndEmitEvents( | ||
ribCallerClassType: 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.
Can we lock this down more than T? With the use of lambda's, this, it, and T here it seems like the risk is high that we end up not tracking the correct class we're expecting.
Is there a common interface we can use here? If not, should we have one?
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.
Good idea, let me explore
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.
Added a "RibComponent" contract for these common components, still thinking a better naming for this
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Show resolved
Hide resolved
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Outdated
Show resolved
Hide resolved
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Show resolved
Hide resolved
internal inline fun <T : Any> triggerRibActionAndEmitEvents( | ||
ribCallerClassType: T, | ||
internal inline fun triggerRibActionAndEmitEvents( | ||
ribComponent: RibComponent, | ||
ribComponentType: RibComponentType, |
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 would like to specify a property on the new RibComponent to be overriden, unfortunately given that Worker and RibCoroutineWorker are interfaces we cannot restrict visibility of those
android/libraries/rib-base/src/main/kotlin/com/uber/rib/core/RibEvents.kt
Outdated
Show resolved
Hide resolved
@@ -34,7 +34,7 @@ protected constructor( | |||
public open val interactor: I, | |||
private val ribRefWatcher: RibRefWatcher, | |||
private val mainThread: Thread, | |||
) { | |||
) : RibComponent { |
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.
Probably too generic for a name for this set of callbacks. How about something more explicit around emitting callbacks around lifecycles, like RibEventEmitter?
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.
Good idea, I like this better
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.
Decided to go with RibActionEmitter
to avoid confusion with existing RibEventType
ac3027f
to
59014ba
Compare
Description:
Expose
ribActionEvents
stream that emits state of each RIB "action" (e.g didBecomeActive, willLoad) For example:One example application of consuming these events is monitoring binding duration of Workers as shown in
ApplicationLevelWorkerLogger
from rib-workers demo app...
WARNING: [RibEvents.enableRibActionEmissions] must be called at the earliest app scope before subscribing/collecting ribAction events. This is intentional in order to avoid unnecessary object creations for each RIB action in case no one is listening
Breaking changes:
WorkerBinder.initializeMonitoring
WorkerBinderListener
RibEvents
RibEvent
RibRouterEvent
events
withinRibEvents
events
torouterEvents
Tests
Related issue(s):
Provide a new RibActionEvent stream that will allow for monitoring/logging options for all RIB components (Interactor, Presenter, Router, Worker)