Since we launched the Firebase Admin SDKs for Python and Go last year, many developers have asked for an SDK for .NET. Today, we are happy to announce the general availability of the Firebase Admin SDK for .NET.
Firebase Admin SDKs enable application developers like you to access Firebase from back-end environments. They complement the Firebase client SDKs, which let you access Firebase from web and mobile apps. The Admin SDK for .NET is the fifth SDK variant to join our growing collection of Admin SDK offerings. The SDK currently supports .NET Framework 4.5+ and .NET Standard 1.5+.
The .NET Admin SDK can be initialized with several different types of authorization credentials. The following code snippet shows how to initialize the SDK using a service account credential obtained from the Firebase console:
using FirebaseAdmin; using Google.Apis.Auth.OAuth2; FirebaseApp.Create(new AppOptions() { Credential = GoogleCredential.FromFile("path/to/serviceAccount.json"), });
If you are running your code on Google Cloud Platform, such as Google App Engine or Google Compute Engine, the SDK can auto-discover application default credentials from the environment. In this case you do not have to specify any credentials at initialization:
using FirebaseAdmin; FirebaseApp.Create();
The initial release of the .NET Admin SDK comes with APIs for creating custom tokens and verifying ID tokens for Firebase Authentication. Custom token creation allows you to integrate your own user store or authentication mechanism with Firebase:
using System.Collections.Generic; using FirebaseAdmin.Auth; // Add some custom claims to the token, which will be available on the // ID token after successful sign in. var claims = new Dictionary<string, object>() { { "premium", true }, { "package", "gold" }, }; using FirebaseAdmin.Auth; var customToken = await FirebaseAuth.DefaultInstance.CreateCustomTokenAsync( "some-uid", claims);
ID token verification lets you securely validate the identity of the currently signed in user on your server. You can use this API to build authorized back-end services that integrate with Firebase:
var decoded = await FirebaseAuth.DefaultInstance.VerifyIdTokenAsync(idToken); var uid = decoded.Uid;
To learn more about using the Firebase Admin SDK for .NET, see the Admin SDK setup guide.
Admin SDK for .NET is fully open source. We welcome and encourage our developer community to help us develop this SDK further. Please file bugs and feature requests as GitHub issues, and also feel free to send us pull requests implementing new features and APIs. You can refer to our other Admin SDK implementations for ideas and inspiration.
We look forward to working with you on the Admin SDK for .NET. Happy coding with Firebase!
Firebase Remote Config can be a powerful and easy way to make changes in your app, discover what resonates with your audience, and then quickly revert those changes if needed. Previously, if you wanted to remember what values you used in the past and how they changed over time, you had to keep track of them manually. In one-person teams, this is a hassle. But for large teams, where lots of different developers could be changing the project's Remote Config values at once, this is a major headache.
Today, we are happy to announce that we're adding change history to Remote Config. Finding out who made changes to what values, and reverting back to an earlier set of values is now as simple as a click of a button!
Change History in Remote Config
With change history in Remote Config, Firebase will save 300 versions of a project's Remote Config values for up to 90 days. You'll also be able to see how parameters and conditions have changed over time, who made those changes, when they were made, and how were they made (via the Firebase console or the REST API). And if you ever want to roll back to a previous version, all you have to do is click the rollback button.
Change history is available both on the Firebase Console and via the Remote Config REST API.
Just-eat.com, a European-based food delivery company and a long time Remote Config user, were delighted with change history for Remote Config.
Alberto De Bortoli, Principal iOS Engineer from Just-eat.com "Thanks to change history, no change going to production goes unnoticed anymore. The team now has more confidence and there is no room for ambiguity when it comes to updating Remote Config. We can inspect who across the company made a particular change and rollback to a previous configuration with confidence should there be a need to."
Let's assume Developer Denise wanted to see the previous values of new_search param in her project's Remote Config.
She opens the change history view of her project and sees that her project is currently at Version 37 & that it was created by Mayank Jain. She clicks on the previous version of her project's Remote Config (version 36).
In the change history view, she can see that in the previous version 36, the value of new_search param was built with a 10% users condition - and that Mayank Jain (from her team) had set the value of new_search param to true in version 37 (current live version). Denise can also see that Mayank made that incremental update from the Firebase Console.
Denise wants to roll back Remote Config to version 36, so she clicks the "Rollback to version 36" button.
Remote Config creates a new version 38 which is based on the rollback to version 36.
new_search param in version 38 now has the same conditional value targeting 10% users as was the case in version 36.
Change history for Remote Config is also accessible through the Remote Config REST API.
Following is an excerpt from updates samples to list the last 5 versions using Node.js.
See the full Node.js, Java and Python examples on GitHub and the technical documentation about change history can be found here.
function listLastFiveVersions(accessToken) { const options = { hostname: 'firebaseremoteconfig.googleapis.com', path: '/v1/projects/' + PROJECT_ID + '/remoteConfig' + ':listVersions?pageSize=5', method: 'GET', headers: { 'Authorization': 'Bearer ' + accessToken, }, }; const request = https.request(options, function(resp) { if (resp.statusCode === 200) { console.log('Versions:'); resp.on('data', function(data) { console.log(data.toString()); }); } else { resp.on('data', function(err) { console.log(err.toString()); }); } }); request.on('error', function(err) { console.error('Request for template versions failed.'); console.error(err.toString()); }); request.end(); }
We hope you give change history in Remote Config a try, and as always, we are eager to hear your feedback, so we can make Firebase Remote Config the best way to remotely configure your app. If you're interested in sharing your thoughts, feedback, or opinions on Remote Config or want to see sneak previews of what we've got in the works, please join the Remote Config Discussion Group.
Happy developing!
Crashlytics currently processes more than 3 billion events per day for our developers and distills them into an opinionated and actionable set of issues in our dashboard. We've heard thousands of requests over the years to let you explore further into your crash data, and that's why today we're extremely excited to offer the ability to export your Firebase Crashlytics data into BigQuery for deeper analysis!
With just a few clicks from the Firebase Crashlytics dashboard you can enable daily exports of all raw crash data on a per-app or per-project basis. This includes your stack traces, logs, keys and any other crash data.
The Crashlytics dashboard currently retains data for 90 days. With BigQuery you own the retention and deletion policies, making it much simpler for your team to track year-over-year trends in stability data.
BigQuery also offers the ability to export your data in CSV, JSON, or Avro format. This should help to streamline any GDPR data takeout requests you may receive.
Up until now, exploring your crash reports by custom metadata like Experiment ID or an Analytics breadcrumb has been limited, making it tough to identify which variant in an experiment is least stable or which level in a game has the most crashes. Now, when you export your data to BigQuery, it's easy to run any deep analysis you want, and then visualize your report with Data Studio or any other business system you use.
As an example, say that you set up your Android game so that you log what level a crash occurs with:
Crashlytics.setInt("current_level", 3);
When you export your Crashlytics data to BigQuery, you can then see the distribution of crashes by level with this query:
#standardSQL SELECT COUNT(DISTINCT event_id) AS num_of_crashes, value FROM `projectId.crashlytics.package_name_ANDROID`, UNNEST(custom_keys) WHERE key = "current_level" GROUP BY key, value ORDER BY num_of_crashes DESC
If you are a current Fabric user, you can gain access to BigQuery export and all the other features of Firebase by linking your app in the Fabric dashboard. Check out this link for details and documentation.
We hope this improvement makes it even easier for you to dig into your crash reporting data and efficiently debug your app! As always, if you have any questions, you can find us on Twitter and on Stack Overflow. Happy debugging!
Do you manage multiple Firebase Hosting sites? Do these sites share a single resource like a Firestore or Realtime database? Do you wish you could manage these sites from one place instead of having to create multiple projects? Do you wish that Firebase Hosting could deploy only the new or modified files? Wish no more! Because it's all here!
Firebase Hosting now allows you to create multiple sites inside of one Firebase project. If your admin site and blog site consume data from a shared Firebase resource, they can now both live in a single project - saving you time and developer resources. You can manage these sites directly in the Firebase Console and deploy via the command line.
Firebase automatically provisions a firebaseapp domain for you, which is the same as your Firebase project name. We currently do not support subdomains on the firebaseapp.com domain, but you can still provision subdomains on your own by connecting a custom domain for your sites. To get started with multiple sites, you'll need to be on the Blaze plan. Once you're on the Blaze plan you'll be able to add multiple sites inside of the Firebase Console.
To help switch between different sites in a single project we introduced a new configuration setup in firebase.json. Make sure you update to the latest version of the Firebase CLI!
firebase.json
{ "hosting": [ { "target": "blog", "public": "blog/dist" }, { "target": "app", "public": "app/dist" } ] }
The "hosting" config can now take in an array of site configurations. A single object still works if you still have just one site. Each configuration has a "target". The CLI uses this target to know what "public" folder to use for deploying assets. Speaking of the CLI! We have a new command for you.
"hosting"
"target"
"public"
To manage switching between multiple sites in one project, we're going to use the target:apply command. This command is a bit like the firebase use --add command except instead of linking the project to the alias, it establishes a link between the site and the target. The applied target can then be used with the firebase deploy and firebase serve commands.
target:apply
firebase use --add
firebase deploy
firebase serve
The firebase use command is helpful for deploying to multiple projects. This is common for those who have a "staging" project versus a "production" project. For managing one site across different environments, we still recommend multiple projects for promoting best practices of each environment having its own set of Firebase resources.
firebase use
However, managing multiple sites is a different problem. The CLI now has to know about multiple sites instead of just one. The CLI must know:
This why we introduced target:apply for Hosting.
firebase target:apply hosting target-name site-name
Let's break down this command.
firebase
hosting
target-name
"blog"
"app"
site-name
Let's say you wanted to deploy your blog using the example firebase.json above:
firebase target:apply hosting blog my-cool-blog firebase deploy --only hosting:blog
In this command, we first identified the target-name of "blog", then associated it with the targeted site "my-cool-blog", and finally deployed to that target. If you don't specify a target in your firebase deploy or firebase serve commands, then all your targets will be deployed, or served locally on different ports, respectively. Note that you only have to define your targets once per project.
If you updated the Firebase CLI recently, you might have noticed that your uploads got a bit faster. You may have also noticed a new .firebase folder in your project. That's because we rolled up a new deployment system that we call Delta Uploads.
.firebase
This new system only processes new, modified, or deleted files. You know, the delta. This means any files that are unchanged aren't uploaded when you run firebase deploy. You may not notice a big improvement in performance if your site is only a few files. However, it will make a huge difference for sites with a large amount of existing unmodified assets.
Check out the official documentation and make sure to update your CLI! Both multi-site and delta uploads features require the latest version of the Firebase CLI. Make sure you're either above or at version 4.2.0 to use these features. Happy deploying!
4.2.0
Notifications, which are messages delivered to a mobile device's home screen, are a great way to bring latent users back into your app. But how do you communicate with users once they're back inside your app? How do you ensure they're interacting with your app in the intended way instead of fumbling between screens without taking meaningful action? How do you guide them through your app experience?
To help you solve those questions, today we're launching Firebase In-App Messaging to help you guide app users who are actively using your app by sending them targeted and contextual messages. Now, you'll be able to communicate with your most valuable users - the ones already interacting with your app - and deepen engagement with them by surfacing relevant information, offers, and tips as they use your app in real-time!
The main purpose of messages sent with In-App Messaging is to "nudge" active users toward key in-app actions (like subscribing, watching a video, completing a level, or buying an item). In-app messages are a guiding light within the app designed to spur conversions, increase session time, and encourage app exploration. In-App Messaging is an essential complement to notifications sent via Firebase Cloud Messaging.
In-app messages appear inside your app, so they should feel like a natural part of your mobile experience. With In-App Messaging, you have the flexibility and control to set up in-app messages in a variety of formats (banners, modal, and image) and customize their look and feel. You can change the color scheme to match your brand, and add visual elements like images. You can also tailor the call-to-action button to match your app's user journeys. And since messages trigger based on Analytics events, if you instrument meaningful events in your app, it's easy to design and test new in-app messages without shipping a new version of your app.
In-app messages are most effective when they are well-targeted and well-timed. In-App Messaging works with Google Analytics for Firebase and Firebase Predictions so you can trigger messages based on user profile data (language, app version, country), current behavior (purchases, screens visited, buttons clicked), and their predicted future behavior (likelihood of spending, risk of churning).
For example, with In-App Messaging and Google Analytics for Firebase, you can send an in-app message to all players using an older version of your game offering a reward if they upgrade their app. Or, you can send an in-app message containing a tip on how to beat a game level when a user fails to complete it.
With In-App Messaging + Firebase Predictions, you can send an in-app message containing a coupon code to users who are unlikely to spend money in your app to entice them to make a purchase.
In-App Messaging also shows you how each in-app messaging campaign is performing. Specifically, it tracks impressions, clicks, and conversions by date so you can understand the success of the campaign and make an informed decision whether or not to re-run it, or alter it, based on the results.
A lot of developers are familiar with notifications, but unsure of when to use in-app messaging. To get the wheels in your head turning, here are some examples of the types of engagement campaigns you could run with In-App Messaging.
These scenarios are just the tip of the iceberg! Whether you want to set up a recurring campaign or send a one-time alert, In-App Messaging supports a variety of use cases.
Get started today by checking out the documentation:
Getting started with Firebase In-App Messaging
We can't wait to see what types of in-app messaging campaigns you run!
