Offline mode
Read time: 5 minutes
Last edited: Feb 27, 2023
Overview
This topic explains how to set an SDK to offline mode.
A context is a generalized way of referring to the people, services, machines, or other resources that encounter feature flags in your product. Contexts replace another data object in LaunchDarkly: "users." To learn more, read Contexts and segments.
Creating contexts and evaluating flags based on them is supported in the latest major versions of most of our SDKs. For these SDKs, the code samples on this page include the two most recent versions.
Understanding offline mode
Offline mode closes an SDK's connection to LaunchDarkly and switches to a feature flag's last known values.
Details about each SDK's configuration are available in the SDK-specific sections below.
Client-side SDKs
If a user's device is not connected to a network, such as when the device is in airplane mode, the SDK uses the latest stored flag settings in memory. If there are no previously stored flag settings, the SDK uses the default values.
This feature is available in the following client-side SDKs:
.NET (client-side)
Expand .NET (client-side) code sample
The fallback values are defined in your code. The SDK returns the fallback value only if it encounters an error or if LaunchDarkly is unreachable.
In some situations, you might want avoid remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. You can do this by setting offline mode in the client's Config. When the client is in offline mode, it makes no network requests, so it is suitable for unit-testing.
Here's how:
Configuration config = Configuration.Builder("SDK_KEY").Offline(true).Build();LdClient client = LdClient.Init(config);
Android
Expand Android code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and switch to the last known values for your feature flags. offline
mode lets you do this easily.
Here's how:
LDConfig ldConfig = new LDConfig.Builder().setMobileKey("mobile-key-123abc").setOffline(true).build();LDClient client = LDClient.init(this.getApplication(), ldConfig, context);// Or to switch an already-instantiated client to offline mode:client.setOffline();
Flutter
Expand Flutter code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and rely on locally cached values for your feature flags for future evaluations. offline
mode lets you do this easily.
Here's how:
LDConfig ldConfig = LDConfigBuilder('mobile-key-123abc').offline(true).build();await LDClient.start(ldConfig, user);// Or to switch an already-instantiated client to offline mode:await LDClient.setOnline(false);
iOS
Expand iOS code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and switch to the last known values for your feature flags. Offline mode lets you do this easily.
The SDK protects itself from multiple rapid calls to setOnline(true)
by enforcing an increasing delay (called throttling) each time setOnline(true)
is called within a short time. The first time, the call proceeds normally. For each subsequent call, the delay is enforced, and if waiting, increased to a maximum delay. When the delay has elapsed, the setOnline(true)
proceeds, assuming that the client app has not called setOnline(false)
during the delay. Therefore, a call to setOnline(true)
may not immediately result in the LDClient going online.
Client app developers should consider this situation abnormal, and take steps to prevent the client app from making multiple rapid setOnline(true)
calls. Calls to setOnline(false)
are not throttled. Calls to start(config: context: completion:)
, and setting the config
or context
can also call setOnline(true)
under certain conditions. After the delay, the SDK resets and the client app can make a subsequent call to setOnline(true)
without being throttled.
Client apps can set a completion closure called when the setOnline call completes. For unthrottled setOnline(true)
and all setOnline(false)
calls, the SDK calls the closure immediately on completion of this method. For throttled setOnline(true)
calls, the SDK calls the closure after the throttling delay at the completion of the setOnline
method.
The SDK does not go online if the client has not been started, or the mobileKey
is empty. For macOS, the SDK does not go online in the background unless enableBackgroundUpdates
is true.
Use isOnline
to get the online/offline state.
Here is an example:
LDClient.get()!.setOnline(false)LDClient.get()!.setOnline(true) {// Client is online}let connectionStatus = LDClient.get()!.isOnline
React Native
Expand React Native code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and switch to the last known values for your feature flags. You can use offline mode to do this.
Here's how:
let offlineResult = client.setOffline(); //true or falselet offlineStatus = client.isOffline(); //true or falselet onlineResult = client.setOnline(); //true or false
Server-side SDKs
This feature is available in the following server-side SDKs:
.NET (server-side)
Expand .NET (server-side) code sample
The feature flag fallback values are defined in your code. The fallback value only returns if the SDK encounters an error or if LaunchDarkly is unreachable.
In some situations, you might want avoid remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. You can do this by setting offline mode in the client's Config. When the client is in offline mode, no network requests will be made, so it is suitable for unit-testing.
Here's how:
Configuration config = Configuration.Builder("SDK_KEY").Offline(true).Build();LdClient client = new LdClient(config);
C/C++ (server-side)
Expand C/C++ (server-side) code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises.
Here's how:
LDConfigSetOffline(config, true);
Erlang
Expand Erlang code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when the software runs on-premises.
You can do this by setting offline mode in the config map with the offline
key.
Here's how:
ldclient:start_instance("sdk-key-123abc", #{offline => true})
Go
Expand Go code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. You can do this by setting Offline
mode in the client's Config
.
Here's how:
var config ld.Configconfig.Offline = trueclient, _ := ld.MakeCustomClient("sdk-key-123abc", config, 5 * time.Second)client.BoolVariation("any.feature.flag", context, false) // will always return the default value (false)
Haskell
Expand Haskell code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values for your feature flags. You can do this by setting offline mode in the config object with configSetOffline
. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises.
Here's how:
config' = configSetOffline True config
Java
Expand Java code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. You can do this by setting offline
mode in the client's LDConfig
.
Here's how:
LDConfig config = new LDConfig.Builder().offline(true).build();LDClient client = new LDClient("sdk-key-123abc", config);client.boolVariation("flag-key-123abc", context, false)// This call to client.boolVariation always// returns the default value (false)
Node.js (server-side)
Expand Node.js (server-side) code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. You can do this by setting offline
mode in the client's config
object.
Here's how:
const options = { offline: true };client = ld.init('sdk-key-123abc', options);client.variation('any.feature.flag', user, false, cb) // cb will always be invoked with the default value (false)
The default value you set in the variation method is returned in offline mode. This does not refer to the default rule set in your flag configuration.
PHP
Expand PHP code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. setOffline
lets you do this easily.
Here's how:
$client = new LaunchDarkly\LDClient("sdk-key-123abc", ["offline" => true]);$client->variation("any.feature.flag", $context, false); // will always return the default value (false)
Python
Expand Python code sample
In some situations, you might want avoid remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. You can do this by setting offline
mode in the client's Config
.
Here's how:
# Initialization:ldclient.set_config(Config("sdk-key-123abc", offline=True))ldclient.get().variation("any.feature.flag", context, False) # will always return the default value (false)
Ruby
Expand Ruby code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. Offline mode lets you do this easily.
Here's how:
config = LaunchDarkly::Config.new({offline: true})client = LaunchDarkly::LDClient.new("sdk-key-123abc", config)client.variation("any.feature.flag", context, false) # will always return the default value (false)
Rust
Expand Rust code sample
In some situations, you might want to stop making remote calls to LaunchDarkly and use fallback values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on-premises, it might make sense to use fallback values when running on-premises. Offline mode lets you do this easily.
Here's how:
let config = ConfigBuilder::new("sdk-key-123abc").offline(true).build();let ld_client = Client::build(config).unwrap();ld_client.bool_variation(&context, "flag-key-123abc", false); // will always return the default value (false)