*July 11 Edit: An earlier version of this blog post said that Firebase Crash Reporting will continue to be functional until September 8th, 2018 - at which point it will be retired fully. To clarify, that means that Firebase Crash Reporting will be accessible on September 8, 2018 and will no longer be accessible on September 9, 2018.*
Back in October, we were thrilled to launch a beta version of Firebase Crashlytics. As the top ranked mobile app crash reporter for over 3 years running, Crashlytics helps you track, prioritize, and fix stability issues in realtime. It's been exciting to see all the positive reactions, as thousands of you have upgraded to Crashlytics in Firebase!
Today, we're graduating Firebase Crashlytics out of beta. As the default crash reporter for Firebase going forward, Crashlytics is the next evolution of the crash reporting capabilities of our platform. It empowers you to achieve everything you want to with Firebase Crash Reporting, plus much more.
This release include several major new features in addition to our stamp of approval when it comes to service reliability. Here's what's new.
We heard from many of you that you love Firebase Crash Reporting's "breadcrumbs" feature. (Breadcrumbs are the automatically created Analytics events that help you retrace user actions preceding a crash.) Starting today, you can see these breadcrumbs within the Crashlytics section of the Firebase console, helping you to triage issues more easily.
To use breadcrumbs on Crashlytics, install the latest SDK and enable Google Analytics for Firebase. If you already have Analytics enabled, the feature will automatically start working.
By broadly analyzing aggregated crash data for common trends, Crashlytics automatically highlights potential root causes and gives you additional context on the underlying problems. For example, it can reveal how widespread incorrect UIKit rendering was in your app so you would know to address that issue first. Crash insights allows you to make more informed decisions on what actions to take, save time on triaging issues, and maximize the impact of your debugging efforts.
From our community:
"In the few weeks that we've been working with Crashlytics' crash insights, it's been quite helpful on a few particularly pesky issues. The description and quality of the linked resources makes it easy to immediately start debugging." - Marc Bernstein, Software Development Team Lead, Hudl
- Marc Bernstein, Software Development Team Lead, Hudl
Generally, you have a few builds you care most about, while others aren't as important at the moment. With this new release of Crashlytics, you can now "pin" your most important builds which will appear at the top of the console. Your pinned builds will also appear on your teammates' consoles so it's easier to collaborate with them. This can be especially helpful when you have a large team with hundreds of builds and millions of users.
To show you stability issues, Crashlytics automatically uploads your dSYM files in the background to symbolicate your crashes. However, some complex situations can arise (i.e. Bitcode compiled apps) and prevent your dSYMs from being uploaded properly. That's why today we're also releasing a new dSYM uploader tool within your Crashlytics console. Now, you can manually upload your dSYM for cases where it cannot be automatically uploaded.
With today's GA release of Firebase Crashlytics, we've decided to sunset Firebase Crash Reporting, so we can best serve you by focusing our efforts on one crash reporter. Starting today, you'll notice the console has changed to only list Crashlytics in the navigation. If you need to access your existing crash data in Firebase Crash Reporting, you can use the app picker to switch from Crashlytics to Crash Reporting.
Firebase Crash Reporting will continue to be functional until September 8th, 2018 - at which point it will be retired fully.
Upgrading to Crashlytics is easy: just visit your project's console, choose Crashlytics in the left navigation and click "Set up Crashlytics":
If you're currently using both Firebase and Fabric, you can now link the two to see your existing crash data within the Firebase console. To get started, click "Link app in Fabric" within the console and go through the flow on fabric.io:
If you are only using Fabric right now, you don't need to take any action. We'll be building out a new flow in the coming months to help you seamlessly link your existing app(s) from Fabric to Firebase. In the meantime, we encourage you to try other Firebase products.
We are excited to bring you the best-in class crash reporter in the Firebase console. As always, let us know your thoughts and we look forward to continuing to improve Crashlytics. Happy debugging!
You have questions about Firebase, and the Firebase community has answers!
But do you know the best place to get your questions answered?
It can be kind of overwhelming to figure out which destination is the best for your particular question. What I'd like to explore today are your options, and how to choose the best one. Choosing the best (and knowing how best to ask) could give you a huge advantage in getting the answers you need. There are five leading options, each with a different purpose. Let's explore those options!
It might seems silly to say, but I think your question should start with a Google search. A well-constructed search could surface existing answers in some of the forums I'll discuss next. You can't pass up the chance of getting your question answered immediately because someone else asked it first!
Try entering your question directly into the search box. Or, if you have an error message in your code, try copying it in there. For exact error messages, sometimes it's helpful to put your search string in quotes to force the most relevant matches to the top of the results.
Bear in mind that not every search yields good results. In some cases, you might stumble across something so rare that only one other person has ever seen it!
That time I searched for "ERROR: Walrus not found: have you checked the polar ice caps?"
If a search doesn't give what you're looking for, it's time to choose from some other options.
But before we continue - if you end up deciding that your question is appropriate for multiple forums, be sure to state that you've cross-posted your question. That gives everyone a chance to figure out which forum may be the best options, and if the question has already been answered elsewhere. That saves everyone time.
Stack Overflow is great for programming questions. In fact, that's the only kind of question you're supposed to ask there. Many Firebase team members pay attention there, including members of the greater community. There are a few tips to making the best of your question on SO:
Not all questions are good for Stack Overflow. In particular, your question may be closed by the community if it's any of the following:
If your question is closed by the community, it will almost certainly not be answered. But don't worry: for questions about Firebase that don't follow the Stack Overflow requirements, there are other options!
Quora is great for general questions, especially those seeking recommendations and opinions. There doesn't have to be a "correct" answer to a question on Quora. It's OK to ask broad questions.
If you choose Quora, be sure to tag your question with the Firebase topic so it's more likely to get noticed by people who have experience with Firebase.
firebase-talk is a long-standing mailing list for people who are looking for open-ended discussion about all things Firebase. It's great for open-ended discussions that require a lot of text that goes back and forth between group members. Many Firebase team members scan the messages here.
When you post your first message here, be prepared to wait for some time for a moderator to accept it.
The Firebase Slack is where Firebase enthusiasts gather to talk about, well, Firebase! This is good for general chit-chat and gathering opinions. While some Firebase team members check in from time to time, it's not an official support channel. So if you have a question that better fits Stack Overflow or Quora, I think it's better to ask there first.
One notable exception is the Firebase Test Lab team who use the #test-lab channel for direct support.
Here's a couple tips for using the Firebase Slack effectively:
This is a good place to ask for urgent issues such as problems with your production app. It's also good for troubleshooting if you require some back and forth with a real person with a problem that can be reproduced in code. You can expect a response from support within 24 hours of asking your question.
Firebase support also handles bug reports and feature requests. So if you have one of those, please fill out the form in that link.
If you want a timely response, I would avoid the following destinations for general questions:
The other reason I would avoid these is because they have limited visibility to the world, whereas the destinations above are well known by the Firebase community. You probably want your question to reach the maximum number of people as possible, in order to get answered quickly.
However, we do encourage you to use Twitter and other social media to broadcast the questions you ask on other sites. For example, it's good to ask a question on Stack Overflow or Quora, then tweet the URL of the question with the hashtag #AskFirebase. Your questions may get picked up for use on the Firebase channel on YouTube.
The Firebase community loves to help with Firebase! And it's easier to get help if you follow the guidelines here to make sure your questions reach the correct audience.
Now watch this video with Kato Richardson, who loves our Firebase community!
I'm always amazed when I think about the fact that Firebase Cloud Messaging sends billions of messages a day. Developers on iOS, Android, and web rely on FCM to send notifications and data messages to their clients. We recently updated FCM to incorporate better security and new features, and now you can access the new FCM through the Firebase Admin SDK for Node.js, Python, Java, and Go.
The latest version of FCM, called FCM v1, includes the ability to send a single request with platform-specific overrides. For example, you can set a time to live for an Android notification and an APNs priority for an iOS notification in the same body. See the documentation or this blog post for more information on platform overrides.
You can now conveniently integrate your server-side applications with the FCM v1 API using the Firebase Admin SDKs. Here's how you can send a simple data message in Node.js:
var registrationToken = 'YOUR_REGISTRATION_TOKEN'; var message = { data: { score: '850', time: '2:45' }, token: registrationToken }; admin.messaging().send(message) .then((response) => { console.log('Successfully sent message:', response); }) .catch((error) => { console.log('Error sending message:', error); });
To see this code in Java, Python, and Go, check the documentation. To see all message payload options, check out the FCM v1 documentation. In addition to sending messages to devices and topics, the Admin SDK for FCM also allows you to manage topic subscriptions from your server.
Here's an example of subscribing to a topic in Node.js:
var registrationTokens = [ 'YOUR_REGISTRATION_TOKEN_1', // ... 'YOUR_REGISTRATION_TOKEN_n' ]; admin.messaging().subscribeToTopic(registrationTokens, topic) .then(function(response) { console.log('Successfully subscribed to topic:', response); }) .catch(function(error) { console.log('Error subscribing to topic:', error); });
To see this code in Java, Python, and Go, check the documentation. Thanks to the Admin SDK, it's even easier than ever to send messages! Check out the full documentation here. And if you build something cool with FCM, be sure to tell us about it! Tweet @Firebase and @ThatJenPerson and let us know how it's going!
Securing your Firebase Realtime Database just got easier with our newest feature: query-based rules. Query-based rules allow you to limit access to a subset of data. Need to restrict a query to return a maximum of 10 records? Want to ensure users are only retrieving the first 20 records instead of the last 20? Want to let a user query for only their documents? Not a problem. Query-based rules has you covered. Query-based rules can even help you simplify your data structure. Read on to learn how!
query
Security rules come with a set of variables that help you protect your data. For instance, the auth variable tells you if a user is authenticated and who they are, and the now allows you to check against the current server time.
auth
now
Now, with the query variable, you can restrict read access based on properties of the query being issued.
messages: { ".read": "query.orderByKey && query.limitToFirst <= 100" }
In the example above a client can read the messages location only if they issue an orderByKey() query that limits the dataset to 100 or less. If the client asks for more than 100 messages the read will fail.
messages
orderByKey()
The query variable contains additional properties for every type of query combination: orderByKey, orderByChild, orderByValue, orderByPriority, startAt, endAt, equalTo, limitToFirst, and limitToLast. Using a combination of these properties you can restrict your read access to whatever criteria you need. Get the full reference and see more examples in our docs.
orderByKey
orderByChild
orderByValue
orderByPriority
startAt
endAt
equalTo
limitToFirst
limitToLast
Another benefit of query-based rules is that they make it easier to manage a shallow data structure.
In the past you might index your items location by a user's id.
items
{ "items": { "user_one": { "item_one": { "text": "Query-based, rules!" } } } }
This structure made it easy to query and restrict item reads on a per-user basis.
{ "rules": { "items": { "$uid": { ".read": "auth.uid == $uid" } } } }
This is great because your user's items are secured, but it requires you to index off of the user's id, potentially replicating data or complicating your client code.
With query-based rules, you can now get the same security without the nesting!
{ "rules": { "items": { ".read": "auth.uid != null && query.orderByChild == 'uid' && query.equalTo == auth.uid" } } }
The above rule will restrict any read on a per-user basis without indexing by the "uid" key, which means you can write a simple query to retrieve a user's items without sacrificing security.
"uid"
Now the data structure is reduced by one level:
```
{ "items": { "item_one": { "text": "Query-based, rules!", "uid": "user_one" } } }
``
db.ref("items").orderByChild("uid") .equalTo(auth.currentUser.uid) .on("value", cb)
The above query will retrieve all the items belonging to the currently authenticated user. If a user tries to access items that don't belong to them, the read will fail.
Query expressions are new feature that can be used in parallel with your existing rules. If you find that query expressions can improve your security or simplify your structures you can upgrade to them incrementally.
Query-based rules are available for use today. Go to your Firebase console and use the emulator to give them a whirl. Check out our official documentation for more information. If you run into any problems make sure to check out our support channels or hit up the Firebase Slack community.
When I think back 10 years or so when I was writing code for a monolithic codebase written in C++, one of the worst memories I have of the time was waiting for a build to complete just to run a couple lines of new code. The pain was so common among engineers that it bore the creation of one of the all-time most popular XKCD comics:
My office at the time didn't have swords to play with, so waiting for a build to complete was really boring.
The pain is similar if I had to deploy my Cloud Functions code every time I want test a function. Fortunately, the Firebase CLI now has a local emulator that works for both HTTPS and other types of functions. This lets me run the functions on my development machine by emulating the events that would trigger it. You can read more about that in the documentation.
One of the emulator's handy features is the fact that it will reload any JavaScript files that change over time. So, if you modify the code of a function, you can test it right away in the emulator without having to restart it:
It's fast and easy, and keeps you "in the zone".
However, things become less easy when you switch from JavaScript to TypeScript. Running TypeScript on Cloud Functions requires a compilation phase to convert the TypeScript into JavaScript so that it can be executed by the emulator. It adds a bit of a hassle:
npm run build
There's an easier way to do this that doesn't involve running a command every time. The TypeScript compiler (tsc) has a special "watch mode" that lets it pick up changes to your TypeScript and automatically compile them. You can run it from the command line by changing to your functions folder and running this command:
tsc
./node_modules/.bin/tsc --watch
With this running alongside the local emulator, which automatically picks up changes to the compiled JavaScript, your development workflow goes back to this:
And, if you're using VSCode, you can even have it directly run tsc in watch mode. You can start it up with Tasks -> Run Build Task..., then choosing "tsc: watch".
It will fire up a command shell right in the IDE, run tsc --watch, and show you the output. You'll see messages like this, along with any compilation errors, any time a TypeScript file changes:
tsc --watch
2:38:38 PM - File change detected. Starting incremental compilation... 2:38:38 PM - Compilation complete. Watching for file changes.
Now, bear in mind that tsc in watch mode won't run TSLint against your code, so be sure to set that up in VSCode so you can always see its recommendations, as I showed in a prior blog post. If you're not linting your code, seriously consider setting that up, because you'll catch potential mistakes that could be costly in production.
