Firebase Android SDK

A Firebase Component is a blueprint used by the Firebase Component Model to discover, resolve dependencies, and instantiate SDK services via Dependency Injection.

Key characteristics of a Component:

• Interfaces: It implements one or more interfaces.
• Dependencies: It declares required or optional dependencies on other components.
• Initialization: It specifies whether it should be initialized eagerly (at app startup) or lazily (on demand).
• Factory: It defines a factory that creates the component instance using its resolved dependencies.

Components are singletons within a FirebaseApp container. For SDKs requiring multiple instances (like multiple databases in RTDB or Firestore), the component registers a 'MultiResource' singleton that manages and provides multiple instances per resource name.

// Defines a component that is registered as both `FirebaseAuth` and `InternalAuthProvider`.
Component<FirebaseAuth> auth = Component.builder(FirebaseAuth.class, InternalAuthProvider.class)
    // Declares dependencies
    .add(Dependency.required(FirebaseOptions.class))
    // Defines a factory
    .factory(container -> new FirebaseAuth(container.get(FirebaseOptions.class)))
    .eagerInDefaultApp() // alwaysEager() or lazy(), lazy is the default.
    .build()

The Data Connect SDK uses a two-level SharedFlow architecture to manage real-time query subscriptions over a single multiplexed bidirectional gRPC connection. This design replaces manual state management with standard Kotlin Coroutine operators to ensure connection lifecycle and query multiplexing are handled efficiently.

The Two-Level Flow Architecture

1. Upper Shared Flow (connectionFlow): This flow maintains the active bidirectional gRPC connection with the server. It uses replay = 0 and SharingStarted.WhileSubscribed(0) to ensure the connection opens when the first query is subscribed to and closes when the last one leaves.
2. Lower Shared Flows: These are spawned per unique query (identified by operation name and variables) and are cached in the RealtimeQueryManager. They multiplex all local subscribers for that specific query. Like the upper flow, they use replay = 0 and WhileSubscribed(0).

Key Mechanisms

• Automatic Lifecycle: By using WhileSubscribed(0), the SDK leverages native coroutine reference-counting. The connection and query-specific resources automatically clean up when there are zero active collectors.
• Late Subscriber Resumption: When a new subscriber joins an active query, the SDK triggers a resume request to the server via a ConflatedSignal. This ensures the late subscriber receives the most recent data immediately rather than waiting for the next server-side emission.
• Reliability: The architecture allows the use of standard operators like retryWhen on the upper flow to implement features like exponential backoff and reconnection on network changes.