Now we have a postType field in Post, which represents whether it's a post from .feed, .history, or .liked. That way, it's more intuitive in how we compare posts (same posts have to have the same type).
Posts from .liked don't have postIDs, so Post equality will take into account whether it is a .liked post. If it is, then we compare the song and the user.
Otherwise, for all other types, we just compare the postID, and make sure they have the same types.
Also fixes crashes that occur when a song finishes playing. That was happening because I was force unwrapping newCell in the currentlyPlayingIndexPath didSet block, which will crash when the currentlyPlayingIndexPath changes due to a song finishing, and the cell is off-screen, and thus doesn't exist. Now, I simply make that an optional, so that playerNav.postView will just be nil in that case. If the cell is ever scrolled into view, the transplantPlayerAndPostViewIfNeeded function will update playerNav.postView.
…ious refactoring
Now we have a postType field in Post, which represents whether it's a post from .feed, .history, or .liked. That way, it's more intuitive in how we compare posts (same posts have to have the same type).
Posts from .liked don't have postIDs, so Post equality will take into account whether it is a .liked post. If it is, then we compare the song and the user. Otherwise, for all other types, we just compare the postID, and make sure they have the same types.
Also fixes crashes that occur when a song finishes playing. That was happening because I was force unwrapping
newCellin thecurrentlyPlayingIndexPathdidSet block, which will crash when the currentlyPlayingIndexPath changes due to a song finishing, and the cell is off-screen, and thus doesn't exist. Now, I simply make that an optional, so that playerNav.postView will just be nil in that case. If the cell is ever scrolled into view, thetransplantPlayerAndPostViewIfNeededfunction will update playerNav.postView.