I'm developing a PWA with Ionic/angular and Firebase/Firestore.
It manage a collection of categorized lyrics. Admins can add/delete/modify lyrics etc. Firestore is very usefull for that.
I want my PWA fully accessible offline after installation. To do that i need to read all collection (300 documents) when app loads in order to cache it. It is an important amount of reads by user, Google charge 300 reads each time app is loaded, and even more with listeners with database changes. I think, my use case is not very adapted to Firestore way to get data.
const lyricsCollection: AngularFirestoreCollection<Lyric> = this.afStore.collection<Lyric>('lyrics', ref => ref.orderBy('title'));
this.lyrics$ = lyricsCollection.snapshotChanges();
My question is: How can i improve my db or app architecture to be more adapted to my needs ?
Thanks
Related
I wanna create a chatapp for my friend, and now remote serve I will use firestore and locally sqlite, but I realized it is default for firestore to save data offline, so my question is I have some data like message, or sending setting for the app, is it ok just to save them in firestore offline which seems automatically and no extra costs.
It depends on what you want or need.
If you want to use the offline persistance only for storing in case internet is not there at all. Firebase supports that out of the box. But you need to keep in mind to do you calls carefully. Because on a slow internet connection, if you tell the Firebase access to wait for the online behavior. It will not be using the local first and you might not be able to show the data. Check the question here
Also if you want to use the offline persistance from Firebase, be mindful that the data size has a default of 40 megabytes of limit. You might assign that by your self. You can check this link
BUT, if you want to have heavy data manipulations and have more control over your data SQLite is more suggested.
My opionion: I think Firebase Offline persistance would be enough for you, so go for it.
I am a intermediate flutter developer and working on my first commercial app And I have almost created whole app ui but problem is when i close my app all data get lost . so how can i prevent it + how can i make my app work at background when app is close like in clock app . In clock app even if app is closed then also we get alarm at the timing we set . It is not possible to provide whole app code thats why i am explaining it in words . Hope you guys will understand the problem and provide best answer .
You can use internal data base concept to save user data like JWT key , user id, first name ,last name or app content for offline usage like blog articles ,pos system data for offline usage
Use Shared preferences to save basic data like user data, JWT but less secure
but if you need save complex data and need query or filter you can use hive and you can keep data more secure
And Alarm is totally deferent approach,
when we schedule alarm,alarm manager schedule task on system alarm services and wakeup app with intent and flutter Isolate class
We divide your question into two parts.
Question 01: How to store data locally :
You can use key-value storage like Shared preferences, Hive
If you are familiar with SQL you can use SQLite
If you are familiar with NoSQL you can use database like sembast
These are some of the popular databases that you can use with flutter. And much more available at pub.dev. But you want to use a database with your task. As an example simply store the user name or user id you can use Shared preferences
Question 02: Make Alarm Application :
For android applications, you can simply use android_alarm_manager
I suggest you take a deep look at the flutter docs about the subject:
Background processes
To run background processes continuously, take a look at this
package: https://pub.dev/packages/background_fetch
If you need to show scheduled messages, use local notifications:
I think by referring to these links you can get an idea.
To store data locally you can use local storage options like Database such as SQFlite, Hive etc or SharedPreference that will save your data locally and to run background process you need to use MethodChannel and write platform specific code or you also have the options to use Isolates. You may read more using this link
https://docs.flutter.dev/development/packages-and-plugins/background-processes
As Firestore charges by the read/write, it would be super helpful to keep the changes in memory during the session and only commit them when the user exists either the entire app or a specific section. Is there a way to do that in a Flutter web application?
I think one problem with this approach is that the user might just close the tab including your app. In this case, you have no time to send your data to Firestore.
This aside, you could use packages like Hive to store your documents offline and later run a function to add the data to Firestore later.
You also have 50k reads and 20k writes for free with Firebase, which is sufficient for smaller apps. If you exceed this limit, your app is probably big enough to earn money with it anyway.
a question about local and remote storage of user data. Is there a best practices for the common situation where a user accesses data from an API and can favourite or otherwise personalise the data.
I have seen tutorials, e.g. a movie browsing app, where the use can make a list of favourite movies, where this personalised data is stored locally (e.g. in sqflite) and other tutorials where this data is stored remotely, eg. firebase. And firebase has an offline mode, so that data can be synced later. In that case, is it a common use case to set up local storage as well as cloud storage? Is there a common practice for this situation?
Thanks for any insights.
This is not specifically a Flutter question, more of a general app development question. It's very common to have both local and cloud "storage" but I wouldn't think of it that way. If you're interacting with an API backend I wouldn't consider it as the cloud storage for your app. Instead look at it as a different component within your applications overall architecture. You API/Backend component, this way it's not apart of your app instead it's something your app interacts with.
I assume you know the purpose of your API. Returns your data you want to see, keeps track of user profile information and other sensitive information.
When it comes to local storage I'd say the most common scenarios for local storage is results caching and storing information that the API requires on every session to make the user experience a bit better. See some examples below for both:
On instagram they store your "Feed watermark" which is a string value that is linked to a specific set of results so that when you open the app and request again they return that set of results, plus anything new - Local storage
They also "store locally" (better referred to as caching) a small set of your feeds from your posts, a list of user profiles that has stories on them and your DM's for instant and offline access. This way when the app loads up it has something to show while performing the action to get the new information. - Caching
They also store your login token, that never expires. - Local storage
tl;dr: Yes. If you need data on every session to use your API store that locally in a secure way and use that to interact with your "Cloud storage".
I have a content based, read-only iPhone app. Users can select favorite topics, which I need to track. Some topics I'd like to make available between app updates through the App Store. I'll need to track if users have downloaded these particular topics or not until the App Store update is available. This approach will consist of two tables for user tracking. All other tables contain mainly static content, save any new downloaded entries.
Before I began tracking user content, I'd always deploy the database on app updates. An overwrite - simple. But now I need to track certain user configurations. Rather than trying to keep track of which app version a user has and running through a list of sql scripts in the correct order, so the user is at the right database version, I'm thiking to use two databases. One contains static content and the other user data. The static content database is always overwritten. That keeps things simple. The database currently is 250kb. It will grow very slowly.
I have plans to use SDK 3.0 push notification and peer-to-peer as well, which will store any user config data in the user database.
Any one see problems with this approach?
This sounds alright to me. If you're using SQLite, you may want to look into the ATTACH DATABASE command, which lets you keep two databases open on the same connection.