I'm trying to create a list of cards, those cards take information from Firestore a query (need .where) it all worked out until I passed my quota, a bit later I found out about this: https://www.youtube.com/watch?v=Lb-Pnytoi-8. I need to read specific documents with .where and post them in a streambuilder, I've thought of multiple options (mostly around Future, JSON) which non of them worked. I've theoretically thought of somehow pausing a streambuilder and reenabling it every pull-to-refresh or making a quota through a futurebuilder but I had no luck.
Here's my code:
Code
I couldn't find an efficient way to do this, any luck anyone?
Apologies for this question. For community members who seek the same answer: using methods such as initState, async or anything alike will cause the widget to rebuild - ergo send once more an API-request.
Related
Current State
I have a Flutter app which shows me a list of data from Firebase in a list view.
return new ListView(
children: snapshot.data.docs.map((DocumentSnapshot documentSnapshot) {
return _createRows(
documentSnapshot.data()['id'],
documentSnapshot.reference.id,
);
}).toList());
Problem/Question
But the list will get bigger and therefore the loading times will increase but much more important the usage of the read processes will increase exponentially. I also plan to add a search function.
Firebase docs:
[...] downloading an entire collection to search for fields
client-side isn't practical.
Is there a possibility to only query the used data from the ListView.builder and to do the search via Firebase?
(One possibility is shown here. However, this is not too advantageous for data storage use)
Also, there are a few third party sites, but I couldn't find any free ones in addition, I'm not sure whether the effort to implement in Flutter is worth it. e.g.elastic
I am curious to hear your suggestions
I decided to download all the data at the start of the app and then pass it around inside the app, as I have comparatively little data to download and a long stay in the app, it is most worthwhile.
I realised the search with the plugin TypeAhead.
I'm beginner in flutter-fire app [: And here i've got a simple issue but not easy to figure out.
When we use Streambuilder in the app, we can usually see awesome synchronization between UI and DB on time. I'm really feeling joyful when using Streambuilder. It seemed like only beautiful things would happen with Streambuilder.
Meanwhile, a suspicious question popped out. When we enter print('hello world!'); in the Streambuilder, we can see that RUN console is printing out the phrase every milliseconds, otherwise would be just printed once. It means that RAM usage is extremely increased. When it comes to DB synchronization, we can easily guess that the use of Streambuilder leads to huge usage of client-server communication fee, which in my case is Firebase fee.
So, here is my question.
Can i feel free to use Streambuilder when the stream is connected to DB(in my case, firebase)?
I'm worrying about communication fee between UI and firebase, because streambuilder seems like literally using huge amount of energy every milliseconds(IMO additionally, server fee) unlike normal builders. Especially when the length of collection is so long that reading the collection once may cost a lot of energy, the fee would increase a lot more on and on, because the streambuilder have to check thousands of firebase documents only to figure out a single line of condition.
I guess many backend-connected flutter methods use the Streambuilder, so someone could clearly figure it out how much we're gonna pay for Google when we use Streambuilder. I know it's quite ambiguous question, but hope you understand. [:
Content coming from the Firebase database, whether FutureBuilder or StreamBuilder, pays only for the query value that has been processed once, and after that, in case the same response value is the same for the same query, it does not pay for that cost and displays the stored list stored in the cache on the client screen again. .
And check that it's not being called on something like setState. if so, of course StreamBuilder is called again.
I have huge data and I need to bring ten items every time a user scrolls down, and I collect them together in my code, is there any method I can use to get this result.
What you're talking about is called pagination, and it's discussed in the documentation.
Firestore pagination does not support numeric offsets. You have to get the next page based on information in the last document in the prior page. That's what startAfter() is for when building a query.
If you want to paginate your data with Firebase, you could do something like this (in JavaScript):
let database = admin.firestore;
let snapshot = await database.collection('items')
.limit(5)
.offset(10)
.get();
This code will retrieve five items following the first ten. It works, but Firebase's official documentation recommends against it, adding "you still get billed for all the reads that you're offsetting." While not ideal, it's not a terrible option for pagination, assuming your average user isn't regularly accessing pages on the fringe side of your application.
Alternatively, you can follow this documentation for a more efficient option.
I want to know how to manage BLoC pattern for Firebase.
I couldn't find any example of BLoC for Firebase so it might be broad but forgive me.
I saw some basic BLoC implementation but those were basically fetch data or updating view in a active way not passive way also not through database(almost API JSON stuff).
So, I want to see how to handle some BLoC pattern for Firestore like get followed(passive way), when user update own profile info something like that.
Does anyone lead me to the correct way?
Any help is highly appreciated!
What BLoC pattern gives you is nothing more than a data stream that can be updated adding new data through the stream.sink.
Using Firestore you already have a data stream, so you might not need BLoC.
If your application requires a more complex logic you might update you BLoC data adding a listener to a firestore ref in the root widget to have db and bloc always in sync (maybe with multiple blocs for multiple db refs).
After watching a fair amount of youtube videos, it seems that Google is advocating for multipath updates when changing data stored in multiple places, however, The more I've messed with cloud functions, it seems like they're and even more viable option as they can just sit in the back and listen for changes to a specific reference and push changes as needed to the other references in real time. Is there a con to going this route? Just curious as to why Google doesn't recommend them for this use case.
NEWER UPDATE: Literally as I was writing this, I received a response from Google regarding my issues. It's too late to turn our apps direction around at this point but it may be useful for someone else.
If your function doesn't return a value, then the server doesn't know how long to wait before giving up and terminating it. I'd wager a quick guess that this might be why the DB calls aren't getting invoked.
Note that since DatabaseReference.set() returns a promise, you can simply return that if you want.
Also, you may want to add a .catch() and log the output to verify the set() op isn't failing.
~firebase-support#google.com
UPDATE: My experience with cloud functions in the last month or so has been sort of a love-hate. A lot of our denormalized data relied on Cloud Functions to keep everything in sync. Unfortunately (and this was a bad idea from the start) we were dealing with transactional/money data and storing that in multiple areas was uncomfortable. When we started having issues with Cloud Functions, i.e. the execution of them on a DB listener was not 100% reliable, we knew that Firebase would not work at least for our transaction data.
Overall the concept is awesome. They work amazingly well when they trigger, but due to some inconsistencies in triggering the functions, they weren't reliable enough for our use case.
We're currently using SQL for our transactional data, and then store user data and other objects that need to be maintained real-time in Firebase. So far that's working pretty well for us.