Creating a Facebook Clone - Part XX - Transcript.pdf

Creating a Facebook Clone - Part XX
Notification is the last client data class that maps to an entity. In that sense it will get more interesting after this point…

@Entity
public class Notification {
@Id
private String id;
@ManyToOne
private User user;
private String text;
private String reaction;
private int reactionColor;
private long date;
private boolean wasRead;
private String postId;
private String commentId;
public Notification() {
id = UUID.randomUUID().toString();
}
public NotificationDAO getDAO() {
return new NotificationDAO(id, user.getDAO(), text, reaction,
reactionColor, date, wasRead, postId, commentId);
Notification
The class is pretty standard

Again these map directly to the client side data

@Entity
public class Notification {
@Id
private String id;
@ManyToOne
private User user;
private long date;
}
Notification
A notification might relate to a post or a comment so having its id here might be useful to launch said post when the notification is clicked

private long date;
}
}
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public User getUser() {
return user;
}
public void setUser(User user) {
this.user = user;
}
Notification
The constructor and DAO match the convention of the other classes

public long getDate() {
return date;
}
public void setDate(long date) {
this.date = date;
}
public boolean isWasRead() {
return wasRead;
}
public void setWasRead(boolean wasRead) {
this.wasRead = wasRead;
}
public String getPostId() {
return postId;
}
public void setPostId(String postId) {
this.postId = postId;
}
public String getCommentId() {
return commentId;
}
public void setCommentId(String commentId) {
this.commentId = commentId;
}
}
Notification
The rest is again getters & setters

public class NotificationDAO {
private String id;
private UserDAO user;
private long date;
public NotificationDAO() {
}
public NotificationDAO(String id, UserDAO user, String text,
String reaction, int reactionColor, long date, boolean wasRead,
String postId, String commentId) {
this.id = id;
this.user = user;
this.text = text;
this.reaction = reaction;
NotificationDAO
The next step is the DAO which again maps very closely.

There is literally nothing special here, we might as well have used the Notification entity to some degree.

return date;
}
public void setDate(long date) {
this.date = date;
}
public boolean isWasRead() {
return wasRead;
}
public void setWasRead(boolean wasRead) {
this.wasRead = wasRead;
}
public String getPostId() {
return postId;
}
public void setPostId(String postId) {
this.postId = postId;
}
public String getCommentId() {
return commentId;
}
public void setCommentId(String commentId) {
this.commentId = commentId;
}
}
NotificationDAO
As you can see the rest of the code is classic boilerplate

Newsfeed
✦Why Newsfeed Entity?
✦Consistency
✦Tune Experience
© Codename One 2017 all rights reserved
This is getting a bit more interesting... Newsfeed represents the feed for a user. I could have just created a really complex join query on Post and called it a day but that's
problematic. The newsfeed isn't just a list of posts based on date. It's something that includes a complex algorithm behind it. Running that algorithm every time the user
pages through data might be very expensive.

Furthermore, changes to the algorithm shouldn't impact past placements. We'd want consistency and we'd also like to have a log of "what did the user see". In that
sense constructing the newsfeed as an entity in its own right makes a lot of sense.

We can place the articles into the newsfeed using a sort order that makes sense for a specific user without impacting everyone. We can tune and experiment with article
placement algorithms easily because our processing can be done oﬄine on the table itself.

@Entity
public class Newsfeed {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private Long id;
@ManyToOne
private User parent;
@ManyToOne
private Post entry;
private long postDay;
private long postTimestamp;
private int rank;
public Newsfeed() {
}
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
Newsfeed
This is getting a bit more interesting... Newsfeed represents the feed for a user. I could have just created a really complex join query on Post and called it a day but that's
problematic. The newsfeed isn't just a list of posts based on date. It's something that includes a complex algorithm behind it. Running that algorithm every time the user
pages through data might be very expensive.

Furthermore, changes to the algorithm shouldn't impact past placements. We'd want consistency and we'd also like to have a log of "what did the user see". In that
sense constructing the newsfeed as an entity in its own right makes a lot of sense.

We can place the articles into the newsfeed using a sort order that makes sense for a specific user without impacting everyone. We can tune and experiment with article
placement algorithms easily because our processing can be done oﬄine on the table itself.

We use an auto-increment numeric id since this object isn't exposed to the client side at any stage the id doesn't matter as much and this id type is faster

@Entity
@Id
private Long id;
@ManyToOne
@ManyToOne
private Post entry;
private int rank;
public Newsfeed() {
}
return id;
}
this.id = id;
Newsfeed
Every entry within the newsfeed has a user & post. Notice that the user is probably a diﬀerent user from the one who submitted the post

