SY: Building Streams, Part 1

SportsYapper is a social media app, and as a social media app, it’s focused on conversation between users. Every social media app has its own form of a post; Twitter calls them tweets, Facebook calls them comments, and we call them Yapps. When a user posts a Yapp, they do it with some context; we have a “topic” associated with each Yapp that corresponds to a team, sport, or some type of general interest group. This allows us to keep conversation about a certain team all together. Internally, we call these Yapps grouped by topic “streams”.

Recently we made the decision to refactor how we handle these streams within the app. Obviously, it’s the most fundamental piece of the app, and after 2+ years of work and changes, we’re at a place where we need to realign the code with our current way of thinking about how they should work. So here we are. In the tradition of Brent Simmons’s “Vesper Sync Diary” and “Underscore” David Smith’s “As I Learn WatchKit” posts, I’m going to use these posts to help me flesh out my ideas for how this is all going to work. I hope something interesting comes from them, but I guess we won’t really know until the end. If you did find something interesting or useful here, I’d love to hear from you.

My normal procedure for something like this is to break out Evernote and start typing bullet points. I like to capture as many of my thoughts as I can. Coming from that, I’ve got a basic structure:

The YappService will communicate with our API and bring in Yapps in one of two ways; the first will be via a REST API call that will return the 30 most recent Yapps in a given topic (polling service). The other will be a persistent connection that will return Yapp data in JSON format as they are posted (streaming service). Both of these services are already in use. When new Yapps are brought in via one of these services, the Yapps will be cached locally, and some type of notification will be sent to the UI layer of the app, which will communicate with the YappService to get the appropriate Yapps to show.

Sensible enough, I think. My first goal is going to be to build the data side of the YappService. There’s two major questions I am considering, and I don’t have a great answer for either.

Question 1: How am I going to store these Yapps? They come through as JSON and are converted to native objects easily, but then what? I’m wary of using Core Data for something this small, but it might be the exact right answer. I can write them out to the caches directory, but will that impact performance? How will I handle sorting and filtering, should I do that as I’m getting them from API, or should I handle that as a UI layer issue?

Question 2: How will I notify the UI that it has new Yapps to show? Throw an NSNotification? Assign the relevant view controller as a delegate to the YappService object? Either of those has the potential to get really ugly really fast if I’m not super careful. Is there some other paradigm that makes sense here that I’m not considering?

Hopefully part 2 will answer these questions. In the meantime, I’m going to start building the YappService in a separate project and will move it into my main SportsYapper project once it’s ready.