Firebase Remote Config: co to je, parametry a jak spravovat na dálku

Co je Firebase Remote Config a jak funguje

Firebase Remote Config je služba, která ukládá páry klíč-hodnota na straně serveru Firebase a doručuje je klientským zařízením na vyžádání nebo podle plánu. Každý parametr má název (řetězec), hodnotu (řetězec, číslo, boolean nebo JSON) a může být vázán na podmínky — pravidla, která určují, jakou hodnotu obdrží konkrétní uživatel. Podmínky mohou kontrolovat verzi aplikace, jazyk zařízení, region, náhodné procento a mnoho dalších atributů.

Architektura Remote Config je postavena na modelu push-pull s prioritou pull. Klient pravidelně vyžaduje aktuální hodnoty ze serveru (ve výchozím nastavení každých 12 hodin). Vývojář však může iniciovat okamžitou synchronizaci v kódu nebo prostřednictvím konzole Firebase (tlačítko „Publish changes”). Po zveřejnění změn server odešle push oznámení prostřednictvím Firebase Cloud Messaging a aplikace po jeho obdržení může parametry znovu vyžádat.

Bezplatný tarif Firebase Remote Config nemá omezení na počet parametrů nebo požadavků, což jej odlišuje od ostatních služeb Firebase. Jediným omezením je velikost odpovědi, která nesmí překročit 800 KB (celkem za všechny parametry). To je více než dostatečné pro typický scénář: většina projektů používá 10–50 parametrů a jejich celkový objem zřídka přesahuje 100 KB.

Jak Remote Config určuje, jakou hodnotu vrátit uživateli

Mechanismus výběru hodnoty je založen na prioritě podmínek. Každá podmínka představuje pravidlo (např. „iOS verze > 15.0”). Remote Config kontroluje podmínky v pořadí priority a vrací hodnotu první vyhovující podmínky. Pokud žádná podmínka nevyhovuje, použije se výchozí hodnota (default value). Tento mechanismus umožňuje vytvářet hierarchii pravidel: od nejspecifičtějšího k nejobecnějšímu.

Důležité: pořadí podmínek v konzoli Firebase má význam. Pokud dvě podmínky mohou vyhovovat jednomu uživateli současně, vítězí ta, která je v seznamu výše. Doporučuje se umístit specifičtější podmínky (např. pro konkrétní verzi aplikace) nad obecné podmínky (např. „Všichni uživatelé iOS”). Nesprávné pořadí může vést k tomu, že cílená změna nebude nikdy použita.

Ukládání do mezipaměti a životnost parametrů

Ve výchozím nastavení Remote Config ukládá do mezipaměti hodnoty přijaté ze serveru po dobu 12 hodin. To znamená, že po zveřejnění změn v konzoli je aplikace uvidí nejdříve za 12 hodin (nebo po dalším explicitním volání fetch). Minimální dobu ukládání do mezipaměti lze nastavit pomocí FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 3600) — pro produkci se doporučuje alespoň 1 hodina, aby se předešlo nadměrným požadavkům na server a spotřebě dat uživatele.

Pro testování změn během vývoje použijte minimální interval 0 sekund: FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 0). V tomto režimu každé volání fetch načte aktuální hodnoty ze serveru. Je důležité nezapomenout před vydáním obnovit produkční interval, jinak se aplikace při každém spuštění připojí k serveru, čímž se zvýší náklady a spotřeba baterie.

Parametry, podmínky a skupiny uživatelů

Parametr Remote Config je pojmenovaná proměnná, která může nabývat jedné z několika hodnot v závislosti na podmínkách. Typy hodnot: string, number (double), boolean, JSON object (serializovaný řetězec). Parametry JSON jsou vhodné pro přenos strukturovaných dat bez vytváření mnoha samostatných parametrů: například objekt s nastavením motivu aplikace (primaryColor, backgroundColor, fontSize).

