Stop using Advertising Id in track and match requests #39
Conversation
dimamo5
force-pushed
the
track-accepts-ids
branch
from
daca4de to
9af97c8
Compare
Codecov Report
@@ Coverage Diff @@
## master #39 +/- ##
======================================
Coverage 0.00% 0.00%
======================================
Files 8 6 -2
Lines 151 117 -34
Branches 21 19 -2
======================================
+ Misses 151 117 -34
Continue to review full report at Codecov.
|
| */ | ||
| data class UserId(val type: String, val id: String) | ||
| data class UserId(val id: String, val type: String = "gaid") { |
There was a problem hiding this comment.
Not related to this PR directly, but should we prevent empty ids?
| Velocidi.getInstance().match("provider1", listOf(UserId("eml", "mail@example.com"))) | ||
| Velocidi.getInstance().match( | ||
| "provider1", | ||
| listOf(UserId("123"), UserId("mail@example.com", "eml")) |
There was a problem hiding this comment.
Nitpick: can we remove literal email examples? This example in particular is not consistent with the id type and I think we should avoid exemplifying plain emails... Can we use a proper sha256 example here and in other examples?
There was a problem hiding this comment.
I think I replace all the references of plain email in 57eeb21
| * | ||
| * @param providerId Id of the match provider | ||
| * @param userIds List of user ids to be linked along with Advertising Id | ||
| * @param userIds List of user ids to be linked | ||
| */ | ||
| fun match(providerId: String, userIds: List<UserId>) { |
There was a problem hiding this comment.
Not directly related to this PR, but can/should we force a non-empty list of ids?
dimamo5
force-pushed
the
track-accepts-ids
branch
from
1317350 to
35314fd
Compare
dimamo5
force-pushed
the
track-accepts-ids
branch
from
35314fd to
57eeb21
Compare
|
Looks good. Waiting on the approval from @silva95gustavo. |
|
Good job @dimamo5! |
Depends on #38
Fetching and using the Advertising Id implicitly on
trackandmatchrequests may lead the client app to break some privacy rules. It is also problematic on devices that don't use Google services or in devices with have stricter privacy settings. To avoid dealing with such issues we decided to shift the responsibility of using Google's Advertising Id to the client app.So, this PR changes the
trackmethod to accept anUserIdand stops fetching the Advertising Id oninitand using it on track and match requests.