diff --git a/P15-Decorating-Post-Cell/working_connections.sketch b/P15-Decorating-Post-Cell/working_connections.sketch new file mode 100644 index 0000000..67599f0 Binary files /dev/null and b/P15-Decorating-Post-Cell/working_connections.sketch differ diff --git a/P16-Implementing-Likes/content.md b/P16-Implementing-Likes/content.md index 670b9f4..0e74471 100755 --- a/P16-Implementing-Likes/content.md +++ b/P16-Implementing-Likes/content.md @@ -43,3 +43,83 @@ Firstly, typos can cause bugs that are difficult to debug. The compiler won't ve Secondly, if we use those strings in multiple places, we need to remember to update every occurrence of them if something in our Parse backend changes. Instead of using plain strings it would be much better to use constants! +Let's add constants for all the different Parse classes and fields we are going to access! Since this isn't too exciting of an exercise, I'll provide you with the full list of constants that we need. + +
+Add the following constants to the `ParseHelper` class: + + class ParseHelper { + + // Following Relation + static let ParseFollowClass = "Follow" + static let ParseFollowFromUser = "fromUser" + static let ParseFollowToUser = "toUser" + + // Like Relation + static let ParseLikeClass = "Like" + static let ParseLikeToPost = "toPost" + static let ParseLikeFromUser = "fromUser" + + // Post Relation + static let ParsePostUser = "user" + static let ParsePostCreatedAt = "createdAt" + + // Flagged Content Relation + static let ParseFlaggedContentClass = "FlaggedContent" + static let ParseFlaggedContentFromUser = "fromUser" + static let ParseFlaggedContentToPost = "toPost" + + // User Relation + static let ParseUserUsername = "username" + + // ... + +This approach has a third advantage that we did not discuss yet: all of the fields are now unambiguous. Before this change we could have used _"toPost"_ to refer to either the _toPost_ column in the _FlaggedContent_ class, or to the _toPost_ column in the _Like_ class. Through giving all of these constants a name, we have removed this ambiguity. + +Note that the constant names follow this pattern: _Parse[ClassName][FieldName]_. Consistent naming is important to make your life as a developer easier! + +With these constants in place, we can now update our timeline query to use them. + +
+Change the timeline query to use constants instead of string literals: + + static func timelineRequestforCurrentUser(completionBlock: PFArrayResultBlock) { + let followingQuery = PFQuery(className: ParseFollowClass) + followingQuery.whereKey(ParseLikeFromUser, equalTo:PFUser.currentUser()!) + + let postsFromFollowedUsers = Post.query() + postsFromFollowedUsers!.whereKey(ParsePostUser, matchesKey: ParseFollowToUser, inQuery: followingQuery) + + let postsFromThisUser = Post.query() + postsFromThisUser!.whereKey(ParsePostUser, equalTo: PFUser.currentUser()!) + + let query = PFQuery.orQueryWithSubqueries([postsFromFollowedUsers!, postsFromThisUser!]) + query.includeKey(ParsePostUser) + query.orderByDescending(ParsePostCreatedAt) + + query.findObjectsInBackgroundWithBlock(completionBlock) + } + +Same, same but nicer! Now we have a solid foundation to add more queries! + +#Adding Parse queries for likes + +There are three types of things our app needs to with likes: + +1. Create a like, when a user likes a post +2. Delete a like, when a user unlikes a post +3. Fetch all likes for a given post + +These three requirements translate directly into three different queries that we're going to +add to our `ParseHelper`. + +Just as a refresher, here's how we are modeling likes in `Makestagram`: + +![image](likes_model.png) + +It's a pretty simple model, that only stores a reference to the user that performed the like and the post that has been liked (ignoring all of the fields that Parse provides automatically). + + + + +##Creating Likes diff --git a/P16-Implementing-Likes/likes_model.png b/P16-Implementing-Likes/likes_model.png new file mode 100644 index 0000000..ba4118d Binary files /dev/null and b/P16-Implementing-Likes/likes_model.png differ