To use the Firebase database, you need to know what the data will look like and how to input it. In this video, learn how to use the Firebase database and build out a sample data structure.
- 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 post. Unfortunately, we cannot create the nodes and leave them blank. Firebase just won't allow that. So we'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. It's key will be Steve, and he will have a list of posts, the first of which will be a post from Olga. So it's key will be the ID of Olga's post which is _0. 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. We will 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 this post and has not liked it. So we'll make that post false. Now Steve has seen a third post, so we'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 root node we will need to add will be for post. So once again, click the plus icon to add a new child. We'll name it post.
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. So 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 viewed by 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. So we'll 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 viewed by node. When we query for this data in the application, we're going to look at each post and determine whether user key is under viewed by or not.
If it is not, then the user has not seen that post and 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. He'll have a created time of zero. A user of Leo, it's text will be "Wonderful ice cream," the URL again will be an empty string 'cause we can't have blank nodes, and lastly, it's viewed by, we'll have both Steve and Olga.
And our last post, also by Leo, Leo_1 of a created time zero, a text of "Perfect salad," the user Leo, a URL of a blank string, and viewed by Steve true and Olga true. And that's the basic structure of our data. We've 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 users node, similar to our posts or history, and under that users 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 post Steve has made.
In addition to that, if Steve has read-write permission on a node, he can also read and write all of the data under that node as well. So there's a security risk there. Best practice is to duplicate the keys to other data sources to do additional queries to resolve it. Similar to joins and sequel, 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 their 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