TODD KERPELMAN: So you've got the basics down
for wiring up your app for remote config.
But do you know the best way to load up and apply these values
in a user-friendly way?
Well, let's find out on this episode of Firecasts.
So when it comes to using remote config,
your app generally performs three steps
before it can start using the latest and greatest values
from the Firebase console.
First off, you supply a whole bunch of default
values locally in your code.
Second, you fetch new values from the cloud.
And third, you call activateFetched,
which tells a remote config, OK, go ahead and copy
these fetch values on top of whatever old ones
you might currently have.
Then you can start retrieving values from remote config,
and you'll either get the default value or a newer value
from the cloud.
Now there are several ways you can apply this
fetch and activate strategy.
Let's go over some of the most common ones.
So option one, and the option you'll
most likely see in our sample apps,
is the activate and refresh strategy.
The idea is that you can start by fetching new values.
And then in your completion handler,
you can call activateFetched to apply these values,
then send off some kind of notification or callback
which tells your app to go ahead and update itself.
Now this works fine in most demos,
and it's fairly straightforward, which
is why you will often see it in our sample code.
The problem is that you don't really
know how long it's going to take for remote config
to finish fetching these values out in the real world.
And you don't necessarily want to get into situations where
your app changes out from under your user
while they're in the middle of using it.
That could get kind of awkward.
So another option a lot of developers like to go with
is to bring up a loading screen.
Instead of starting up your app right away,
you'll just show a loading screen,
and then like in the previous strategy,
you can fetch new values and call activateFetched
in your completion handler.
Then right after that, again using
a callback or a notification of some sort,
you can dismiss the loading screen
and the user can start up your app for real.
You might also want to add a time out, too.
Remote config does have its own, but it's
about a minute long, which might be too
long for your user's tastes.
And this technique is nice in that you're
guaranteed to almost always have the latest and greatest values
from remote config by the time your users get
into the main content of your app.
The drawback, of course, is that your users now
have to wait to start your app and they're impatient.
Plus you now have to build a loading screen
and I don't know about you, but I'm lazy.
That sounds like work I'd rather not do.
Now granted, if your app already has a loading screen,
then go ahead.
Do this work alongside everything else
that's happening during that startup process
and you'll be fine.
But if you don't already have a loading screen in your app,
there's another technique I like even better which
sounds a little non-intuitive at first, so bear with me.
It's the load up values for next time strategy,
and here's how this works.
When you start up an app, you immediately
call activateFetched.
And this would apply any old values
you've downloaded from the cloud in a previous session
and is nearly instantaneous.
Then your user can start using your app like normal.
Now in the meantime, you also kick off
a call to fetch new values, and this happens asynchronously.
And then in the completion handler, you do nothing.
Your app will basically keep those downloaded values
until you call activateFetched on them the next time
you start your app.
Now I really like this approach because the user wait
time is down to nothing.
But it does mean your user will have
to run your app a second time to see your latest
remote config values.
Now in many situations, this is fine,
but you will need to decide if this kind of tradeoff
is right for you.
You can also look into some kind of hybrid approach.
Remote config lets you see when you last successfully fetched
data and so you can look at that value and decide what to do.
Like maybe if it was more than 48 hours ago,
you throw up a loading screen and force the app
to fetch new values.
But otherwise, you can just apply the current values
and fetch new ones for next time, something like that.
Say, as long as we're talking about loading techniques
and network calls and all that stuff, let's
talk about caching.
As I've mentioned in previous videos,
remote config will cache fetched values for about 12 hours
by default before it decides to go out and fetch
new values from the cloud.
And this is one of the ways we're
able to keep the service free no matter
how popular your app gets.
Now you can shorten this cash value
if you'd like, but don't shorten it too much
or you might run into throttling,
either on the client side or on the server.
So for most uses of remote config,
this 12 hour cache is fine.
If your users are using your app once a day,
they'll still see your latest values every time
they start up your app.
And honestly, if you find yourself in a situation
where you want to be changing these values every half hour
or something, you might want to consider the real time
database as that might be more suited to your use case.
But there may be times when every once in a while,
you decide it's really, really important
that your app fetches updated remote config
values right away.
Like maybe Billy the summer intern
uploaded a bad set of values yesterday
and it's killing your in-game economy
or causing some kind of crash and you really
want to get your new values out there faster than usual.
So what can you do?
Well, one technique you can try is sending a notification
through Firebase Cloud Messaging to all your devices
and letting them know that there's
an urgent update to remote config that they need to grab.
Your app could handle this incoming notification
by waking up and immediately performing a fetch with a cache
value of zero.
And this would make sure that it's
loaded up fresh values from remote config and the next time
your users startup your app.
But I'm not crazy about this approach.
If millions of instances of your app
suddenly woke up and made a background fetch,
you'd probably hit the server side throttle.
So an approach I like a little better
is when your app receives this notification, rather
than making a call to a remote config,
make a little note locally that there's
an urgent update pending.
Then the next time your app starts up
and gets ready to make its fetch call,
it can check and see if this local flag exists.
If it does, well, that means there's probably
an urgent update and your app can go make a fetch call
with a cache time of zero.
And this will ensure that every new session of your app
will get the latest values from remote config,
but that fetch time is distributed across the time
period in which your users open your app instead of all
at once, meaning it's much less likely that your calls will
get throttled.
Of course, when you're done fetching,
don't forget to remove this flag to go back
to your usual caching behavior.
Now granted, this is logic you do
have to have built into your app in advance.
But if you ever think that you might need to urgently change
remote config values, it is a really nice insurance policy
to have.
Oh, Billy.
So there you go, kids-- some tips and tricks for how
to best load up remote config.
Got any tips of your own?
Add to the comments below.
And we'll see you soon on another exciting episode
of Firecasts.
Thanks for watching.
Did you enjoy this video?
Well, don't miss some other exciting Firebase
content like this one here, or maybe this video.
This one's my favorite.
I like this one too.
This one's my favorite.