-
Notifications
You must be signed in to change notification settings - Fork 6
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
Migrate EventsBuilder
to Kotlin
#100
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
9458153
Rename .java to .kt
wzieba 882915a
refactor: convert `EventsBuilder` to Kotlin
wzieba 26746d9
fix: do not allow users to start engagement session without tracking …
wzieba a5811f5
fix: update signature of `ParselyMetadata#toMap` methods
wzieba 636a172
fix: update signature of `buildEvent` method
wzieba 3dc2e2b
fix: make Logging object internal
wzieba d154b8a
feat: use `Clock` for getting time in `EventsBuilder`
wzieba 2c64338
style: remove unused imports and runTest
wzieba File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
83 changes: 0 additions & 83 deletions
83
parsely/src/main/java/com/parsely/parselyandroid/EventsBuilder.java
This file was deleted.
Oops, something went wrong.
63 changes: 63 additions & 0 deletions
63
parsely/src/main/java/com/parsely/parselyandroid/EventsBuilder.kt
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,63 @@ | ||
package com.parsely.parselyandroid | ||
|
||
import com.parsely.parselyandroid.Logging.log | ||
import java.util.Calendar | ||
import java.util.TimeZone | ||
|
||
internal class EventsBuilder( | ||
private val deviceInfoRepository: DeviceInfoRepository, | ||
private val siteId: String, | ||
private val clock: Clock, | ||
) { | ||
/** | ||
* Create an event Map | ||
* | ||
* @param url The URL identifying the pageview/heartbeat | ||
* @param action Action to use (e.g. pageview, heartbeat, videostart, vheartbeat) | ||
* @param metadata Metadata to attach to the event. | ||
* @param extraData A Map of additional information to send with the event. | ||
* @return A Map object representing the event to be sent to Parse.ly. | ||
*/ | ||
fun buildEvent( | ||
url: String, | ||
urlRef: String, | ||
action: String, | ||
metadata: ParselyMetadata?, | ||
extraData: Map<String, Any>?, | ||
uuid: String | ||
): Map<String, Any> { | ||
log("buildEvent called for %s/%s", action, url) | ||
|
||
// Main event info | ||
val event: MutableMap<String, Any> = HashMap() | ||
event["url"] = url | ||
event["urlref"] = urlRef | ||
event["idsite"] = siteId | ||
event["action"] = action | ||
|
||
// Make a copy of extraData and add some things. | ||
val data: MutableMap<String, Any> = HashMap() | ||
if (extraData != null) { | ||
data.putAll(extraData) | ||
} | ||
val deviceInfo = deviceInfoRepository.collectDeviceInfo() | ||
data["ts"] = clock.now.inWholeMilliseconds | ||
data.putAll(deviceInfo) | ||
event["data"] = data | ||
metadata?.let { | ||
event["metadata"] = it.toMap() | ||
} | ||
if (action == "videostart" || action == "vheartbeat") { | ||
event[VIDEO_START_ID_KEY] = uuid | ||
} | ||
if (action == "pageview" || action == "heartbeat") { | ||
event[PAGE_VIEW_ID_KEY] = uuid | ||
} | ||
return event | ||
} | ||
|
||
companion object { | ||
private const val VIDEO_START_ID_KEY = "vsid" | ||
private const val PAGE_VIEW_ID_KEY = "pvid" | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
This is mostly going to be a nitpick, but I guess it affects the architecture, so I'll leave the decision to you whether it's worth addressing:
Taking
Clock
as a parameter in the constructor doesn't feel correct to me. If we are going to takeClock
as a parameter, I thinkbuildEvent
is the better place for it, because that's where it's used. However, if we are going to do that, we might as well takenow
as a parameter and not deal with theClock
ourselves.If we are going to deal with the
Clock
internally - and not involve the caller, then I think we can just initiate it ourselves and be the owner of it.I am generally in favor of taking whatever is necessary at the point of its actual usage, which in this case would be taking
now
as a parameter. However,ParselyTracker
doesn't own aClock
, so there is some practical benefit to owning it ourselves - unless there are unit testing considerations.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 just reviewed the unit test changes for this as well and I think taking
now
as a parameter simplifies that as well. I am curious to hear if you had any reservations to use that approach as opposed to taking it as a constructor argument.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 my opinion, there are two solutions: either
Clock
in the constructor ornow
in thebuildEvent
. I'm okay with the second as well, but below I share my rationale behindClock
in the constructor.I've put
Clock
mentally in the same category asDeviceInfoRepository
. We don't executedeviceInfoRepository.collectDeviceInfo()
outsideEventsBuilder
and pass the result inbuildEvent
in the case of this class, and I treated theClock
the same way.Also putting
Clock
as a constructor parameter is that in this design, the code communicates thatEventsBuilder
needs aClock
for building an event, but it doesn't communicate externally why exactly. I think that's good, as it creates less overhead for the client of taking care ofClock
at the time of invokingbuildEvent
.WDYT such idea of thinking about
Clock
in the scope ofEventsBuilder
?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's interesting that you mention this, because I actually drafted something about this in the review and then discarded it. I'd have done this outside of the
EventsBuilder
as well and passed in the data.I see this as complete opposite. If possible, I want to know why you need a clock when you are building the event. So for example, if this was in an SDK and I needed to directly use it, as the client I'd ask, why do you need me to pass you a clock? If it's for the event time, why not ask for it. In fact, even at the cost of a bit extra memory, in my opinion the most ergonomic design would be something like:
Anyhow - I don't think this is a particularly important one to pick one solution or the other. So, I am happy with whatever you decide to go with :)
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.
That's a very interesting perspective! I'd lean more towards asking API: "why do you bother me with passing
now
or anything that you could figure out before". So that's definitely a refreshing view on the topic to me and food for thoughts 🙂. Thanks for sharing this, I'm glad we exchanged the views!True - it's internal for the API, and we can always iterate without any risk of breaking public contract. I'll default to the currently proposed implementation, just because it doesn't involve more work.
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.
That's a good point, but it's also applicable to why we are taking
Clock
as a constructor or function argument as well. It's something we can figure out ourselves. I assume the reason we do it is for testing and I have mixed feelings about that. Generally, I don't love having to change the API just for testing, but I understand that it's sometimes a necessary evil.I also made my suggestion as
eventTime
instead of takingnow
as an argument, because I can see a use case for passing a different event time then the current time.Anyhow, I am totally fine with keeping this as is, just wanted to clarify a few points.