@Entity
@Id
private Long id;
@ManyToOne
@ManyToOne
private Post entry;
private int rank;
public Newsfeed() {
}
return id;
}
this.id = id;
Newsfeed
postDay is the number of days since epoch. This is useful for sorting, I want todays posts to always come before yesterdays posts even if they are higher quality

@Entity
@Id
private Long id;
@ManyToOne
@ManyToOne
private Post entry;
private int rank;
public Newsfeed() {
}
return id;
}
this.id = id;
Newsfeed
Timestamp is also used for the sort but to a lesser degree

@Entity
@Id
private Long id;
@ManyToOne
@ManyToOne
private Post entry;
private int rank;
public Newsfeed() {
}
return id;
}
this.id = id;
Newsfeed
Rank can be manipulated by a ranking algorithm to push good posts up within the day

@ManyToOne
private Post entry;
private int rank;
public Newsfeed() {
}
return id;
}
this.id = id;
}
public User getParent() {
return parent;
}
public void setParent(User parent) {
this.parent = parent;
}
public Post getEntry() {
return entry;
}
Newsfeed
We have no DAO. We don't need it, this is a server side object

return entry;
}
public void setEntry(Post entry) {
this.entry = entry;
}
public int getRank() {
return rank;
}
public void setRank(int rank) {
this.rank = rank;
}
public long getPostDay() {
return postDay;
}
public void setPostDay(long postDay) {
this.postDay = postDay;
}
public long getPostTimestamp() {
return postTimestamp;
}
public void setPostTimestamp(long postTimestamp) {
this.postTimestamp = postTimestamp;
}
}
Newsfeed
We do need the getters/setters though for the entity

public interface NewsfeedRepository extends CrudRepository<Newsfeed, Long>{
@Query("select n from Newsfeed n where n.parent.authtoken = ?1")
public Page<Newsfeed> findNewsfeedForUser(
String auth, Pageable page);
}
NewsfeedRepository
The Newsfeed also requires a CrudRepository class. We need to use the auth and not the ID to prevent a case where another user gets a peek at my feed which might
include "friend only" posts

With that we only have one more item...

@Entity
public class ShadowUser {
@Id
private Long id;
private String fullName;
private String phone;
private String email;
private String secondaryPhone;
@ManyToOne
private User owner;
public ShadowUser() {
}
public ShadowUser(ShadowUserDAO dao, User owner) {
this.fullName = dao.getFullName();
this.phone = dao.getPhone();
this.email = dao.getEmail();
this.secondaryPhone = dao.getSecondaryPhone();
ShadowUser
The shadow user is a "potential" user of whom we have knowledge but he might not be in the social network.

Do you ever wonder how Facebook seems to know so much about you before you even signed up? They keep suggesting people that they can't possibly know about...

Well, here's one of the tricks they use. When you agree to synchronize your contacts to Facebook (and they nag a lot about this) they upload the whole thing and store it.
If you have friends that are already in Facebook you'll get suggestions instantly but they keep everything anyway.

When one of your contacts signs up for Facebook they notice that you know and instantly add a suggestion. This works in reverse too, someone has your email or phone
number so you'd see them as a suggestion.

They go even further by associations e.g. you might have a connection like that through a 3rd party so even if you never synchronized contacts they'd still know.

I chose to implement a relatively simple version of this and didn't include all the meta-data that Facebook probably stores. This is mostly a simple proof of concept that
should be enough for us to provide friend suggestions.

We again use auto-increment for an internal entity

@Entity
@Id
private Long id;
@ManyToOne
private User owner;
}
ShadowUser
This is the meta-data we gather for a user, there is obviously a lot more we can gather

@Entity
@Id
private Long id;
@ManyToOne
private User owner;
}
ShadowUser
This is the user who uploaded the data so if the data in this record matches me then I probably know the owner

