Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I have been researching around the web on how to create a friends list system using firebase. So far I had no luck and was given resources that was not quite what I was looking for. The premise of the app is using the User Login & Authentication to create a account(completed), then once the user has an account they can add people that are register in the firbase users. This can comparable to a friends list. once the user adds another user they can have an option to create a post that only his friends can see and the users can group chat in side the post.
The Problem:
Don't know where to start in creating a friends list using firebase custom User Login & Authentication
After that how do only the people that are add to the users friends list see the content posted.
P.S. just looking for some guidance on the subject from anything to resources to/ tips
Kato's comment is on point. Being super new to Firebase can be a bit daunting so here's some ideas:
You cannot use the Login & Authentication in the way you want. It is a function that allows you to create users that can access your Firebase and that's it.
If you want to do more with users, create a /users node that contains other stuff.
users
uid_0
name: "Frank"
friends
uid_1: true
uid_2: true
uid_1
name: "Kato"
uid_2
name: "Bill"
This tells us that Frank has two friends, Kato and Bill.
To accomplish your task, Firebase will need to notify your app when new users sign up (by adding them to the users node and observing the Users node for .childAdded) and then display the new users to your user so they can add them to their friends list.
Posts can be handled in a similar fashion
posts
post_id_0
msg: "Hey look kids, there's Big Ben, and there's Parliament"
posted_by: uid_0
viewers:
uid_1: true
This structure has a post reference (created by autoId), a msg and who posted it and who's allowed to view it, in this case user with a uid_1, Kato.
Saving Data and Retrieving Data are critical reads and simply going through the well-written Firebase Guide to the Stars is a must.
Hope this provides some direction, and in the future, craft your code, create a Firebase structure and when you really get stuck, post those (as text please) as they will help us, help you.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I'm trying to get started with stripe to build out a Patreon like app. I've done a lot of searching and have even started with these docs from Stripe. Unfortunately, I am encountering many problems, probably as a result of a faulty integration.
What I am using:
I am using Firebase database.
Express accounts in stripe
iOS
What I am trying to achieve:
User1 can create a subscription of his chosen price.
User2 can join/pay the subscription.
User1 gets 70% of his money made from the subscription, and I the developer get remainder.
What I have done so far:
Created a Stripe account and set it up at a very base level.
created an Xcode project and included code up until step 2.3
I have setup firebase functions at a base level, and have some code in there from steps up to 2.3 in link above.
What I would like is to have a clear starting point, and path to follow.
How do I get started in achieveing this goal?
Just commenting on the Stripe portion -- what you can do is have a page where your content creators (i.e. User1) can create a Product. Each Product must be tied to a Price:
On another page, retrieve all active Products so content receivers (i.e. User2) can subscribe to it.
Full details can be found at https://stripe.com/docs/billing/prices-guide.
For the revenue splitting, Stripe doesn't seem to support this. Your only option is to do a payout to your business bank account, then further disburse the 70% to your content creators. For this, you must be able to match payment records on Stripe to your database, e.g. design your database in such a way it can answer the SQL query "what is the total amount paid to this particular content creator within a given time period?".
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
Firebase is configured in APPDelegate.
Read is set to .true in rules.
But, before I have a user sign into my application, I am checking for usernames, within a separate table of my Firebase DB. It would skip the observation block entirely, until I forced signed-in into another already created account of mine. And then when I would re-build the application the block is no longer skipped and actually accesses the table.
How do I "Wake Up" Firebase when I run the app on a fresh device, so I can check for usernames without having to log onto the app with an existing account before hand?
You may want to reconsider how the app is structured.
If you are checking for usernames before being authenticated that means the node is exposed and anyone can grab a copy of all the usernames. Obviously that in itself may not be a huge issue but if your users decide to use an email, whoever grabs the list has a instant list they can spam to.
When you add any observer to a node, that node is read once as soon as the observer is added. When you app starts you can use .childAdded to iterate over an existing node to pre-load some data, a grocery list for example, and then any new grociees added after that will be sent your your app via an event.
Likewise a .value event will read in an entire node and leave an observer attached for any future events.
The username issue is tricky and the way you are doing is now is probably going to get you in trouble in the long run.
A better way is to leverage Firebase Authentication.
Firebase handles all of the usernames and passwords for you. It's very powerful and flexible and avoids the issues you are encountering. It will let you know if user names exist or not, it will do password reset emails and you can manage users from the Firebase Console. It's the way to go.
If you want to add username functionality it can be pretty easily done by adding a username or nickname node to the /users node
/users
uid_0
email: "bill#email.com"
username: "bill_the_cat"
uid_1
email: "clark#email.com"
username: "superman"
Once the user authenticates using Firebase Authentication, from there forward any time the user info needs to be displayed in the app, simply look up the uid that you need (uid_1) and grab the username node (superman) for display.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
So my idea is to have an user A requesting any number of arrangements (any service) from another user B. Both user A and B can leave feedbacks to each user B and A (only one per user and service). Just like CouchSurfing
I had some thoughts about the setup on the database and ruby on rails, but would be glad if you would have a quick look on it, since I'm still a beginner seeking for knowledge.
Lets have a sample scenario:
But first a quick note: It's important that every user has the ability to become an acceptor or requestor.
User A requests this service off another user B (in this case user A becomes the Requestor and user B becomes the Acceptor, who needs to accept the request of user A). Once user B accepted the request, an Arragement is built having its primary key made of the ids of user A and B. Inside this Arrangement Table are several informations related to the arrangement. Once the arrangement took place, both user A and B are allowed to give feedback to the other user (but only one!)
This is why I have set up seperate tables for the Acceptor, Requestor and Arrangement. I want to control how many feedbacks a user can give database-wise.
Now each user has (for sure) a user-show-page where all of his received feedbacks are shown. Means: Every user has N feedbacks (or messages, if you see it database-wise). And that is why I extracted a Message-Table out of the Feedback-Table
In short: It should be very similar to CouchSurfing. E.G. the stay at ones home is an arrangement and both the host and guest can leave one feedback to oneanother.
What are your thoughts on this setup? Is it good/bad? How can I make it better?
Sounds reasonable, but your design limits A and B to having only one Arrangement with A as Requestor and B as Acceptor.
Generate an int id for the Arrangement to use as PK (and as the FK in Feedbacks) and you're there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I don't understand a thing about the Card, Conversation, Confirmation formula for user stories.
I don't understand if the conversation and confirmation part must be written down or they remain as a dialogue, in particular the CONVERSATION part.
To be clear: is it right if a write down ALL these things in user stories? (see example below)
Or do I have to write down only the CARD part?
Example:
CARD
As a user of a coffee machine, I want to be able to purchase a beverage.
CONVERSATION
- The user will not be able to purchase a beverage if they do not deposit enough money into the CoffeeMaker
- A user's money will be returned if there is not enough inventory to make the beverage
CONFIRMATION
1 user introduces the amount of money needed to purchase the beverage
2 user selects the beverage
3 user gets the beverage
The 3 C's is a saying used to serve as a reminder on what is important when using User Stories.
A simple card to write down the requirements - as opposed to a heavy weight document.
Having a conversation - collaborating to define the requirements and understand the value.
Confirmation - agreeing on the acceptance criteria, so you know when you are done.
There is another saying which sums up the idea behind User Stories nicely. "The card is a place holder for a conversation". This highlights that the conversation is the important part, not the card artifact. The card can be discarded once the feature has been developed and automation tests written using any suitable acceptable criteria.
The format of a User Story will typically follow:
As a (role) - This can be an end user or a business proxy
I want - A description of what need to be done
So that - the definition of the value
An attempt at your scenario
As a vending machine customer
I want my change returned
So that I do not loose my money
The confirmation part could just be bullet points on the back
Change should be returned if the customer does not put in enough money and then selects a beverage
Or you can use the context specification style, a BDD (Business Driven Development) technique
Given a customer does not put in enough money
When they select a beverage
Then their change should be returned
If you would like to know more I would suggest researching the INVEST principles and reading Mike Cohn's User Stories Applied.
You can do whatever you want ;), from writing down everything to memorizing everything and writing nothing. Personally I write everything down, so the next dev that picks up the story can understand as much as I do and pick up from there.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm still learning Rails and how to best design my resource structure. Could someone help me with this? Here's my problem:
I am designing a specialized social network with profiles - every account has one profile. At the moment, an Account stores basic info about the user (username, password, etc.) from when they first sign up. A Profile stores other thinks like a picture link, answers to personality questions (linked back to a Profile via foreign key), and maybe more in the future. There is a one-to-one relationship between Account and Profile. Users can view/edit their own profile and view profiles belonging to others.
My questions:
Is it a good idea to split these two into separate resources altogether (i.e. have two different models) or collapse them into one model with two controllers? I have tried the latter, and it almost seems like more trouble than it's worth. Am I, in this case, fighting against the framework? I'm not sure yet whether users should be able to have more than one account in the future.
If I do split them, should I use a singular or plural resource for the profile? I noticed in the language at guide.rubyonrails.org that get (show) and put (update) work with the ONE and ONLY profile resource. My question with respect to my current situation is: "one and only" with respect to what? The "one and only" profile for the current user's account or with respect to the entire site? If so, how could I have the current user view profiles of other users - should I use a URL parameter like so:
http://www.example.com/profile?id=x, where x is the other user's account id
If I go the plural route, does index showing "all profiles" intend to mean all for the current user or for everyone across the site? Or is this up to my own interpretation?
I would appreciate any help I can get with this, as I feel like I am starting to understand REST and RoR conceptually but am just trying to put it into practice. Thanks!
I would personally keep Account and profile as two separate resources or at the lest 2 separate controllers accessing different parts of the same model.
This allows easy routes like http://www.example.com/profiles/2 for viewing other users and http://www.example.com/accounts/2 for managing your own account without having to add custom routes.
If you have the possibility of adding more profiles to an account, then this is a form of future proofing too.