I’ve been able to work a little bit on my beloved side project, Stream. For those not following along, or those that have forgotten, Stream is my Twitter-like News Reader.
Life changed pretty dramatically for is over the past nine months or so. Our daughter, grand daughter, and son-in-law moved to the east coast. Kim and I had a two year plan in place to move back east so we could be near them, living in California doesn’t make for easy day trips to visit when we want. That is another story all together. Suffice it to say serendipity struck and we moved the timeline up, way up.
We arrived in Virginia November, 1 and moved into our new home. Yes, it was extremely fast. All the work surrounding the move meant I really needed to focus on all things related to the move and let the side project sit. Now that we’re settled in our home and I’m settled in at work I finally got Stream out of moth balls and worked on it a bit.
Crashing Sucks
I had sent out a few TestFlight builds to folks but I knew where the ugly parts of the code were. I pushed it out way too soon, I realized that after a couple builds. I should have finished all features before user testing became a thing. Live and learn.
I found two things that bugged me more than anything else; the app would crash on occasion and syncing feeds was way too slow.
A couple weekends back I was able to plant myself on the couch and work through the performance issue and the crasher. I can thank Brent Simmons for the most significant performance wins. His blog posts, tweets, and Slack messages about feed reading and general Cocoa Framework oddities have proven invaluable. I only hope I can pay his kindness forward at some point. Thanks, Brent.
Ok, on with the wins. The first two tips I picked up.
Handle 304 HTTP responses
This one was an instant performance boost if servers hosting feeds actually return it. If you’re making 100 network requests to update your 100 feeds it can be kind of slow to parse all the resulting data. But what it you don’t need to parse the results? Right! The data you don’t have to parse makes your code faster. Imagine that!
Create a hash of the response data
So, what if you ask for feed data and it hasn’t changed but the server doesn’t return a 304 indicating it hasn’t changed? Well, you create a hash of the response data and keep it for later. Next time you grab the feed, hash it and compare it to the hash you created last time.
One more thing
After reading Brent’s piece about KVO crashes I decided to stop using NSOperation and NSOperationQueue. I was only using it so I could create dependencies that would allow me to have a final operation that updated the UI’s data source. Now I don’t do that. I just rely on URLSession and URLRequest to do the job.
Not done
I feel a lot better about the performance but I know there will be more changes down the road. Moving forward I need to focus my effort on finishing the UI and adding some niceties like a share extension to add a feed and things like dark mode support. There are other things I’d like to do as well. Least of which is building a Stream Mac App. 😀
I’ve adjusted my personal expectations to ship before WWDC this year. Let’s see if I can make it.