Flutter and Firestore realtime Pagination

in today's video we'll implement paged fire store results and keep them real-time hey guys and welcome back to the eighth episode of the firebase and flutter series today we will perform the functionality of creating real-time regenerated data from fire store we won't have actual pages in the results instead we will use an infinite loading style functionality and as always if you head over to fall stacks comm you can find the full written tutorial with the link to the code that we'll use in this tutorial the code can be found at the top of the tutorial and you can download that as the starting project once you have the code on your PC you can open up the pub spec Tiamo and make sure you fetch all of the packages and before we continue I'd like to ask you what video you'd like to see next would you like to see the firebase remote config or we can do the video on dynamic links please leave a comment below and if you see a comment that you like please leave a thumbs up so I can see the number of people that would like to see a specific video now we can get back to the video for the implementation these are the steps that we'd like to follow we have to limit the number of requests to 20 we have to save the last document for reference on requesting the next set of results we have to keep all of these results in a list that represents pages of results when a real time listener fires for a certain page we have to then update that page of results only let's start with a UI and we'll create the mechanism to request more results you can open up the widget folder and create a new file called creation away list item this is a pattern that I showed in this video that you'll see in the top right corner now and basically what this does is fire a callback when an item has been created in the ListView within that file create a new stateful widget called creation away list item then you can create a new final function at the top called item created you can also create another property called child of type widget will pass both of these values in through the constructor then for the actual functionality of this widget will override the inert state function and all that will do is check if the created is not equal to null meaning we've supplied a function and if we have a function or we'll do is execute the function that has been supplied and for the bulk function we will return the child that has been passed in then if you press control P you can type in home view and navigate to the home view file put your cursor on the gesture detector and press control-shift or on Windows or option shift R on the Mac choose rap with widget and we'll wrap it with a creation away list item then we can supply the item create a function within this function is where we will run the logic to check if we have to request more data the check for us is pretty easy we'll check if the index modulus 20 equals zero that means when the index is 20 we know that we are at the end of the list and we'd like to request more data when this condition is true we'll call request more data on the model you can create the function on the home view model called request more data and this function will call the function on the firestore service called request more data you can do control shift or add create a function on the firestore service you can then define the type to return as a future then the first thing for us to do is move the actual lessening of the results into its own function it is the lesson to post real-time function and cut out the post that listens to the snapshot on the post collection we will create a new function of the void called request posts and inside the function you can paste the code that you just cut from the listened to posts real time function make sure that you add the request posts call at the top of the lesson to post real time function as well as for the function request more data we'll just simply call the requests posts function you can change the type to avoid since I made a mistake at the beginning the request posts in itself won't work at the moment so we have to do a few things to get it to act in a paginated fashion the first thing is to allow the query to be modified on the next request what that means in code is that we split the query from the request and subscription the second thing we'll have to do is limit the number of results then we have to keep track of the page being requested so we can set the correct page metadata and the last thing is to broadcast all of the results instead of the results that was requested for that specific page the reason for that can be seen in the home view model where you see when we listen to the data we set the posts directly to everything that's being passed in this is the post being displayed in the home view using the link so we can make use of this code without having to change anything if we simply broadcast all of the paged results whenever a new page of results has been added this makes it so that we will only change the functionality within the firestore service and the home view and home view model will have no code to be change we'll start with number one by splitting up the query from the subscription we'll create a new variable called page post query and we'll paste the post collection reference in there we'll start off with the order by call which you need if you want to start the next request from the last document you must also make sure to limit the number of results to 20 then we can put the page post query back the way we subscribe and listen to those document next up we'll make sure that we can continue requesting data from the previous results point for that we need to keep a reference to the last document snapshot in the results that was returned in the previous request go to the top of the class and create a variable called last document of type document snapshot then you can head back down to the request post function and we'll simply check if the last document is not equal to null and if that is the case all we'll do is update the page post query by calling page post square e dot start after document and then we'll pass in the last document that we sit next up let's create the page structure that we'll use to keep things simple we'll simply store a list of list of posts this is the most logical structure to use since every list of post will correspond with the page number that it's currently at this means we'll be able to have an index where we can update post if real-time results are being invited for a specific page will create a new called all paged results this will be a list of list of post models so every list index in this list will have a list and by using the structure we have the unique property that the length before we request the new results is actually the page number of the request being performed so we'll store the current request index using the length of the old paged results then we'll start with a paging functionality and logic the first thing we have to know is if the page that we are currently requesting already exists within the structure the way to check that is to see if the current request index is less than the length of the current set of results in the all page results so the way this works is if the index is zero and we have one item within the list that means that the page already exists and if the current index is the same number as the length that means that it's a new page so we'll add the value but in the conditioner we'll check if the page exists and if it exists we'll simply update the results of that specific page index with the new results that has been returned this means whenever this lesson stream fires again it will do this exact same check and if the current request is less than the length it will simply just update the current post results giving us real-time data for that page and if the page doesn't exist we'll add it as a new page at the back of the old paged results then the last thing within the paging functionality is to make sure that we broadcast all of the posts instead of the posts from the current result that's being requested we'll create a new variable called all posts and we'll call the fold function on the old paged results we'll give it a type of list of the model post and for the initial value we will construct a new list of type post what the fault function does is go through each of your items and allows you to concatenate them using your own internal logic what we will do we supply a function that gives us the initial value and the page items and we will simply add all of the page items into the initial value and return that as our function value this will build up all of the values in the old page results into one list and we can use that to broadcast over the posts controller this will now send out all of the list items whenever a page has been updated or a new page has been added the reason that this will still be efficient is because of the ListView Boulder that we are using in the home view this only builds the widgets that are on screen meaning we can have millions of results in the post and it was stolen at 60 frames per second and to finalize this functionality we have to do some basic guarding and then also set the last document so the next request starts from the correct position will create a new boolean variable called has more posts which has a default value of true then we can hit back down to the request posts function and after we check the lost document condition we will check if there is more results to be requested and if there is not we've already turned from the function then you can scroll to the bottom and after we add all of the posts onto the posts controller we can now check if the current request index is actually the last page being requested by checking if the current request index equals to the length of the results minus one and if this is the case we want to set the last document equal to the last document in the documents list on the post snapshot and for the final piece of logic we want to determine if there is more posts to request this will be a easy check for us since we know that we are requesting only 20 results at a time all we have to do is check if the latest results has 20 items in the posts value if it doesn't have 20 items it means that there's no more results to request to check that this works head over to the home view file and uncomment the request more data function call and if you run this code and you go through your view look at the results top one if you scroll to the bottom of the view you will see that there is nothing left and we know that these over a hundred results within the current database then you can go back to the home view and uncomment request more data and if you run this code now with the request more data functionality enabled you'll see that we can continuously scroll and load more results without any lag or any additional functionality to be added the request is too fast for us to show any buzzy indicators but if you want to see how to implement that you can go to this video link in the top right corner which shows you how to implement lazy loading in pure flutter and then just to check that this is in real time and I'm not fooling any of you to open up the firebase console and scroll down to some results that we know has been requested after the fact we'll go to the post 42 and we'll scroll down to post 42 was on the console we'll update the title to add a string at the back of it that says updated and once we press the Update button you'll see that the results still update in real time in that list and that is all paginated data that is loaded after the first request that is my implementation of paginated real time firestore queries please remember to leave a comment to the following question which video would you like to see next we can do firebase dynamic links or we can do firebase remote config leave your answer in the comments below and I'll see you guys next week

Channel: FilledStacks

Views: 16,958

Keywords:

Id: 1chV50D5BVU

Length: 12min 29sec (749 seconds)

Published: Sat Mar 14 2020