Develop Reference

How to show Firebase data only once?

I'm working on an android app which uses Firebase Realtime database.
This app is quite similar like a social media app with limited functionality.
The app will show the post contain text data to the users.
I'm stuck with the two problem in which I solved the first one with the help of Pagination but couldn't able to solve the second .
The problem is How can I identify if the post is already seen by the other users and then not show it again.
like other social media platforms
For example Quora, Quora will show different answer every time we open the app.
Do I need to remap my data get this functionality ?
My user object and post object will look something like this.
User{
Name;
Id;
Post;
}
Post {
dateCreated;
data;
userId;
}
My database tree structure will look something like this
ROOT
/ \
POST Users
I'm keeping the copy of the post in child node of ROOT that is POST and also in every users node to get the post posted by the user.
PS: sorry for the poor English.

If you want to
1- Show posts with NO views yet, you can filter posts where for example num_reads < 3. The num_reads will be increased everytime a user sees the post.
2- Show posts to use which the user himself didn't read yet. In this case it is better to create a collection user_post_read which will be many-to-many (ie. link user to post read). Get all posts where the is no entry for current user in user_post_read

Filter data in Firebase by follows

I have a simple Firebase database:
I would like to create an Android app where everybody can posts short texts. However, on the main screen I would like to show only those posts from other users who I followed. On the example, this means that if I logged in like Mrs. Nobody into the app, I can see only the first post created by Mr. Nobody.
Is that possible? (I tried to receive every posts in "posts" and after that I could show only posts what are relevant for me, but data traffic was really high in this case)
I have another idea, but I try to find a more efficient one. My idea is to receive every relations from "relations" where follow_uid is mine. After that, I iterate through all the elements and I download those posts where uid is equals with the uid from "relations"

How to model a timeline that automatically adds post from every follower on firebase database

I am building a social app, I have a database on firebase that is structured like this:
tJWRbfqUUbSQn5eI8ZS5vPG9znr1
bio:
coverPhotoUrl:
email:
firstname:
imgUrl:
lastname:
name:
phone:
posts
-KPN0b7QmNp8AjYy4yFl
-KPXmtvZdiQ--QjZ-j3m
-KPc7PpDkmFNU9JjlIJP
-KPc7PptOulQdrpsrGEp
-KPc7Pq6JC7bjt8-sRFU
-KPc7PqJ2651EIQWXIv6
the top level key is th user id, so i have that for every user, each user has posts too, inside the posts node, i have comments, pushed in the exact the same way as posts.
My question is that I am a bit curious about how i am going to model a Newsfeed, right now A Newsfeed to me is a list of posts from you and your everyone you are following in the exact order of the time they were posted while a timeline is just posts from the said user in that order too.
I have correctly done the timeline by just iterating over posts from the user
I have tried to do the Newsfeed part in two ways, which has bugs and I think is not very efficient
Since every user maintains a list of his followers in his own node, i made it such that anytime a user makes a post, he not only writes in his own 'posts node' but also in every other person following him's 'Newsfeed' node
Cons of this method
a. in the event of an unfollow, i am not able to remove user A's posts from User B's timeline
b. i am giving every user access to write in every other person's node, which as i have read, is not a very good practice.
Maintain the url of User A's post node in user B's Timeline node, which would solve the con B of method 1.
Cons of this method
a. I dont know how to implement it.
I dont know if there is any textbook way to do this(of course there has to be, there is only so much social network platforms out there), if there is i want to know, also if you could point me to how(not help me to) implement my method 2, i will very much appreciate it.
Also, i was following this similar question
which does not completely answer my question but looks like a very interesting approach

I think the solution you are looking for is referred to as client-side fan-out. This Firebase Blog post provides a great explanation and will point you in the right direction.
Client-side fan-out for data consistency

It looks like you need a new datastructure for keeping score who is following who. Use that information to build your newsfeed. That way there is no need for one user to write "into" another user. Every posting is only stored once for the user why created the post. If the follow and unfollow changes, you can simply recalculate on the fly which posts to include in a newsfeed

How to efficiently perform server queries?

I want to implement an article viewer with the help of tabs. Basically each tab will correspond to an article category (e.g. Sports, News and so on) and will contain a list underneath with all the available articles (much like the google play store implementation in the Movies>Top Selling or Music>Top Albums/New Releases).
The problem is that those articles will be pulled from a server and the server's query protocol is... impractical at best. It supports two kinds of queries. One that will result in a json file of the category, which is basically a list of the article titles, authors and id's and the other that will result in another json file with article-specific data (Author, Header, Body, et.c.).
My question is the following:
The way I see it, there are 5 categories, each containing 5 articles, so that means that I will possibly have to query the server 30 times to first get the data from the category-wide query to populate the listViews and each time a list item (i.e. an article) is being clicked, I'll have to query the server again for the article itself. Let alone the fact that I will have to have 10 SQLite tables on the device (5 for category data and another 5 which actually contain the articles).
This all sounds wildly inefficient to me, so does anyone have a better idea of implementing this?

How to get most popular post?

I am creating an app in which users can make posts and other users can like and comment over these posts.To achieve this facility i am using tables likes POSTS, LIKES, COMMENTS.(I am using parse.com database to store these table).
POSTS have fields like postId, content, userWhoMadeThePost, dateOfPosting
LIKES contains filelds as id, postOnWhichLikeWasMade (foreign key to POSTS(postId)), userWhoLiked, dateofLike
COMMENTS have id, content, postOnWhichCommentWasMade(foreign key to POSTS(postId)), userWhoCommented, dateOfComment
I want to retrieve most popular posts (posts with most no of likes and comments).
First way to do this is count no of post and likes for each post each time whenever a request is made for popular posts but this can become very time consuming if
there are millions of posts.
Other way to do this one way is to include 'noOfLikes' and 'noOfComments' in POSTS table, so in order to get popular posts I will have to access only post table, but the problem with this approach is whenever a user makes a comment over a post then I will have to increment 'noOfComments' in POSTS table as well as make a entry in COMMENTS table, problem starts when the increment is successfully made to POST table and before making change to the COMMENTS table connection is lost. In that case POST and COMMENTS table would be showing wrong data.
How to do this?

This would be simple, if you had control over the database, but doing this with Parse means that you have two main problems (one of which you already mentioned):
As far as I can tell, Parse does not allow grouping in queries. That means that (with your schema) it's actually impossible to get the most liked/commented posts without retrieving all of them. This is because you can't actually dynamically add a new column with the number of likes/comments like you would in a standard SQL query (using JOIN and GROUP BY).
You can't update more than one object within one transaction, so there is the possibility that a user could add a comment but the number of comments in the post object would not change.
That being said I think (at least if you insist on using parse) you must add the 'noOfLikes' and 'noOfComments' columns to the Post object. Not only does it provide the only viable solution for retrieving N top posts (without getting all of them), but the actual risk of inconsistencies is pretty low in my opinion. You can always catch network (or other) exceptions and temporarely store the update requests locally and retry them later.