I have only found code snippets to load the currently logged in user:
FirebaseUser user = FirebaseAuth.getInstance().getCurrentUser();
But what if I need to load another user's data, like the image path and name? I want to load them by their UID.
I could of course save the data myself like this:
-> users
-> UID
-> imagePath
-> name
But I thought there might be a way to use the FirebaserUser class.
I actually think there has to be some way, it's just not written in the docs.
There's no way to do this directly using FirebaseUser class. The old docs of Firebase 1.0 (Before it was acquired by Google) mentioned that exact scenario and the possible solution. The current doc is not completed yet.
The solution was to save the user's data in the Real-time database keeping the uid as the key. So when you need the data of another user, you'll just have to remember their UID and can search for their data (Exactly like how you mentioned in the question description).
I searched the other way to do that without using Real-time database when I started working on my own app, however after finding no other method and reading the old doc, I gave up and used the database way. Trust me it's way easier and flexible to use the database, instead of hacking your way to avoid using it altogether.
Related
I would like to share data between two users in my app. Generally, users are registered in the app and the storage of their data is done via Firestore. To access the data I use the UID of the user on the one hand and an id for the corresponding document inside a collection to be accessed on the other.
I am now looking for a way to share some selected data of a user with other users. The data is to be shared via WhatsApp, Email, etc., for example. These are the ways I have thought of so far:
The DataClass with all the stored data is packaged as an app-specific file and sent between the users.
or
The UID of the user and the id of the corresponding document inside the collection are sent. Using these two pieces of information, I can access the data from the user who is to receive the data via Firestore and save it on his or her device.
In general, my data sets are not particularly large. Now to my question:
Which of the two ways seems to make more sense and, above all, how can I implement this or which other sites could help me?
I've tried a few things with FileProvider so far, but haven't really got anywhere. It would be important that the user in question receives a message via e.g. WhatsApp, email, etc., can open my app via this, and the processing of the data for the user begins. Basically, I need to start an intent from the message the user receives with some extra data. How can I achieve that?
If you need any further information, please just let me know. Many thanks in advance!
You might want to have a look at Firebase Dynamic Links, which:
If a user opens a Dynamic Link on iOS or Android, they can be taken directly to the linked content in your native app.
I am starting with Firebase and want to know what are the most effective ways to structure data
Let's take the example of a simple social media app where only photos can be shared (like the beginnings of Instagram).
user upload a photo with some meta data (Description)
(Home Feed) the users (followers) will see the post in a chronological way
and offcource there will be other functionality like (liking the post , saving it , commenting)
searching and following users
notification about likes and comments
search in comments
what could be a good structure for storing the data and good effcient way to get data ASAP
I'll go ahead and leave an answer for how I would approach this. My answer will be geared more towards Firestore even though the question is marked as Realtime Database. There are multiple ways to structure the data. This is the general structure I would use given your example:
users
- name
- timestamp
posts
- imageURL
- description
- timestamp
- likeCount
- commentCount
posts/comments //subcollection
- userID
- comment
- timestamp
posts/likes //subcollection
- userID
- timestamp
savedposts
- postID
- userID
followers
- userID
- followedID
Some additional notes:
Image Upload
The best option here is to upload the images to cloud storage and utilize a cloud function to generate a public URL and save it to the post document.
Comment / User Search
As stated in my comment, Firebase does not have a great solution for text based searches. The solution I utilized in my project was to utilize a cloud function to keep an Algolia index in sync with my users collection. I then offload the user search to them through a callable cloud function - though you could utilize the Algolia client SDK directly in your app if you wanted. In your scenario, you would also have to keep all of your comments in sync as well. Algolia isn't a cheap service, so I would look into the pros / cons of using the other options listed in the docs.
Document IDs
I generally let Firestore auto ID the documents, but here I would make some exceptions. For the savedposts and followers collections I would utilize a (manual) compound ID of {userID}{postID} and {userID}{followedID} respectively. It allows you to perform simple actions of unliking and unfollowing without querying for the document first. Ex) firestore().collection('postsaves').doc(`${userID}${postID}`).delete()
Final Thoughts
You mention maybe moving to AWS. I have worked much more in Firebase than in AWS, but I have done both. In my opinion, Firebase is unmatched in both usability and documentation. There are some compromises in terms of functionality and fine tuning but I recommend sticking with Firebase if the lack of text searching is the only hurdle.
I wanna ask about the concept and logically ways to give another user the privilege to access other's users' data. What I want to do exactly is like this :
Basically, collection 1 contains several Users ID (UID) from authentication, then the user will have their own data collected in collection 2 which contain the data ID.
So, it's like giving access to another user to collaborate with the data like Google Docs Apps where we can add another user to edit our documents. I've been thinking of how to do this, but still, I got stuck.
My question is, how can I possibly do this? cause from what I've read, cloud firestore don't use such a foreign key like MySQL. Thank You
haven't tried something like this but i think this approch overcomes your problem.
modify your structure according to above image. userID collection will contain userIds which are allowed to edit their parent collection.and create firestore rules according to your use to check weather the userId is allowed to edit the Collection or not.
in your case when 'user 2' will have reference to 'collection 2', he/she will try to change data. firebase rule will check if auth.userId is inside the 'collection2.UserIDs' or not and will allow according that.
I have an android app which uses firebase for authentication and firestore for storing user data. Once the authentication is complete for a first time user, we collect extra info like nick name, age etc and store them in Firestore. We also have an important field called USER_BALANCE. This is set to 0 on new account creation. How can i make sure they dont manipulate this field.
int USER_BALANCE = 0;
User user = new User(name, email, USER_BALANCE,0,0, refreshedToken); db.collection(FIREBASE_COLLECTION_USERS).document(firebaseUser.getUid()).set(user).addOnSuccessListener(this);
We also have certain task in app,on completion where user gets rewarded and points will be added to USER_BALANCE in firestore. I want to make sure nobody decompile the app and can update the field with whatever value they want.
You can use firebase rules for that. Firebase rules check if a user is able to manipulate your data. You can choose for the user to be able to only read the specific value. Because you haven't provided a view of your database structure I haven't tell you how the specific rule that you need will be framed. Check this blog it really helped me a lot when I was starting.
---Edit---
The below firebase rule checks if the user tries to update the specific field and blocks it. You can check this post for more information.
function notUpdating(field) {
return !(field in request.resource.data)
|| resource.data[field] == request.resource.data[field]
}
match /Users/{userId}{
allow read;
allow update: notUpdating('user_balance');
}
Anybody can decompile the app and attempt to make changes. There is no way to prevent that. They don't even need your app to write the database, since it has a public REST API.
What you will need to do instead is use Firebase Authentication along with security rules to determine who can read and write which documents. There is no other way to control access to your database if you intend for your app to be able to read and write it directly. If you can certainly disable public access entirely and create your own backend - but you have just shifted the responsibility onto the backend for making sure the API it exposes also does not allow arbitrary callers to make unauthorized changes.
Working with Firebase for the first time and looking for advice of setting up the right structure for my project which is basically an "offers/coupon" type starter project.
The scenario is this:
I have a node containing a list of all offers available to users
This list of offers is displayed to users after successful Firebase authentication
When a user redeems an offer, I want to be able to count/record that activity in their child node under user and hide that offer so that they cannot see it again once used.
My question is what would be the best way to do this given that offers may be added, may expire, or may change at some point in the future. So, in effect, the user should receive the list of most updated offers, minus the ones he/she have used in the past.
a) would it be more effective to have a master list of offers, and then run a cloud/server function to clone this list for each new user an track that way
Firebase Structure 1
or
b) Keep a master list of offers in one node, then track user specific offer usage
Firebase Structure 2
Appreciate your guidance
The second solution is better because you'll save bandwith. This practice is called denormalization and is a common practice when it comes to Firebase. The first solution is not good becase every time you want to display the users you donwload unnecessary data. If you want to read more details about how you can structure a Firebase database in a efficient way, please read this post, Structuring your Firebase Data correctly for a Complex App. Also, you can take a look a this tutorial, Denormalization is normal with the Firebase Database, for a better understanding.
Second solution is much good. Because in first one we are having redundancy of data in our database. And second one obviously removing that cause.
But instead of using true or false because it is only showing you, "it's available or not", so you can use a string type parameter as "expired", "going to expire" and "updated" or whatever sooo. So it. Will be able to trace all you information related to offer for particular user. I think this is your requirement also.
Happy coding.