Developer AdvocateIf you're a fan of our FirebaseDevelopers channel, you might have noticed that we just published a video all about how to best load up Remote Config values in your app:
But we know there are some people out there who would rather read than watch a video, so we thought we'd provide this for you in convenient blog form, too!
So if you've done any Remote Config work in the past, you probably noticed there are three main steps to implementing Remote Config in your app:
You supply remote config with a bunch of default values. This is done locally on the device, either in code or by pulling in values from a local plist or xml file.
You then call fetch() to download any new values from the cloud
Finally, you call activateFetched() to apply these downloaded values on top of the default values you originally supplied.
At this point, when you query remote config for a particular value, you'll either get the updated value from the cloud, or whatever default you've supplied locally. And this is nice, because you can wire up your app to grab allof its values through Remote Config. You're still keeping your network calls nice and small, because you're only downloading the values that are different than your defaults, but you now have the flexibility to change any aspect of your app later through the cloud.
Seems pretty straightforward, right? And, for the most part, it is. The problem is that step 2 up there requires making a network call, and out in the real world, where people are using your app in tunnels, elevators, deserts, or places with poor network connections, you never really know how long it's going to take for that network call to complete. You can't guarantee that this process will be finished before your user starts interacting with your app.
So with that said, here are three strategies you can employ:
Strategy #1: Activate and refresh
This strategy is the most straightforward, which is generally why you'll see it in our sample apps and tutorials. The idea is that, once you've downloaded these new values from the cloud, you can call activateFetched() in your completion handler to immediately apply them, and then you tell your app to just go ahead update itself.
This strategy is nice in that it allows your user to get right into your app. But it's a little weird in that you potentially have your app changing things like button text, UI placement, or other critical values while your user is in the middle of using it, which can be a poor user experience. This is why many developers will opt to choose a solution like...
Strategy #2: Add a loading screen
A fairly common strategy is to display a loading screen when your user first starts up your app. Just like before, you'd call activateFetched in your completion handler to immediately apply these values, but instead of telling your app to refresh its interface, you would tell your app to dismiss the loading screen and transition to the main content. This is nice in that by the time your users make it past your loading screen and into your app, you're almost guaranteed to have fresh values from the cloud downloaded and ready to go.
Obviously, the big drawback here is that now you have a loading screen. This requires time and effort to build, and is also a barrier to your users getting into your app. But if your app already has a loading screen because you have to perform other work and/or network calls at startup, then this could be a good strategy. Just fetch your remote config values alongside whatever other startup work you're doing.
However, if your app doesn't already have a loading screen, I'd recommend trying an alternate strategy instead. Something like...
Strategy #3: Load values for next time
This one seems a little counter-intuitive, but hear me out: When your user starts up your app, you immediately call activateFetched(). This will apply any old values you've previously fetched from the cloud. And then your user can immediately start interacting with your app. In the meantime, you kick off an asynchronous fetch() call to fetch new values from the cloud. And in the completion handler for this call… you do nothing. Heck, you don't even need add a completion handler in the first place. Those values you fetched from the cloud will remain stored locally on the device until your user calls activateFetched the next time they start your app.
This strategy is really nice in that your users can immediately start using their app, and there's no weird behavior where your app's interface suddenly changes out from under them. The obvious drawback is that it takes two sessions for your users to see your updated remote config values. You'll need to decide for yourself whether or not this is the right behavior for your app. If you're using Remote Config to, say, fine-tune some values in your tower defense game, this is probably fine. If you're using it to deliver a message-of-the-day, or content specific to certain dates (like a holiday re-skin of your app) it might not be.
Strategy #3.5: Some hybrid of strategies 2 and 3. Or 1 and 3.
One nice thing about Remote Config is that it can tell you whenyour last successful fetch() call was performed. And so you can build some hybrid strategy where you first check how old your most recently fetched Remote Config data was. If it's fairly recent (say, in the last 48 hours or so), you can go ahead and run the "apply the latest batch of values and perform another fetch for next time" strategy. Otherwise, you can fall back to one of the earlier two strategies.
Let's talk about caching
As long as we're talking about loading strategies, let me hit on a related topic; caching. It sometimes confuses developers that values from remote config are cached for 12 hours instead of being grabbed immediately every time you call fetch(). And while you can reduce this cache time somewhat, if you start making network calls too frequently, your app might start getting throttled, either by the client, or the Remote Config service.
So, why do we have all of this caching and throttling behavior in the first place?
Well, partly it's a way to ensure we can keep this service free, even if your app scales to millions upon millions of users. By adding in some well-behaved caching, we can make sure that our service can handle your app for free, no matter how popular it gets.
It's also a nice way to protect the service from bad code. There are some developers out there (not you, of course) who might accidentally call fetch()too frequently. And we don't want the entire service getting slammed because one developer out there is accidentally DDoSing it. Having the client-side library serve up cached values and/or throttle frequent network calls helps keep the service safe.
But it's also good for your users. A good caching strategy prevents your app from using up your user's battery and/or data plan by making too many unnecessary network calls, which is always a good thing.
Obviously, while you're developing and testing your Remote Config implementation, this can be inconvenient, which is why you can override the local throttling behavior by turning on developer mode. But out in the real world, even if your users are using your app every single day, this kind of caching behavior is usually just fine.
But what if you want to push out values more frequently than that? What if you're trying to deliver a "Message of the hour" kind of feature through Remote Config? Well, frankly, this might be a sign that the Remote Config service isn't the ideal solution for you, and you should consider using the Realtime Database instead for something a little more timely.
On the other hand, there may be times when you want to infrequently apply an urgent Remote Config update. Perhaps you've accidentally broken your in-app economy with your latest batch of changes and you want everybody to get new values right away. How can you get around the cache and force your clients to perform a fetch?
One solution is to use Firebase Cloud Messaging. With FCM, you can send a data-only notification to all of your devices, letting them know that there's an urgent update pending. Your apps can respond to this incoming notification by storing some kind of flag locally. The next time your user starts up your app, it can look for this flag. If it's set to true, your app can perform a fetch with a cache time of 0 to ensure an immediate fetch. Just make sure you set this flag back when you're done, so your app can resume its usual caching behavior.
You might be tempted to have your clients respond to this incoming notification by immediately waking up and fetching new values from the Remote Config service, but if every instance of your app did that at once, there's a very good chance it will hit the server-side throttle, so I don't recommend this. Stick with the above strategy instead; that will spread out the network calls across the time period it takes for all of your users to open up your app.
So there ya go, folks! A few tips and tricks for loading up your values from Remote Config. Got any tips of your own? Feel free to share them in the comments on our YouTube video, or head on over to the Firebase Talk group and let us know how you're coming along with your Remote Config implementation.
Developer Advocate at ProgressSWGuest blogger Jen Looper The powerful combination of NativeScript, Firebase, and Angular 2 can kickstart your app building into high gear, especially during the holidays when you find yourself confronted with the need to speed up your app development AND meet your family's gift-giving needs! Just in time, I am happy to presentto you (see what I did there 🎁) a demo of how to leverage Firebase in your Angular 2-powered NativeScript apps using several elements of Eddy Verbruggen's famousNativeScript-Firebase plugin.
In this tutorial, I'm going to show you how to use four popular Firebase elements in your NativeScript app: Authentication with a login and registration routine; Database for data storage and real-time updates; Remote Config to make changes to an app remotely; and Storage for saving photos. To do this, I decided to rewrite my Giftler app, originally written in Ionic. Before we get started, I encourage you to read through thedocumentation before starting in on your project, and make sure that a few prerequisites are in place:
Ensure thatNativeScript is installed on your local machine and that the CLI works as expected
Configure your preferred IDE for NativeScript and Angular development. You're going to need TypeScript, so ensure that your transpiling process is working. There are excellent NativeScript plugins available forVisual Studio, Visual Studio Code, andJetbrains-compatible IDEs, among others. Visual Studio Code in particular has handysnippets that speed up development
Log in to your Firebase account and find your console
Create a new project in the Firebase console. I named mine 'Giftler'. Also create an iOS and Android app in the Firebase console. As part of this process you'll download both a GoogleServices-Info.plist and google-services.json file. Make sure you note where you place those files, and you'll need them in a minute.
Install the dependencies
I've built Giftler as an example of an authenticated NativeScript app where users can list the gifts that they would like to receive for the holidays, including photos and text descriptions. For the time being, this app does the following on iOS and Android:
allows login and logout, registration, and a 'forgot password' routine
lets users enter gift items into a list
lets users delete items from a list
lets users edit items in the list individually by adding descriptions and photos
provides messaging from the Remote Config service in Firebase that can be quickly changed in the backend
Now, fork the Giftler source code, which is a complete and functional app. Once your app is cloned, replace the app's current Firebase-oriented files that you downloaded when you created your app:
In the /app/App_Resources/Android folder, put the google.services.json file that you downloaded from Firebase.
Likewise, in /app/App_Resources/iOS folder, put the GoogleService-Info.plist file also downloaded from Firebase.
These files are necessary to initialize Firebase in your app and connect it to the relevant external services. Now, let's take a look at the package.json at the root of this app. It contains the plugins that you'll use in this app. I want to draw your attention to the NativeScript-oriented plugins:
The NativeScript-Angular plugin is NativeScript's integration of Angular. The Camera plugin makes managing the camera a bit easier. IQKeyboardManager is an iOS-specific plugin that handles the finicky keyboard on iOS. The Theme plugin is a great way to add default styles to your app without having to skin the app entirely yourself. And finally, the most important plugin in this app is the Firebase plugin. With the dependencies in place and the plugins ready to install, you can build your app to create your platforms folder with iOS and Android-specific code and initialize the Firebase plugin along with the rest of the npm-based plugins. Using the NativeScript CLI, navigate to the root of your cloned app and type tns run ios or tns run android. This will start the plugin building routines and, in particular, you'll see the various parts of the Firebase plugin start to install. The install script that runs will prompt you to install several elements to integrate to the various Firebase services. We're going to select everything except Messaging and social authentication for the moment. A great feature is that a firebase.nativescript.json file is installed at the root of the app, so if you need to install a new part of the plugin later, you can edit that file and reinstall the plugin.
At this point, if you run tns livesync ios --watch or tns livesync android --watch to see the app running on an emulator and watching for changes, you would see a the app running and ready to accept your new login. Before you initialize a login, however, ensure that Firebase handles Email/Password type logins by enabling this feature in the Firebase console in the Authentication tab:
Let's take a look under the covers a bit to see what's happening behind the scenes. Before you can log in to Firebase, you need to initialize the Firebase services that you installed. In app/main.ts, there are a few interesting bits.
// this import should be first in order to load some required settings (like globals and reflect-metadata) import { platformNativeScriptDynamic } from "nativescript-angular/platform"; import { AppModule } from "./app.module"; import { BackendService } from "./services/backend.service";
firebase.init({ //persist should be set to false as otherwise numbers aren't returned during livesync persist: false, storageBucket: 'gs://giftler-f48c4.appspot.com', onAuthStateChanged: (data: any) => { console.log(JSON.stringify(data)) if (data.loggedIn) { BackendService.token = data.user.uid; } else { BackendService.token = ""; } } }).then( function (instance) { console.log("firebase.init done"); }, function (error) { console.log("firebase.init error: " + error); } ); platformNativeScriptDynamic().bootstrapModule(AppModule);
First, we import firebase from the plugin, and then we call .init(). Edit the storageBucket property to reflect the value in the Storage tab of your Firebase console:
Now your app is customized to your own Firebase account and you should be able to register a new user and login in the app. You can edit the user.email and password variables in app/login/login.component.ts file to change the default login credentials from user@nativescript.org to your own login and password if you like.
The iOS and Android login screens
Note: you should be able to emulate your app right away on iOS, using the Xcode simulator. On Android, make sure that you select an Android SDK emulator image that supports Google Services, such as "Google APIs Intel x86 Atom System Image." It can be hard to get the versions lined up perfectly, so pay close attention to the Firebase dependencies and version info.
Code Structure and Authentication
Angular 2 design patterns require that you modularize your code, so we will oblige by using the following code structure: —login
login.component.ts
login.html
login.module.ts
login.routes.ts
—list … —list-detail … —models
gift.model.ts
user.model.ts
index.ts
—services
backend.service.ts
firebase.service.ts
utils.service.ts
index.ts
app.component.ts app.css app.module.ts app.routes.ts auth-guard.service.ts main.ts I want to draw your attention to the way Firebase authentication works with the Angular 2 auth-guard.service. When Firebase is initialized in your app in app/main.ts as we saw above, the onAuthStateChanged function is called:
When the app starts, check the console for the stringified data being returned by Firebase. If this user is flagged as being loggedIn, we will simply set a token which is the userId sent back by Firebase. We'll use the NativeScript application settings module, which functions like localStorage, to keep this userId available and associate it to the data that we create. This token and the authentication tests that use it, managed in the app/services/backend.service.tsfile, are made available to the app/auth-guard.service.ts file. The auth-guard file offers a neat way to manage logged-in and logged-out app state. The AuthGuard class implements the CanActivate interface from the Angular Router module.
Essentially, if the token is set during the above login routine, and the BackendService.isLoggedIn function returns true, then the app is allowed to navigate to the default route which is our wish list; otherwise, the user is sent back to login:
Now that you have initialized your Firebase-powered NativeScript app, let's learn how to populate it with data and use Firebase's amazing realtime power to watch for the database to be updated.
Making your list, checking it twice
Starting in app/list/list.html, which is the basis of the wish list, you'll see a textfield and a blank list. Go ahead, tell Santa what you want! The items are sent to the database and added to your list in realtime. Let's see how this is done. First, note that in app/list/list.component.ts, we set up an observable to hold the list of gifts: public gifts$: Observable; then, we populate that list from the database when the component is initialized:
It's in the firebaseService file that things get interesting. Note the way that this function adds a listener and returns an rxjs observable, checking for changes on the Gifts collection in the Firebase database:
getMyWishList(): Observable { return new Observable((observer: any) => { let path = 'Gifts'; let onValueEvent = (snapshot: any) => { this.ngZone.run(() => { let results = this.handleSnapshot(snapshot.value); console.log(JSON.stringify(results)) observer.next(results); }); }; firebase.addValueEventListener(onValueEvent, `/${path}`); }).share(); }
The results of this query are handled in a handleSnapshot function below, which filters the data by user, populating an _allItems array:
handleSnapshot(data: any) { //empty array, then refill and filter this._allItems = []; if (data) { for (let id in data) { let result = (Object).assign({id: id}, data[id]); if(BackendService.token === result.UID){ this._allItems.push(result); } } this.publishUpdates(); } return this._allItems; }
And finally, publishUpdates is called, which sorts the data by date so that newer items are shown first:
publishUpdates() { // here, we sort must emit a *new* value (immutability!) this._allItems.sort(function(a, b){ if(a.date < b.date) return -1; if(a.date > b.date) return 1; return 0; }) this.items.next([...this._allItems]); }
Once the data has populated your $gifts observable, you can edit and delete elements of it and it will be handled by the listener and the front end updated accordingly. Note that the onValueEvent function of getMyWishList method includes the use ofngZone which ensures that, although data updates occur asynchronously, the UI is updated accordingly. A good overview of ngZone in NativeScript apps can be foundhere.
Remotely Configured Messages from Beyond
Another cool piece of Firebase's service includes "Remote Config", a way to provide app updates from the Firebase backend. You can use Remote Config to toggle features on and off in your app, make UI changes, or send messages from Santa, which is what we're going to do! In app/list/list.html, you'll find a message box: <Label class="gold card" textWrap="true" [text]="message$ | async"></Label> The message$ observable is built in much the same way as the data list; changes are picked up in this case each time the app is freshly initialized:
And the magic occurs in the service layer (app/services/firebase.service.ts ):
getMyMessage(): Observable{ return new Observable((observer:any) => { firebase.getRemoteConfig({ developerMode: false, cacheExpirationSeconds: 300, properties: [{ key: "message", default: "Happy Holidays!" }] }).then( function (result) { console.log("Fetched at " + result.lastFetch + (result.throttled ? " (throttled)" : "")); for (let entry in result.properties) { observer.next(result.properties[entry]); } } ); }).share(); }
Publish new messages as often as you like!
Note: tinkering repeatedly with Remote Config may cause throttling of your Firebase instance, so develop with care
Take a picture!
One of the more interesting parts of this project, I think, is the ability to take a picture of your present of choice and store it in Firebase Storage. I leveraged the Camera plugin, as mentioned above, which makes managing the hardware a little easier. To start, ensure that your app has access to the device camera by getting permissions set in the ngOnInit() method in app/list-detail/list-detail.component.ts:
ngOnInit() { camera.requestPermissions(); ... }
A chain of events begins when the user clicks the 'Photo' button in the detail screen. First,
takePhoto() { let options = { width: 300, height: 300, keepAspectRatio: true, saveToGallery: true }; camera.takePicture(options) .then(imageAsset => { imageSource.fromAsset(imageAsset).then(res => { this.image = res; //save the source image to a file, then send that file path to firebase this.saveToFile(this.image); }) }).catch(function (err) { console.log("Error -> " + err.message); }); }
The camera takes a picture, and then that photo is stored as an imageAsset and displayed on the screen. The image is then named with a date stamp and saved to a file locally. That path is reserved for future use.
Once the 'Save' button is pressed, this image, via its local path, is sent to Firebase and saved in the storage module. Its full path in Firebase is returned to the app and stored in the /Gifts database collection:
editGift(id: string){ if(this.image){ //upload the file, then save all this.firebaseService.uploadFile(this.imagePath).then((uploadedFile: any) => { this.uploadedImageName = uploadedFile.name; //get downloadURL and store it as a full path; this.firebaseService.getDownloadUrl(this.uploadedImageName).then((downloadUrl: string) => { this.firebaseService.editGift(id,this.description,downloadUrl).then((result:any) => { alert(result) }, (error: any) => { alert(error); }); }) }, (error: any) => { alert('File upload error: ' + error); }); } else { //just edit the description this.firebaseService.editDescription(id,this.description).then((result:any) => { alert(result) }, (error: any) => { alert(error); }); } }
This chain of events seems complicated, but it boils down to a few lines in the Firebase service file:
The end result is a nice way to capture both photos and descriptions of the gifts for your wish list. No more excuses that Santa didn't know exactly WHICH Kylie Eyeliner to buy. By combining the power of NativeScript and Angular, you can create a native iOS and Android app in a matter of minutes. By adding Firebase you have a powerful way of storing your app's users, images and data, and a way of updating that data in real-time across devices. Cool, huh? It looks like this:
We are well on our way to create a solid wishlist management app! It remains to figure out the best way to inform Santa of our wishes - a Mailgun email integration or using push notifications would be the obvious next route. In the meantime, best wishes for a wonderful holiday season, and I hope you have a great time creating awesome NativeScript apps using Firebase! Want to learn more about NativeScript? Visit http://www.nativescript.org. If you need help, join the NativeScript Slack channel here.
Our goal with Firebase is to help developers build better apps and grow them into successful businesses. Six months ago at Google I/O, we took our well-loved backend-as-a-service (BaaS) and expanded it to 15 features to make it Google’s unified app development platform, available across iOS, Android, and the web.
We launched many new features at Google I/O, but our work didn’t stop there. Since then, we’ve learned a lot from you (750,000+ projects created on Firebase to date!) about how you’re using our platform and how we can improve it. Thanks to your feedback, today we’re launching a number of enhancements to Crash Reporting, Analytics, support for game developers and more. For more information on our announcements, tune in to the livestream video from Firebase Dev Summit in Berlin. They’re also listed here:
Improve App Quality to Deliver Better User Experiences
Firebase Crash Reporting comes out of Beta and adds a new feature that helps you diagnose and reproduce app crashes.
Often the hardest part about fixing an issue is reproducing it, so we’ve added rich context to each crash to make the process simple. Firebase Crash Reporting now shows Firebase Analytics event data in the logs for each crash. This gives you clarity into the state of your app leading up to an error. Things like which screens of your app were visited are automatically logged with no instrumentation code required. Crash logs will also display any custom events and parameters you explicitly log using Firebase Analytics. Firebase Crash Reporting works for both iOS and Android apps.
Glide, a popular live video messaging app, relies on Firebase Crash Reporting to ensure user quality and release agility. “No matter how much effort you put into testing, it will never be as thorough as millions of active users in different locations, experiencing a variety of network conditions and real life situations. Firebase allows us to rapidly gain trust in our new version during phased release, as well as accelerate the process of identifying core issues and providing quick solutions.” - Roi Ginat, Founder, Glide.
Firebase Test Lab for Android supports more devices and introduces a free tier.
We want to help you deliver high-quality experiences, so testing your app before it goes into the wild is incredibly important. Firebase Test Lab allows you to easily test your app on many physical and virtual devices in the cloud, without writing a single line of test code. Beginning today, developers on the Spark service tier (which is free!) can run five tests per day on physical devices and ten tests per day on virtual devices—with no credit card setup required. We’ve also heard that you want more device options, so we’ve added 11 new popular Android device models to Test Lab, available today.
Illustration of Firebase Crash Reporting
Make Faster Data Driven Decisions with Firebase Analytics
Firebase Analytics now offers live conversion collection, a new integration with Google “Data Studio”, and real-time exporting to BigQuery.
We know that your data is most actionable when you can see and process it as quickly as possible. Therefore, we’re announcing a number of features to help you maximize the potential of your analytics events:
DebugView for validation of your analytics instrumentation is currently offered in limited availability and will be made more broadly available later this year
We were happy to give you a sneak preview at the Firebase Dev Summit of a new feature we are now building, StreamView, which will offer a live, dynamic view of your analytics data as it streams in.
To further enhance your targeting options, we’ve improved the connection between Firebase Analytics and other Firebase features, such as Dynamic Links and Remote Config. For example, you can now use Dynamic Links on your Facebook business page, and we can identify Facebook as a source in Firebase Analytics reporting. Also, you can now target Remote Config changes by User Properties, in addition to Audiences.
Build Better Games using Firebase
Firebase now has a Unity plugin!
Game developers are building great apps, and we want Firebase to work for you, too. We’ve built an entirely new plugin for Unity that supports Analytics, the Realtime Database, Authentication, Dynamic Links, Remote Config, Notifications and more. We've also expanded our C++ SDK with Realtime Database support.
Integrate Firebase Even Easier with Open-Sourced UI Library
FirebaseUI is a library that provides common UI elements when building apps, and it’s a quick way to integrate with Firebase. FirebaseUI 1.0 includes a drop-in UI flow for Firebase Authentication, with common identity providers such as Google, Facebook, and Twitter. FirebaseUI 1.0 also added features such as client-side joins and intersections for the Realtime Database, plus integrations with Glide and SDWebImage that make downloading and displaying images from Firebase Storage a cinch. Follow our progress or contribute to our Android, iOS, and Web components on Github.
Learn More via Udacity and Join the Firebase Community
We want to provide the best tool for developers, but it’s also important that we give resources and training to help you get more out of the platform. As such, we’ve created a new Udacity course: Firebase in a Weekend! It’s an instructor-led video course to help all developers get up and running with Firebase on iOS and Android, in two days.
Finally, to help wrap your head around all our announcements, we’ve created a new demo app. This is an easy way to see how Analytics, Crash Reporting, Test Lab, Notifications, and Remote Config work in a live environment, without having to write a line of code.
Helping developers build better apps and successful businesses is at the core of Firebase. We work hard on it every day. We love hearing your feedback and ideas for new features and improvements—and we hope you can see from the length of this post that we take them to heart! Follow us on Twitter, join our Slack channel, participate in our Google Group, and let us know what you think. We’re excited to see what you’ll build next!
One of my favorite features of Firebase Remote Config is its ability to deliver different content to different groups of users. For instance, you can change the look and feel of your storefront for people who have spent a lot of money in your app. Or you could emphasize one part of your fitness app for runners and another for weightlifters.
Ever since Remote Config first launched, you could accomplish some pretty sophisticated user targeting by delivering different content to people who were in different Firebase Analytics audiences.
But more recently, Remote Config added the ability for you to send different sets of data to people with different user properties, which has made this feature even more useful.
"Wait a second," you might be saying. "I can already target users with audiences, which allow more sophisticated targeting than just a user property. Why is this any better?"
And it's true; audiences give you some very powerful and very specific user targeting by enabling you to create groups of users who can be defined by a number of different events and user properties. For instance, you could create an audience of "Left-handed Canadians who have completed level 5 in my game."1
But audiences have two limitations that can make them more difficult to use within Remote Config:
First off, you're limited to 50 audiences, and they're shared among people who might be using these same audiences for other targeting features within Firebase, such as running Analytics reports, or building remarketing campaigns via Google AdWords. This makes it more difficult to create several smaller ad hoc user groups, or to edit existing audiences that other people in your organization might be using.
Second, with the way audiences currently work, once a user joins an audience, they can never leave. To your average marketer who uses audiences for remarketing campaigns, this might be exactly what they're expecting, but for Remote Config purposes, this can sometimes be problematic.
Imagine you wanted to create a "Newbies" audience of people who have started your game but not yet completed level 10. If you tried creating an audience out of this group, everybody who started your game would be placed into this audience. But then they would remain in this audience even if they reach level 15 or 20, essentially turning this into an "All players" audience.
And that's why, when I'm targeting users in Remote Config, I prefer to use User Properties as a way to personalize my content. They allow me to create lots of smaller one-off targeting groups, and let me be little more dynamic than with traditional audiences.
For instance, let's say you have a fitness app and wanted to deliver a different front page image based on the user's favorite fitness activity. If you have that favorite exercise stored as a user property, you can easily set that up by creating a new condition based on that property.
Then you can show a different front page image based on each one of those conditions.
In this way, you could easily create a half dozen different conditions and not worry about "using up" those Firebase Analytics audiences.2
Or imagine you have a game and you want to change aspects your game's behavior based on what level the user is at. You can do that by storing that level as a user property and then creating a number of different conditions based on these tiers. For instance, I can create a "intermediate" tier of players who are in between levels 4 and 10…
...and give a different daily bonus to those players.
As users progress in level, Remote Config will automatically start delivering them different values based on their level as their user property places them in different tiers. And I don't need to create new audiences for each one.
It's also simple to change these groupings later. If, in the future, I decide that my intermediate tier should really start at level 6, I can make that change within the Firebase control panel, and those changes are pushed out immediately to Remote Config.
Heck I could even add in a fourth tier if I suddenly decide I need to change my game's behavior for the the extra special players.
By default, user properties are stored as strings, which means you can run string comparisons like "exactly matches" or "contains" against them. If you stored your user's top 3 fitness activities as a pipe separated string (e.g. yoga|interval_training|running) you could create an "All runners" condition by targeting anybody whose fitness activities contained the string "running."
But you can also run numeric comparisons against them, as we did in the playerLevel example above. Remote Config will translate strings to numbers as you might expect; "42" evaluates to 42, "3.14159" evaluates to 3.14159, and so on. Numeric comparisons with user property strings that don't translate to integers or floats (e.g. "Level_42") will always fail, however.
Being able to target user properties is a relatively new feature, so if you haven't played with it yet, I encourage you to give it a try. Head on over to the Remote Config panel and try making a minor change based on a user property you're already storing. Once you have that working, stop and think what parts of your app could really benefit from personalization, and considering adding another user property or two to support that.
And if you end up building something cool, let us know! We'd be excited to hear about it.
1Assuming you targeted "handedness" as a user property, that is.
2To be fair, there is also a limit to the number of Remote Config conditions you can create, but it's 100, which gives you a lot more room to experiment.
Turning a great app into a successful business requires more than simply releasing your app and calling it a day. You need to quickly adapt to your user’s feedback, test out new features and deliver content that your users care about most.
This is what Firebase Remote Config is made for. By allowing you to change the look and feel of your app from the cloud, Firebase Remote Config enables you to stay responsive to your user’s needs. Firebase Remote Config also enables you to deliver different content to different users, so you can run experiments, gradually roll out features, and even deliver customized content based on how your users interact within your app.
Let's look at what you can accomplish when your wire up your app to work with Remote Config.
Update your app without updating your app
We've all had the experience of shipping an app and discovering soon afterwards that it was less than perfect. Maybe you had incorrect or confusing text that your users don't like. Maybe you made a level in your game too difficult, and players aren't able to progress past it. Or maybe it was something as simple as adding an animation that takes too long to complete.
Traditionally, you'd need to fix these kinds of mistakes by updating those values in your app's code, building and publishing a new version of your app, and then waiting for all your users to download the new version.
But if you've wired up your app for Remote Config in the Firebase platform, you can quickly and easily change those values directly in the cloud. Remote Config can download those new values the next time your user starts your app and address your users' needs, all without having to publish a new version of your app.
Deliver the Right Content to the Right People
Firebase Remote Config allows you to deliver different configurations to targeted groups of users by making use of conditions, which use targeting rules to deliver specific values for different users. For example, you can send down custom Remote Config data to your users in different countries. Or, you can send down different data sets separately to iOS and Android devices.
You can can also deliver different values based on audiences you've defined in Firebase Analytics for some more sophisticated targeting. So if you want to change the look of your in-app store just for players who have visited your store in the past, but haven't purchased anything yet, that's something you can do by creating Remote Config values just for that audience.
Run A/B Tests and Gradual Rollouts
Remote Config conditions also allow you to deliver different values to random sets of users. You can take advantage of this feature to run A/B tests or to gradually rollout new features.
If you are launching a new feature in your app but aren't sure if your audience is going to love it, you can hide it behind a flag in your code. Then, you can change the value of that flag using Remote Config to turn the feature on or off. By defining a "My New Feature Experiment" condition that is active for, say, 10% of the population, you can turn on this new feature for a small subset of your users, and make sure it's a great experience before you turn it on for the rest of your population.
Similarly, you can run A/B tests by supplying different values to different population groups. Want to see if people are more likely to complete a purchase if your in-app purchase button says, "Buy now" or "Checkout"? That's the kind of experiment you can easily run using A/B tests.
If you want to track the results of these A/B tests, you can do that today by setting a user property in Firebase Analytics based on your experiment. Then, you can filter any of your Firebase Analytics reports (like whether or not the user started the purchase process) by this property. Watch this space for news on upcoming improvements to A/B testing.
A Fabulous Improvement in Retention
Many of our early partners have already been using Firebase Remote config to test out changes within their app.
Fabulous, an app from Duke University's designed to help people adopt better lifestyle habits, wanted to experiment with their getting started flow to see which methods were most effective for getting their users up and running in their app. They not only A/B tested changes like images, text, and button labels, but they also A/B tested the entire onboarding process by using Remote Config to determine what dialogs people saw and in what order.
Thanks to their experiments with Remote Config, Fabulous was able to increase the number of people who completed their onboarding flow from 42% to 64%, and their one-day retention rate by 27%.
Research has shown that an average app loses the majority of their users in the first 3 days, so making these kinds of improvements to your app's onboarding process -- and confirming their effectiveness by conducting A/B tests -- can be crucial to ensuring the long-term success of your app.
Is Your App Wired Up?
When you use remote config Remote Config, you can supply all of your default values locally on the device, then only send down new values from the cloud where they differ from your defaults. This gives you the flexibility to wire up every value in your app to be potentially configurable through Remote Config, while keeping your network calls lightweight because you're only sending down changes. So feel free to take all your hard-coded strings, constants, and that AppConstants file you've got sitting around (it's okay, we all have one), and wire 'em up for Remote Config!
Firebase Remote Config is part of the Firebase platform and is available for free on both iOS and Android. If you want to find out more, please see our documentation and be sure to explore all the features of the Firebase SDK.
Posted by Todd Kerpelman, Firebase Developer Advocate and Safa Alai, Remote Config Product Manager
Eighteen months ago, Firebase joined Google. Since then, our backend-as-a-service (BaaS) that handles the heavy lifting of building an app has grown from a passionate community of 110,000 developers to over 450,000.
Our current features -- Realtime Database, User Authentication, and Hosting -- make app development easier, but there’s more we can do, so today, we’re announcing a major expansion!
Firebase is expanding to become a unified app platform for Android, iOS and mobile web development. We’re adding new tools to help you develop faster, improve app quality, acquire and engage users, and monetize apps. On top of this, we’re launching a brand new analytics product that ties everything together, all while staying true to the guiding principles we’ve had from the beginning:
Developer experience matters. Ease-of-use, good documentation, and intuitive APIs make developers happy.
Work across platforms. We’ll support you whether you’re building for iOS, Web, or Android.
Integrate where possible. Firebase has one SDK, one console, and one place to go for documentation and support. You can mix-and-match any of our features and, where it makes sense, data flows between them to help you do more, faster.
Introducing Firebase Analytics
Firebase Analytics is our brand new, free and unlimited analytics solution for mobile apps. It benefits from Google’s experience with Google Analytics, and features some new capabilities for apps:
Firebase Analytics is user and event-centric and gives you insight into what your users are doing in your app. You can also see how your paid advertising campaigns are performing with cross-network attribution, which tells you where your users are coming from. You can see all of this from a single dashboard.
Firebase Analytics is also integrated with other Firebase offerings to provide a single source of truth for in-app activity and through a feature called Audiences. Audiences let you define groups of users with common attributes. Once defined, these groups can be accessed from other Firebase features -- to illustrate, we’ll reference Audiences throughout this post.
Develop Faster with Messaging, Storage, Config
To help you build better apps, our suite of backend services is expanding.
Google Cloud Messaging, the most popular cloud-to-device push messaging service in the world, is integrating with Firebase and changing its name to Firebase Cloud Messaging (FCM). Available for free and for unlimited usage, FCM supports messaging on iOS, Android, and the Web, and is heavily optimized for reliability and battery-efficiency. It’s built for scale and already sends 170 billion messages per day to two billion devices.
One of our most requested features is the ability to store images, videos, and other large files. We’re launching Firebase Storage so developers can easily and securely upload and download such files. Firebase Storage is powered by Google Cloud Storage, giving it massive scalability and allowing stored files to be easily accessed by Google Cloud projects. The Firebase Storage client SDKs have advanced logic to gracefully handle poor network conditions.
Firebase Remote Config gives you instantly-updatable variables that you can use to tune and customize your app on the fly to deliver the best experience to your users. You can enable or disable features or change the look and feel without having to publish a new version. You can also target configurations to specific Firebase Analytics Audiences so that each of your users has an experience that’s tailored for them.
In addition, we’re continuing to invest heavily in our existing backend products, Firebase Realtime Database, Firebase Hosting, and Firebase Authentication. Authentication has seen the biggest updates, with brand new SDKs, and an upgraded backend infrastructure. This provides added security, reliability, and scale using the same technologies that power Google’s own accounts. We’ve also added new Authentication features including email verification and account linking. For Hosting, custom domain support is now free for all developers, and the Database has a completely rebuilt UI. We’re working hard on other great Realtime Database features, stay tuned for those.
Introducing Test Lab and Crash Reporting
We’re adding two new offerings to Firebase to help you deliver higher quality apps.
When your app crashes, it’s bad for your users and it hurts your business. Firebase Crash Reporting gives you prioritized, actionable reports to help you diagnose and fix problems in your iOS or Android app after it has shipped. We’ve also connected Crash Reporting to Audiences in Firebase Analytics, so you can tell if users on a particular device, in a specific geography, or in any other custom segment are experiencing elevated crash rates.
Cloud Test Lab, announced last year at Google I/O, is now Firebase Test Lab for Android. Test Lab helps you find problems in your app before your users do. It allows for both automatic and customized testing of your app on real devices hosted in Google data centers.
Grow Your App with Notifications, Dynamic Links, and More
After you’ve launched your app, we can help you grow and re-engage users with five powerful growth features.
Firebase Notifications is a new UI built on top of the Firebase Cloud Messaging APIs that lets you easily deliver notifications to your users without writing a line of code. Using the Notifications console you can re-engage users, run marketing campaigns, and target messages to Audiences in Firebase Analytics.
Firebase Dynamic Links make URLs more powerful in two ways. First, they provide “durability” -- links persist across the app install process so users are taken to the right place when they first open your app. This “warm welcome” increases engagement and retention. Second, they allow for dynamically changing the destination of a link based on run-time conditions, such as the type of browser or device. Use them in web, email, social media, and physical promotions to gain insight into your growth channels.
Firebase Invites turns your customers into advocates. Your users can easily share referral codes or their favorite content via SMS or email to their network, so you can increase your app's reach and retention.
Firebase App Indexing, formerly Google App Indexing, brings new and existing users to your app from the billions of Google searches. If your app is already installed, users can launch it directly from the search results. New users are presented with a link to install your app.
AdWords, Google’s advertising platform for user acquisition and engagement, is now integrated with Firebase. Firebase can track your AdWords app installs and report lifetime value to the Firebase Analytics dashboard. Firebase Audiences can be used in AdWords to re-engage specific groups of users. In-app events can be defined as conversions in AdWords, to automatically optimize your ads, including universal app campaigns.
Monetize Your App With AdMob
To help you generate revenue from your app and build a sustainable business, we’ve integrated Firebase with AdMob, an advertising platform used by more than 1 million apps. We’ve made it easier to get started with AdMob when you integrate the Firebase SDK into your app. Using AdMob, you can choose from the latest ad formats, including native ads, which help provide a great user experience.
Introducing a New Console, Documentation, and SDK
Along with new feature launches, we’re moving our website and documentation to a new home: firebase.google.com.
We’re also launching a brand new console to manage your app. It is completely redesigned and rebuilt for improved ease of use, and we’ve deeply integrated it with other Google offerings, like Google Cloud and Google Play.
Firebase now uses the same underlying account system as Google Cloud Platform, which means you can use Cloud products with your Firebase app. For example, a feature of Firebase Analytics is the ability to export your raw analytics data to BigQuery for advanced querying. We’ll continue to weave together Cloud and Firebase, giving you the functionality of a full public cloud as you grow.
You can also link your Firebase account to Google Play from our new console. This allows data, like in-app purchases, to flow to Firebase Analytics, and ANRs (application not responding) to flow to Firebase Crash Reporting, giving you one place to check the status of your app.
Finally, we’re announcing the beta launch of a new C++ SDK. You can find the documentation and getting started guides here.
Announcing New Pricing Plans
We’re excited to announce that most of these new products, including Analytics, Crash Reporting, Remote Config, and Dynamic Links, are free for unlimited usage.
For our four paid products: Test Lab, Storage, Realtime Database, and Hosting, we’re announcing simpler pricing. We now offer:
A free plan with generous limits
A fixed-rate plan for early-stage startups who need a predictable monthly price
A metered pay-as-you-go plan that scales with the largest apps
Some Things Stay the Same
Many things are changing, but Firebase’s core principles remain the same. We care deeply about providing a great developer experience through easy-to-use APIs, intuitive interfaces, comprehensive documentation, and tight integrations. We’re committed to cross-platform development for iOS, Android, and the Web, and when you run into trouble, we’ll provide support to help you succeed.
If you were using a Firebase feature before today -- like the Realtime Database, GCM, or App Indexing -- there’s no impact on your app. We’ll continue to support you, though we recommend upgrading to the latest SDK to access our new features.
More to Come
As far as we’ve come, this is still early days. We’ll continue to refine and add to Firebase. For example, the JavaScript SDK does not yet support all the new features. We’re working quickly to close gaps, and we’d love to hear your feedback so we can improve. You can help by requesting a feature.
Get Started!
All the new features are ready-to-go, and already in use by apps like Shazam, SkyScanner, PicCollage, and more. Get started today by signing up, visiting our new site, or reading the documentation to learn more.
We can’t wait to hear what you think!
Posted by James Tamplin & Francis Ma, Firebase Product Leads
