Real estate investing is a fantastic way to build a stream of passive income and grow your wealth. Numerous studies have pointed out that real estate investing has created more millionaires throughout history than any other form of investing (like this one and this one). So why don’t more people do it?
I asked myself this very question a few years ago after talking to a group of friends about the success I’ve had with real estate, and listening to their reasons why they think it’s out of their reach.
A common theme among them was that they viewed it as something too difficult to learn and master. There were too many steps, the learning curve was steep and there was a lot of room for mistakes for somebody just starting out, especially when analyzing the financial performance of potential investment properties.
Traditionally, most investors used spreadsheets to do the math - which works only if you know what and how you’re calculating something. But if you don’t know that, it’s very easy to make mistakes and overlook things. And no one wants to make mathematical errors before a huge purchase like an investment property.
Where do I even begin?!
And that’s when I had the idea to build DealCheck – a cloud-based, easy-to-use property analysis tool for real estate investors and agents. I wanted to create a platform that would help new investors learn the ropes and avoid costly mistakes, but at the same time provide the flexibility to perform more advanced analysis with a click of a button.
Making real estate investing easier and more accessible.
I was working as a front-end engineer at the time, so I knew I could build the UI myself, but what about the back-end, data storage, authentication, and a bunch of other things you need for a full-functioning cloud app?
I didn’t know anybody I could bring on as a co-founder, so I set out to research what technologies and platforms I could leverage to help me with the back-end and server infrastructure.
Firebase kept popping up again and again and I began to look at it in more detail. It was then recently acquired by Google and its collection of BaaS (backend-as-a-service) modules seemed to offer the exact solution I needed to build DealCheck.
I was especially impressed with the documentation for each feature and how well all of the different technologies could be tied together to create one unified platform.
It wasn’t long before I signed up and started building the first MVP of the app.
As the only developer on the project, I had limited time and resources to spend on building the back-end, so I set out to use every Firebase feature that was available at the time to my advantage.
My goal was actually to write as little server-side code as possible and instead focus on leveraging the different Firebase modules to solve three specific challenges:
The first one was authentication and user management. DealCheck’s users needed the ability to create their accounts so they can view and analyze properties on any device (more on that later). I wanted to have the ability to sign in with email, Facebook or a Google account.
Firebase Authentication was designed specifically for this purpose and I used it to handle pretty much the entire authentication flow. Out-of-the-box, it has support for all the major social networks, cross-network credential linking and the basic account management operations like email changes, password resets and account deletions.
There was no server-side code required at all – I just needed to build the UI on the front-end.
Email, Facebook and Google sign in powered by Firebase.
And as an added benefit, Firebase Authentication ties directly into the Realtime Database product to create a declarative permissions and access control framework that’s easy to implement and maintain. This helped me make sure user data was protected from unauthorized access, but also facilitate data sharing among users.
Next up was data storage. I knew that I wanted DealCheck’s users to be able to use the app and analyze properties online, on iOS and Android. So I needed a real-time, cloud-based database solution that could sync data across any device.
Syncing data across web and mobile is not easy!
Firebase Realtime Database is a NoSQL, JSON-based database solution that was designed exactly for this purpose, and I was actually surprised how great it worked. I used the official AngularJS bindings for Firebase on the front-end to read and write to it directly from the client.
I had to do some extra work on mobile to implement an offline mode with syncing after reconnections, but all-together the code required to make everything work was minimal.
As I mentioned, Firebase Authentication tied directly to the database to facilitate access control, so I really didn’t need to do anything extra there. And I was able to set up automatic daily backups of all the data with a click of a button.
Up to now, I had written exactly 0 lines of server-side code and everything was handled by the client directly. As DealCheck’s development progressed, however, I knew that I would need a server to handle some operations that could not be done in the client.
I wasn’t very experienced with server maintenance and DevOps, but fortunately the Firebase Cloud Functions product was able to solve all of my needs. Cloud Functions are essentially single-purpose functions that can be triggered (or executed) based on a specific HTTP request or events coming from the Authentication, Realtime Database or other Firebase products.
Each function can be run once based on a specific event trigger to perform its prescribed task. You don’t have to worry about provisioning a server instance or managing load – everything is done automatically for you by Firebase.
What’s even cooler, is that Cloud Functions can access the Realtime Database and Cloud Storage buckets of the same project, performing operations on them server-side, as needed.
This is how DealCheck processes subscription payments through Stripe, validates Apple and Google Play mobile subscription receipts, integrates with third-party APIs and updates database records without user interaction.
Bringing in sales comparable data from third-party providers into DealCheck.
Cloud Functions became the “glue” that tied the entire back-end infrastructure together.
The first version of the DealCheck app was built and launched in less than 5 months with just me on the development team. I definitely don’t think that would have been possible without Firebase powering the back-end infrastructure. Maybe the project wouldn’t have ever launched at all.
While Firebase is awesome for quick MVP development, it’s definitely designed to power production applications at scale as well. As DealCheck grew from a small side-project to one of the most popular real estate apps with over 100k users, all of the Firebase products that we use scaled to support the increasing load.
Moreover, the fantastic interoperability of all Firebase modules allows us to develop and release new features much faster because of the reduced coding requirements and ease of configuration.
So next time you’re looking to build an ambitious project with a small team – take a look at how Firebase can help you reduce development time and provide a suite of powerful tools that scale as your business grows.
This is exactly how DealCheck grew from a simple idea to make property analysis easier and faster, to an app that is helping tens of thousands of people grow their wealth and passive income through real estate investing. It’s a truly awesome and fulfilling experience to see your work positively impact so many people and it wouldn’t have been possible without Firebase.
We know that the web is one of the largest platforms developed on across the globe. We want to meet developers where they are, no matter what platform that may be using.
At I/O earlier this year, we announced Firebase Performance Monitoring for web. It was our next big step in bringing the complete suite of Firebase products to the web. And just a few weeks ago, at the Firebase Summit, we announced support for web apps in Google Analytics, Cloud Messaging and Remote Config! These new features give you insight into your web users, what they are doing inside your app, and help you create personalized experiences for them - just like you already do on native. Let’s take a closer look at all that is new for web developers in Firebase.
At the heart of a successful app and business strategy lies data. Analytics helps you understand how your user base is growing, who these users are, and what actions they are taking in your app. You can then use these insights to build tailored experiences that will delight, engage and retain your users.
If you're already comfortable using Google Analytics for your native apps, the web version of Analytics should look very familiar to you. But if you are new to Firebase, there are a few key components in Analytics we want to highlight:
Analytics also has a feature called audiences, which provides a way to segment users along attributes that are meaningful to you. For example, you can create an audience comprising all the users who performed a specific sequence of events in your app. These audiences now also work for users on the web, and membership can even be evaluated across multiple platforms by setting the user_id in the Analytics SDK.
Let’s take the example of an e-commerce app and a product review feature. One important thing to track in such an app is users who started writing a product review, and then left without completing it. Using audiences, we can create a user segment that represents exactly this group of users.
Example sequence of events “Started session” > “Started review” > “Canceled review”
We can create an audience representing that sequence in the Audience builder shown in the screenshot below:
In the next two sections we will show you how to combine audiences with Remote Config & Cloud Messaging to create personalized experiences for your users.
Remote Config (now works on web) gives you the power to alter your app for any segment of users without requiring you to release a new build. For example, you can segment users by geo and date (like Christmas) and infuse a holiday color palette into your app.
Going back to the product review example, say you want to show a custom message when any user who’s part of the “Abandoned reviewers” audience opens the app. You can now use that audience as the targeting condition for your Remote Config parameters across both your web and native apps. You could even strategically roll out new features to target audiences across web and native, so you can monitor regression and roll it back if you run into any issues.
Cloud Messaging has already been available for web for quite some time. What's new is that FCM for web is now integrated with Google Analytics, which allows you to send targeted notifications to your users based on their behavior in your app. You can do this by leveraging both new web specific signals (like browser type) and Google Analytics’ custom audiences and user properties. It’s another great way for you to personalize your users’ app experiences.
What’s also new is that campaigns can be easily configured in the Firebase console. Additionally, the funnel report that tracks campaign success also now works for web campaigns. All you need to do is specify an Analytics conversion event when setting up your campaign and the report will track success automatically.
Let’s go back to our favorite product review example. Now that we have a way to identify the audience who haven’t completed their reviews, we can re-engage them with tailored notifications for users on the native app as well as users on the web app. Since the audience is already being populated by Google Analytics with these user segments, you now simply have to go to Firebase Cloud Messaging in the Firebase console and create a campaign which sends a message to these audiences on their respective platforms.
Once we’ve started our messaging re-engagement campaign, we can use Google Analytics to create closed funnels to view the performance of the engagement workflow on any specific platform.
To use any of what we just described you, take a look at the instructions for implementing and integrating the web analytics SDK here. One important note is that if you are already using analytics for your native apps, you will first need to upgrade to the full Google Analytics experience in order to access web analytics. The Remote Config SDK for web is currently in Beta and you can access it here. To get started with FCM for web, simply follow the instructions here.
We hope you’re as excited about these new web features as we are. The above example illustrates one way you can use the new web analytics features to improve your web app experience and engage users, but there are many more ways these features can be used together. We can’t wait to hear what use cases you’ve implemented in your own web apps. As always, you can reach out to us on StackOverflow and through our official support page to let us know and give us feedback. Happy Developing!
Last month, our friends at Android launched the Android Developer Challenge, and asked you to submit your ideas focused on helpful innovation, powered by on-device machine learning.
ML Kit for Firebase helps power many of these experiences, including adidas’ new in-store shopping experience for their London store. Shoppers can scan products on their phones while they are in the store and the app lets them check stock and request their size without the need for queues.
If you’ve used ML Kit for Firebase to create a great user experience, or if you’ve got a great idea for how you might use it, submit your idea by December 2! You can also check out more examples on the Android Developers blog.
Firebase Authentication provides an end-to-end identity solution for your applications, which allows you to authenticate and verify users with passwords, phone numbers and popular federated identity providers such as Google, Facebook, Twitter, and Microsoft.
Today, we are pleased to announce beta support for Sign in with Apple in Firebase Authentication. Sign in with Apple allows your users to sign in to your applications and websites using their Apple ID.
Firebase also provides FirebaseUI, a customizable drop-in authentication UI that allows developers to easily implement a variety of authentication flows using any of the authentication services supported by Firebase, including Sign in with Apple.
Support for Sign in with Apple is available in beta now, and can be integrated in your applications using the latest versions of the Firebase SDKs for iOS, Android, and the web.
Hello, Cloud Firestore developers! We wanted to let you know about some useful new querying features we've added to Cloud Firestore this week. Starting with… in queries!
in
With the in query, you can query a specific field for multiple values (up to 10) in a single query. You do this by passing a list containing all the values you want to search for, and Cloud Firestore will match any document whose field equals one of those values.
in queries are a good way to run simple OR queries in Cloud Firestore. For instance, if the database for your E-commerce app had a customer_orders collection, and you wanted to find which orders had a "Ready to ship", "Out for delivery" or "Completed" status, this is now something you can do with a single query, like so:
customer_orders
We've launched another feature similar to the in query, the array-contains-any query. This feature allows you to perform array-contains queries against multiple values at the same time.
array-contains-any
array-contains
For example, if your app had a products collection, and those documents contained an array of categories that every item belongs in, you could now look for items that were in the "Appliances" or "Electronics" category, by passing these values into a single array-contains-any query.
Note that the baby monitor document will only be returned once in your query, even though it matches with multiple categories.
These queries are also supported in the Firebase console, which gives you the ability to try them out on your dataset before you start modifying your client code.
This also seems like a good time to remind you that you can apply filters directly in the Firebase console. Neat, huh?
Security rule behavior for these queries is pretty straightforward. Cloud Firestore will look at each potential value passed in for your in or array-contains-any operation and make sure your query would be allowed for that value. If any value is not allowed, the entire query fails.
For example, if your project was set up with these security rules…
match /projects/{project} { allow read: if resource.data.status != "secret"; ... }
This request would work…
db.collection("projects").where("status", "in", ["public", "unlisted"]);
...but this entire request would fail, because it's possible that our query will return documents that are forbidden in our security rules.
db.collection("projects").where("status", "in", ["public", "unlisted", "secret"]);
Not sure why we couldn't just send you back the allowed documents? Make sure to review the 'Rules are not filters' section of this video.
While we're excited to have you unlock the potential of in queries and array-contains-any queries, you should know about a few important limitations:
I think there's a lot of exciting things you can do now with in queries, and we're looking forward to hearing what new functionality you've added to your apps. So make sure you've upgraded your client libraries to the latest versions to take advantage of the new features, check out the documentation, and happy databasing!
At Firebase, our mission is to help mobile and web developers succeed, but with over 2 million apps actively using Firebase every month, we know that success means different things to different developers. For example, to Le Figaro, the oldest and largest French newspaper, success means increasing paid subscriptions significantly with the help of a combination of Firebase products. For Mighty Immersion, a three person startup on a journey to improve patient care with VR technology, success means scaling their apps to more hospitals as fast as possible using Firebase backend products.
Stories like these are what inspire us to continue investing in our developer community. We all benefit from a vibrant and open ecosystem that helps bring ideas to life.
We’re excited to be in Madrid at the fourth annual Firebase Summit to hear about what you’re building, and share updates on how we’re simplifying your app development workflows and infrastructure needs. Read on to learn about everything that’s new at Firebase Summit 2019! You can also check out the keynote and sessions on our YouTube channel or the summit website.
Save time on everyday development tasks with Firebase Extensions
Repetitive app development tasks can slow you down, leaving less time for creating amazing user experiences. To save you time, we’re thrilled to introduce Firebase Extensions, pre-packaged bundles of code designed to automate common tasks in your projects. Whether you want to resize an image, add people to an email list or shorten URLs, we’ve built an array of solutions that you can easily deploy to your projects. There’s no need to write or debug code–it’s all done for you, but you still have the flexibility to configure extensions for your specific use cases. Firebase Extensions are open-source and integrate seamlessly with other Firebase and Google Cloud Platform products. Starting today, you can discover extensions suited to your specific use cases on the Extensions Directory page on our website or Firebase Extensions GitHub repository.
Launch extensions available in Firebase Console
Increase your development velocity with the Firebase Emulator Suite
The Firebase Emulator Suite is a fast, rich and safe environment that provides you with a set of local tools for building your next app or feature. Based on your feedback, we’ve expanded the functionality of our emulator suite to include hot reloading for changes to Security Rules and added broader support for client and server side SDKs. We’ve also included support for Realtime Database triggered Functions and developed a new command to tighten how it works with CI. Learn more here.
Firebase Emulator suite now supports Realtime Database & broader client and server side SDKS
Enhance app stability and usability before publishing with Firebase App Distribution
Building apps inevitably comes with bugs, which are important to address before your app is live so they don’t affect the user experience, or your ratings and reviews. Today, we’re excited to announce Firebase App Distribution, which gives you an easy and flexible way to distribute pre-release versions of your apps to trusted testers. App Distribution provides one central hub where you can distribute both iOS and Android test apps. You can also build pre-release testing into your existing workflows with CLI support for Gradle, fastlane and the Firebase CLI. There’s no SDK to install, forms to fill out or review process to go through. Get started with Firebase App Distribution here.
Send pre-release versions of your app to trusted testers via the Firebase console
Expand your web app capabilities with Google Analytics, Firebase Remote Config and Firebase Cloud Messaging
Once your app is running, the next step is to understand your users and identify ways to increase engagement. Users often interact with your business across multiple touch points and on different devices, so today we’re excited to announce we're expanding our integration with Google Analytics to include support for the web. You can now use the powerful analytics features you’ve enjoyed for native mobile apps–like the ability to segment your audience, trigger actions, and record events and user properties–for web apps. This makes it easier to understand how users are interacting with your apps, no matter what device or platform they're on. You’ll also now have access to closed funnels just a click away in the Google Analytics UI. And with our recently-upgraded audiences feature, you can create a more personalized experience for your web users with Remote Config or Firebase Cloud Messaging, which are now also available for web.
Google Analytics now supports web apps
Easily forecast user behavior with Firebase Predictions
Last year we launched Firebase Predictions into general availability, letting you apply the power of machine learning to your app analytics and create smart segments of your users based on their predicted future behavior. We’ve made some recent improvements to the Predictions experience to give you more information and more control. Most significantly, we’ve updated the Predictions interface so you can see the full spectrum of your user’s predicted behavior and target any segment of users depending on your use case. Learn more here.
Peek under the hood with more open-sourced SDKs
We believe an open platform is essential to creating powerful software and a connected community. Over the past few months, we’ve open-sourced four additional iOS libraries and four additional Android libraries. Today we’re open-sourcing the new Web SDK releases for Remote Config and Analytics. We’ve also worked closely with Invertase, a company that has created a comprehensive React Native library for Firebase, to ensure their libraries cover all Firebase products. The new React Native Firebase v6 release adds support for every Firebase service and includes a new documentation website, quick start guides, and upgraded SDKs. Get started here.
Limit access to your Firebase projects
In addition to making our platform more open, we’re also making sure you have the right processes in place to keep your data secure. To help you do this, we’re happy to share Firebase Roles and Permissions has graduated into general availability. This battle-tested system lets you use either predefined Firebase roles or create your own custom roles in order to limit access to your Firebase projects and data to the appropriate people. Learn more here.
Reduce test run time with Firebase Test Lab
We’ve made improvements to Firebase Test Lab that allow you to speed up tests with Test Sharding. Test Sharding enables you to divide tests into subgroups (shards), and run them in parallel. Learn more here.
Update on Fabric migration
With the launch of App Distribution, we’ve completed our journey to bring the best of Fabric to Firebase. All of the Fabric features you love can now be accessed in Firebase, and to take advantage of the latest updates, we recommend migrating your Fabric apps and teammates to Firebase today. The Fabric dashboard will sunset on March 31st 2020 and an early migration will ensure that you’re set up for success in your new home. Get started here.
We're continuing to invest in Firebase to provide a more helpful platform that simplifies your app development workflows and infrastructure needs, so you can focus on building amazing user experiences. As we continue to grow and enhance the platform, we'd love to get your feedback. Join our Alpha program to get a sneak peek of what we're building next, share your thoughts with us, and help shape the future of Firebase.
Today, we’re delighted to announce that we’ve doubled the concurrent connections limit for the Firebase Realtime Database from 100k to 200k. This takes effect today, for all existing databases and new projects. And while this level of scalability will be enough for the majority of projects out there, some of you might want to support even more concurrent users. For that, you might want to consider sharding your database.
Many kinds of apps can scale much higher by sharding their data across multiple Realtime Database instances in a single project. The 200k concurrent user limit applies to each individual database, so the total number of concurrent connections increases linearly as you add more instances.
Sharding is a good strategy to employ when each client interacts with isolated parts of the database. Imagine a virtual whiteboard app, which is the sort of high-frequency, low-latency collaboration app for which the Realtime Database really excels. Whiteboard sessions don’t interact with each other -- just with the handful of users that are drawing together. So they can be sharded across an unlimited number of instances. When multiple users create a session, your app could assign that session to a random shard; then the clients only need to be connected to that database in order to receive their realtime updates.
Most IoT apps can also take advantage of sharding. If you want to have a gigantic number of tiny sensors sending periodic updates, they probably don’t all need to write to the same RTDB instance. You can create lots of shards (we support up to 1000), and assign each sensor to a shard. If you're interested in working with multiple versions of the Realtime Database in the same project, make sure to check out our documentation.
Of course, if you're looking for a powerful realtime database that scales without sharding, we still recommend our newer database, Cloud Firestore, for most new projects. It has the same magical realtime, offline, serverless functionality as the Realtime Database, but has been architected for higher reliability, has more powerful queries, and locations around the world.
Nonetheless, there are some use cases for which the Realtime Database is the right choice, even for new applications. That’s why we’re continuing to invest in making it even better for these purposes.
When should you pick the Realtime Database for a new project? The short answer is that if you are building an application that will have lots of tiny operations, the Realtime Database may be less expensive and more performant. For the whiteboarding app, you’d want to send lots of frequent little updates as the users draw on the whiteboard, and you’d want latency to be as low as possible. In the IoT case, performance may not be as important, but the Realtime Database may end up cheaper than Cloud Firestore if you are sending a massive stream of tiny writes.
Of course, you can use both Cloud Firestore and the Realtime Database together in the same project — we encourage it! For instance, you can use the Realtime Database to power the live whiteboard feature, but then persist the whiteboard contents to Firestore periodically to take advantage of its 99.999% availability and less expensive storage.
We hope you are excited about the increased scaling capabilities of the Realtime Database. And we also hope this guidance helps you decide between Cloud Firestore and the Realtime Database for new projects. As always if you have any questions, feel free to reach out on StackOverflow, or the firebase-talk discussion group.
Keeping an eye out for issues that affect your app’s stability is crucial, but we also know that you can’t spend your entire day staring at the Firebase Crashlytics console.
From the beginning, Crashlytics has given developers the ability to turn on stability alerts so they can be notified when issues increase in impact and severity. Developers have the power to customize these notifications so they're delivered at the right time and channel for maximum visibility - channels where developers already spend their time.
In this blog post, we'll review the types of alerts Crashlytics provides and our recommendations on how to configure them based on observations from customers.
Let’s start by reviewing the different types of alerts Crashlytics sends. Currently, Crashlytics sends five alerts: new fatal issue, new non-fatal issue, trending issues, regression, and velocity alerts.
New issue alerts let you know the first time a new crash has occurred. We filter out the noise of repeated crashes, but give you the full stream of unique crashes by stack trace grouping. These alerts are turned off by default to avoid over inundating you, because as your app grows, you could get tons of alerts for every new version. We recommend turning these on for teams interested in knowing about every new type of crash, and for QA teams chasing down crashes found in testing versions of their apps.
Regression detection alerts you when a previously closed issue re-occurs in a new app version, which is a signal that something else may be awry and you should pay close attention to it.
Trending issues digest is sent out to developers in two instances 1) When Crashlytics detects a new crash is beginning to gain momentum (called emerging issues) 2) When Crashlytics detects new top crashes that have climbed to close to the top of your issue list recently (called trending issues). This daily email is on by default, and is a great way to keep track of emerging issues in your app.
One of the most important alerts within Crashlytics is the velocity alert, which notifies you when an issue suddenly increases in severity and impacts a significant percentage of your users. However, we recognize that every app is unique and the one-size-fits-all alerting threshold might not be what’s best for you and your business. That’s why you can now customize velocity alerts and determine how often and when you want to be alerted about changes to your app’s stability.
You can learn more about customizing velocity alerts here.
Now that you know the different notification types in Crashlytics, you can begin to build your alerting plan.
Firebase Crashlytics offers several channels to receive the above alerts. The first two channels are email and in-console alerts.
To setup these alerts:
Next, you can set up notifications through Slack, Jira or PagerDuty. To set up these alerts, you need to do two things: integrate Slack / Jira / PagerDuty with your Firebase project, and then choose your triggers.
For Slack:
There are two ways to create Jira issues from Crashlytics issues:
Here’s how you enable the Jira integration:
Our PagerDuty integration is setup similarly.
We find that a lot of our users get different utility out of each channel. In Slack, teams frequently set up a channel to show a real-time feed of all new issues, as a way to loosely monitor new issues coming up. Developers with an interest in specific pieces of code can then click through to get more detail on the issues they’re interested in. This is a pattern that seems to work well for most teams.
In Jira, we see developers using the manual integration option to create issues when they know their team is ready to take on that work. In addition, teams also setup automatic triggers for velocity alerts and regressions as those are known higher priority issues to look into.
And for PagerDuty, most teams focus on velocity alerts, which provide insight into the most critical situations your users are experiencing. For teams with even more custom use cases, we recommend developers integrate Crashlytics with Cloud Functions.
By setting up alerting in Crashlytics, you can rest assured that you’ll be alerted when critical issues occur in your app and be ready to take action when needed. For more about Crashlytics check out our docs here.
Notifications are all about getting the user’s attention at the right place and at the right time, leading them to the most important places in your app. Having richer content in your notifications can make them stand out to your users, and increase the chances that they engage with your app. In this blog post, we'll discuss several ways to make your notifications more interesting to your users by:
Recently, the Firebase Cloud Messaging team added image support for notifications on both iOS and Android platforms. We've also added 12 parameters on Android which let you easily craft fun and rich notifications with minimal effort.
You can now add images to your notifications, as shown in the figure below. These can help make your notifications a lot livelier, and provide a visual context for your notification that can match with your app. For example, if you're developing a video streaming app, a notification that includes movie poster images for new releases could be a great way for your notification to get more attention. If you're an e-commerce app developer, notifying your user with the picture of the product they've been waiting for could help encourage them to make the purchase.
Figure 1: Image notifications on iOS platform
Figure 2: On Android, images show up in both the notification tray when your notification is expanded, as well as when that notification is opened.
The first thing you need to do is to prepare a notification with an image URL. From the Firebase console, you’ll be presented with two options when you are composing a notification:
Option 1 - You can enter a URL to the image you want to use;
Option 2 - You can upload a local image directly to your notification composer.
If you are using the HTTP v1 API, you will need to provide a public URL to the image parameter in the JSON body for the notification you’re sending. If you like, you can use Cloud Storage for Firebase to upload an image and get a public URL for the image from there.
When you copy and paste the public image URL or upload your image directly to the notification composer, the newly updated notification composer will render a preview of the image on the notification for each platform, as shown in Figure 3.
Figure 3: The newly updated notification composer helps you easily visualize the image layout for your notifications
Download the latest Messaging SDKs for Android and iOS and rebuild your app with the new dependencies. When a notification that includes an image URL is delivered to the device, the messaging SDK will download the image and attach it to the notification. If the image cannot be downloaded due to the size of the image or availability of the network, the FCM client will display the notification without rendering the image.
Note that in order to send notifications with images or other media files on iOS, you will need to enable service extensions for the iOS platform. We’ll cover that next. If you are an Android developer, you’re already all set for sending notifications!
To receive notifications with media files in iOS, you will need to add a Notification Service Extension target in your project. The extension is available starting from iOS 10+ and supports media files like images, videos and gifs! To use videos and gifs, you will have to upload them to Cloud Storage for Firebase first and copy and paste the public URLs of those files in the Notification composer, or to the JSON image parameter in the HTTP v1 API.
When a notification is first received on a client device, the Notification Service Extension intercepts the message and allows developers to modify it before it becomes visible to users. At this point is when you will call the Firebase Messaging ExtensionHelper API to let the iOS SDK handle downloading and attaching the media files for you. Keep in mind, the processing time available for a service extension is short-lived, so if the media file is too big to download or process, the client might not complete attaching it to the notification before it is sent. When network availability is limited or slow, or the image is too large, the service extension might simply complete without an image included since it wasn’t able to finish downloading it.
You can follow these steps in Apple Documents to create a notification service extension target. Next, modify the last call in didReceiveNotificationRequest:withContentHandler: by doing the following: instead of completing it with the contentHandler(self.bestAttemptContent), call the FIRMessaging extensionHelper API. This will allow the Messaging SDK to handle downloading the image and completing the handler for you.
@interface NotificationService () <NSURLSessionDelegate> @property(nonatomic) void (^contentHandler)(UNNotificationContent *contentToDeliver); @property(nonatomic) UNMutableNotificationContent *bestAttemptContent; @end @implementation NotificationService - (void)didReceiveNotificationRequest:(UNNotificationRequest *)request withContentHandler:(void (^)(UNNotificationContent * _Nonnull))contentHandler { self.contentHandler = contentHandler; self.bestAttemptContent = [request.content mutableCopy]; // Modify the notification content here as you wish self.bestAttemptContent.title = [NSString stringWithFormat:@"%@ [modified]", self.bestAttemptContent.title]; // Call FIRMessaging extension helper API. [[FIRMessaging extensionHelper] populateNotificationContent:self.bestAttemptContent withContentHandler:contentHandler]; }
Code sample on how to call FIRMessaging extension helper API to attach image to your notification.
Figure 4: An example of a gif notification received on iOS platform.
That’s it! Go ahead and start sending notifications with some fun images!
Firebase Cloud Messaging now gives you more options to enhance notifications and do things like enabling the default sound and vibration pattern, controlling whether your notifications show on locked screens or not, and more. To enable these features, you’ll just need to add additional parameters to your notifications using the HTTP Send API. Below are all the new parameters we’ve introduced in this release. You can check which Android API levels support which parameter features by checking out the documentation here.
{ "ticker" : "this is a ticker text", "event_time": "2000-01-01T00:00:00Z", // dismiss on click "sticky": false, // won't show on bridged devices such as Android wear watches. Only show on target device "local_only": true, // require the user's prompt attention. Ex: earthquake alert "priority": "PRIORITY_MAX", // vibrate pattern being off 1s, on 1s, off 4s, 8s "vibrate_timings": ["1s", "2s", "4s", "8s"], // won't show on a locked screen. Ex: no show on direct booted devices "visibility": "VISIBILITY_PRIVATE" "light_settings": "color": { "red": 0.2, // amount of red in the color "green": 0.4, // amount of green in the color "blue": 1 // amount of blue in the color "alpha": 0.8 // almost solid color }, "light_on_duration": "1s", "light_off_durtaion": "2s" } }
Let’s look at some new possibilities and use cases for different notifications using these new parameters!
Often, developers send notifications that inform users about events with an absolute time reference, like a limited-time sale a concert date. However, the time that the notification actually gets delivered may not always match up with the event time for the content of that notification. For instance, let’s say a short-lasting Firebase pizza sale notification is delivered to a device in airplane mode. When the device regains connectivity, the notification will be displayed with a timestamp of the time the notification was received as the device got back online. That received notification time will be misleading if the sale has already expired, leaving the user misinformed.
By default, notifications are time-stamped with the system time at the moment they are received on the device. If they are not the time value you wish to have for your notifications, you can override the timestamp value by setting event_time. In addition, setting event_time can be useful since notifications are sorted in the notification drawer by the event time indicating when they were received. For example, if you're a sports app developer and send play by plays for major games via notifications to your users, you'll want these to show up in chronological order in the notification tray for your users. Setting event_time will help you accomplish just that.
event_time
Note that to represent a point in time independent of any time zone or calendar, we use the UTC Epoch time defined by the Timestamp object.
Most modern Android devices have vibration capabilities and some have LED lights that can be used for notifications. These can provide physical and visual cues for your customers to distinguish your app from others. You can set both settings with the light_settings and vibrate_timings parameters.
light_settings
vibrate_timings
If you want to set a sound and vibrate pattern for a notification without spending a lot of time configuring it, just set defaultSound and defaultVibrateTimings to true and you’ll be set to go.
defaultSound
defaultVibrateTimings
Like all other information, notifications have varying levels of importance.The higher the importance of a notification, the more prioritized and interruptive notifications will be. You can set notification importance by setting notification_priority.
notification_priority
Note that notification_priority is different from AndroidMessagePriority. The former one controls the UI behavior of the notifications on the device. The latter one is an FCM concept that controls when the message is delivered. See FCM guides for more information.
AndroidMessagePriority
Some notifications may carry sensitive content. As a developer, you might want to control the level of visibility for notifications posted by your app on a secure locked screen. Now you can set visibility to control how notifications are displayed on a locked screen.
visibility
Figure 5. Notifications on the lock screen with sensitive content hidden
By default, each notification received for your app increments a notification number displayed on the long-press menu for your app launcher icon , but you can override this number for your app. For example, this might be useful if you're using just one notification to represent multiple new messages but you want the count here to represent the number of total new messages. You can set the notification count by setting the field of “notification_count”
Figure 6 Notification badges and the long-press menu with notification count
We highly recommend that you start incorporating images into your notifications to make them richer and more engaging on iOS and Android, and enhancing them even further with notification parameters for Android ! As always, if you have any questions or feedback from us, please reach out on StackOverflow or our official support page.
