[Video](https://www.youtube.com/watch?v=6TWJ_rR7K6g)

Firebase Remote Config provides lots of flexibility for how and when to
fetch new values from the server and activate them in your app, allowing you to
ensure a quality end user experience by controlling the timing of any visible
configuration changes. You can fetch new values on application launch using
`fetchAndActivate`, and use [real-time
Remote Config](https://firebase.google.com/docs/remote-config#how_it_works) as a complementary method
to automatically fetch the latest parameter values after you publish a new
version of your Remote Config.

This guide looks at a few loading strategies and discusses key considerations
for picking the best option for your app.

## Strategy 1: Fetch and activate on load

In this strategy, your app calls `fetchAndActivate` when your app first
starts up to fetch new values from Remote Config and activate them as soon
as they are done loading. This approach works well for configuration changes
that don't cause any dramatic visual changes in your UI. Avoid this approach in
any situation where your UI could change noticeably while users are using it.

After your app calls `fetchAndActivate`, it can start listening for parameter
value updates in real time by calling `addOnConfigUpdateListener`. This method
starts listening for any server-side updates to parameter values, fetches them
automatically, and then calls the listener. One strategy is to activate the new
values in the listener. However, as mentioned for `fetchAndActivate`,
avoid activating immediately for sensitive UIs.

## Strategy 2: Activate behind loading screen

As a remedy to the potential UI issue encountered in strategy 1, you could rely
on a loading screen. Instead of starting up your app right away, show a loading
screen and call `fetchAndActivate` in your completion handler. Then right after
that---again using a callback or a notification---dismiss the
loading screen and allow the user to start interacting with your app.

If you use this strategy, it's recommended to add a timeout to the loading
screen. Remote Config's one-minute timeout may be too long for a quality app
startup experience for users.

Listening for real-time Remote Config updates by calling
`addOnConfigUpdateListener` works well with this strategy. Add the listener when
the loading screen is displayed, then use `activate()` at one or more points in
your app where Remote Config values won't cause dramatic visual changes.

> [!NOTE]
> **Note:** If you are loading values for an [A/B
> Testing](https://firebase.google.com/docs/ab-testing/abtest-config) experiment, we strongly recommend this strategy. A/B Testing requires additional time to place the user into the experiment and apply the experimental values.

## Strategy 3: Load new values for next startup

An effective strategy is to load new configuration values to activate on your
app's *next* startup. In this strategy, your app activates fetched values on
startup before attempting to fetch new ones, operating on the assumption that it
may have already fetched---but not yet activated---new configuration
values. The order of operations for this strategy is:

1. On startup, immediately activate previously fetched values. This applies any values you've downloaded from the server in a previous session, and is nearly instantaneous.
2. While the user interacts with your app, kick off an asynchronous call to fetch new values according to the default minimum fetch interval and add a real-time config update listener. The real-time listener will automatically fetch any values that are published on the server while your app is running. Real-time updates bypass the minimum fetch interval setting.
3. In the completion handler or callback for the fetch call, do nothing. Your app will keep the downloaded values until you activate them the next time the app starts.

With this strategy, user wait time is greatly minimized. Combining the fetch and
real-time listener strategies with `activate()` calls as needed in the app
lifecycle makes sure users have the latest values from Remote Config as they
interact with your app.

> [!TIP]
> **Tip:** Use `fetch()` and `addOnConfigUpdateListener()` as complementary methods. It's recommended to call fetch once per app launch, then start listening for updates in real time and activate them as needed. Listening for real-time updates makes it possible to get the latest parameter values without calling fetch frequently.

## Loading anti-strategies

Based on the preceding sections of loading strategies, avoid the following usage
patterns:

- **Don't** update or switch aspects of the UI while the user is viewing or interacting with it --- *unless* you have strong app or business reasons for doing so, like removing options related to a promotion that has just ended.
- **Don't** send mass numbers of simultaneous fetch requests, which could result in the server throttling your app. If you need to fetch updates frequently, use [real-time
  Remote Config](https://firebase.google.com/docs/remote-config#how_does_it_work). While the risk of throttling is low in most production scenarios, it can be an issue during active development---and real-time Remote Config is designed for this use case. Check out the [throttling
  guidance](https://firebase.google.com/docs/remote-config/get-started#throttling).
- **Don't** rely on network connectivity to obtain Remote Config values. **Do** set in-app default parameter values so that your app always behaves as expected. You can periodically keep app and Remote Config backend default values in sync using [downloaded template
  defaults](https://firebase.google.com/docs/remote-config/templates#download_template_defaults).

## Next steps

These three basic strategies don't by any means constitute a complete list of
ways to load configuration values. Depending on your needs, you could devise
much more sophisticated strategies.

Check out the API reference for your platform to learn more about the specific
calls for fetching and activating configuration values.