Podmínky (conditions) jsou logická pravidla, která kontrolují atributy uživatele nebo zařízení: verze OS (iOS, Android), verze aplikace, země, jazyk, uživatelská skupina (vlastnost definovaná v kódu), náhodné procento (pro A/B testy). Podmínky lze kombinovat pomocí logického AND: například „verze aplikace >= 5.0” A „země = Rusko”. Každý parametr může mít neomezený počet podmínek, ale v praxi se používají 2–5.

Pro personalizaci použijte uživatelské vlastnosti (user properties) — atributy nastavené v kódu aplikace prostřednictvím Firebase Analytics. Například analytics.setUserProperty(„subscription_tier”, „premium”). Remote Config může tuto vlastnost zkontrolovat a vrátit hodnoty specifické pro prémiové uživatele. Personalizace prostřednictvím Remote Config nevyžaduje vytváření podmínek na straně klienta — veškerá logika je soustředěna v cloudové konzoli.

Skupiny uživatelů a segmentace

Remote Config podporuje dva modely segmentace: založený na atributech (conditions) a založený na vlastnostech Firebase Analytics (user properties). První model je statický: podmínka kontroluje pevný atribut, který se nemění v rámci relace nebo verze aplikace. Druhý model je dynamický: vlastnost může být nastavena v jakémkoli okamžiku běhu aplikace, což umožňuje flexibilní segmentaci uživatelů za běhu.

Důležité: pro použití user properties v Remote Config je nutná integrace Firebase Analytics. Tento požadavek je způsoben tím, že Remote Config získává uživatelská data z Analytics SDK. Bez Analytics pracuje Remote Config pouze s atributy zařízení (verze OS, verze aplikace, země z IP). Personalizace založená na chování uživatele (např. „provedl 5 nákupů”) je dostupná pouze prostřednictvím Analytics.

Správa verzí šablony

Šablona Remote Config (template) je kompletní sada všech parametrů, podmínek a jejich hodnot. Firebase uchovává historii změn šablony a umožňuje vrátit se k libovolné předchozí verzi do 90 dnů. Správa verzí je kriticky důležitá: pokud je po zveřejnění změn objevena chyba (např. nesprávná hodnota parametru rozbíjí UI), lze šablonu okamžitě vrátit na předchozí funkční verzi prostřednictvím konzole Firebase.

Každá změna šablony (zveřejnění) vytváří novou verzi s jedinečným číslem. V konzoli Firebase je k dispozici protokol změn s uvedením času, uživatele a popisu (pokud je vyplněn). Doporučuje se vždy přidávat popis k publikaci: „Zapnuli jsme nový feed pro iOS 10% testovací skupiny”. Bez popisu po měsíci nelze vzpomenout, co přesně bylo změněno ve verzi 42.

Jak implementovat Remote Config v aplikaci

Implementace Remote Config se skládá ze tří kroků: inicializace SDK s nastavením (doba ukládání do mezipaměti), definování výchozích parametrů (hodnoty pro případ nedostupnosti serveru) a logika aplikace získaných hodnot. Výchozí parametry jsou pojistkou pro případ, že se zařízení nemůže připojit k Firebase (žádný internet, server nedostupný). Bez default values bude aplikace používat null, což může vést k pádu.

Definování default values se provádí dvěma způsoby: programově pomocí volání setDefaultsAsync nebo pomocí XML souboru. Programový způsob je vhodný pro malé projekty: všechny hodnoty se nastaví přímo v kódu jednou při spuštění aplikace. Souborový způsob je preferován pro projekty s desítkami parametrů: hodnoty jsou uloženy v prostředcích a lze je snadno upravovat bez rekompilace. Doporučuje se kombinovat: základní nastavení v XML a specifická — programově.

