Potential refactor

[jrodiz]

This is a proposal for removing SessionManager as a singleton

Current implementation

SessionManager primary purposes are:

• Session Creation and Management: It creates and manages PerfSession objects. Each session is identified by a unique ID (a UUID), which is crucial for grouping related performance data. A new session is generated at every cold start of the app and also when the app comes to the foreground.

• Session ID Distribution: The class acts as a broadcaster. It informs other parts of the application (referred to as SessionAwareObject clients) whenever the active performance session changes. This ensures that all performance data (like traces and metrics) is correctly associated with the current session ID.

• Lifecycle Awareness: It listens to application state changes (like going into the foreground or background) via the AppStateMonitor. This allows it to make decisions, such as starting a new session when the app is foregrounded.

• Gauge Metric Control: It controls the collection of periodic metrics (gauges), like CPU and memory usage. It tells the GaugeManager when to start or stop collecting these metrics based on the current session's configuration and the application's state (foreground/background).

Currently this class is referenced in some others like

Trace

• Usage in start() method: When a Trace is started, it interacts with the SessionManager for two primary reasons:

  1. To get the current session: It calls SessionManager.getInstance().perfSession() to retrieve the active PerfSession. This session object (containing the session ID) is then associated with the trace.
  2. To register for updates: It calls SessionManager.getInstance().registerForSessionUpdates(sessionAwareObject) to listen for future session changes. This ensures that if a new session starts while the trace is still running (e.g., the app goes to the background and comes back), the trace can be associated with the new session ID as well.

• Usage in stop() method: When the Trace is stopped, it calls SessionManager.getInstance().unregisterForSessionUpdates(sessionAwareObject) to stop listening for session updates, preventing memory leaks.

GaugeManager

• Usage's purpose: The GaugeManager is responsible for collecting periodic data like CPU and memory usage (gauges).
• Interaction: The SessionManager holds the logic for when to start or stop collecting these gauges. It calls methods on GaugeManager to start or stop gauge collection based on whether a session is running and if the app is in the foreground. This ensures that gauge metrics are only collected during an active, verbose session.

AppStateMonitor

• Usage's purpose: This class monitors the application's lifecycle (e.g., when the app enters the foreground or background).
• Interaction: The AppStateMonitor notifies its listeners, one of which is the SessionManager, of these state changes. The SessionManager uses this information to decide when to update the session. For example, when the app comes to the foreground after a certain period of inactivity in the background, SessionManager will generate a new session ID.

FirebasePerformance

• Usage's purpose: This is the main public entry point for the Firebase Performance Monitoring SDK.
• Interaction: During the initialization of the Performance Monitoring feature, FirebasePerformance likely triggers the initialization of the SessionManager to start the very first session when the app starts up.

Proposed refactor

Trace

The core change is that the Trace class no longer directly calls a static SessionManager.getInstance() method. Instead, it now receives its SessionManager instance from AppStateMonitor during its own initialization.

In order to eliminate SessionManager as a singleton

1. Removal of Direct Singleton Access
2. New Class Member Variable for SessionManager
3. SessionManager is Now Injected During Construction

The Trace constructors have been updated to receive the SessionManager instance from AppStateMonitor. AppStateMonitor now acts as a provider or factory for the SessionManager. However more effort should be made to also remove AppStateMonitor as a singleton.

TransportManager

This class is responsible for queueing and sending performance data to the Firebase backend. The changes here are central to the new dependency injection approach.

SessionManager Injected via initialize(): The primary initialize method, which is called when Firebase Performance starts up, now explicitly requires a SessionManager object as a parameter. This is the key injection point.

AppStartTrace

AppStartTrace is a special, one-time-use class responsible for capturing the application's startup metrics. It has a unique lifecycle compared to regular Trace objects.

The AppStartTrace would have called SessionManager.getInstance() directly, most likely when it was time to dispatch the trace, to get the session ID. The constructor for AppStartTrace has been updated to accept the SessionManager instance as a parameter. This is the key dependency injection point for this class.

Impact of These Changes

1. Decoupling: Trace is no longer tightly coupled to the static singleton implementation of SessionManager. It now only knows that it needs an instance of SessionManager, which it receives from AppStateMonitor.
2. Improved Testability: This is a major benefit. When testing the Trace class, we can now provide a mock or fake SessionManager object in the constructor. This allows us to test the logic of the Trace class in isolation without relying on the real SessionManager and the entire Firebase SDK initialization.
3. Centralized Dependency Management: By having AppStateMonitor be the source for the SessionManager instance, we have centralized the responsibility of creating and providing this dependency. This makes the code more organized and is a significant step toward completely removing the global singleton pattern.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.