To use the Firebase database we need to know what the data will look like and how to input it. In this video, learn how to use Firebase's database and build out a sample data structure.
- [Instructor] Here we are at the main console page of the dinder project we created previously. Let's open the database by clicking the Database on the left-hand side. At the root of our Database, we'll be making two children: history and posts. Unfortunately, we cannot create the nodes and leave them blank. Firebase just won't allow that. So I'll have to start with our history node. Under the history node, we will have a child for each user. For our example data, we will only have one user and that will be Steve.
So click the Plus icon to create a new child. Its key will be steve and he will have a list of posts, the first of which will be a post from Olga, so its key will be the ID of Olga's post, which is underscore zero and the value we will assign to that is true. What this value represents is that Steve has seen the post olga_0 and he's liked it in the application. And we'll add another child under steve by clicking the Plus icon again. And this will be a post from Leo with the ID leo_0.
Steve has seen his post and has not liked it, so we'll make that post false. Now Steve has seen a third post, so I'll click the icon for Plus again and that post is Leo's second post, leo_1, and Steve happened to like that one again, so we will add true. Now we can click the Add button and that will save it to our database. The next group node we will need to add will be for posts. So once again, click the Plus icon to add a new child. We'll name it posts.
And under here, we will create each of the posts Steve has seen. So our first one will be olga_0. Each post has several children. We'll use that same Plus icon again. Each post has a created time, which in this case will be zero. It has a text for Olga's first post. That will be, "great pizza." They also have a URL, which once again, because Firebase will not allow you to have blank data, we'll need to make that an empty string.
Next, we'll add a node for the user which this post will be olga. And then a viewedBy node which is a list representing the users that have viewed this post. So in this case, we only have one user that's viewed it, and that's Steve. We will add steve and set him to true. Now we have our second user, Leo, who has also made posts, but he has not seen Olga's post, so we don't add him under our viewedBy node. When we query for this data in the application, we're going to look at each post and determine whether a user key is under viewedBy or not, If it is not and the user has not seen that post, then we will show it to them.
So let's go ahead and add this post. And we'll need to create two others. Next will be leo_0. We'll add created time. That's zero. A user of leo. Its text will be, "wonderful ice cream." The URL again will be an empty string 'cause we can't have blank nodes. And then lastly, its viewedBy. We'll have both steve and olga.
Now the last post, also by Leo, leo_1 of created time, zero. A text of, "perfect salad." User leo, the url, a blank string, and viewedBy steve, true and olga, true. And that's the basic structure of our data. We structured the data in this way because Firebase will load all of the data under each location which means we don't want to nest data as much as fan it out.
For example, if we had made a main user's node similar to our posts or history, and under that user's node, we had steve, olga, and leo, then under each of them had a post nodes with a copy of every post and each of these posts comes with a list of the users that have viewed the post and a history node that had a copy of every post with a list of the users again, that's a lot of data to load and a lot of data to update if we just wanted to count the posts Steve has made.
In addition to that, if Steve has read/write permission on a node, he can also read and write all the data under that node as well. So there's a security risk then. Best practice is to duplicate the keys to other data sources to do additional queries to resolve it. Similar to joins in SQL, we want our data to be as flat as possible. Now that our placeholder data is in place, we can take a look at our rules by clicking on the Rules tab in our Database. In Firebase, data access and data validation are controlled by the rule definitions.
Right now, everything is able to be written to and read from as long as you're an authenticated user. That's great for development, but we'll want to lock it down and add a little validation to it. We'll cover this later in the course. In the example files for this video, I have included a data.json which contains what we have input by hand already. If you would like to use that, back on the Data tab, click the Menu button and select Import JSON.
You'll need to navigate to the file and upload it. Let's turn our attention back to the main application and use this data that we've stubbed out in the database.
- Setting up your project and Firebase account
- Creating the app container
- Setting up basic navigation
- Creating a splash screen
- Creating a login screen
- Creating a match feature
- Creating a post feature