Asynchronnost je klíčovou vlastností Remote Config SDK. Metoda fetchAndActivate() provádí požadavek na server na pozadí, aniž by blokovala UI. Po dokončení načítání dojde k aktivaci — hodnoty parametrů se aktualizují v paměti aplikace. Pro sledování dokončení použijte posluchače nebo korutiny (v Android/Kotlin). Uživatel by neměl vidět „trhání” UI při aktualizaci parametrů — všechny změny by měly být aplikovány plynule.

Inicializace s onComplete a posluchači

Při prvním spuštění Remote Config SDK neblokuje inicializaci aplikace. Během synchronizace aplikace používá výchozí hodnoty. To znamená, že uživatel může při prvním spuštění vidět starou verzi rozhraní a po dokončení fetch — novou. Pro kritické parametry (např. serverUrl, na kterém závisí funkčnost), použijte synchronní aktivaci s čekáním na výsledek.

Doporučený postup: zobrazte načítací obrazovku s minimálním zpožděním, pokud aplikace kriticky potřebuje získat aktuální parametry před zobrazením první obrazovky. Na načítací obrazovce se spustí fetchAndActivate s časovým limitem 5 sekund. Pokud se do 5 sekund parametry nenačtou, aplikace se spustí s default values. Tím se zabrání nekonečnému čekání při nedostatku internetu.

Práce s JSON parametry

