Hacker News Reader

Comment by bennyg | Hacker News Reader

HNKit isn't in ARC, and does a myriad of things that I think are unnecessary and can be maintained cleaner (there's absolutely no documentation!!!). Those methods are actually very quick (imperceptibly fast) right now - but I'm not a computer scientist by any means, so I believe they can be made even faster by someone that knows a better data structure to use. Each comment comes back out of order with a parent ID and a comment ID. A comment that is a reply to Comment 1 will have the parent ID matching Comment 1's comment ID (hence my linked list structure right now). There's got to be a better way, and that's also why I open sourced the whole thing.

HNKit is also doing XML parsing over everything, and string comparisons can be fairly slow as well. That, in conjunction with not being ARC ready and a total lack of documentation made me choose something else entirely.

View on HN

Hey, I wrote HNKit.

I'll admit I haven't had time to write documentation. However, most everything follows Cocoa conventions, and the headers should be pretty readable. Absolute worst case, there's an existing app using the framework as an example. :)

You can also combine ARC and non-ARC code in one project. HNKit was written before ARC (although I still prefer manual memory management), but there's nothing keeping you from using HNKit with an ARC-based app. And unless you're modifying HNKit itself, you wouldn't ever need to see or write any retain or release calls as a client of the API. Apple did a pretty good job making ARC and non-ARC code interoperate well.

I'm happy to help with any HNKit questions — feel free to open issues on GitHub if there's anything confusing. HNKit already supports most of the things you are hoping to implement (logging in, commenting, voting), so I would hate to have all that effort duplicated. If you have any specifics about things that could be done better, I'm all ears.

Performance-wise, HNKit hasn't been optimized, but it does do parsing on a background thread. In general, a bit of extra local parsing is almost always going to be faster than additional network fetches. I haven't had any performance issues, even on older devices, so I doubt that part will be an issue at all.

Hey Xuzz,

Didn't mean for that to come off rude if it read that way. I haven't dug too far deep into HNKit - I was really just worried about the interplay of ARC and nonARC code and what that meant for the future of maintainability of my own codebase (really for things that go multiple classes deep, I didn't want to introduce retain cycles and the like).

I'm considering creating a branch of this with HNKit and starting to build that in to see how it plays with everything I have now.

You can integrate non-ARC code into an iOS app pretty easily: http://stackoverflow.com/questions/8958761/how-to-remove-arc...

Reply on news.ycombinator.com