@Id
private Long id;
@ManyToOne
private User owner;
}
this.owner = owner;
}
return id;
}
this.id = id;
ShadowUser
We have a DAO object but this DAO is write only. So the entity isn't exposed to the outside world but the outside world is exposed to the entity. That’s why we don’t have
a getDAO method!

We do have a special constructor type that makes adding a new ShadowUser easier.

public String getPhone() {
return phone;
}
public void setPhone(String phone) {
this.phone = phone;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public String getSecondaryPhone() {
return secondaryPhone;
}
public void setSecondaryPhone(String secondaryPhone) {
this.secondaryPhone = secondaryPhone;
}
public User getOwner() {
return owner;
}
public void setOwner(User owner) {
this.owner = owner;
}
}
ShadowUser
As with the other entities the rest is just setters & getters.

public class ShadowUserDAO {
public ShadowUserDAO() {
}
public String getFullName() {
return fullName;
}
public void setFullName(String fullName) {
this.fullName = fullName;
}
return phone;
}
this.phone = phone;
}
return email;
ShadowUserDAO
In a sense the ShadowUserDAO is a bit diﬀerent from the other DAO’s.

This is a pretty standard DAO with two big omissions: ID & Owner both of which are missing… 
The ID is redundant as it's auto generated, the owner is also redundant as it's always the user that uploaded the contacts. There is no point of including either one of
these values in the DAO as they won't arrive through it from the client.

return fullName;
}
public void setFullName(String fullName) {
this.fullName = fullName;
}
return phone;
}
this.phone = phone;
}
return email;
}
public void setEmail(String email) {
this.email = email;
}
public String getSecondaryPhone() {
return secondaryPhone;
}
public void setSecondaryPhone(String secondaryPhone) {
this.secondaryPhone = secondaryPhone;
}
}
ShadowUserDAO
The rest of the DAO is just getters and setters

public interface ShadowUserRepository extends
CrudRepository<ShadowUser, Long> {
@Query("select n from ShadowUser n where n.owner.authtoken = ?1")
public List<ShadowUser> findShadowUsers(String auth);
@Query("select n from ShadowUser n where n.phone = ?1 or "
+ "n.secondaryPhone = ?1")
public List<ShadowUser> findByPhone(String phone);
@Query("select n from ShadowUser n where n.email = ?1")
public List<ShadowUser> findByEmail(String email);
@Query("select count(n) from ShadowUser n where "
+ "n.owner.authtoken = ?1")
public Long countByUser(String auth);
@Query("select n from ShadowUser n where n.owner.authtoken = ?1 and "
+ "n.fullName = ?2")
public List<ShadowUser> findByFullName(String auth, String fullName);
}
ShadowUserRepository
In this case the CrudRepository is actually pretty interesting. We need it for the case where we create a new user or update data. We need to find all the related users.

Given a users phone we look through the database for users who might have that phone in their contacts, the same is true for email

}
We check if a user has uploaded contacts in the past by counting his entries, assuming he has we will try to merge the data

}
We use the full name of the user when merging contact data.

With that we finished all the entities and we are finally ready to move up the food chain to the service layer!

Creating a Facebook Clone - Part XX - Transcript.pdf

Recommended

Recommended

More Related Content

Similar to Creating a Facebook Clone - Part XX - Transcript.pdf

Similar to Creating a Facebook Clone - Part XX - Transcript.pdf (20)

More from ShaiAlmog1

More from ShaiAlmog1 (20)

Recently uploaded

Recently uploaded (20)

Creating a Facebook Clone - Part XX - Transcript.pdf