JSON parametry Remote Config umožňují přenášet strukturovaná data jednou hodnotou. Například objekt se styly motivu: {„primaryColor”: „#6200EE”, „borderRadius”: 8, „fontFamily”: „Roboto”}. Na klientovi je JSON analyzován a aplikován na UI. Výhody: jeden parametr místo tří, atomicita aktualizace (všechna tři pole se aktualizují současně), čistá konzole. Nevýhoda: obtížné čtení v konzoli Firebase (JSON se zobrazuje jako řetězec).

Doporučení: používejte JSON parametry pro skupiny logicky souvisejících hodnot, které se aktualizují společně (motivy, konfigurace obrazovky, nastavení sítě). Pro nezávislé parametry (feature toggle, serverUrl) používejte samostatné řetězcové nebo boolean parametry — jsou snadněji čitelné v konzoli a snadněji se sledují změny v historii verzí šablony.

A/B testování s Remote Config

A/B testování je vestavěná funkce Firebase Remote Config, která umožňuje rozdělit uživatele do skupin, nastavit pro každou skupinu různé hodnoty parametrů a měřit dopad změn na vybrané metriky. Na rozdíl od ručního rozdělení prostřednictvím podmínek s random_percent, integrace s Firebase Analytics automaticky sbírá statistiky pro každou experimentální skupinu a ukazuje statistickou významnost rozdílů.

Proces A/B testu: vývojář vytvoří experiment v konzoli Firebase (sekce A/B Testing), vybere parametr Remote Config, nastaví hodnoty pro kontrolní a testovací skupinu a určí cílovou metriku (např. conversion rate nebo revenue). Firebase automaticky rozděluje uživatele do skupin, sbírá data a po 2–4 týdnech zobrazí výsledek s p-hodnotou. Experiment lze předčasně zastavit, pokud je výsledek jednoznačný.

Statistická významnost je klíčovým kritériem pro zastavení experimentu. Firebase A/B Testing používá častostní přístup (Frequentist) a ukazuje p-hodnotu pro každou metriku. Standardní práh významnosti je 0,05 (95% pravděpodobnost spolehlivosti). Po dosažení tohoto prahu ve prospěch jedné ze skupin Firebase doporučuje zastavit experiment a aplikovat změny pro všechny uživatele. Pokud po 4 týdnech není významnosti dosaženo, experiment se považuje za nepřesvědčivý.

Typy experimentů

Firebase A/B Testing podporuje dva typy experimentů: klasický A/B (porovnání dvou hodnot jednoho parametru) a multivariační A/B/n (porovnání tří nebo více hodnot). Pro multivariační testy je potřeba více uživatelů k dosažení statistické významnosti. Doporučuje se používat A/B/n pouze pro parametry s 3–5 variantami, kde se každá varianta zásadně liší od ostatních.

Doba trvání experimentu závisí na objemu provozu: pro aplikace s 1000 aktivními uživateli denně je minimální doba 2 týdny, pro aplikace se 100 000 uživateli — 3–5 dní. Firebase automaticky vypočítá potřebný čas a varuje, pokud aktuální provoz není dostatečný pro detekci významných rozdílů. Důležité: nezastavujte experiment před vypočítaným termínem, i když se výsledek zdá zřejmý — to je klasická chyba „peeking”.

Metriky pro A/B testování

Cílové metriky v Firebase A/B Testing jsou definovány na základě událostí Firebase Analytics. K dispozici jsou standardní metriky: daily active users, revenue, conversion rate, retention, user engagement. Lze také vytvořit vlastní metriku na základě libovolné události Analytics s dalšími parametry. Například metrika „Procento uživatelů, kteří se dostali na platební obrazovku” je vytvořena z události screen_view s parametrem screen_name = „payment”.

Doporučuje se vybrat jednu primární metriku (primary metric), na jejímž základě se rozhoduje o úspěchu experimentu, a 2–3 sekundární metriky pro doplňkovou analýzu. Výběr více primárních metrik zvyšuje riziko falešně pozitivního výsledku (multiple comparison problem). Pokud vybraná primární metrika nevykazuje statisticky významné zlepšení, experiment se považuje za neúspěšný, i když se sekundární metriky zlepšily.

Příklady kódu pro Remote Config v Kotlinu

Prozkoumáme integraci Remote Config v Android aplikaci v Kotlinu. Příklady zahrnují inicializaci SDK s vlastní dobou ukládání do mezipaměti, získání parametrů různých typů, implementaci A/B podmínky na straně klienta a zpracování chyb při nedostupnosti serveru. Veškerý kód se provádí v hlavní aktivitě nebo třídě Application, aby byly parametry dostupné od samého začátku aplikace.

Před použitím přidejte závislost: implementation(„com.google.firebase:firebase-config”) prostřednictvím Firebase BOM. Ujistěte se, že Firebase Analytics je také připojen, protože Remote Config používá Analytics pro přenos uživatelských vlastností.

Inicializace a získání parametrů

První příklad — základní nastavení Remote Config s minimálním intervalem fetch 1 hodina pro produkci. SDK se inicializuje v metodě onCreate třídy Application. Po fetchAndActivate se zkontroluje hodnota parametru welcome_message, který lze vzdáleně změnit pro úvodní obrazovku.

class MainApp : Application() {

    override fun onCreate() {
        super.onCreate()
        val remoteConfig = Firebase.remoteConfig
        val settings = FirebaseRemoteConfigSettings.Builder()
            .setMinimumFetchIntervalInSeconds(3600)
            .build()

        remoteConfig.setConfigSettingsAsync(settings)
        remoteConfig.setDefaultsAsync(
            R.xml.remote_config_defaults
        )

        remoteConfig.fetchAndActivate()
            .addOnCompleteListener { task ->
                if (task.isSuccessful) {
                    val welcomeMsg = remoteConfig
                        .getString("welcome_message")
                    Log.d("RemoteConfig", welcomeMsg)
                }
            }
    }
}

V příkladu setDefaultsAsync načítá default values z XML souboru res/xml/remote_config_defaults.xml. Pokud fetch skončí chybou (žádná síť, server nedostupný), aplikace bude používat tyto hodnoty. XML soubor obsahuje stejné názvy parametrů jako v konzoli Firebase: <entry key=„welcome_message”>Vítejte!</entry>. Doporučuje se mít vždy default values pro všechny parametry Remote Config.

Feature toggle s Remote Config

Druhý příklad — feature toggle (příznak zapnutí funkce). Parametr new_checkout_enabled je typu boolean. Pokud je hodnota true — aplikace zobrazí novou obrazovku dokončení objednávky, pokud false — starou. Feature toggle je nejoblíbenějším scénářem Remote Config: změna ovlivňuje pouze jeden parametr, nevyžaduje úpravu logiky a může být okamžitě vrácena.

fun isFeatureEnabled(paramName: String): Boolean {
    return Firebase.remoteConfig
        .getBoolean(paramName)
}

// Použití v activity
if (isFeatureEnabled("new_checkout_enabled")) {
    navigateToNewCheckout()
} else {
    navigateToLegacyCheckout()
}

Funkce isFeatureEnabled zapouzdřuje přístup k Remote Config a lze ji snadno testovat pomocí mocku. Pro feature toggles se doporučuje používat konvenci pojmenování: prefix feature_, ff_ nebo flag_, aby v konzoli Firebase bylo okamžitě jasné, k čemu parametr slouží. Příklad: feature_new_onboarding, ff_dark_mode, flag_v3_api. Nepoužívejte parametry-příznaky pro zapínání/vypínání déle než 3 měsíce — hromadění mrtvých příznaků komplikuje údržbu.

Získání konfigurace motivu JSON

Třetí příklad — získání JSON parametru s nastavením motivu aplikace. Parametr app_theme obsahuje JSON objekt s primaryColor, borderRadius a fontFamily. Na klientovi je JSON analyzován pomocí Gson nebo kotlinx.serialization a hodnoty jsou aplikovány na UI. Tento přístup umožňuje designérům měnit motiv aplikace bez účasti vývojáře a bez vydání nové verze.

data class AppTheme(
    val primaryColor: String = "#6200EE",
    val borderRadius: Int = 8,
    val fontFamily: String = "Roboto"
)

fun getAppTheme(): AppTheme {
    val json = Firebase.remoteConfig
        .getString("app_theme")
    return Gson().fromJson(json, AppTheme::class.java)
}

Práce s JSON vyžaduje opatrnost: pokud je JSON v konzoli Firebase neplatný (např. chybí čárka), analýza selže a aplikace obdrží default values namísto aktuálního motivu. Doporučuje se validovat JSON řetězce před publikací pomocí JSON validátoru. Pro produkci přidejte try-catch při analýze a zaznamenávejte chyby prostřednictvím Firebase Crashlytics.

Nejlepší postupy a omezení

Firebase Remote Config je mocný nástroj, ale při nesprávném použití může vést k problémům s výkonem, předvídatelností chování a bezpečností. Probereme klíčové postupy, které pomohou vyhnout se typickým chybám při práci se službou, a omezení, která je třeba vzít v úvahu při navrhování architektury aplikace.

Vyhněte se citlivým údajům — Remote Config není určen k ukládání tajemství (API klíčů, tokenů, hesel). Všechny hodnoty parametrů jsou přístupné klientskému kódu a lze je získat z paměti aplikace. Pro důvěrná data používejte Cloud Functions s ověřením na serveru nebo Secret Manager. V Remote Config ukládejte pouze veřejné parametry: texty, příznaky, nastavení UI, URL veřejných endpointů.

Testujte každou změnu před zveřejněním pro celé publikum. Použijte A/B test nebo zveřejnění na malé procento (1–5% uživatelů) ke kontrole, že nová hodnota nezpůsobuje pád a nerozbíjí zobrazení. Remote Config nemá staging prostředí — všechny změny jsou zveřejněny přímo do produkce. Jediným bezpečným způsobem zveřejnění je postupné zavádění.

Omezení platformy: maximální počet parametrů — 2000 (pro všechny typy), maximální velikost jedné hodnoty — 256 KB, celková velikost odpovědi serveru — 800 KB. Počet uživatelských vlastností (user properties), které lze použít v Remote Config, je omezen na 25. Minimální interval fetch — 0 sekund (pro ladění), ale zneužití může vést k překročení kvóty Cloud Functions (30 000 požadavků za minutu na projekt).