eliasyishak / dash_analytics Goto Github PK

If a user has analytics enabled and they have not been active on any dash tools, send some kind of survey to understand why, while also highlighting other tooling they may not know about.

We want to create a class that can handle all operations dealing with the configuration file that is persisted on the user's computer.

List below of the objectives we want for this class

• Parse the configuration file into something that can be used within the codebase (#6)
• Functionality needed to add a new tool that hasn't been configured in the file yet (#7)
• Method to enable/disable telemetry (#9)
• Method that can take in a new tool message and show the user the output as well as increment the tool version

Need to add some functionality that will be able to read in a config file that has been altered to not follow our assumptions.

Need to handle the cases below:

• If there were two or more lines for the reporting boolean indicator
• When there are two more lines for a given tool (ie. if flutter-tools=2022-12-13,1 showed up twice at the bottom of the config file)

Originally, I thought that the client (other dash tooling) would be responsible for passing in their own message to show the user about our data collection policy, but really there should be one standard message that is shown to all clients that is controlled by this package. And when there is an update to the messaging, we will update the package version.

We should include the version of the package being used by the client (Dash tools) so that we can see in the analytics whether certain tools are using old versions or the latest

This is a utility function that doesn't need to belong within the classes

Look into adding functionality (can be disabled with flag) that logs all of the events that have been sent on user's computer incase they would like to see what events they are emitting. This will allow them to make an informed decision on whether or not they want to opt in/out of telemetry.

This feature can also enable other use cases – ie. surveying users about inactivity if logs show a decrease in activity over a period of time.

Convert the setTelemetry method under the Analytics class to be async to free up resources during file I/O related operations.

This pattern can also be used to for other file i/o operations around the session + log files

Moving our conversation @christopherfujino from the commit to an issue to track better.

The original comment on commit on the lib/src/analytics.dart file: 595be88#diff-8959a2a24fd89be63385a1feffed84beb3be8dab70ec527a4d3dcafc938607f6

Current setup

// Setup the singleton
Analytics.setup(...);

// Can call the singleton like this after
// within different classes, files, etc.
final Analytics analytics = Analytics();
final Analytics analytics2 = Analytics();

If we don't want to use a setup static method before calling for the singleton, we will need to change the design of the package so that the analytics singleton is initialized once and passed down to children where analytics events are passed.

With the current setup we can setup once at the entry point and easily import the package's Analytics class anywhere within the codebase so long as the setup has happened before.

We should have an API that can be exposed from this package that will allow for aggregations and analyses to be done on the locally persisted analytical events

This will be blocked until #4 is completed

Most of the file io related operations are all synchronous right now and can be converted to async for improved performance.

Generate the below items so that we can standardize the events we send

• Create a Session object that is responsible for creating and extending sessions
• Use a UserProperty class to store information about the user
• Create a Google Analytics client class to handle sending events to the POST endpoint

At the moment, we do not have a fake/mocked http client that we can send the body of the request too. A fake class should be created that returns a Future<Response> type to test sending events

Discussion from @bwilkerson

It looks like there's a master list of event names to pass into sendEvent. I had assumed that these would be tool-specific, but that appears to not be the case. How are we going to prevent multiple tools from using the same event name for different purposes? Will we use a naming convention, such as 'toolName_eventName'? Or will the tool name and event name be joined automatically so that we don't need to worry about collisions?

Discussion from @bwilkerson

The class Analytics takes several pieces of data, and the example has (presumably) fake values for these. How will I know what the correct values are for these parameters when using the package in production? I could imagine an enum for the tool name, and I think I can figure out how to find the Dart and Flutter version numbers (though if there's a standard way we might want to consider computing them in the analytics package rather than making every client duplicate the code), but it seems like we wouldn't want some of the data to be visible in the source code (like measurementId and apiSecret).