We know that Kotlin is the future of Android and that Kotlin developers want clean, idiomatic APIs when they use Firebase in their apps. For the past year, we've been releasing Firebase Kotlin extension (KTX) libraries alongside our Android Java SDKs to give Kotlin developers the best of both worlds.
Today, we're happy to announce that these KTX libraries are out of Beta and recommended for all Firebase developers using Kotlin in their Android apps!
So what does this mean for you?
To get started with our KTX libraries, look for the -ktx suffix in the "Kotlin+KTX" section of our available Android libraries. As an example, let's see what it looks like to set up Remote Config with and without the KTX library.
-ktx
app/build.gradle (before)
implementation 'com.google.firebase:firebase-config:19.1.2'
MainActivity.kt (before)
val remoteConfig = FirebaseRemoteConfig.getInstance() val configSettings = FirebaseRemoteConfigSettings.Builder() .setMinimumFetchIntervalInSeconds(3600) .setFetchTimeoutInSeconds(60) .build() remoteConfig.setConfigSettingsAsync(configSettings)
app/build.gradle (after)
// The -ktx library has a dependency on the firebase-config library implementation 'com.google.firebase:firebase-config-ktx:19.1.2'
MainActivity.kt (after)
// New global "Firebase" class val remoteConfig = Firebase.remoteConfig // New settings builder syntax val configSettings = remoteConfigSettings { minimumFetchIntervalInSeconds = 3600 fetchTimeoutInSeconds = 60 } remoteConfig.setConfigSettingsAsync(configSettings)
And the KTX libraries that we have available today are just the beginning, as we're working hard to add coverage for all Firebase products and add new Kotlin-focused features in the near future!
We wouldn't have been able to release these KTX libraries without the help of all the Kotlin enthusiasts in the Firebase community. We'd like to give a special shout out to Rosário Pereira Fernandes who contributed so much excellent code and documentation to the KTX effort.
If you have feedback or want to contribute, you can find us on GitHub.
Hello, game developers!
Well, this has certainly been a challenging couple of months. We had been looking forward to meeting you in person last week at the Game Developers Conference, sharing some updates, and hearing directly from all of you. But, obviously, plans change, and we're committed to doing whatever it takes to keep everybody safe. Even if it means recording session videos from our kid's bedroom and hoping the cat doesn't wander into the scene.
Still, our teams have been working hard to ensure you have all the tools and resources you need to build great games. This year at our digital Google for Games Developer Summit (which you can find here if you missed it), we announced some new features that will help you spend less time on infrastructure work, and more time on making your game fun and unique. Let's take a look at some of these now, shall we?
Cloud Firestore is our next generation, scalable NoSQL database in the cloud. It offers features that database aficionados love, like multi-region reliability (for five 9s of uptime), atomic transactions, robust offline support, and realtime listeners that let you build some really great gameplay experiences. And we're happy to announce that alpha versions of our SDKs are now available for C++ and Unity developers.
Cloud Firestore can be used in many different situations. You could use it to simply save your users' game state to the cloud. Or save a shared game state to be viewed by several different clients in a multiplayer game. Use it to post daily challenges or user-generated content that can be easily queried and viewed by millions of clients. Or build a sophisticated caching layer on top of your existing game server, so you can share your latest gameplay data from your role-playing game or collectible card game with millions of clients, without having to worry about them hitting your server directly.
Cloud Firestore for C++/Unity is open for anybody to download and use as an open alpha release. This alpha tag means it still has some rough edges here and there. Specifically, the Unity version of the SDK is missing some of the more advanced querying features. And there's a good chance the API will change in the coming months, which means you'll need to change your method names in the future. But we wanted to give you a chance to try it out, see what cool stuff you can build, and let us know how we can make it better.
And none of this is to say that the Realtime Database is going away -- it's still a great option for many situations. In fact, the Google Doodle team just used it to power the Loteria Google Doodle that ran on the Google homepage in December. But if you're a game developer who's been pining away for all the great new features that Cloud Firestore has available, you can stop all that pining and start building.
The Firebase Unity SDKs are now compatible with the Unity Package Manager. This means that in supported versions of Unity, Firebase will be easier to keep up to date and the Firebase plugin will no longer have to be mixed in with the rest of your game’s assets. The process of doing this is automated with an open source tool that used to be known as the Play Services Resolver, but is now known as the External Dependency Manager for Unity, or what we've been calling "EDM4U" around the office.
Note, of course, that using these tools are completely optional. We know that many of you prefer having manual control over all of your libraries, and if you want to keep managing them yourselves, you're more than welcome.
Our friends over at Google Analytics have built a number of new reports that will be of interest to game developers, business analysts, or anybody who wants to grow a successful gaming business.
They've added new dashboards centered around user acquisition, retention, user engagement, and monetization, along with some new reports and visualizations that you've been asking for, like First-time Buyers, Revenue Heartbeat, User Engagement (in game days), and trending DAU / MAU (a good measure of "stickiness").
These new reports are available for all Firebase developers if you've linked your Firebase project to a GA account. You'll just need to head on over to the Google Analytics console to see these reports in detail. For more information, be sure to read the Games reporting article in the Analytics help center.
And what better way to celebrate some new launches than with an updated product page on the Firebase website? Head on over to the new Firebase for Games product page to get a better idea of everything Firebase has to offer to the game developer community.
While we are disappointed that we couldn't spend last week seeing you all in person, we hope that what we've been able to share as part of the online summit has made you a little more interested in adding Firebase into your next new game. We have some documentation and videos to help get you started, and can't wait to see what you build next!
Stay safe, everyone!
This article was cross-posted from the Google Developer Blog. Firebase will be participating in the Google for Games Developer Summit on March 23rd at 9:00AM PT to share how we're making Firebase even more powerful for game developers!
Last month, Game Developers Conference (GDC) organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community. GDC is one of our most anticipated times of the year to connect with the gaming industry. Though we won’t be bringing the news in-person this year, we’re hosting the Google for Games Developer Summit, a free, digital-only experience where developers can watch the announcements and session content that was planned for GDC.
Google for Games Developer Summit
The Developer Summit kicks off on March 23rd at 9:00AM PT with our broadcasted keynote. Immediately following, we’ll be releasing a full lineup of developer sessions with over 10 hours of content to help take your games to the next level.
Here are some types of sessions to expect:
Sign up to stay informed at g.co/gamedevsummit.
Support for the game developer community
We recognize every developer is impacted differently by this situation. We’re coordinating with the GDC Relief Fund to sponsor and assist developers who’ve invested in this moment to further grow their games.
We also understand many developers were looking forward to sharing their content with peers. To help with this, developers can use YouTube to stream events from small to large using tools like Live Streaming and Premieres.
We can’t wait to share what we have in store for gaming. Discover the solutions our teams have been building to support the success of this community for years to come.
Stability is critical to your app’s success, so we’ve continued to enhance Firebase with tools to help you maintain high quality apps. This includes bringing the best of Fabric’s crash reporting tools to Firebase. Many of you have made the move from Fabric to Firebase yet still have questions like “Why do I still have ‘Fabric’ everywhere in my code?” or “Why does it feel like I am in Firebase, yet still in Fabric?”
We can now lay your questions to rest. We're excited to announce Firebase Crashlytics SDK is in Beta!
With the Firebase Crashlytics SDK, you can remove all Fabric dependencies, such as references to Fabric’s APIs in your code, giving you a much cleaner codebase.
The Firebase Crashlytics SDK is also designed to be intuitive and consistent with all other Firebase SDKs. For example, the Crashlytics SDK has consistent package names, API design, and initialization as other Firebase SDKs.
The Crashlytics SDK also supports Mac Catalyst apps, in addition to iOS, macOS, and tvOS apps. This new feature makes it easier for you to continue building apps for Apple devices.
We’ve also open-sourced the Crashlytics SDK to further increase the extensibility and transparency of our platform.
Combining analytics data and crashes helps you unlock additional insights into your app’s stability. The Firebase Crashlytics SDK works seamlessly with the Google Analytics SDK to provide features such as crash-free statistics, the Latest Release report, and Breadcrumbs. With Breadcrumbs you can see the steps a user took that led to a crash. This insight helps you reproduce and fix issues quickly. Google Analytics replaces Fabric's legacy analytics engine, Answers, so we encourage you to add Google Analytics to your apps.
Try it out!
Ready to begin developing with Firebase Crashlytics SDK? If you are upgrading from the legacy Fabric Crashlytics SDK, read our upgrade guide. Developers new to Crashlytics should begin with our getting started docs. Interested in the Crashlytics source code? View our Android and iOS repositories on GitHub.
We'd love to hear your feedback. As always, you can reach out to us through our official support page. Happy developing!
Did you play the interactive Google Doodle for the Mexican card game “Lotería” last December? If not, you can still check it out here. Lotería is a multiplayer bingo-style game that supports up to five players per room. In the digitized Doodle version, you can play with random people around the world or create a private game with your friends.
The Lotería game was developed in JavaScript primarily by one engineer over a few months, and the game's usage jumped from no players to millions literally overnight. The multiplayer component that supported it all was built entirely with the Firebase Realtime Database, which meant we could spend more time developing a great user experience, and less time worrying about infrastructure. Let's look into how we did it!
/games/{gameId}/deal = {card, time, countDown}
To detect the winner, all players listen to another database location at /games/{gameId}/winner. When a player clicks “Lotería!” and has a valid winning pattern on their board, we write their ID to that location.
/games/{gameId}/winner.
Often, there’s a close tie, so we use Reference.transaction to ensure that only the first player to call, “Lotería!” is declared the winner. We do this by making sure that /games/{gameId}/winner doesn’t already have an existing value before we write anything to that location.
Reference.transaction
/games/{gameId}/winner
To create random public games, we utilized Cloud Functions for Firebase in conjunction with the Realtime Database.
When a player selects “Random Match,” their player ID is written to the location /queue/. A Cloud Function is set up to trigger when a new entry is created, and it checks whether we have enough players to start a game. If so, it creates the game at /games/{gameId}, and writes the gameId to each player's entry, like so: /players/{playerId}/gameId = {gameId}
/queue/
/games/{gameId}
/players/{playerId}/gameId = {gameId}
Players listen to gameId on their own database entries, so they know when to transition to the gameplay screen.
gameId
Since there are a lot of players connecting simultaneously, and the Cloud Function is asynchronous, we once again used a transaction to ensure that players are removed from the queue and placed into games atomically. Making one game at a time atomically could create a bottleneck, so instead we create as many games as possible in one transaction.
Interactive Google Doodles get millions of players, so we needed to make sure that the database could handle the load. To do this, we sharded the database into multiple instances. Each instance can handle a limited amount of traffic, so we estimated how much traffic we expected to have. To do this, we wrote a load testing bot that could be run repeatedly and measured how much load this generated on a single instance. Then, we extrapolated that number to how many players we expected, which then gave us the number of instances we might need.
However, there is a downside to having too many instances: if players are spread too thinly, it might take longer for enough to connect to one instance to start a game. To solve this problem, we created an entry in the default database instance called “shards.” This was a number that could be adjusted from 1 to the maximum number of shards we created. Clients read this value and only used shards in that range. Since the Doodle was only live on the Google homepage for a short time, we updated the shards value manually through the Firebase Console, setting it lower when there was less traffic, and higher when there were spikes. Naturally, this process could be automated for a longer-running application.
