-
Notifications
You must be signed in to change notification settings - Fork 64
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
RUMM-2138 make SDK Features simple classes #928
Conversation
eeabb5c
to
ca7a978
Compare
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.
LGTM
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've added some questions/concerns, but overall lgtm and these are non-blocking.
With this change we have quite a lot of usages of ?.
operator and null
checks, but I hope later it will go away (otherwise we need to think how to we check invariants of the SDK state - for example for A
to work we should have B
created, and if it is not the case, we should report this violation).
@@ -144,7 +143,8 @@ internal constructor( | |||
|
|||
/** @inheritdoc */ | |||
override fun intercept(chain: Interceptor.Chain): Response { | |||
if (RumFeature.isInitialized()) { | |||
val rumFeature = (Datadog.globalSDKCore as? DatadogCore)?.rumFeature |
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.
How do we make sure that we won't forget parts of the code like this (getting the feature with nullable chain with casting)? Maybe add TODO item?
I think we need to add some method which will encapsulate that, or maybe such chains will go away once we finish the rewrite.
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.
A lot of the dependencies will be reversed.
In v1 we had something like :
class SomethingUsingFeatureA {
fun foo() {
get FeatureA.component
}
}
In v2 we'll have:
class SomethingUsingFeatureA(component: FeatureAComponent)
class FeatureA {
buildSomething(): SomethingUsingFeatureA
}
@@ -466,4 +426,53 @@ internal object CoreFeature { | |||
} | |||
|
|||
// endregion | |||
|
|||
companion object { | |||
internal var processImportance: Int = |
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.
Shouldn't this field be a class member? I understand why we would want to keep it in the companion
(the value will always be the same for the whole process for any instance of CoreFeature
), but my concern is what if we have call to this field from different threads (say each instance of CoreFeature
is running on the dedicated 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.
In the end it'll be in the SDKContext
, I kept it there to minimize the impact of the current feature
uploadAllBatches( | ||
RumFeature.persistenceStrategy.getReader(), | ||
RumFeature.uploader | ||
val globalSDKCore: DatadogCore? = (Datadog.globalSDKCore as? DatadogCore) |
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.
minor: why do we need an explicit type here?
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 necessary, it'll disappear eventually
val rumApplicationId = CoreFeature.rumApplicationId | ||
return if (!RumFeature.isInitialized()) { | ||
val datadogCore = Datadog.globalSDKCore as? DatadogCore | ||
val coreFeature = datadogCore?.coreFeature |
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.
A thought: if rumFeature
(and any other feature) takes non-null coreFeature
in the constructor, can we get coreFeature
through rumFeature
? This would eliminate checking coreFeature
for null
here and other places in the codebase where we access coreFeature
near the specific feature.
Because otherwise they are independent code-wise (while in reality they are dependent) and for example blocks like check for if (rumFeature == null || coreFeature == null)
below look strange: we cannot have a rumFeature
without having a coreFeature
.
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.
In the end yes, it'll be that way
@@ -63,7 +63,7 @@ internal class WindowCallbackWrapper( | |||
} | |||
|
|||
override fun onMenuItemSelected(featureId: Int, item: MenuItem): Boolean { | |||
val resourceId = resourceIdName(item.itemId) | |||
val resourceId = windowReference.get()?.context.resourceIdName(item.itemId) |
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 be replaced with extension function created
timeProvider = CoreFeature.timeProvider | ||
|
||
if (coreFeature == null || webViewLogsFeature == null || webViewRumFeature == null) { | ||
return NoOpWebViewEventConsumer() |
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.
should we add the warning?
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.
It'll disappear before the end of the v2 refactor
What does this PR do?
Converts all
SdkFeature
object
s toclass
es.NOTE: tests were not updated at this stage, this is a transitional state that will be followed by more refactoring.