-
Notifications
You must be signed in to change notification settings - Fork 51
Checking for devtools config file for opt out #227
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -137,13 +137,17 @@ Directory? getHomeDirectory(FileSystem fs) { | |
/// Dart: `$HOME/.dart/dartdev.json` | ||
/// | ||
/// Flutter: `$HOME/.flutter` | ||
/// | ||
/// Devtools: `$HOME/.flutter-devtools/.devtools` | ||
bool legacyOptOut({ | ||
required FileSystem fs, | ||
required Directory home, | ||
}) { | ||
final dartLegacyConfigFile = | ||
fs.file(p.join(home.path, '.dart', 'dartdev.json')); | ||
final flutterLegacyConfigFile = fs.file(p.join(home.path, '.flutter')); | ||
final devtoolsLegacyConfigFile = | ||
fs.file(p.join(home.path, '.flutter-devtools', '.devtools')); | ||
|
||
// Example of what the file looks like for dart | ||
// | ||
|
@@ -202,6 +206,38 @@ bool legacyOptOut({ | |
} | ||
} | ||
|
||
// Example of what the file looks like for devtools | ||
// | ||
// { | ||
// "analyticsEnabled": false, <-- THIS USER HAS OPTED OUT | ||
// "isFirstRun": false, | ||
// "lastReleaseNotesVersion": "2.31.0", | ||
// "2023-Q4": { | ||
// "surveyActionTaken": false, | ||
// "surveyShownCount": 0 | ||
// } | ||
// } | ||
if (devtoolsLegacyConfigFile.existsSync()) { | ||
try { | ||
final devtoolsObj = | ||
jsonDecode(devtoolsLegacyConfigFile.readAsStringSync()) | ||
as Map<String, Object?>; | ||
if (devtoolsObj.containsKey('analyticsEnabled') && | ||
devtoolsObj['analyticsEnabled'] == false) { | ||
return true; | ||
} | ||
} on FormatException { | ||
// In the case of an error when parsing the json file, return true | ||
christopherfujino marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// which will result in the user being opted out of unified_analytics | ||
// | ||
// A corrupted file could mean they opted out previously but for some | ||
// reason, the file was written incorrectly | ||
return true; | ||
eliasyishak marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} on FileSystemException { | ||
return true; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i see this is the same logic for other tools with legacy opt in / opt out files, but why assume they are opted out if we can't read the file? Seems like instead we should assume that they haven't answered the question as to whether they want to opt in or not, and then we can ask them There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a fair question, I think we wanted to approach this with a more conservative approach. I was imagining a developer who thought they were opted out in the past, somehow ended up with a corrupted file, and now gets prompted again... they may dismiss it thinking it was bug and now we're collecting their data I'm not opposed to swapping out this logic, just wanted to highlight that edge case There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would think that if a user opted out once, they'd opt out again when prompted. The user set I'd be worried about dropping are the users who have opted yes, and then somehow their file gets corrected, and now we opt them out instead of asking them again, which would show up as a drop in our usage that could be due to the logic here. I would guess the corrupted file case is pretty rare though, so maybe this isn't as big of a risk. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I have a separate PR that is out that will allow us to track how many times we run into these catch blocks so that should help answer if this happens often in the wild |
||
} | ||
} | ||
|
||
return false; | ||
} | ||
|
||
|
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.
So here "legacy" doesn't necessarily refer to the analytics instance it's going to, but an implementation of analytics that predates package:unified_analytics, right?
And therefore, we will need to maintain this code in perpetuity?
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.
Couldn't it mean both? Currently devtools has their own implementation for analytics while it also sends to a different GA instance.. is that what you mean?
And yes, we would maintain this. It only runs the first time
package:unified_analytics
is run on a developers workstation though