 So hi guys, I'm Soha and I'll be talking about the Firebase real-time database today. So can everybody hear me at the back? Yeah? Cool. So let's get started. Quick introduction to myself. I'm Soha. I'm the founder of this company called Trivius. I've created an app called Voice Recorder in the Play Store. It has about a more than a million downloads. I'm also a Google expert on user experience. Android UX consultant works with various companies across the world. I'm also an organizer with Beallatroid. We conduct monthly meetups and so on. One of the largest communities in the world on Android. I'm also one of the mentors at the Google Launchpad accelerator. In case you want to discuss this talk or if you have any questions, feel free to reach out to me on Twitter or on email. Okay, so this is the agenda for today. We have a lot to cover on the Firebase real-time database. We'll introduce you to the Firebase platform. How many of you have heard of Firebase? Okay, so most of you have heard of Firebase. So we quickly introduce you to the platform and then to Firebase real-time database. And we see what that is all about. Look at the API for Firebase, how to read and write data, right? How many of you use Firebase real-time database? Okay, couple. So that's good. Okay, so I'll show you how to read and write data from the database, right? You also look at some of the listeners. And then finally, we look at some of the caveats of Firebase real-time database. It's not a perfect database. There are lots of issues. So we'll discuss some of those issues and how to work around those issues, right? Discuss some of the design patterns of how I've seen Firebase being used in the industry. And finally, we look at some of the alternatives, right? Lots of alternatives. And I'll tell you why Firebase is better in some respects than the alternatives. So let's get started. So this is the Firebase platform. Firebase is basically a company that was launched back in 2011. And then Google acquired it, I think, somewhere in 2014. Before Google acquired it, it created this product called the Firebase real-time database. That's the product that we'll talk about today. But earlier this year in Google I.O., Firebase rebranded itself. They are now a lot of products under the Firebase banner. There's analytics, there is the storage, there is app indexing, remote config, and so on. So there are lots of different products. We'll not talk about all of them. We'll just talk about the Firebase real-time database, okay? So as the name suggests, Firebase real-time database is a real-time database, right? It's basically a database and it's real-time in nature. So what is that? To illustrate that, I've created a sample application, okay? This is a completely fictional application. And this will help me explain some of the concepts of the Firebase real-time database. So over here we have a movie booking application. Again, these are purely prototypes I created just for the presentation. So let's say I open the application and it takes my location and it shows the movie listings around me, okay? Very simple application. So I'm browsing for the latest movies. For example, this Doctor Strange, this Jack Reacher, and so on. When I click on any movie, it shows me details about the movie. It shows me the reviews and so on. And then I can book tickets for that movie, right? Clear? Very simple application. And I'll show you how to use Firebase real-time database to enhance this particular application. Again, you can use this as an analogy to use Firebase real-time database in your application. It could be an e-commerce application. It could be a news application, whatever, right? Now let's assume this application is on the Play Store and it's doing fairly well, okay? It's a popular application. People are using it. And I'm also generating a lot of revenue, right? So now I want to make this application better. I want to take it to the next level. So what I want to do is increase engagement and retention in the application, okay? I want people to spend more time in the application, okay? So now there are many ways of doing that, of course. Most of the ways will be dependent on the sector or the business that you are in. For this application, what I'll be looking at right now is introducing real-time features in the application to enhance it, to increase engagement, clear? So we talk about some real-time features. So one real-time feature we could add to the app is a real-time chart. Okay? It's like any chart. But let's say I'm browsing for movies. I'm on Doctor Strange and I want to ask my friend, okay? You know, do you want to watch this movie? How's this movie? Have you seen this movie? Or let's plan for a movie, right? That is something which is very interesting. It's really exciting because that brings inner level of interactivity inside the application. Okay? Again, you're not leaving the application inside the application itself. You can chat about the movie itself. You could also have real-time polling in the application. So for example, a couple of your friends are going to a movie and you want to discuss, you know, which movie should we go for? So you can open a poll and again, it's a real-time poll, a real-time poll. So your friends can poll on it on any movie and you'll see the updates coming in real-time. So if somebody votes for Doctor Strange, or for Jack Reacher, or PennFerner, you can actually see that life count increasing. Okay? All these features are designed to increase the engagement in the application. So our application has changed from a very popular and profitable application. But which is very static in nature to something which is completely dynamic in nature. Right? Now, not only are you coming to the app to book a movie, but to actually discuss the movie. Right? Just imagine the kind of effects it can have on your application as well. So people can come, they can look for movies, they can discuss movies different. It's a completely new kind of application and it increases the engagement and it increases the revenue for your app as well. Okay? So it's a completely new app right now. So now we'll see how to kind of implement some of these features, like real-time features. Now a lot of your software developers, how many of you are developers here? Okay. So most of you are developers. So you're very familiar with, you know, APIs and server side, client side stuff. So you must be thinking it's all very easy to do in a simple endpoint, right? I can create an endpoint on my server and that will basically take care of all these things for you. I can create an endpoint for polling. I can create an XMPP server for testing and it'll take care of everything. Right? It's that simple. How many of you have actually created an XMPP server? Nobody? Okay. So you don't know the amount of horror that creates you because it's very, very difficult. The client library is not that easy. And again, to kind of get everything together on Android is very, very difficult. So instead of doing that, you can look at five years real-time data. Now what are the challenges that we're talking about real-time updates? Okay. Now that is something which is very difficult. Whenever any device, for example, you or your friend is updating a port, the update has to be propagated to all devices that are connected and it should be in real-time. So you should see the update in less than 100 milliseconds or 200 milliseconds, depending on of course the network latency, but should happen very, very, you know, in, in, in your real-time. Right? Also you have to synchronize state, which is a very, very difficult thing to do. Right? Why is it difficult to synchronize state? You can see a lot of other things, even like, just imagine if 200 people are hitting the same resource at the same time. Who do you trust? How do you update the resource? How do you do conflict management? All these are very, very difficult things to do, especially in a real-time environment. So doing all of this is not trivial. And especially if you talk about offline, how many of you have used a chat app which doesn't work offline, where you can't send messages offline? How many of you? A lot of you have used apps which don't work offline and we know that it can be a very terrible experience. Right? If you send a message, it asks you to send it again when you have network connection. Now that is not great, right? You have to build apps which are offline, especially if you're in a country like India. So when you bring an offline into the whole picture, again, complicates everything, right? Because you know, you're adding, removing stuff to the database when you're offline. When it comes online, the whole state has to be synchronized, which is a very, very difficult thing to do, right? Because the database has been updated by other people when it was online. And then you're offline, you have a completely different state, mixing the states, synchronizing the whole state is, again, very, very, very difficult thing to do. Again, building client and server libraries for this application is going to be very difficult design. You're going to deal with libraries like retrofit, rest, you're going to deal with rest, parsing, doing a lot of other things. So again, none of these things are trivial to do. You have to spend a lot of time doing it and then testing it. So instead of doing that, you can use the Firebase real time database, which does a lot of this for you. Now what is Firebase real time database? Essentially, it's a hosted JSON database. It's a no SQL database, basically a JSON database. It's hosted for you on the Google Cloud. That means it works well, it scales well, and so on. It provides you all the real time updates and all the facilities that you need to have all these kind of real time features like chat and so on. It's completely scalable in nature. So tomorrow, if you have a movie booking application and 10 people are using the poll feature, and then the next day, a million people are using it, you will not get to know the difference the next day. You'll only get to know the difference at the end of the month when you see your business. So that's the only way you'll find that out. Apart from that, it handles all these consistency and state issues. Everything is handled for you. It works offline by default, which is great. You don't have to add extra libraries for it to work offline. It's very, very fast. So all these updates are in near real time, updates are in milliseconds. The pricing is very good. The pricing depends on the amount of data that you have, not on the number of people connected to the server. So that is something which is very, very good. It has cross platform support. So if you have applications across different platforms, again, even then it's a great platform to use. It has libraries for the web, for iOS, and so on. Also has a great admin API in case you want to make changes in the back end. And it has a great open source library called Firebase UI to do some of the UI things. For example, if you want to use a recycler with Firebase data database, all of those things are also handled for you. So let's get started. Let's see how to use Firebase real time database. Again, imagine this is a cloud hosted database. There is no other server involved in the middle of it. It's just the database. So to include it in your application, all you have to do is add the compile dependency for the Firebase database. If you're already using Firebase, that's the only line that you have to add, the one about the Firebase database. If you're not using Firebase, you have to add all these lines to your Gradle configuration, simple, until just do everything for you. So now you must be wondering, right, it's a real time database. I'm doing so many things. It must be really difficult to do. For any kind of networking operation, imagine the amount of things you have to do. You have to do networking. You have to do the REST APIs. You have to do parsing. You have to do queuing, threading, serialization, deserialization. There are so many things that you have to do. But this is all the code that you need to make an update to the Firebase database. That's it, like three lines of code. You don't have to worry about threading, queuing, networking, all that stuff. Everything is taken care of from the API. So in the first line, I'm getting an instance of the Firebase database. Second line, I'm getting a reference to any node in the database. Remember, it's a JSON database, so it will have different nodes. So I'm getting a reference to a node, and just setting a value there. So it's a node, so it's a JSON database key value pair. I can set any value to it. It can be an object. It can be a string integer and so on. Clear? OK, three lines of code. Now we've written a value to the database. Let's read some values. The first two lines are the same. You just get a reference to it. You can handle it as a single turn. You can add dagger or whatever to kind of manage this database reference for yourself. Now remember that this is a real-time database, not a static database. So updates or queries to the database will not be like a static database. Because the database is constantly getting updated. If somebody is chatting with you, the data is constantly coming in. Somebody is updating a whole resource. It's constantly getting updated. So rather than just querying something, what you do over here is you would add a listener to it. In this case, I'm adding a value event listener. A value event listener lets you capture the state of any node in the database. So the different nodes in the JSON database, I'll add a listener to that node. Now if anybody else updates that node, I will get an update. I'll get a callback in onDataChange. Very, very straightforward. Now you have to keep in mind that this onDataChange is a little tricky method. You will get the whole state of the node in this method. You'll not get updates, but you will get the whole state of the node. Now for example, if I'm having a chat message or a chat node, and there are 1,000 messages in it, if I attach a listener to that node, I will get all the 1,000 messages as a callback. So for example, if I have 1,000 messages and somebody has added a new message in the chat, now there are 1,001 messages, I will get all of those messages here in this callback, every time. Now you must be wondering it's not an efficient process. Don't worry about that, because Firebase will do delta updates with the cloud, so that it will just get that one extra message from the cloud. It will give you all the 1,001 messages, but it will get only the extra message from the cloud. It will just aggregate it and give it to you. Now this listener has certain use cases. So for example, it's the same application. In this case, what I'm doing is I'm opening a poll for people, and over here, I want to get the status of all the elements in that poll. So I want to see what's going on with this movie, that movie, and so on. In this case, I would put a value event listener, and every time there's an update to the poll, I'll get the whole object, because there are not a lot of objects inside this, I'll get the whole node over here, and I'll see the status of it. And I can just set it to a recycling or something. So I'll just get a callback in on data change. Now you must be wondering, sometimes I might want to do simple queries, which don't have to have a real-time kind of update scenario. For that, I can just use the method addListener for single-value event. In this, I can just query it, and I can get the current state of any node. In this case, I'm getting the state of the messaging node, and I get what is the state of that. So I'll get just one callback, and I'll get the current state. It'll not keep giving me a callback, not keep giving me updates. This is also this interesting method called child event listener. This is the method that you should be really paying attention about. So in this, you get callbacks whenever a child is added, changed, removed, moved, and so on. So let's see this with an example. So this is where you can use it for a chat application. So let's say you have 1,000 messages, and I add a new message to the chat screen. Over here, whenever the new message is added, you'll get a callback on child added, and you'll get just the new message, so that you can animate the new message in, or you can show that message, and so on. Let's say somebody is deleting a message, you get a callback, you can delete it from in-cycle. This message is very versatile, and I've used this a lot. So this is the child event listener. There's lots of different callbacks. Next, let's look at querying. So we looked at how to read data. Now let's look at how to filter and sort the information. So again, just like before, you can get a reference to your database, and you can call .child on it to get the child of that particular node. Remember it's a JSON tree, so there are different nodes, and you can have children on those nodes. And then you can say order by child. So if there are different fields in that particular node, you can order by one of those fields. So in the case, and then you can just add a listener to it. So in case of a chat application, you want to order everything by timestamp. It's very obvious, so you want to get all the results ordered in a timestamp manner. So you can do that very, very easily. Once you do that, you can set a listener to it and do everything like before. Apart from sorting, you also have the option of filtering, getting the last few values, and so on. So all those facilities are different. Now, Firebase Realtime Database is completely offline. That's one of the biggest advantages. You can read as well as write data when you're completely not on the network. And this is a real cool thing, right? Just one line of code. Get instance.setPersistenceTrue, that persistence enableTrue, will enable the app to work completely offline. You can add stuff, you can remove stuff, can work completely offline. There is no extra code. You don't have to attach it to offline serialization utility or do anything for yourself. Everything is handled for you, which is really, really cool. As soon as you come online, it will basically sync the stage and give you the latest version of the database. So another thing that you can do is you can get a reference to a node and say that you want to always sync it. You want to keep synced true to true, right? So in this case, what happens is if you have a node you're really ingested in, even if you don't have a listener attached to it, the state of those nodes will be synced always with the cloud, which is something which is really cool. And then after that, you can order, you can filter and add listeners to it. So even if you don't, so all the time, right, even if you open the application of its close, you'll get updates. And the whole data will basically be synced. In this case, I have used the limit to last method, which allows me to filter by the last four results. Next. So that's pretty much it about the core APIs of Firebase. And you can see how simple it is, right? There's not a lot of code to read stuff, to write stuff. It's just a very simple database with very, very path. Handles all the real-time stuff for you. Now, it's not perfect because it's very simple to use. It doesn't give you a lot of control. And that's how there are a bunch of caveats in it. You should understand that caveats to see where you can use it in your application. So first of all, it's a no SQL database. And like any no SQL database, you have to structure the data very, very intelligently, right? You cannot structure it like a relational database. Relational database is just working in a different way. So this is a sample JSON file or database or whatever. This is sample JSON schema for that. So here, you have a chats node at the very top that contains a list of all my chat messages. Inside the chats, there is a node for each chat conversation that I'm having. So the first conversation has a title, which is my name. It has a bunch of messages inside of it. So it has another node called M1 for the first message, a node called M2 for the second message, and so on. Is this clear? Simple structure. If you think about any chat message, you would probably organize it like this. So can you tell me what are the problems with this? What could be the possible problem? If I create my database schema like this. Any ideas? Yeah, sorry. Changing the structure. Migration is always difficult. That's going to be an obvious thing. What next? What are the other problems that I'll face today? I'm sorry. Messages of all users. Exactly. So in certain scenarios, I'll explain what he just said. So for example, this is a screen where I'm seeing the chat messages. It's basically showing me all the conversations that I'm currently having. You can see that there are three conversations. Clicking on each conversation will take me to the conversation screen, and that will be a detailed message screen. Over here is just a list of conversations. First conversation, second conversation, third conversation. Now, just for showing this screen, I have to basically download the whole database, especially the whole chat's node. Do you agree? Even if there are 1,000 messages inside the chat node, I will basically download everything. But for this screen, I basically need to know what is the latest message that's in this conversation, latest message in that conversation. But even for that, I have to download everything, the whole node, which is not optimal. So I have to download all the messages for almost every screen. So in the NoSQL world, we'll basically not organize it like that. You'll organize it a little differently. So over here, I have the chat's node. Over here, I have different nodes inside it, like the first is called 1. Inside that, I just have the title of the message and the last message that I sent to the person there. It just contains the last message, some image URL, and a timestamp. It doesn't contain all my messages. So if you go back to the screen, you can see that it's basically mapped to this screen. Again, I'm just talking about NoSQL database. It's not related specifically to Firebase. It's just a general observation. So if you see this screen, it's very, very optimal. I'm not downloading any extra messages. Is that clear? So this is very optimal. I can basically download it and sync just the chat's node. But you might be asking, where are my messages? My messages are just below that in the messages node. Now my messages will have a more detailed description over here. The first one is called 1. Inside that, I have the first message, the second message, and so on. So if you see a detailed conversation, the first message is, OK, what's that movie again or whatever, and then the second message comes in. So there are advantages and disadvantages to this approach. The advantages are that I don't have to load extra data for all the screens. The disadvantage is that the data is duplicated. There is some data over here. The last message is over here, as well as in the other node. There's clear data duplication, which you would not do in a relational world. Relational world says that data should be only once and lots of other things around that. Other disadvantages, as well. But if you're designing for Firebase and you want real-time data, this is how you have to structure your data. That's one of the first caveats. You basically have to think a little differently and restructure your data. Clear? Next, this is a very important question. You have to ask yourself which sinks in the background. Now before I answer this question, I want to ask you, have you ever come across the problem where you have a service and that's getting killed every couple of minutes? Have you ever faced that problem? Yes? How many times in a day do you face that problem? Every day, right? If you create a service, you know that's going to get killed in the background. And it's very difficult to design around that. It's the same thing in Firebase, as well. Let me illustrate that with an example. So let's say it's 2.15 AM. This is the timeline. I'm not sure if you can see it. But at 2.15 AM, 2.15 PM, I get a message saying that, or I send a message to somebody saying that, OK, let's watch this movie or let's go for this movie or whatever. I open the app and I send that message. Now after a couple of minutes, I go into the background. So this is a sample news application. So I'm surfing news or the phone is in the background in those mode or whatever. And at 3 o'clock, at 3 PM, a couple of minutes after I send the message, I open the app again. And then I find that there's a new message from my friend. So that person has replied to me saying that, OK, I would like to see this movie. What is the problem over here? Yes, exactly, right? So basically, this is fine. But I was supposed to receive, if you see that small notification over there, I was supposed to receive a notification at 2.47 PM when my friend replied to me. That is something which is very, very important. Because I came back at 3 o'clock and I found that my friend had sent me a message, but I didn't get a notification about it. That is very important. You're supposed to receive a notification. Even in Firebase, you will not receive that notification because many phones of the service or the Firebase connection will be killed. So how do you work around such issues in a typical chat application or normal application? Pushmesting, simple pushmesting. Now, doing pushmesting in Android is easy, but doing it in Firebase real-time data is a little difficult. It's not trivial because, again, remember that you don't have a server. It's just a database. So doing that is very difficult. So what you have over here is a separate SDK for doing stuff stuff. It's called the admin SDK. And let's look at what it does. So this is a simple example. There are two devices. In this case, both the devices are in the connected state. Both the devices have the app open, and they are in the foreground. So when one device sends an update to the Firebase Cloud, because the other device is connected to it and the connection is live, the other device gets the update instantly. Clear? Great. So this is a typical use case. But for this, the other app has to be in the foreground or has to be using the app very frequently. Now, take another example, where the second device on the right-hand side is basically not online. It could be an offline state. It could be in the background state or whatever. So in this case, I'm pushing an update to the Firebase Cloud. But the second device is not connected. So I cannot get an update on it instantly. What happens there is you have to create a server, which will basically send a push notification to my client. To connect to the server, we use something called the admin SDK for Firebase. So the server could be an app engine instance running Java or whatever. And basically, it will behave as a privileged client for Firebase. Just like as a client, you are listening for changes on the Firebase, like for any node, a similar way that server can continuously listen for updates on the node. But it will have extra privileges, so it can access pretty much anything in Firebase. Whereas your clients can only access their client's data. So this server SDK will get the update because it's listening for it. Then it will send a push message to my client, waking it up, either sending it a notification or asking it to get woken up. And then it can basically sync back with Firebase and get the latest updates. So this is a small caveat of the Firebase real-time It's not a very big problem, but you should be aware of it if you're building completely real-time applications because devices can go out of sync and you have to bring them back into sync. Okay, clear? All you have to do over here in the second device is just wake it up and just call get instance and get reference and keep sync. Firebase will do the sync automatically, but you just have to wake it up because it's not in the woken up state. Clear? Some of the other caveats of Firebase real-time database, it's very good, it's very powerful as you've seen, but the API is not that flexible. Okay, it gives you a lot of power and the API is so simple to use. That also makes it inflexible because you cannot use it in all cases. If you're just doing like a get, post 10 of an update, you don't need a real-time database, right? And you cannot use this for that. Then the search query is not that easy. So a lot of things are taken for granted in the relational world. For example, the where clause, right? We do something, you know, order by or where and you use wildcards, right? So you select string from whatever and then you use the where clause just to search for stuff, right? Just to find stuff. Doing that in Firebase is very difficult. They don't have a where with wildcards equivalent, okay, which is very, very difficult to do. This is one of the requests that we have kind of shared with them. But currently there's no way around it. To do that, we have an integration with Lucene. Lucene is basically a kind of a database dedicated for search and you have to integrate that. They have an integration guide so you can use that to query everything. Also, you cannot run server-side code. You are probably used to running server-side code if you want to query something. You want to update the database every single day. But that is not possible if you're using Firebase real-time database. You can use the admin SDK to do something on the server-side but you have to keep, there are lots of considerations in mind for that. Migration as somebody said is always an issue, especially so for Firebase because it's a very specific product and the database can be accessed by the console. So you have to keep in mind how to migrate in. Just have to plan for that very well. As I said, the use cases are pretty limited. You only have to use it for such real-time use cases. And it works on play services. What is the disadvantages of that? What is the disadvantage of a library that works on play services? Some phones, it's not there. So phones in China, right? Any phone that's not on the play store, you'll not be able to run this, okay? So the app will not work. You have to create a backup plan for that. What other problems? Yeah? 65K, my third little bit, brilliant, right? It will definitely cross 65K for sure. What else? Version, right? Very, very important. Most people don't have the latest version of play services. So include the latest Firebase messaging API, like 9.8 or something. Almost nobody has it, right? Although Google might tell you that everybody has it. But these days the SDK is around 78 MB, I think for play services. Every update is very, very big. So it's very difficult to get the latest version. So you have to be careful on which version of the SDK that you're using, right? Finally, it's also hosted. So it's on Google's cloud. So you have a requirement if it, that it should be on some intranet, okay? Or it should be on a private network for let's say a financial customer or something. This is not possible. I've actually had to say no to customers because they wanted it on their intranet, okay? These are some of the key aviates, okay? Now let's finally look at some of the design patterns of Firebase real-time database. I'm talking about architectural design patterns, not UX design patterns. So I've seen Firebase being used in three different ways and I'll quickly illustrate those. First is the core use case, okay? So if you're building an application which is let's say a, a cab application, right? It's a real-time application at its very core because you want to see which are the cabs around you, right? Similar case for a chat application. It's completely real-time in nature. For that, you have to use Firebase as a core application. It will do all the real-time stuff for you, okay? There are lots of other use cases for this as well. Now there are the second ways, a modular approach where the real-time stuff is not your core functionality. For example, like my movie booking application. For that, I'm not using Firebase for getting the movie tickets or anything like that but it's just added to increase the engagement or some other functionality. Madding chat, madding pools, interaction and so on. There are lots of really good apps which kind of demonstrate this. For example, Twitch, how many of you use Twitch? Okay, it's a live gaming streaming service. So for that, their chat completely works on Firebase and you can see how instantaneous it is, okay? Because if you're gaming, right, and you're commenting on the game, it has to be very, very instantaneous. And the third use case is auxiliary. So in case you have an application which is just like a normal use application, you don't want to integrate it as a core feature. You want to integrate it as an auxiliary feature like customer support, right? That means you want to have customer chat in your application. Some kind of customer service or something. You can do that using Firebase, your 10 database. It's a great alternative to example, right? Or for troubleshooting. So for example, if you want screen sharing capability in your application. So when the customer contacts customer support, they can share their screen and basically troubleshoot it with you, right? All of those features can also be done using Firebase. So these are the basic three different kinds of use cases that I've seen. And your app can fall into any of these categories. And for all of these categories, you can use Firebase Field Time Database. Now let's quickly look at some of the alternatives to Firebase Field Time Database. Now I've told you what it does and what it doesn't do. So I've given you kind of a good picture about it. These are some of the alternatives to Firebase Field Time Database. First of course, you can have your own server and do all of this yourself, which is very difficult. If you don't want to do that, there are like, there is an option called Realm. How many of you use Realm? Okay, so I'm guessing you have used the Realm, just the database like offline database and it works really, really well. I've heard fairly good things about it. There are certain issues around it, but it's good. And I'll be discussing them in a little more detail in the next slide. So Realm is one option because they've launched their Realm mobile platform I think last month, which does things very, very similarly to Firebase. You can sync all your data on a device to the cloud. It's fairly good in nature. The next is Couch. How many of you have heard of Couch TV? Right, we also had a meetup on Couch TV. The folks had come down and we had discussed how you can use that for doing similar kind of synchronization. Again, Couch TV is reliable, but a lot of the Android support is not that great. It's a project from Apache, but a lot of stuff is not that great. There are other options as well. There's an option called Rethink TV and Gun. I think both of those are open source solutions. They're great solutions, but again, they don't have great Android libraries. So if you have to implement anything on let's say Gun or Rethink TV, you have to host the whole server yourself and you have to build the whole Android libraries. You know how you interact with it, how to keep the connection open and everything, how to handle offline, for example. So there are a lot of those challenges which are there. Let's look at REL mobile platform because I think REL itself is very popular. So it's good to kind of look at the advantages of that as well. So REL, like when you compare it to Firebase, is a completely object-first database, right? It's a native model-based database. What do I mean by that? That means that it's object-first, okay? Whereas Firebase is basically a JSON database, REL is completely an object database. So if you're dealing with objects on Android, REL is very, very easy to serialize these lights and with the cloud. You're not dealing with JSON as an intermediary, right? Which is great, right? Takes away all the problems in parsing and kind of creating and kind of persisting objects. It's very easy to use, okay? It's almost as easy to use like Firebase and storing data, reading, writing, all those things are very, very easy. The client-side libraries for both Android and iOS are excellent, I'm sure you've used that. And the good thing is they work around all the issues that are present there. The performance is great, right? Reading and writing is extremely fast. Some cases it's faster than SQLite, which is awesome. Offline experience is actually better than Firebase. So Firebase, remember, only has a 10 MB cache for its offline service. So you cannot stay offline for a long period of time, okay? Keep that in mind. So you can do reads and writes up to the 10 MB limit. After that, it just runs out of cache and any write will then be lost. So it's kind of dangerous in that sense. With REL, because it's an offline-first database, it just persists everything and it thinks when it comes online. So there's no limit on REL massage. Because of that, it's just really good. Finally, it also has built-in encryption support. A lot of you are building enterprise applications or e-commerce applications. You want encryption in your database. That's also built into REL. There are disadvantages of REL, and, of course, it increases the size of your APK and you are threading disadvantages. But essentially, these are the advantages. So hopefully this has given you an idea about the Firebase real-time database and compared it to a lot of the solutions out there. And let me know if you have any questions around Firebase. These are some of the links that I've used in the presentation. There are links about how to structure data. There's a really good presentation on that. There are links about how you can hook up LUCINE, which is the text-based search for Firebase and so on. So all these links will be available. The link to this presentation is already there on SpeakerDeck, as well as on the funnel. Hopefully this has been useful. So I'll be taking some questions. I think I have four minutes. Introduction, so question regarding... Hello. So is there any way, like easier way, to have hardware introduction with the Firebase? For example, if I have a robot or something and then if it's running and it's giving me data on my app back, then can I just hit a URL or something on Firebase because I'm pretty sure they won't have, you know, like macroprocessor label access or something. So do you have any idea about that? Sure, so like any library in Android, it's basically how you use it, right? So let's say you're getting a stream of information from your microprocessor. Either you can get it as a callback, you know, you're getting a callback or you're using RxJava, you're getting observables or something. So you're getting that stream of information and you can just keep on hitting Firebase. You know, I've shown you how to write data in a quickly forwarded way. Not directly, but it's like a method call. I'm showing you a method call. So as soon as you get the callback, so you have to integrate the whole thing yourself. You have to like integrate the drivers and all that stuff yourself. You have to create your own callback. Once the callback is there, you can use Firebase, like any other library, just to set value or something. But the great thing is perfect for real-time use cases, right? So for example, I know people who are using this on buses in the US. So each bus in San Francisco has a sensor. That sensor has been, you know, that sensor has location, information, other kinds of information. And it's all being related to the Firebase Cloud in real-time. I can share the URL where you can actually go and see all the buses in San Francisco running in real-time. So this is actually a perfect use case for like a real-time monetary system or something with hardware. Pricing and data sizing, because the price depends on how much data is stored and how much gets transferred. And also because of the volatile nature of the data itself. You know, data gets added, removed, and how exactly does the pricing work? Okay, so yeah, that's a good question. So pricing is all based on data. You can go to the Firebase site. They have certain pricing, so per GB they charge you some amount of data stored in the Firebase database. But the actual expensive part is the data transfer. That's what I have noticed. Because it's a real-time database, right? There will be a lot of devices connected to it. So if you have a chat room with 1,000 messages and 1,000 people are connected to it, the data will be sent everywhere, right? So data quickly multiplies. So that is the key thing that you have to kind of look out for. Because the data can quickly expand. The pricing can quickly increase. You have to be very efficient. You have to use the child event listener, if I can go back. How much time do I have a minute? So instead of using the value event listener, you have to use the child event listener, like this one, right? So that you get only the updates, okay? The other one also does delta things, but if you use this intelligently, you just get the updates, right? And then you just have to calculate that. I have found that it's actually on par cheaper than real servers, where you're maintaining the server, connecting to all those things. Because again, they are managing everything for you. The connection is managed. The scaling is managed. It's actually reducing a lot of infrastructure costs. It's reducing people costs. You don't have to maintain all of that. So overall, I feel for a properly structured schema, I think it's very cost efficient. Again, your mileage may vary. You have to see what kind of data you're sending. Any other questions? I think I'm almost out of time. So I just wanted to understand the use case for this keep sync true when you're not monitoring the changes, but you want to keep the notes sync. What is the use case for that? Okay. So, so for example, you want to open the app, right? And you are, let's say, browsing, you know, a list of the movies, right? You want to click on your chat messages and instantly that data should be there. You're not even connecting to Firebase at that point. The data is absolutely fresh, but it's fresh the moment you open the page. Okay. So that is the use case. So again, there might be a lot of use cases, but that's one example. Do we have time for one more question? Nope. Okay. Cool. So I'll take some questions offline. Okay. I'm almost out of time. Thank you.