I have a question about storing data in the database.
I'm working on some screens within an app: the login screen (where the user can access your account), the signup screen (where the user can create a new account), the screen where the user provides information (such 'Mothers name and height'), and the profile screen (where information provided by the user is displayed).
My question is: how can I save this information provided by the user in Firebase Database?
I'm having no problems in login screen and signup screen, however I have no idea how I can save in Firebase Database the information provided by the user in the screen where the user provides information.
Can any of you guys help me with this? I know I can create a user with name, email and password using firebase auth, however I have no idea how I can save in Firebase Database the information provided by the user. And I know I can add a node but I don't know how. I read some articles but none of them talk about creating a node in Firebase.
Thanks in advance!
Notes:
*The screen where the user provides information comes after the user creates an account on the signup screen.
*If you want to see what I'm trying to do, please look at the project in GitHub: https://github.com/JoaoVRodrigues01/React-Native-Codec-App
The best approach is in fact store all data in your firebase database. If you store only on local storage the user can delete it and lost all data that supposed to be available, or also can't share data between different users.
Remember that to write/read your database node, the user must have the correctly permissions, either be logged or your database allows anonymous access.
You can use react-native-firebase (https://invertase.io/react-native-firebase/#/) if you need to persist your data, so use it locally when user is offline, for instance.
Hope it helps.
Related
I am working on a simple app that allows users to search for something using an API and save it to view later.
However, I don't want to integrate authentication in the app. I can, but would rather not as a UX decision. Do you know of a way to generate a device token, that is unique to every device and can be used to store which assets a device has saved in the db?
I am thinking of expo push tokens as a possible solution, but that would require users to accept push notifications - so what happens if a user says no?
Sounds like you could just use react-native-uid to generate a unique id for your device and then store it in AsyncStorage and fetch it from there going forward.
For more inspiration, or perhaps just a more canonical way to do this... read up on suggestions surroundings the recently deprecated constant for installationId here:
https://docs.expo.dev/versions/latest/sdk/constants
I haven't used this before but if you're looking for something bullet proof then this is probably your goal of getting the same concept.
Firebase Anonymous Authentication might be ideal to use in this case. This can be used to create a user in Firebase auth without any credentials and can be useful especially when you are using either of Firebase's databases since you can use security rules with user's UIDs.
However, once the user logs out of the account by any means including but not limited to using sign out option in your app, clearing app data or uninstalling the app, the same account with that UID cannot be recovered. I looked up for AsyncStorage and apparently that gets cleared to if the app is deleted.
Imagine an app that is saving the user's configuration to Firebase. The structure in Firestore looks like:
users (collection)
- user1 (document)
- user2 (document)
How do you name the user's document, in a way that keeps the user anonymous?
My original intention was to use User.uid as document-id. This would make identifying a person very difficult compared to using the email address. Might appear over-cautious, but you never know if the database gets hacked, and if it would happen and there would be plenty of personal data in it, then well, with the current regulations, you're pretty much... "screwed".
Problem with User.uid is, that it changes every time the app is installed, so all data would get lost...
How do you save user data anonymously, so it's available across installations but does not allow an unauthorized third party to figure out the user's identity?
According to the documentation of Firestore you can do this by using the method push which ensures a unique and chronological key.
I am building a job portal for the web using React, Redux and Firebase/Firestore. I've completed all the features I needed except one.
I want unregistered-users/job-seekers to be able to:
Bookmark job posts.
Keep the record of applied jobs.
Keep the record of search queries.
I am thinking about using IndexedDB for this feature. Particularly Dexie.js to make things easier. However, this data will be persisted in user's browser and user will have no access to it in another browser or device. Therefore, I want to give users an option to be able to save all the data to Firestore if user sign into the website and I need this to be automatic. So, as soon as user signs in, I will save it to the database.
I thought about using Anonymous Authentication instead of IndexedDB/Firestore, so all the data will be saved into the database and as soon as user signs in using credentials, the user can claim the ownership of the data. However, this is an extra step to use these features I listed above and not everyone is happy with authenticating an app even though nothing is required from the user. Besides, there will be so many ghost accounts.
So, as I mentioned in the title; I want to save everything to IndexedDB (I will take care of this), but how am I going to synchronize all the data in IndexedDB to Firestore as soon as user signs in?
I imagined the basic process will be like this:
User clicks "Bookmark Job Post"
App checks if users is authenticated or not.
If authenticated, save the bookmark to the Firestore.
If not authenticated, save the bookmark to the IndexedDB.
If User decided to sign in or sign up, check IndexedDB and synchronize it with Firestore and clear IndexedDB.
How can I achieve the 5th step technically? Is there any built in system in Firebase? Also, please feel free to share your idea if you can think of another way implementing this feature. Should I be using firebase.auth().onAuthStateChanged() for the 5th step?
And lastly, how should I structure the Firestore to save bookmarked jobs, applied jobs and search history?
Should I create a bookmarkedJobs collection and have documents of jobPosts duplicated for each user, who bookmarked the job post? And every time a job post is updated by an employer, I will have a cloud function going through bookmarkedJobs collection, updating every instance of it?
Thank you
This may be of interest to you
https://dexie.org/docs/Syncable/Dexie.Syncable.js
Been looking into making my website fully static/pwa, and just using indexeddb, and some webservice for data handling/storage ..this seems like a interesting route to explore.
I'm new to react native. I am trying to develop an application that uses firebase user authentication. But there is something I can think of. For example, 2 users have registered to my application but I want to show extra information to the first user according to a condition.
How can I separate these two?
Where exactly should I manage this condition?
The question is not super clear as to what issue you are trying to tackle so I apologize if I am inferring incorrectly.
I use MongoDB personally with a Node/Express backend for user data and haven't used Firebase myself but I'm sure you can do the same things with it. I'll be speaking in Mongo terminology but again I'm sure you can do the same with Firebase and at the least this will give a good idea of the thought process.
I have a UserSchema that holds all the user information. When logged in the client app would get this information to be used on the frontend after authentication.
Assuming you are only displaying "extra" information that doesn't need additional privilege you can just pull in the users data stored in firebase and handle the display of this extra info with logic on your frontend client.
If its extra privilege you need to setup firebase to look at the user data that is authenticating and only serve back information if they have the proper privileges.
Also important to note, you should ensure that when you are updating user information from client -> firebase backend you should ensure that you can only update specific user fields via read/write authentication on firebase.
Hope this gives a little better idea on how this process might look. I'll let someone who has used firebase specifically add tech specifics.
Is this a common/reasonable Use case?
An app allows a user to save favorites locally so that the user doesn't need to signup.
Then the user afterwards desires to share their favorites.
Therefore favorites data needs to be synced from local to remote. The usual local storage for flutter is sqflite, and firebase/store is the remote. However, this seems cumbersome, as sql to nosql conversion is necessary.
I thought that this would be a general issue for UX etc, but I can't find any discussion of this issue? Maybe forcing the user to create an account is the most general solution?
It's a common understanding that if you don't have user account then you can't have any user data associated with your name. You don't have to force the user to have an account or lock them out.
When they favourite something just show a dialog telling them "If you don't have an account your favourites are stored on the device only. If you want your favourites to be available everywhere please create an account" then show options for "Create account" or "No, Thanks"
Create account: Goes to account creation page
No, Thanks: Adds the device to the favourites list and lets the user continue to do what your app does.
There's no problem to solve here from what I'm seeing. If you don't have an account you don't get account functionality. If you track users without them entering anything it's also a little bit illegal and creepy so no need to push the limits on how you can track the same user.
Another way to think of it is to make signup so easy they don't mind and also guarantee that it's worth it. Won't be used for spam or information selling. Take what's app as an example, even though you need to mobile number to send the messages, it's just used as a unique identifier and has nothing to do with the device's number.
Ask for their phone number or email or just any email, you'll most likely get fake info.
And what does your analytics say? Are you getting requests from users saying they lost all their information on a different device? How many people are using your favourite functionality?
I may have come to the party a little late here but here's my 2 cents worth.
The Sql to NoSql conversion is not cumbersome. In fact, there is a reasonable use case for this. I have the same requirement for an app that I am about to build.
Anyway, to store data in RDMDB or NoSQLDB you will need a data model to ensure consistency in your app. If the user has been using the app offline, and they later choose to go online, you can allow them to create the Remote Account, then check if they have local favorites. If they do, you will HAVE to ask them if they'd like to import them into the remote storage. If they choose to do so, you will then have to read their favorites from the local storage and store them in a List<Model> then map() that back to the online storage.
NoSqlDB can accept the json type data, so your model should include the conversion fromMap() and toJson() for this purpose (and others).
When I have come around to doing this, I will share my code (if I remember to come back here).