Protocols

The following protocols are available globally.

  • Each OHTTP request-reply exchange needs to create an OhttpSession object to manage encryption state.

    See more

    Declaration

    Swift

    public protocol OhttpSessionProtocol : AnyObject
  • A testing interface for decrypting and responding to OHTTP messages. This should only be used for testing.

    See more

    Declaration

    Swift

    public protocol OhttpTestServerProtocol : AnyObject
  • Declaration

    Swift

    public protocol StoreProtocol : AnyObject
  • Declaration

    Swift

    public protocol ApplicationErrorReporter : AnyObject
  • Object representing the signed-in state of an application.

    The FirefoxAccount object is the main interface provided by this crate. It represents the signed-in state of an application that may be connected to user’s Firefox Account, and provides methods for inspecting the state of the account and accessing other services on behalf of the user.

    See more

    Declaration

    Swift

    public protocol FirefoxAccountProtocol : AnyObject
  • Machinery for dry-run testing of FxaAuthStateMachine

    Remove this once we’ve migrated the firefox-android and firefox-ios code to using FxaAuthStateMachine https:///bugzilla.mozilla.org/show_bug.cgi?id=1867793

    See more

    Declaration

    Swift

    public protocol FxaStateMachineCheckerProtocol : AnyObject
  • Declaration

    Swift

    public protocol LoginStoreProtocol : AnyObject
  • Declaration

    Swift

    public protocol NimbusClientProtocol : AnyObject
  • Declaration

    Swift

    public protocol NimbusStringHelperProtocol : AnyObject
  • Declaration

    Swift

    public protocol NimbusTargetingHelperProtocol : AnyObject
  • Declaration

    Swift

    public protocol RecordedContext : AnyObject
  • Declaration

    Swift

    public protocol MetricsHandler : AnyObject
  • Declaration

    Swift

    public protocol PlacesApiProtocol : AnyObject
  • Declaration

    Swift

    public protocol PlacesConnectionProtocol : AnyObject
  • Declaration

    Swift

    public protocol SqlInterruptHandleProtocol : AnyObject
  • Object representing the PushManager used to manage subscriptions

    The PushManager object is the main interface provided by this crate it allow consumers to manage push subscriptions. It exposes methods that interact with the autopush server and persists state representing subscriptions.

    See more

    Declaration

    Swift

    public protocol PushManagerProtocol : AnyObject
  • Declaration

    Swift

    public protocol RemoteSettingsProtocol : AnyObject
  • Client for a single Remote Settings collection

    Use [RemoteSettingsService::make_client] to create these.

    See more

    Declaration

    Swift

    public protocol RemoteSettingsClientProtocol : AnyObject
  • Application-level Remote Settings manager.

    This handles application-level operations, like syncing all the collections, and acts as a factory for creating clients.

    See more

    Declaration

    Swift

    public protocol RemoteSettingsServiceProtocol : AnyObject
  • Declaration

    Swift

    public protocol AppServicesLogger : AnyObject
  • The store is the entry point to the Suggest component. It incrementally downloads suggestions from the Remote Settings service, stores them in a local database, and returns them in response to user queries.

    Your application should create a single store, and manage it as a singleton. The store is thread-safe, and supports concurrent queries and ingests. We expect that your application will call [SuggestStore::query()] to show suggestions as the user types into the address bar, and periodically call [SuggestStore::ingest()] in the background to update the database with new suggestions from Remote Settings.

    For responsiveness, we recommend always calling query() on a worker thread. When the user types new input into the address bar, call [SuggestStore::interrupt()] on the main thread to cancel the query for the old input, and unblock the worker thread for the new query.

    The store keeps track of the state needed to support incremental ingestion, but doesn’t schedule the ingestion work itself, or decide how many suggestions to ingest at once. This is for two reasons:

    1. The primitives for scheduling background work vary between platforms, and aren’t available to the lower-level Rust layer. You might use an idle timer on Desktop, WorkManager on Android, or BGTaskScheduler on iOS.
    2. Ingestion constraints can change, depending on the platform and the needs of your application. A mobile device on a metered connection might want to request a small subset of the Suggest data and download the rest later, while a desktop on a fast link might download the entire dataset on the first launch.
    See more

    Declaration

    Swift

    public protocol SuggestStoreProtocol : AnyObject
  • Builder for [SuggestStore]

    Using a builder is preferred to calling the constructor directly since it’s harder to confuse the data_path and cache_path strings.

    See more

    Declaration

    Swift

    public protocol SuggestStoreBuilderProtocol : AnyObject
  • Declaration

    Swift

    public protocol SyncManagerProtocol : AnyObject
  • Declaration

    Swift

    public protocol RemoteCommandStoreProtocol : AnyObject
  • Note the canonical docs for this are in https://searchfox.org/mozilla-central/source/services/interfaces/mozIBridgedSyncEngine.idl It’s only actually used in desktop, but it’s fine to expose this everywhere. NOTE: all timestamps here are milliseconds.

    See more

    Declaration

    Swift

    public protocol TabsBridgedEngineProtocol : AnyObject
  • Declaration

    Swift

    public protocol TabsStoreProtocol : AnyObject