I am a novice android programmer, and I am developing my first android application. I'm trying to figure out if firebase is suitable for my needs.
My app looks like this:
users add the product to the database by filling in the product
fields
products are stored in the database as objects with simple fields (numbers and strings)
users search for a product in the database to compare its fields according to different criteria
users edit (update) product fields
users have their own accounts
My priority is the ease of use.
My question is:
Is Firebase suitable for my needs or is there a more suitable solution?
Do I understand correctly that I am interested in the Cloud Storage product?
users add the product to the database by filling in the product fields
Yes, you can achieve this using either Cloud Firestore or the Realtime Database. In both cases, you can add the data as a Map object or as a custom object of your choice.
products are stored in the database as objects with simple fields (numbers and strings)
Yes, you can achieve that. Here are Cloud Firestore supported data types, as well as Firebase Realtime Database data types.
users search for a product in the database to compare its fields according to different criteria.
None of the above databases supports native indexing or search for text fields, so you can use third-party libraries like Algolia or Elasticsearch.
users edit (update) product fields.
These are basic CRUD operations that are supported by both databases.
users have their own accounts
In this case, you should use Firebase Authentication, a service that works perfectly with both databases.
Is firebase suitable for my needs or is there a more suitable solution.
As I see in your requirements, yes, it suits your needs.
Do I understand correctly that I am interested in the Cloud Storage product?
For storing data (objects) you need to choose one of the above-mentioned databases, or why not even both, and for storing files, you should indeed use Cloud Storage for Firebase.
You could use firestore for this. Although full-text search won't work, you can use algoia/elastic to do full-text search.
Related
In my chat application, I store the participants of a chat as their UIDs in a Map so I can so I can do queries like this:
.whereEqualTo("participantUIDs.$currentUserUid", true)
.whereEqualTo("participantUIDs.$partnerUid", true)
The problem is when I try to use this with orderBy
.whereEqualTo("participantUIDs.$currentUserUid", true)
.orderBy("lastMessageSentTimestamp")
I have to create a custom index. But this index will contain that specific user UID and I can't create an index for every user in my app. How can I circumvent this problem?
You can order the documents on the client after an unordered query. This should not be very taxing on the client app when the number of documents is less than 10,000.
Regarding:
I can't create an index for every user in my app.
That's definitely not an option, as there are some limitations when it comes to Cloud Firestore indexes:
https://firebase.google.com/docs/firestore/quotas#indexes
However, even if you manage to stay below these limits, that's not an option to manually create an index for each and every user that joins your app.
In my opinion, for your particular use-case, you should consider augmenting your data structure to allow a reverse lookup. Meaning that you should create a participantUIDs collection where you should keep the lists for each user. This technique is called denormalization and is a common practice when it comes to NoSQL databases like Cloud Firestore or Firebase Realtime Database.
But remember, there is "no perfect database structure":
What is the correct way to structure this kind of data in Firestore?
It's a little old, but I think this video might also help:
https://www.youtube.com/watch?v=u3KwKQddPoo
More info regarding why you need an index:
Why does this firestore query require an index?
P.S. You can also rely on Firebase Realtime Database when Cloud Firestore may become a little expensive. Both work really well together.
Info:
Array or Subcollection for storing events user uploaded
I am using firebase Cloud Firestore for my Android and iOS apps. I am stuck with how to structure my database.
Basically I have an "organization" collection that contains many users, and for every user, I want to save attendance time and leave time for every day.
The problem is I want to generate reports that allow me to get every day-attendance for each user, single-day attendance for all users, and all days attendance for all users.
so I tried this: inside the user I would have an "attendance" collection then each document is Unix timestamp of that day (to make sure that it's unique). then save fields like attend_time and leave_time...etc. the path is like that "/organization/android/users/3PRs42gRFzZQhLKcUhpf4wPMRV43/attendance/1590271200"
then I needed to get attendance for a single day for all users, so I did this: now I have another path "/organization/android/attendance" and inside the attendance, I store the Unix timestamp of the day, then the user ID then his attendance. and now I am saving attendance twice.
but I still can't get attendance for all days for all users!
this would be easy in Relational Database like SQL. any idea how to do it in firebase?
If you want to track attendance across all users, you're looking for a collection group query. This allows you to query documents from all collections named attendance.
Since a query in Firestore can only see data in the collection(s) it queries, you may have to duplicate some data from parent collections (your users and organizations) into each attendance document to allow the query. This type of data duplication is quite normal in NoSQL databases too.
Finally: if you need to perform many ad-hoc queries, you might want to consider using a database for those that is more suited to that use-case. For example, it is quite common to use Firestore to handle the direct-to-client interactions that require scaling to massive number of users, but then use BigQuery for the ad-hoc querying of that data. There is even a Firebase Extension that automatically exports to BigQuery to make this easier.
I have a database in Firestore that is available for all my users. This way updates made by me to this database is instant updated for my users.
My challenge is that my users can edit some of the data in the database - user preferred values. These changes can of course not be written to the public database, but must either be written to a local SQLite-database on the phone or somehow written to each users private collection of documents in firestore.
A SQLite solution means that each time a document from Firestore is displayed, I need to read the local SQLite database to check for changes.
Using private collection of documents in Firestore means that I have to read two documents for each item that I want to display.
I struggle to find the "perfect" solution for this situation.
What is the best approach? Is there a solution I haven't thought of?
I believe the best approach is Firestore Security Rules.
Any data for a user should go in a special document: /users/userId
Set up the firestore rules so that this document is only writable by the user with ID === userId. You can make the document readable by all if you need or limit it to only the user who created it.
I'm developing an android application that will allow users to find informations about the streets in my city. They will be able to register and save some streets as "favourites".
My question is, how can I use Firebase to store the streets data considering that they won't change overtime?
The Firebase data model is not well suited to storing arrays (or Java List objects). See this blog post explaining the behavior you get. Instead of storing a List, follow the Firebase documentation's approach for storing collections. This will indeed store it as a map, which is the correct approach precisely .
That depends mostly on how you want to read the data.
If you always load all of the street data, then you might as well store it as a file on Firebase Hosting. That'll be a lot cheaper, and perform better (since the data is cached on a CDN).
If the app loads parts of the data, but it's not very dynamic, you could split the data into multiple files and still store those on Firebase Hosting.
If users sometimes update the data, but it's still hardly queries by the apps, consider storing it in Cloud Storage through the Firebase SDK. The files are available to all of your users that way.
If you want advanced querying of the data, consider storing it in the Firebase Realtime Database or in Cloud Firestore.
I recently started using Kinvey as a backend for my Android app. The documentation doesn't have a lot of info about Collections. I want to know if it's possible to create Collections using the same concepts applied to MySQL tables for example:
A Collection called Users will hold a User ID, Username, User Email
And another Collection called Items corresponding to users -> Item ID, Item Name, User ID.
Has anyone successfully created Collections like this using Kinvey?
kinvey.com
I have also contacted their support team about this bu no reply yet.
I'm an engineer at Kinvey and can help you at this. Kinvey uses a NoSQL store on the back end, so the concepts are a little different than those of a relational database system like MySql, but in general the same thought process can apply. A Collection is similar to a table, although it is Schema-less. This means that attributes (columns in MySql terms) can be added dynamically as needed. You simply create the collection, and then start saving data objects to it. For more info on our Android library specifically, take a look at our Data Store User Guide.