Fix late initialization error for Analytics.userProperty

[eliasyishak]

Fixes:

• Late initialization error for Analytics.userProperty #238

TLDR: initialization logic within the Session class's constructor body expects Analytics.userProperty to be initialized, this moves that constructor body logic from Session into a separate method (Session.initialize) we will call at the end of the Analytics class's constructor after we are sure all necessary fields have been initialized

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:unified_analytics	5.8.5	ready to publish	unified_analytics-v5.8.5
package:cli_config	0.1.2	already published at pub.dev
package:extension_discovery	2.0.1-wip	WIP (no publish necessary)
package:graphs	2.3.2-wip	WIP (no publish necessary)

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[christopherfujino]

it worries me anytime there is an initialize() function that one must remember to call at the right time, because a refactor could easily lead to code now accessing state in this class BEFORE the initialize() method was called.

I think this would solve the particular issue linked, and maybe this is the right change to make immediately to stop crashes, but I think long-term we should refactor all of these classes (especially Analytics) such that it is not possible to access any of its state BEFORE it has been initialized.

[christopherfujino]

This LGTM as a fix to get to users.

As discussed, I think ideally we would make all class fields either final or late final with initializer expressions, to ensure we don't hit LateInitializationErrors.

[eliasyishak]

Going to merge this in now and publish so we can have a fix, filed a separate issue to refactor session handler

• Refactor analytics session handler to use File.lastModifiedSync for _lastPing #240

[christopherfujino]

Going to merge this in now and publish so we can have a fix, filed a separate issue to refactor session handler

• Refactor analytics session handler to use File.lastModifiedSync for _lastPing #240

Can we also track refactoring all the late/late final fields to something safer? I feel like unless one can reason globally about all the state in this package and all possible edge cases, it's impossible to know that users won't hit another LateInitializationError.

[eliasyishak]

Definitely, I captured here: #241

[christopherfujino]

Definitely, I captured here: #241

nice, thanks!